> 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 ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
