[GRASS-dev] pygrass vs grass python scripting library

[Pietro]

Hi Paulo,

On Tue, Jul 22, 2014 at 8:55 AM, Paulo van Breugel
<p.vanbreugel at gmail.com> wrote:
> I am trying to familiarize myself a bit with python scripting in GRASS. I am
> a bit confused about the different approaches that seem possible. More
> specifically, there is the pygrass
> (http://grasswiki.osgeo.org/wiki/Python/pygrass) and grass python scripting
> library (
> http://grasswiki.osgeo.org/wiki/GRASS_Python_Scripting_Library). Is there
> somewhere a concise description explaining the difference between the two.

I tried to explain the different approach in the following article:

Zambelli, P., Gebbert, S., Ciolli, M., 2013. Pygrass: An Object
Oriented Python Application Programming Interface (API) for Geographic
Resources Analysis Support System (GRASS) Geographic Information
System (GIS). ISPRS International Journal of Geo-Information 2,
201–219.
http://dx.doi.org/10.3390/ijgi2010201
http://www.mdpi.com/2220-9964/2/1/201/pdf


> And for writing python scripts (addons), which of these two are a better
> option to use (for somebody fairly familiar with GRASS, with some experience
> in writing shell or R scripts for GRASS, but with no experience at all with
> python).

pygrass has been written to be as much pythonic as possible, therefore
for people knowing python should be easier to work with pygrass.
In general I think that the grass.script API is more tested and stable
and more important it is working for both GRASS6 and GRASS7.

pygrass.Module has been devloped to interact with a module as an
object, setting the module parameters, check if the parameters are
valid or not, and execute the module. The Module class has been used
to apply a GRASS module over the current region, splitting the region
in several tiles, create a mapset for each tile, execute the module
and then patch the results and remove the temporary mapset
(GridModule), or in ParallelModuleQueue to handle a queue of modules.

If combine with shortcuts can Improve the python syntax:

from:

run_command("r.slope.aspect", elevation="elevation", slope="slope",
overwrite=True)

to:

r.slope_aspect(elevation="elevation", slope="slope", overwrite=True)

that is closer to the BASH syntax.

But what is particularly interesting of pygrass is the ability to use
and call the C API of GRASS through the ctypes , all the functions in
the grass.script modules are calling and parsing the results of some
GRASS modules.

With pygrass we are using directly the C API of GRASS, like for
example you can write a function that work row by row or pixel by
pixel to do some analysis on a raster map, or line by line in a vector
map, and user don't have to know C or the C API of GRASS.

I hope that the difference is clearer now, otherwise please ask me! :-)

Pietro