Changes between Initial Version and Version 1 of ZooWorkshop/FOSS4GJapan/CreatingOGRBasedWebServices


Ignore:
Timestamp:
Oct 15, 2010, 2:11:39 PM (14 years ago)
Author:
djay
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ZooWorkshop/FOSS4GJapan/CreatingOGRBasedWebServices

    v1 v1  
     1= Creating WPS compliant OGR based Web Services =
     2
     3== Introduction ==
     4
     5In this part, we are going to create a ZOO ServiceProvider containing several Services based on the OGR C API or on the OGR Python module, which have also been placed in the ZOO installation on OSGeoLive. The intended goal is to use OGR and its GEOS based simple spatial functions as WPS Services.
     6
     7We will first start with the Boundary spatial function, which will be explained, codded and tested gradually as a ZOO Service. The same procedure will then be used to enable the Buffer, Centroid and Convex Hull functions. Once done, some multiple geometries processes such as Intersection, Union, Difference and Symetric Difference will be implemented through an exercise at the end of the workshop.
     8
     9As already said in the introduction, you have the choice to code your service in C or Python (or both!) during this workshop. Explanations will be based on the C part, but will be very helpful for those who will choose Python. Please decide according to your habits and preferences and tell your choice to the instructors. The results will be the same in both case.
     10
     11== Preparing ZOO metadata file ==
     12
     13A ZOO Service is a combination of a ZOO metadata file (.zcfg) and the runtime module for the corresponding implementation, which is commonly called ZOO Service Provider. We will first prepare a .zcfg file step-by-step. Please open your preferred text editor and edit a file named Boundary.zcfg in your /home/user/zoows/sources/zoo-services/ws_sp directory. First, you need to name the service between brackets at the top of the file, as the following:
     14
     15{{{
     16[Boundary]
     17}}}
     18
     19This name is very important, it is the name of the Service and so the name of the function defined in the Services Provider. A title and a brief abstract must then be added to inform clients on what the service can do :
     20
     21{{{
     22Title = Compute boundary.
     23Abstract = Returns the boundary of the geometry on which the method is invoked.
     24}}}
     25
     26Such metadata informations will be returned by a GetCapabilities request.
     27
     28You can also add other specific informations like the processVersion. You can set if your ZOO Service can store its results, by setting the storeSupported parameter to true or false. You can also decide if the function can be run as a background task and inform on its current status, according to the statusSupported value :
     29
     30{{{
     31processVersion = 1
     32storeSupported = true
     33statusSupported = true
     34}}}
     35
     36In the main section of the ZOO Service metadata file, you must also specify two important things:
     37 * serviceProvider, which is the name of the C shared library containing the Service function or the Python module name.
     38 * serviceType, which defines the programming language to be used for the Service. (value can be C or Python depending on what language you have decided to use)
     39
     40C ServiceProvider Example :
     41{{{
     42serviceProvider=ogr_ws_service_provider.zo
     43serviceType=C
     44}}}
     45
     46In this case you will get an ogr_ws_service_provider.zo shared library containing the Boundary function, placed in the same directory than ZOO Kernel.
     47
     48Python ServiceProvider Example :
     49
     50{{{
     51serviceProvider=ogr_ws_service_provider
     52serviceType=Python
     53}}}
     54
     55In this case, you will get an ogr_ws_service_provider.py file containing the Python code of your Boundary function.
     56
     57In the main section you can also add any other metadata information, as the following:
     58
     59{{{
     60<MetaData>
     61Title = Demo
     62</MetaData>
     63}}}
     64
     65The main metadata informations have been declared, so you can now define data input which will be used by the ZOO Service. You can define any input needed by the Service. Please note that you can request ZOO Kernel using more data input than defined in the .zcfg file without any problem, those values will be passed to your service without filtering. In the Boundary Service example, a single polygon will be used as input, the one on which to apply the Boundary function.
     66
     67The data input declarations are included in a DataInputs block. They use the same syntax as the Service itself and the input name is between brackets. You can also fill a title, an abstract and aMetaData section for the input. You must set values for the minOccurs and maxOccurs parameters, as they will inform ZOO Kernel which parameters are required to be able to run the Service function.
     68
     69{{{
     70[InputPolygon]
     71Title = Polygon to compute boundary
     72Abstract = URI to a set of GML that describes the polygon.
     73minOccurs = 1
     74maxOccurs = 1
     75<MetaData lang="en">
     76Test = My test
     77</MetaData>
     78}}}
     79
     80The metadata defines what type of data the Service supports. In the Boundary example, the input polygon can be provided as a GML file or as a JSON string. Next step is thus to define the default and supported input formats. Both formats should be declared in a LitteralData or ComplexData block depending on their types. For this first example we will use ComplexData blocks only.
     81
     82{{{
     83<ComplexData>
     84<Default>
     85mimeType = text/xml
     86encoding = UTF-8
     87</Default>
     88<Supported>
     89mimeType = application/json
     90encoding = UTF-8
     91</Supported>
     92</ComplexData>
     93}}}
     94
     95Then, the same metadata information must be defined for the output of the Service, inside aDataOutputs block, as the following:
     96
     97{{{
     98[Result]
     99Title = The created geometry
     100Abstract = The geometry containing the boundary of the geometry on which the method was invoked.
     101<MetaData lang="en">
     102Title = Result
     103</MetaData>
     104<ComplexData>
     105<Default>
     106mimeType = application/json
     107encoding = UTF-8
     108</Default>
     109<Supported>
     110mimeType = text/xml
     111encoding = UTF-8
     112</Supported>
     113</ComplexData>
     114}}}

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