Hi,
does anyone can make the point about Grass/Python SWIG interface development? I’ve seen in May the last changes on SVN made by Markus Neteler. Is the interface somehow ready to be used? Is there a roadmap in the development?
Thanks,
Giovanni
G. Allegri wrote:
does anyone can make the point about Grass/Python SWIG interface
development? I've seen in May the last changes on SVN made by Markus
Neteler. Is the interface somehow ready to be used? Is there a roadmap in
the development?
Yes, it works, at a prototype stage. ie it may be rough around the edges
but basically works - it's at a stage where it needs testers & feedback
reports.
see
http://grass.gdf-hannover.de/wiki/GRASS_and_Python#Python-SWIG-GRASS_interface
http://mpa.itc.it/markus/grass63progman/swig/
http://thread.gmane.org/gmane.comp.gis.grass.devel/20751
src/swig/python/README
src/swig/python/TODO
src/swig/python/test.py
src/swig/python/rasteraccess.py
src/swig/python/vectoraccess.py
the subject of your email ("What's the point"?) touches on the reason I
personally haven't worked on python/swig further than getting it running-
even though I'd like to learn more python. To date I haven't been able to
think of a time when I'd want to use it over writing a module directly in
C or scripting compiled modules in python without SWIG (as a replacement
for bash scripting). The low level grass modules give you a lot of
control, so direct access to the C libgis functions isn't all that
critical.
good luck,
Hamish
Thanks Hamish.
My desire was to make some benchmarking between different solutions…
I know Grass C low level modules do a lot of work, but as I’m not an experienced C programmer, I would prefer to do the same job (beyond scripting) with Python.
A good reason, to me, to consider a SWIG solution is the possibility to make direct use of the huge quantity of Python packages available (as NumPy, wxPython, etc.), without loosing low level access to the Grass API.
As you said, without the SWIG API, the most I can do is making system calls (“os.popen”) to run Grass bash commands, with an unacceptable slowness and the obvious limitations it puts.
I think that the only solution is to start learning SWIG interface development by myself 
Giovanni
2007/8/27, Hamish <hamish_nospam@yahoo.com>:
G. Allegri wrote:
does anyone can make the point about Grass/Python SWIG interface
development? I’ve seen in May the last changes on SVN made by Markus
Neteler. Is the interface somehow ready to be used? Is there a roadmap in
the development?Yes, it works, at a prototype stage. ie it may be rough around the edges
but basically works - it’s at a stage where it needs testers & feedback
reports.see
http://grass.gdf-hannover.de/wiki/GRASS_and_Python#Python-SWIG-GRASS_interface
http://mpa.itc.it/markus/grass63progman/swig/
http://thread.gmane.org/gmane.comp.gis.grass.devel/20751
src/swig/python/README
src/swig/python/TODO
src/swig/python/test.py
src/swig/python/rasteraccess.py
src/swig/python/vectoraccess.pythe subject of your email (“What’s the point”?) touches on the reason I
personally haven’t worked on python/swig further than getting it running-
even though I’d like to learn more python. To date I haven’t been able to
think of a time when I’d want to use it over writing a module directly in
C or scripting compiled modules in python without SWIG (as a replacement
for bash scripting). The low level grass modules give you a lot of
control, so direct access to the C libgis functions isn’t all that
critical.good luck,
Hamish
G. Allegri wrote:
As you said, without the SWIG API, the most I can do is making system calls
("os.popen") to run Grass bash commands, with an unacceptable slowness and
the obvious limitations it puts.
Sure it's more overhead, and a pain to pass data back and forth, but does
running as system calls from Python really make it run any slower or
impose any hard limitations?
curious; I know little about Python,
Hamish
The limitations are due to the use of Grass shell commands. I would
like to have access to the C API. An use case (that is what I would
like to try) could be the coupling of NumPy with Grass.
Giovanni
2007/8/28, Hamish <hamish_nospam@yahoo.com>:
G. Allegri wrote:
> As you said, without the SWIG API, the most I can do is making system calls
> ("os.popen") to run Grass bash commands, with an unacceptable slowness and
> the obvious limitations it puts.Sure it's more overhead, and a pain to pass data back and forth, but does
running as system calls from Python really make it run any slower or
impose any hard limitations?curious; I know little about Python,
Hamish