source: branches/PublicaMundi_David-devel/docs/services/process-profiles.rst @ 812

Last change on this file since 812 was 698, checked in by djay, 9 years ago

Fixes in Profile Registry documentation

  • Property svn:keywords set to Date Author
File size: 9.2 KB

Process profiles registry

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

?

:ref:`ZOO-Kernel <kernel_index>` 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 :ref:`ZCFG reference <services-zcfg>` for more information).

    ?

Both Generic and Implementation process profiles are created from :ref:`ZCFG <services-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 :ref:`install_gfr` 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:

?
.. code-block:: none
   :linenos:
   [GO]
    Title = Geographic Operation
    Abstract = Geographic Operation on exactly one input, returning one output
    concept = GOC
    level = generic
    statusSupported = true
    storeSupported = true
    <DataInputs>
     [InputPolygon]
      Title = the geographic data
      Abstract = the geographic data to run geographipc operation
      minOccurs = 1
      maxOccurs = 1
    </DataInputs>
    <DataOutputs>
     [Result]
      Title = the resulting data
      Abstract = the resulting data after processing the operation
    </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:

?
.. code-block:: none
   :linenos:
   [VectorOperation]
    Title = Vector Geographic Operation
    Abstract = Apply a Vector Geographic Operation on a features collection and return the resulting features collection
    extend = GO
    level = profile
    <DataInputs>
     [InputPolygon]
      Title = the vector data
      Abstract = the vector data to run geographic operation
      <ComplexData>
       <Default>
        mimeType = text/xml
        encoding = UTF-8
        schema = http://fooa/gml/3.1.0/polygon.xsd
       </Default>
       <Supported>
        mimeType = application/json
        encoding = UTF-8
        extension = js
       </Supported>
    </DataInputs>
    <DataOutputs>
     [Result]
      Title = the resulting data
      Abstract = the resulting geographic data after processing the operation
      <ComplexData>
       <Default>
        mimeType = text/xml
        encoding = UTF-8
        schema = http://fooa/gml/3.1.0/polygon.xsd
       </Default>
       <Supported>
        mimeType = application/json
        encoding = UTF-8
        extension = js
       </Supported>
      </ComplexData>
    </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:

?
.. code-block:: none
   :linenos:
   [ConvexHull]
    Title = Compute convex hull.
    Abstract = Return a feature collection that represents the convex hull of each geometry from the input collection.
    serviceProvider = ogr_service.zo
    serviceType = C
    extend = VectorOperation
    level = implementation

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

?
.. code-block:: none
   :linenos:
   [ConvexHull]
    Title = Compute convex hull.
    Abstract = Return a feature collection that represents the convex hull of each geometry from the input collection.
    serviceProvider = ogr_service.zo
    serviceType = C
    extend = VectorOperation
    level = implementation
    <DataOutputs>
     [Result]
        <Supported>
         mimeType = application/vnd.google-earth.kml+xml
         encoding = utf-8
        </Supported>
    </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
Note: See TracBrowser for help on using the repository browser.

Search

Context Navigation

ZOO Sponsors

http://www.zoo-project.org/trac/chrome/site/img/geolabs-logo.pnghttp://www.zoo-project.org/trac/chrome/site/img/neogeo-logo.png http://www.zoo-project.org/trac/chrome/site/img/apptech-logo.png http://www.zoo-project.org/trac/chrome/site/img/3liz-logo.png http://www.zoo-project.org/trac/chrome/site/img/gateway-logo.png

Become a sponsor !

Knowledge partners

http://www.zoo-project.org/trac/chrome/site/img/ocu-logo.png http://www.zoo-project.org/trac/chrome/site/img/gucas-logo.png http://www.zoo-project.org/trac/chrome/site/img/polimi-logo.png http://www.zoo-project.org/trac/chrome/site/img/fem-logo.png http://www.zoo-project.org/trac/chrome/site/img/supsi-logo.png http://www.zoo-project.org/trac/chrome/site/img/cumtb-logo.png

Become a knowledge partner

Related links

http://zoo-project.org/img/ogclogo.png http://zoo-project.org/img/osgeologo.png