On Mar 3, 2008, at 2:30 AM, Hamish wrote:
Martin Landa wrote:
it would be good to use d.measure or something like g.measure in
wxGUI too instead of using Python-based function for distance
calculation (at least it would make sense for LL projections)?
Hamish wrote:
Yes, we should use existing library functions whenever possible, in
this case those found in lib/gis/distance.c and lib/gis/geodist.c.
call it m.distance;
...
It would be very easy to write in C but from a learning exercise
perspective it seems like a perfect thing to try doing with
SWIG+Python, and perhaps too simple a thing to have as a generic
module??
Python-SWIG m.distance (working) prototype:
http://grass.gdf-hannover.de/wiki/PythonSwigExamples
Starting from the shell it takes about 0.5 sec to run. ie very slow.
But that includes the overhead of starting #!/usr/bin/python and
importing the required modules. If the same code was called from an
already running python session with all that stuff already loaded, I
expect it would be highly fast. (FWIW unstripped libgis.so is ~900kb,
_python_grass6.so ~1.7mb)
G_area_of_polygon() needs x and y vertices passed to it as memory
address pointers to two double-FP arrays. I really don't know much
about SWIG but a web search turned up a Python module called NumPtr
(Numeric Pointer) for doing that. It seems pretty simple. Instructions
for it are on the wiki link above.
If there isn't already a built-in easier way that I missed, perhaps we
could add that code as a contrib in our swig/python/ dir? It is GPL2,
less than 100kb, and several years without a new version. Hopefully
the
lack of upstream activity means that it is mature, and not abandoned.
It is a simple enough thing that it wouldn't surprise me if it was
mature. And because it is so simple and small it seems more trouble
than it would be worth to insist that it be an external dependency, or
a be a significant burden to maintain.
To build the SWIG-Python interface I had to hack the Makefile a
little.
I also had to install the "swig" package on my machine to get
/usr/bin/swig, as compiling failed when it couldn't find it. Maybe add
a check for that program in the main './configure --with-python'? (for
one thing it would give --with-python something useful to do which
currently AFAIK it doesn't?)
# the Makefile problem:
cd swig/python/
make
In file included from
[...]/grass63/dist.i686-pc-linux-gnu/include/grass/vect/digit.h:3,
from
[...]/grass63/dist.i686-pc-linux-gnu/include/grass/Vect.h:4,
from python_grass6_wrap.c:2933:
[...]/grass63/dist.i686-pc-linux-gnu/include/grass/vect/
dig_structs.h:22:21:
error: ogr_api.h: No such file or directory
....
local solution:
edit swig/python/Makefile and add -I/usr/include/gdal to CFLAGS.
not sure what the correct fix in swig/python/Makefile.in for that
would
be or if the error is really in the vector includes.
Should 'make clean' remove the Makefile or should that only happen
with
'make distclean'?
see also my notes on an earlier attempt at building swig/python/:
http://thread.gmane.org/gmane.comp.gis.grass.devel/20751
Hamish
Hamish,
Thanks for checking on this. I'll look at your example to see how it
is done. In fact, we don't even need to create an independent module.
The discussion was over how to implement measurement (and I suppose
bearing if it's also supported) in the GUI, and Martin's point was
'why do these calculations in Python when the GRASS libraries can do
them?' We should simply be able to incorporate the SWIG calls to the
library in the wxPython GUI module. It already can grab xy points.
For a stand alone module--i.e., to be used in non-GUI circumstances
too--your Python script could be an example of how to begin to replace
bash with Python programming. SWIG would give us more options than we
now have with bash.
Michael
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
