| 1 | .. _process-profiles: |
|---|
| 2 | |
|---|
| 3 | Process Profiles Registry |
|---|
| 4 | ========================================= |
|---|
| 5 | |
|---|
| 6 | :Authors: Nicolas Bozon, Gérald Fenoy, Jeff McKenna |
|---|
| 7 | :Last Updated: $Date: 2015-03-12 13:31:37 +0000 (Thu, 12 Mar 2015) $ |
|---|
| 8 | |
|---|
| 9 | .. contents:: Table of Contents |
|---|
| 10 | :depth: 3 |
|---|
| 11 | :backlinks: top |
|---|
| 12 | |
|---|
| 13 | Many times, services from the same ServicesProvider share inputs and |
|---|
| 14 | outputs. In such a casse, defining the ZCFG files for each service |
|---|
| 15 | from the same provider may lead to rewrite the same metadata |
|---|
| 16 | informations in different files. |
|---|
| 17 | |
|---|
| 18 | From `rev. 607 <http://www.zoo-project.org/trac/changeset/607>`__, the |
|---|
| 19 | ZOO-Kernel is able to handle metadata inheritance, it create a |
|---|
| 20 | Registry (before loading any other ZCFG files) containing a set of |
|---|
| 21 | Process Profiles organized in levels depending on their position in |
|---|
| 22 | the hierarchy: |
|---|
| 23 | |
|---|
| 24 | :Concept: the higher level in the hierarchy, concepts are basically |
|---|
| 25 | txt files containing an abstract description of a service, |
|---|
| 26 | :Generic: a generic profile can make reference to concepts, it defines |
|---|
| 27 | inputs and outputs but nor the data format nor the maximum size |
|---|
| 28 | limitation, |
|---|
| 29 | :Implementation: an implementation profile can inherit from a generic |
|---|
| 30 | profile and make reference to concepts, it contains all the |
|---|
| 31 | metadata informations about a service (see |
|---|
| 32 | `ref. <cfg-reference.html#main-metadata-information>`__). |
|---|
| 33 | |
|---|
| 34 | Both Generic Process Profiles and Process Implementation Profiles are |
|---|
| 35 | created from ZCFG files, stored in the registry sub-directories |
|---|
| 36 | depending on their level: ``concept``, ``generic`` and |
|---|
| 37 | ``implementation``. |
|---|
| 38 | |
|---|
| 39 | To activate the registry, you have to add a ``registry`` key to the |
|---|
| 40 | ``[main]`` section of your ``main.cfg`` file, and set its value to the |
|---|
| 41 | directory path used to store the profile ZCFG files. |
|---|
| 42 | |
|---|
| 43 | |
|---|
| 44 | Generic Process Profile |
|---|
| 45 | ----------------------- |
|---|
| 46 | |
|---|
| 47 | A Generic Process Profile is a ZCFG file located in the ``generic`` |
|---|
| 48 | sub-directory, it defines `main metadata information |
|---|
| 49 | <zcfg-reference.html#main-metadata-information>`__, inputs and outputs |
|---|
| 50 | name, basic metadata and multiplicity. It can make reference to a |
|---|
| 51 | concept by defining a ``concept`` key in the `main metadata |
|---|
| 52 | information <zcfg-reference.html#main-metadata-information>`__ part. |
|---|
| 53 | |
|---|
| 54 | You can find below the `GO.zcfg` file, a typical Generic Process |
|---|
| 55 | Profile for Generic Geographic Operation, taking one InputPolygon |
|---|
| 56 | input parameter and returning a result named Result, it make reference |
|---|
| 57 | to the ``GOC`` concept: |
|---|
| 58 | |
|---|
| 59 | .. code-block:: none |
|---|
| 60 | :linenos: |
|---|
| 61 | |
|---|
| 62 | [GO] |
|---|
| 63 | Title = Geographic Operation |
|---|
| 64 | Abstract = Geographic Operation on exactly one input, returning one output |
|---|
| 65 | concept = GOC |
|---|
| 66 | level = generic |
|---|
| 67 | statusSupported = true |
|---|
| 68 | storeSupported = true |
|---|
| 69 | <DataInputs> |
|---|
| 70 | [InputPolygon] |
|---|
| 71 | Title = the geographic data |
|---|
| 72 | Abstract = the geographic data to run geographipc operation |
|---|
| 73 | minOccurs = 1 |
|---|
| 74 | maxOccurs = 1 |
|---|
| 75 | </DataInputs> |
|---|
| 76 | <DataOutputs> |
|---|
| 77 | [Result] |
|---|
| 78 | Title = the resulting data |
|---|
| 79 | Abstract = the resulting data after processing the operation |
|---|
| 80 | </DataOutputs> |
|---|
| 81 | |
|---|
| 82 | |
|---|
| 83 | .. Note:: if you need to reference more than one concept, you should |
|---|
| 84 | separate their names with a comma (ie. concept = GO,GB), |
|---|
| 85 | |
|---|
| 86 | Process Implementation Profile |
|---|
| 87 | ------------------------------ |
|---|
| 88 | |
|---|
| 89 | A Process Implementation Profile is similar to a `ZCFG file |
|---|
| 90 | <zcfg-reference.html>`__ located in the `implementation` |
|---|
| 91 | sub-directory, it defines (or inherit from its parent) all the |
|---|
| 92 | properties of a `Generic Process Profile <#generic-process-profile>`__ |
|---|
| 93 | and specify `Data Format <zcfg-reference.html#type-of-data-nodes>`__ |
|---|
| 94 | for both inputs and outputs. It can make reference to a concept by |
|---|
| 95 | defining a ``concept`` key in the `main metadata information |
|---|
| 96 | <zcfg-reference.html#main-metadata-information>`__ part. |
|---|
| 97 | |
|---|
| 98 | You can find below the `VectorOperation.zcfg` file, a typical Process |
|---|
| 99 | Implementation Profile for Vector Geographic Operation, it inherit |
|---|
| 100 | from the `GP generic profile <#generic-process-profile>`__: |
|---|
| 101 | |
|---|
| 102 | .. code-block:: none |
|---|
| 103 | :linenos: |
|---|
| 104 | |
|---|
| 105 | [VectorOperation] |
|---|
| 106 | Title = Vector Geographic Operation |
|---|
| 107 | Abstract = Apply a Vector Geographic Operation on a features collection and return the resulting features collection |
|---|
| 108 | extend = GO |
|---|
| 109 | level = profile |
|---|
| 110 | <DataInputs> |
|---|
| 111 | [InputPolygon] |
|---|
| 112 | Title = the vector data |
|---|
| 113 | Abstract = the vector data to run geographic operation |
|---|
| 114 | <ComplexData> |
|---|
| 115 | <Default> |
|---|
| 116 | mimeType = text/xml |
|---|
| 117 | encoding = UTF-8 |
|---|
| 118 | schema = http://fooa/gml/3.1.0/polygon.xsd |
|---|
| 119 | </Default> |
|---|
| 120 | <Supported> |
|---|
| 121 | mimeType = application/json |
|---|
| 122 | encoding = UTF-8 |
|---|
| 123 | extension = js |
|---|
| 124 | </Supported> |
|---|
| 125 | </DataInputs> |
|---|
| 126 | <DataOutputs> |
|---|
| 127 | [Result] |
|---|
| 128 | Title = the resulting data |
|---|
| 129 | Abstract = the resulting geographic data after processing the operation |
|---|
| 130 | <ComplexData> |
|---|
| 131 | <Default> |
|---|
| 132 | mimeType = text/xml |
|---|
| 133 | encoding = UTF-8 |
|---|
| 134 | schema = http://fooa/gml/3.1.0/polygon.xsd |
|---|
| 135 | </Default> |
|---|
| 136 | <Supported> |
|---|
| 137 | mimeType = application/json |
|---|
| 138 | encoding = UTF-8 |
|---|
| 139 | extension = js |
|---|
| 140 | </Supported> |
|---|
| 141 | </ComplexData> |
|---|
| 142 | </DataOutputs> |
|---|
| 143 | |
|---|
| 144 | |
|---|
| 145 | ZCFG inheritance |
|---|
| 146 | ---------------------------------- |
|---|
| 147 | |
|---|
| 148 | For the ZCFG files at the service level, you can inherit the metadata |
|---|
| 149 | from a Process Implementation Profile available in the registry. As |
|---|
| 150 | before, you simply need to add a ``extend`` key refering the ZCFG you |
|---|
| 151 | want to inherit from and a ``level`` key taking the `ìmplementation`` |
|---|
| 152 | value to your main metadata informations. |
|---|
| 153 | |
|---|
| 154 | So, for example, the original `ConvexHull.zcfg |
|---|
| 155 | <http://www.zoo-project.org/trac/browser/trunk/zoo-project/zoo-services/ogr/base-vect-ops/cgi-env/ConvexHull.zcfg?rev=491>`__ |
|---|
| 156 | may be rewritten as: |
|---|
| 157 | |
|---|
| 158 | .. code-block:: none |
|---|
| 159 | :linenos: |
|---|
| 160 | |
|---|
| 161 | [ConvexHull] |
|---|
| 162 | Title = Compute convex hull. |
|---|
| 163 | Abstract = Return a feature collection that represents the convex hull of each geometry from the input collection. |
|---|
| 164 | serviceProvider = ogr_service.zo |
|---|
| 165 | serviceType = C |
|---|
| 166 | extend = VectorOperation |
|---|
| 167 | level = implementation |
|---|
| 168 | |
|---|
| 169 | Now, suppose that your service is able to return the result in KML |
|---|
| 170 | format, then you may write the following: |
|---|
| 171 | |
|---|
| 172 | .. code-block:: none |
|---|
| 173 | :linenos: |
|---|
| 174 | |
|---|
| 175 | [ConvexHull] |
|---|
| 176 | Title = Compute convex hull. |
|---|
| 177 | Abstract = Return a feature collection that represents the convex hull of each geometry from the input collection. |
|---|
| 178 | serviceProvider = ogr_service.zo |
|---|
| 179 | serviceType = C |
|---|
| 180 | extend = VectorOperation |
|---|
| 181 | level = implementation |
|---|
| 182 | <DataOutputs> |
|---|
| 183 | [Result] |
|---|
| 184 | <Supported> |
|---|
| 185 | mimeType = application/vnd.google-earth.kml+xml |
|---|
| 186 | encoding = utf-8 |
|---|
| 187 | </Supported> |
|---|
| 188 | </DataOutputs> |
|---|