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

Hamish hamish_b at yahoo.com
Mon Mar 3 04:30:51 EST 2008


> 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 




More information about the grass-dev mailing list