Process profiles registry

WPS Services belonging to the same Services provider often share the same inputs and outputs. In such a case, every ZCFG file would contain the same metadata information and this may be a waste of time to write them all.

ZOO-Kernel is able to handle metadata inheritance from rev. 607, and this solves the issue of writing many ZCFG with same input and output. A registry can be loaded by the ZOO-Kernel (before any other ZCFG files) and contain a set of Process Profiles organized in hierarchic levels according to the following rules:

  • Concept: The higher level in the hierarchy. Concepts are basic text files containing an abstract description of a WPS Service (see the OGC definition for more details).

  • Generic: A Generic profile can make reference to Concepts. It defines inputs and outputs without data format or maximum size limitation (see the OGC definition for more details).

  • Implementation: An Implementation profile can inherit from a generic profile and make reference to concepts (see the OGC definition for more details). It contains all the metadata information about a particular WPS Service (see ZCFG reference for more information).

Both Generic and Implementation process profiles are created from ZCFG files and stored in the registry sub-directories according to their level (Concept, Generic or Implementation).

To activate the registry, you have to add a registry key to the [main] section of your main.cfg file, and set its value to the directory path used to store the profile ZCFG files. Please see Setup registry browser for more details about the other services and parameters required.

Note

Even if the profile registry was first introduced in WPS 2.0.0, it can be also used in the same way for WPS 1.0.0 Services.

Generic Process Profile

A Generic Process Profile is a ZCFG file located in the generic sub-directory, it defines main metadata information, inputs and outputs name, basic metadata and multiplicity. It can make reference to a concept by defining a concept key in the main metadata information part.

You can find below the GO.zcfg file, a typical Generic Process Profile for Generic Geographic Operation, taking one InputPolygon input parameter and returning a result named Result, it make reference to the GOC concept:

 1[GO]
 2 Title = Geographic Operation
 3 Abstract = Geographic Operation on exactly one input, returning one output
 4 concept = GOC
 5 level = generic
 6 statusSupported = true
 7 storeSupported = true
 8 <DataInputs>
 9  [InputPolygon]
10   Title = the geographic data
11   Abstract = the geographic data to run geographipc operation
12   minOccurs = 1
13   maxOccurs = 1
14 </DataInputs>
15 <DataOutputs>
16  [Result]
17   Title = the resulting data
18   Abstract = the resulting data after processing the operation
19 </DataOutputs>

Note

if you need to reference more than one concept, you should separate their names with a comma (ie. concept = GO,GB),

Process Implementation Profile

A Process Implementation Profile is similar to a ZCFG file located in the implementation sub-directory, it defines (or inherit from its parent) all the properties of a Generic Process Profile and specify Data Format for both inputs and outputs. It can make reference to a concept by defining a concept key in the main metadata information part.

You can find below the VectorOperation.zcfg file, a typical Process Implementation Profile for Vector Geographic Operation, it inherit from the GP generic profile:

 1[VectorOperation]
 2 Title = Vector Geographic Operation
 3 Abstract = Apply a Vector Geographic Operation on a features collection and return the resulting features collection
 4 extend = GO
 5 level = profile
 6 <DataInputs>
 7  [InputPolygon]
 8   Title = the vector data
 9   Abstract = the vector data to run geographic operation
10   <ComplexData>
11    <Default>
12     mimeType = text/xml
13     encoding = UTF-8
14     schema = http://fooa/gml/3.1.0/polygon.xsd
15    </Default>
16    <Supported>
17     mimeType = application/json
18     encoding = UTF-8
19     extension = js
20    </Supported>
21 </DataInputs>
22 <DataOutputs>
23  [Result]
24   Title = the resulting data
25   Abstract = the resulting geographic data after processing the operation
26   <ComplexData>
27    <Default>
28     mimeType = text/xml
29     encoding = UTF-8
30     schema = http://fooa/gml/3.1.0/polygon.xsd
31    </Default>
32    <Supported>
33     mimeType = application/json
34     encoding = UTF-8
35     extension = js
36    </Supported>
37   </ComplexData>
38 </DataOutputs>

ZCFG inheritance

For the ZCFG files at the service level, you can inherit the metadata from a Process Implementation Profile available in the registry. As before, you simply need to add a extend key refering the ZCFG you want to inherit from and a level key taking the ìmplementation` value to your main metadata informations.

So, for example, the original ConvexHull.zcfg may be rewritten as:

1[ConvexHull]
2 Title = Compute convex hull.
3 Abstract = Return a feature collection that represents the convex hull of each geometry from the input collection.
4 serviceProvider = ogr_service.zo
5 serviceType = C
6 extend = VectorOperation
7 level = implementation

Now, suppose that your service is able to return the result in KML format, then you may write the following:

 1[ConvexHull]
 2 Title = Compute convex hull.
 3 Abstract = Return a feature collection that represents the convex hull of each geometry from the input collection.
 4 serviceProvider = ogr_service.zo
 5 serviceType = C
 6 extend = VectorOperation
 7 level = implementation
 8 <DataOutputs>
 9  [Result]
10     <Supported>
11      mimeType = application/vnd.google-earth.kml+xml
12      encoding = utf-8
13     </Supported>
14 </DataOutputs>

Setup registry browser

In the zoo-project/zoo-services/utils/registry you can find the source code and the Makefile required to build the Registry Browser Services Provider. To build and install this service, use the following comands:

cd zoo-project/zoo-services/utils/registry
make
cp cgi-env/* /usr/lib/cgi-bin

To have valid href in the metadata children of a wps:Process, you have to define the registryUrl to point to the path to browse the registry. For this you have two different options, the first one is to install the GetFromRegistry ZOO-Service and to use a WPS 1.0.0 Execute request as registryUrl to dynamically generate Process Concept, Generic Process Profile and Process Implementation Profile. You also have to add a registryUrl to the [main] section to inform the ZOO-Kernel that it should use the Registry Browser to create the href attribute of Metadata nodes. So by adding the following line:

registryUrl = http://localhost/cgi-bin/zoo_loader.cgi?request=Execute&service=WPS&version=1.0.0&Identifier=GetFromRegistry&RawDataOutput=Result&DataInputs=id=

The second option is to pre-generate each level of the hierarchy by running shell commands then set registryUrl to the URL to browse the generated files. In such a case, you will also have to define the registryExt and set it to the file extension you used to generate your registry cache.

To generate the cache in /opt/zoo/registry/, use the following command:

cd /usr/lib/cgi-bin
mkdir /opt/zoo/regcache/{concept,generic,implementation}
for i in $(find /opt/zoo/registry/ -name "*.*") ;
do
    j=$(echo $i | sed "s:../registry//::g;s:.zcfg::g;s:.txt::g") ;
   if [ -z "$(echo $j | grep concept)" ];
   then
       ext="xml" ;
   else
       ext="txt";
   fi
    ./zoo_loader.cgi "request=Execute&service=wps&version=1.0.0&Identifier=GetFromRegistry&RawDataOutput=Result&DataInputs=id=$j" | grep "<" > /opt/zoo/regcache/$j.$ext;
done