[GRASS-dev] pygrass vs grass python scripting library

[Paulo van Breugel]

Hi Pietro, Thanks for the explanation!



On 22-07-14 15:05, Pietro wrote:
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140723/45328af9/attachment.html>