Changes between Version 9 and Version 10 of ZooWorkshop/FOSS4GJapan/CreatingOGRBasedWebServices

Oct 15, 2010, 7:00:46 PM (11 years ago)



  • ZooWorkshop/FOSS4GJapan/CreatingOGRBasedWebServices

    v9 v10  
    150150=== Boundary ===
    152 === C Version ===
     152==== C Version ====
    154154As 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.
    428428Your ZOO Services Provider is now ready to use from an Execute request passed to ZOO Kernel.
    430 === Python Version ===
     430==== Python Version ====
    432432For those using Python to implement their ZOO Services Provider, the full code to copy in 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 :
    481481Finally, simply run make install from the ZOO Services Provider main directory, in order to deploy your ZOO Service Provider.
    483 === Testing the Service using Execute Request ===
    485 ==== The simple and unreadable way ====
     483==== Testing the Service using Execute Request ====
     485===== The simple and unreadable way =====
    487487Everybody 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 :
    509509Finally, 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.
    511 ==== Simplification and readability of request ====
     511===== Simplification and readability of request =====
    513513As 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 :
    570570If 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.
    572 == Creating Services for other functions (ConvexHull and Centroid) ==
     572=== Creating Services for other functions (ConvexHull and Centroid) ===
    574574As 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.
    576 === C Version ===
     576==== C Version ====
    578578Please add first the following code to the service.c source code :
    679679Note 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.
    681 === Python Version ===
     681==== Python Version ====
    760760You 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 == Create the Buffer Service ==
     762=== Create the Buffer Service ===
    764764We 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.
    766766The 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.
    768 === C Version ===
     768==== C Version ====
    770770If 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 :
    857 === Python Version ===
     857==== Python Version ====
    859859As we already defined the utility functions createGeometryFromWFS and outputResult, the code is as simple as this :


Context Navigation

ZOO Sponsors

Become a sponsor !

Knowledge partners

Become a knowledge partner

Related links