Changes between Version 12 and Version 13 of ZooWorkshop/FOSS4GJapan/CreatingOGRBasedWebServices
- Timestamp:
- Oct 15, 2010, 7:28:34 PM (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
ZooWorkshop/FOSS4GJapan/CreatingOGRBasedWebServices
v12 v13 7 7 == Introduction == 8 8 9 In 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.9 In this part, we are going to create a ZOO !ServicesProvider 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. 10 10 11 11 We 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. … … 28 28 }}} 29 29 30 Such metadata informations will be returned by a GetCapabilities request.30 Such metadata informations will be returned by a !GetCapabilities request. 31 31 32 32 You 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 : … … 42 42 * 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) 43 43 44 C ServiceProvider Example :44 C !ServicesProvider Example : 45 45 {{{ 46 46 serviceProvider=ogr_ws_service_provider.zo … … 50 50 In 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. 51 51 52 Python ServiceProvider Example :52 Python !ServicesProvider Example : 53 53 54 54 {{{ … … 69 69 The 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. 70 70 71 The 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.71 The 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. 72 72 73 73 {{{ … … 140 140 == Implementing single geometry processes == 141 141 142 In order to learn the Services Provider creation and deployement step-by-step, we will first focus on creating a very simple one dedicated to the Boundary function. Similar procedure will then be used for the Buffer, Centroid and ConvexHull implementation.142 In order to learn the Services Provider creation and deployement step-by-step, we will first focus on creating a very simple one dedicated to the Boundary function. Similar procedure will then be used for the Buffer, Centroid and !ConvexHull implementation. 143 143 144 144 Your metadata is now ok, so you now must create the code of your Service. The most important thing you must be aware of when coding ZOO Services is that the function corresponding to your Service takes three parameters (internal maps datatype or Python dictionaries) and returns an integer value representing the status of execution (SERVICE_FAILED or SERVICE_SUCCEEDED) : … … 373 373 {{{ 374 374 #!c 375 g++ $CFLAGS -shared -fpic -o cgi-env/ ServiceProvider.zo ./service.c $LDFLAGS375 g++ $CFLAGS -shared -fpic -o cgi-env/!ServicesProvider.zo ./service.c $LDFLAGS 376 376 }}} 377 377 … … 410 410 Using this Makefile, you should be able to run make from your ZOO Service Provider main directory and to get the resulting ogr_ws_service_provider.zo file located in the cgi-env directory. 411 411 412 The metadata file and the ZOO Service Shared Object are now both located in the cgi-env directory. In order to deploy your new ServiceProvider, you only have to copy the ZOO Service Shared Object and its corresponding metadata file in the directory where ZOO Kernel is located, so in/usr/lib/cgi-bin. You must use a sudo command to achieve this task:412 The metadata file and the ZOO Service Shared Object are now both located in the cgi-env directory. In order to deploy your new !ServicesProvider, you only have to copy the ZOO Service Shared Object and its corresponding metadata file in the directory where ZOO Kernel is located, so in/usr/lib/cgi-bin. You must use a sudo command to achieve this task: 413 413 414 414 {{{ … … 489 489 [http://localhost/cgi-bin/zoo_loader.cgi?request=Execute&service=WPS&version=1.0.0&Identifier=Boundary&DataInputs=InputPolygon=Reference@xlink:href= http%3A%2F%2Flocalhost%3A8082%2Fgeoserver%2Fows%3FSERVICE%3DWFS%26REQUEST%3DGetFeature%26VERSION%3D1.0.0%26typename%3Dtopp%3Astates%26SRS%3DEPSG%3A4326%26FeatureID%3Dstates.15] 490 490 491 As you can see in the url above, we use an URLEncoded WFS request to the Geoserver WFS server available on OSGeoLive as a xlink:href key in the DataInputs KVP value, and set the InputPolygon value to Reference. The corresponding non encoded WFS request is as follow :491 As you can see in the url above, we use an URLEncoded WFS request to the Geoserver WFS server available on OSGeoLive as a xlink:href key in the !DataInputs KVP value, and set the InputPolygon value to Reference. The corresponding non encoded WFS request is as follow : 492 492 493 493 [http://localhost:8082/geoserver/ows/?SERVICE=WFS&REQUEST=GetFeature&VERSION=1.0.0&typename=topp:states&SRS=EPSG:4326&FeatureID=state s.15] … … 574 574 If everything went well, you should get the Boundary of the JSON geometry passed as argument, and so be sure that your Service support both GML and JSON as input data. Note that in the previous request, we added a mimeType attribute to the ComplexData node to specify that the input data is not in the default text/xml mimeType but passed as an application/json string directly. It is similar to add @mimeType=application/json as we discussed before. 575 575 576 === Creating Services for other functions ( ConvexHull and Centroid) ===577 578 As the Boundary sample service code is available, you can now easily add ConvexHull and Centroid functions as they take exactly the same number of arguments : Only one geometry. The details for implementing and deploying theConvexHull Service are provided bellow, and we will let you do the same thing for the Centroid one.576 === Creating Services for other functions (!ConvexHull and Centroid) === 577 578 As the Boundary sample service code is available, you can now easily add !ConvexHull and Centroid functions as they take exactly the same number of arguments : Only one geometry. The details for implementing and deploying the !ConvexHull Service are provided bellow, and we will let you do the same thing for the Centroid one. 579 579 580 580 ==== C Version ==== … … 661 661 }}} 662 662 663 The genericity of the applyOne function let you add two new Services in your ZOO Services Provider : ConvexHull and Centroid.664 665 Note that you should define MY_OGR_Centroid function before the Centroid one as OGR_G_Centroid don't return a geometry object but set the value to an already existing one and support only Polygon as input, so to ensure we use the ConvexHull for MultiPolygon. So please use the code bellow :663 The genericity of the applyOne function let you add two new Services in your ZOO Services Provider : !ConvexHull and Centroid. 664 665 Note that you should define MY_OGR_Centroid function before the Centroid one as OGR_G_Centroid don't return a geometry object but set the value to an already existing one and support only Polygon as input, so to ensure we use the !ConvexHull for MultiPolygon. So please use the code bellow : 666 666 667 667 {{{ … … 679 679 }}} 680 680 681 To deploy your Services, you only have to copy the Boundary.zcfg metadata file from your cgi-env directory as ConvexHull.zcfg and Centroid.zcfg. Then, you must rename the Service name on the first line to be able to run and test the Execute request in the same way you did before. You only have to set the Identifier value toConvexHull or Centroid in your request depending on the Service you want to run.682 683 Note here that the GetCapabilities andDescribeProcess requests will return odd results as we didn't modified any metadata informations, you can edit the .zcfg files to set correct values. By the way it can be used for testing purpose, as the input and output get the same name and default/supported formats.681 To deploy your Services, you only have to copy the Boundary.zcfg metadata file from your cgi-env directory as !ConvexHull.zcfg and Centroid.zcfg. Then, you must rename the Service name on the first line to be able to run and test the Execute request in the same way you did before. You only have to set the Identifier value to !ConvexHull or Centroid in your request depending on the Service you want to run. 682 683 Note here that the !GetCapabilities and !DescribeProcess requests will return odd results as we didn't modified any metadata informations, you can edit the .zcfg files to set correct values. By the way it can be used for testing purpose, as the input and output get the same name and default/supported formats. 684 684 685 685 ==== Python Version ==== … … 737 737 }}} 738 738 739 Then definition of the ConvexHull and Centroid Services can be achieved using the following code :739 Then definition of the !ConvexHull and Centroid Services can be achieved using the following code : 740 740 741 741 {{{ … … 760 760 }}} 761 761 762 Note, that in Python you also need to use ConvexHull to deal with MultiPolygons.763 764 You must now copy the Boundary.zcfg file as we explained for the C version in ConvexHull.zcfg and Centroid.zcfg respectively and then, use make install command to re-deploy and test your Services Provider.762 Note, that in Python you also need to use !ConvexHull to deal with MultiPolygons. 763 764 You must now copy the Boundary.zcfg file as we explained for the C version in !ConvexHull.zcfg and Centroid.zcfg respectively and then, use make install command to re-deploy and test your Services Provider. 765 765 766 766 === Create the Buffer Service === 767 767 768 We can now work on the Buffer Service, which takes more arguments than the other ones. Indeed, the code is a bit different from the one used to implement the Boundary, ConvexHull and Centroid Services.768 We can now work on the Buffer Service, which takes more arguments than the other ones. Indeed, the code is a bit different from the one used to implement the Boundary, !ConvexHull and Centroid Services. 769 769 770 770 The Buffer service also takes an input geometry, but uses a BufferDistance parameter. It will also allow you to define LitteralData block as the BufferDistance will be simple integer value. The read access to such kind of input value is made using the same function as used before. … … 811 811 You may have noted that the above code check if a BufferDistance input was passed to the service. If not, we will use 1 as the default value, which explains why you do not have to use one more input to your previous queries. 812 812 813 You can change the BufferDistance value used by your Service to compute Buffer of your geometry by adding it to the DataInputs value in your request. Note that using KVP syntaxe, eachDataInputs are separated by a semicolon.813 You can change the BufferDistance value used by your Service to compute Buffer of your geometry by adding it to the !DataInputs value in your request. Note that using KVP syntaxe, each !DataInputs are separated by a semicolon. 814 814 815 815 So, the previous request : … … 882 882 ==== The Buffer MetadataFile file ==== 883 883 884 You must add BufferDistance to the Service Metadata File to let clients know that this Service supports this parameter. To do this, please copy your orginal Boundary.zcfg file as Buffer.zcfg and add the following lines to the DataInputs block :884 You must add BufferDistance to the Service Metadata File to let clients know that this Service supports this parameter. To do this, please copy your orginal Boundary.zcfg file as Buffer.zcfg and add the following lines to the !DataInputs block : 885 885 886 886 {{{ … … 908 908 http://zoo-project.org/trac/browser/trunk/zoo-services/ogr/base-vect-ops/cgi-env/Buffer.zcfg 909 909 910 You can now ask ZOO Kernel for GetCapabilities,DescribeProcess and Execute for the Buffer Service.911 910 You can now ask ZOO Kernel for !GetCapabilities, !DescribeProcess and Execute for the Buffer Service. 911
