[ZOO-Discuss] Python script to call grass 7 modules as service

[Gérald Fenoy]

Hi Soeren,
always nice to hear from you.

Le 3 janv. 2010 à 15:17, Soeren Gebbert a écrit :

> Dear developers,
> JFYI:
> I have implemented a Python script which allows to call grass 7
> modules as a service (e.g.: from a WPS server).
> This script works currently only with grass raster modules. Vector
> modules are work in progress. The processing is based
> on grass version 7.

Ok sounds promising.

> The clue is that the user provides the name of the module, some
> parameters and the input data as png or geotiff files and receives
> geotiff or gml files as output.

Great, in fact the ZOO Kernel use the same things in his heart. GRASS would only become a module of ZOO Server, in other words a Service Provider. The difference is that the name of the module is the Identifier in Execute Request, it won't point directly on GRASS module but on a function defined in a ZSP GRASS Based, DataInputs wasn't extracted from a file but also from the request, as for output, including mimeType and so on (this way user can dinamicaly change parameter without writing any file). By the way, I'm pretty sure you know that well.

Nevertheless, we can easily imagine a generic way to load and run module, a similar way you used in your script, for the ZSP GRASS Based pacesses. This can became a function which permit to load and run a specific grass module.  Currently, ZOO Kernel only support to call function defined in such an ZSP, but this ZSP can then call others functions defined in linked shared libraries (against the ZSP).

At the begining, I thought that if we suppose that we have to change the behavior of the ZOO Kernel internal mechanisms only for GRASS then we missed something somewhere. Indeed, from my point of view, ZOO Kernel use a generic way to dynamicaly load then run functions from a ZSP (coded in many languages), dealing with error on loading process and/or running process.  

Nevetheless, for each supported languages, we handle loading/running in a different way, only input parsing and output restitution was shared betwin languages. I think that, in some sens, we can view GRASS support in the ZOO Kernel as a language support.  

If we view GRASS as a new languages we can then easily implement stuff like you did in your script, doing specific stuff before running (automatic environment variables setting is available), run then doing specific stuff after running. 

It's similar to what we do in various language support.

> All the location/mapset creation as well as the import and export is
> done automatically by the script. The coordinate system of the
> first input file is used to create the grass work location.

Great, this can be used as a generic starting point for each GRASS processes which would be included in the work on  ZOO SP GRASS based. This can became a function in the ZOO API GRASS specific to help development of new processes.

> Next features is, that all the input files are linked via r.external into
> the grass work location. No explicit import is needed. Currently the output is
> exported via r.out.gdal and v.out.ogr,
> but r.external.out will be used in the future, so that raster data
> will be processed via gdla access without import or export (thanks to
> Glynn and Frank!).

Cool, we will need this special gdal trick to remove import/export mechnism. 
Frank, if needed, can you help us on this specific requirement when it will be time ?

> The Python script (some parts are based on pyWPS from Jachym Cepicky):
> http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/WPS/GrassModuleStarter.py
> 

Thanks for this link.

> Example input files:
> http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/WPS/Testing/Python/r.contour_input.txt
> http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/WPS/Testing/Python/r.watershed_input.txt
> 
> I hope this script will simplify the use of grass as WPS server back-end.
> 

Sure it will :)

> The script is still under development and provides only basic features.
> Better error and message handling is needed, as well as vector support
> and testing.
> 

ZOO Kernel handles errors in ZSP Python based to return an ExceptionReport as expected. 

> Any comments, suggestions, criticism are welcome. :)

We really apriciate your support to the ZOO Project.

> Have fun

Hope we will have :)

Best regards,

Djay
Just a ZOO Monkey
gerald.fenoy at geolabs.fr