Changes between Version 9 and Version 10 of ZooWorkshop/FOSS4GJapan/CreatingOGRBasedWebServices
- Timestamp:
- Oct 15, 2010, 7:00:46 PM (14 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
ZooWorkshop/FOSS4GJapan/CreatingOGRBasedWebServices
v9 v10 150 150 === Boundary === 151 151 152 === C Version===152 ==== C Version ==== 153 153 154 154 As explained before, ZOO Kernel will pass the parameters to your Service function in a specific datatype called maps. In order to code your Service in C language, you also need to learn how to access this datatype in read/write mode. … … 428 428 Your ZOO Services Provider is now ready to use from an Execute request passed to ZOO Kernel. 429 429 430 === Python Version===430 ==== Python Version ==== 431 431 432 432 For those using Python to implement their ZOO Services Provider, the full code to copy in ogr_ws_service_provider.py in cgi-env directory is shown bellow. Indeed, as Python is an interpreted language, you do not have to compile anything before deploying your service which makes the deployement step much easier : … … 481 481 Finally, simply run make install from the ZOO Services Provider main directory, in order to deploy your ZOO Service Provider. 482 482 483 === Testing the Service using Execute Request===484 485 ==== The simple and unreadable way====483 ==== Testing the Service using Execute Request ==== 484 485 ===== The simple and unreadable way ===== 486 486 487 487 Everybody should now get his own copy of the OGR Boundary Service stored as a ZOO Services Provider called ogr_ws_service_provider and deployed in the ZOO Kernel tree, so the following Execute request can be used to test the Service : … … 509 509 Finally, please note that we go back to the default mimeType to directly obtain the JSON string as we will use this kind of request to develop our client application in the next section of this workshop. 510 510 511 ==== Simplification and readability of request====511 ===== Simplification and readability of request ===== 512 512 513 513 As you can see in the simple example we used since the begining of this workshop, it is sometimes hard to write the Execute requests using the GET method as it makes really long and complexe URLs. In the next requests examples, we will thus use the POST XML requests. First , here is the XML request corresponding to the previous Execute we used : … … 570 570 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. 571 571 572 == Creating Services for other functions (ConvexHull and Centroid)==572 === Creating Services for other functions (ConvexHull and Centroid) === 573 573 574 574 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. 575 575 576 === C Version===576 ==== C Version ==== 577 577 578 578 Please add first the following code to the service.c source code : … … 679 679 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. 680 680 681 === Python Version===681 ==== Python Version ==== 682 682 683 683 {{{ … … 760 760 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. 761 761 762 == Create the Buffer Service==762 === Create the Buffer Service === 763 763 764 764 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. … … 766 766 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. 767 767 768 === C Version===768 ==== C Version ==== 769 769 770 770 If you go back to the first Boundary Service source code, you should not find the following very complicated. Indeed, you simply have to add the access of the BufferDistance argument and modify the line whenthe OGR_G_Buffer must be called (instead of OGR_G_GetBoundary). Here is the ful lcode : … … 855 855 }}} 856 856 857 === Python Version===857 ==== Python Version ==== 858 858 859 859 As we already defined the utility functions createGeometryFromWFS and outputResult, the code is as simple as this :
