[GRASS-dev] Re: m.distance / SWIG-Python interface + passing pointers with SWIG [was: d.measure w/ bearing]

[Michael Barton]

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