[GRASS-dev] WPS XML process description added to lib/gis/parser.c

[Soeren Gebbert]

Hello,
i while ago i discussed with markus how to support a better
integration of grass in WPS server.
He suggested that it would be the best to add WPS XML process
description generation directly into grass.
So here we are.  :)
I have added the generation of WPS process description XML documents
to lib/gis/parser.c in grass7 .

If a module is started with the parameter "--wps-process-description"
the process description XML document is
written to stdout and the module will exit.

Currently only raster and vector modules are supported, but the
generation works with any module (more or less meaningful).
Most of the input options are catched:
* single and multiple raster and vector maps
* single and multiple string, float and integer data with default
values and value options (range is missing)
Flags are supported as boolean values.

The mime types for vector maps are GML 3.1 and grass ascii and binary vectors.
mime type: application/grass-vector-ascii  -> a text file generated
with v.out.asci
Example.: urn:file:///path/name
mime type: application/grass-vector-binary -> the binary vectors must
be addressed with a non standard urn:
Example: urn:grass:vector:location/mapset/name

The mime types for raster maps are tiff and png as well as grass ascii
and binary raster maps, following the same scheme as the vector maps

The mime types are reflecting the capabilities of gdal and may be extended.
The support for specific grass formats is just a crazy idea of mine. o_O

Only single maps are supported as output or plain text on stdout.
BoundignBox support is currently not available for inputs and outputs.
Literal data output (string, float or integer)  is currently not supported.

A lot of work must still be done to verify the correct generation of
WPS process descriptions,
so please do not use them right now for WPS server input. ;)
I am afraid that to fully support the WPS XML process description
generation, which is IMO very important for grass, the option, flag
and module  structures
which are used to describe the input and output parameter for each
module, must be reviewed and may be extended.

Any hints, criticism and suggestions are welcome.

Best regards
Soeren