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

[Hamish]

Michael:
> Thanks for checking on this. I'll look at your example to see how it 
> is done.

new updated demo version at the wiki site:
  http://grass.gdf-hannover.de/wiki/PythonSwigExamples

and new full version in the source code: 
  http://trac.osgeo.org/grass/browser/grass/trunk/swig/python/examples


Both versions now have fully functional g.parser support!* The full +
cleaned version in SVN has support for multi-segment input either given
from the command line coord= option or piped from stdin, and also
supports parsing DDD:MM:SS.SSSS formatted lat/lon coordinates.

Requires NumPy and NumPtr. As the NumPtr module seems very useful for
us, I will add it in SVN unless there are objections.


* having a slight issue testing for the existance of an enviro
variable, which means it can hang when reading nothing from stdin.
os.getenv() returns None if the variable doesn't exist. But g.parser
seems to create the variable anyway and set it equal to '' if it was
unset. So there is no way easy to test if(option->answer == NULL) from
the script AFAICT. sys.argv is already toast by then. (replaced after
g.parser call)

i.e. this doesn't work as expected:
opt_answer = os.getenv("GIS_OPT_COORD")
if opt_answer is not None:
   # read from command line option
else:
   # read from stdin


> In fact, we don't even need to create an independent module.

Agreed, I do not expect to move the (full) module to be an official
module, I think it's too simple for that. It is just meant to be a
fully working example, or could be used as an addon if someone needed a
multi-segment geodesic distance/area calculator.


> 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.

I suppose you could say "programming" is not banned in the GUI (e.g. wx
measurement or profile tool), but reimplementing complicated things
like great circle calculations in the GUI when well tested and faster C
versions already exist and are accessible via swig.

For general use we would have to make the decision to make swig a
mandatory dependency for the wxGUI. I think that opens more doors than
it closes, so support the idea.

> 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.

exactly.


Hamish



      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping