Index: /trunk/docs/index.txt =================================================================== --- /trunk/docs/index.txt (revision 573) +++ /trunk/docs/index.txt (revision 574) @@ -1,5 +1,5 @@ .. _home: -ZOO 1.4 Documentation +ZOO 1.5 Documentation ===================== @@ -14,5 +14,5 @@ :ref:`kernel`,:ref:`services`,:ref:`api` :ref:`kernel-installation`,:ref:`community`,`Search mailing list `__ - :ref:`documentation_development`,:ref:`workshop-foss4g-japan-2010`,:ref:`workshop-foss4g-cee-2012` + :ref:`documentation_development`,:ref:`workshop-foss4g-2014`,:ref:`workshop-foss4g-japan-2010` .. note:: @@ -66,7 +66,8 @@ api/index client/index + workshop/2014/index + workshop/2013/index + workshop/2012/index workshop/2010/index - workshop/2012/index - workshop/2013/index community/index development/documentation Index: /trunk/docs/workshop/2014/building_blocks_presentation.txt =================================================================== --- /trunk/docs/workshop/2014/building_blocks_presentation.txt (revision 574) +++ /trunk/docs/workshop/2014/building_blocks_presentation.txt (revision 574) @@ -0,0 +1,150 @@ +.. _ogr_base_vect_ops: + +********************************************************* +Building blocks presentation - Using OGR and PgRouting based Web Services +********************************************************* + +.. contents:: Table of Contents + :depth: 5 + :backlinks: top + +Introduction +============ + +In this section, you will use basic ZOO-Services : ``Buffer``, +``Intersection`` and ``DifferencePy`` which use OGR and psycopg Python modules. +The intended goal of this section is to present and interact with your new building blocks before chaining them in the next section. + +First of all, you should use the following links to access the user +interfaces and interact with your services, the first one is used to +access basic spatial-tools demo client interface and the second to +access the routing application : + * `http://localhost/zoo-ws/spatialtools-py.html `__ + * `http://localhost/zoo-ws/ `__ + +Services Provider and configuration files +========================================= + +First you may verify if the ZOO-Services are available from your current setup. +You can take a look at the ``Buffer.zcfg``, ``Intersection.zcfg`` and +``DifferencePy.zcfg`` to get details about parameters. +As you can see from the ZCFG files, you will use ZOO-Services provided by the +``service`` Python service provider. So if you want to modify the Python code +you will have to edit the corresponding file (so ``service.py``). +You are invited to use similar requests as the one used in previous +sections to learn about each services individually. + +The Buffer Service +========================= + +First click on a street then once the street is displayed in blue, click the +'Buffer' button on top, you should get similar result as displayed in the following. + +.. image:: ./images/Buffer_Level_15.png + :width: 650px + :align: center + +Since version ZOO-Project 1.2.0, you can run automatically some basic tests to +make sure that you wrote a correct ZCFG file and your service is validating. + +.. note:: the current testing is really simple and should be adapted to each Services + Provider, mainly to define input names. + +You can use the following command: + +.. code-block:: bash + + cd /home/user/zoo/testing + ./run.sh http://localhost/cgi-bin/zoo_loader.cgi Buffer + + +.. note:: During or after the test run, you can take a look inside the ``tmp`` directory + which contains both the XML requests send to the ZOO Kernel (``*1.xml``) and the + responses it gave (``output*.xml``). + +The Intersection Service +========================= + +Using the same client interface as before, once you get a Buffer, you can then +select a street intersecting the Buffer geometry to compute intersection by clicking on the Intersection button. + + +.. image:: ./images/Intersection_Level_15.png + :width: 650px + :align: center + + +The DifferencePy Service +========================= + +Using the same instructions as for Intersetion, you can get the following result. + +.. image:: ./images/Difference_Level_15.png + :width: 650px + :align: center + + +The Routing and Profile Services +========================= + +First click on the blue flag then place your starting point on the +map, do the same with the red flag to get the shortest path computed +by the dedicated service and then display its profile. Note that when +you pass the mouse over the profile display then you will see its +corresponding position displayed on the map. You can also click on a +specific step in your path to get the corresponding line displayed. + +.. image:: ./images/Routing_Basic.png + :width: 650px + :align: center + +If you take a look in the file: ``/usr/lib/cgi-bin/routing/do.zcfg`` +you may notice something new in the supported format which is +reproduced here after. + +.. code-block:: guess + + + mimeType = image/png + asReference = true + msStyle = STYLE COLOR 125 0 105 OUTLINECOLOR 0 0 0 WIDTH 3 END + useMapServer = true + extension = json + + +The ``mimeType`` is defined as ``image/png`` and there is two new +parameter which are both optional: + * ``useMapServer``: which make you able to inform the ZOO-Kernel + that it have to use MapServer to publish your result as WMS / WFS or WCS (this last + won't be used in this workshop) rather than simply storing the + result as a file. + * ``msStyle``: which let you define your own MapServer ``STYLE`` block definition. + +When you need to access a result many time or for different purpose +accross other services then it is really useful to ask ZOO-Kernel to +publish your result as WMS, WFS or WCS. + +Note that no modification of the code of the do service was required +to handle automatic pubilcation of the result as it is a vector format +supported by OGR, only modification of the zcfg was required. + +This routing example is here to illustrate how easy it is to publish +your result as WMS, WFS or WCS ressource. Indeed, when your routing +service was called, ZOO-Kernel published the result as WMS and WFS +ressources which was both used first for the UI purpose, the WMS to +display the resulting path on the map, the WFS for displaying details +about each steps. The WFS protocol is also used as the input value +for the profile computation. So, the computation was run once +and accessed three times for different purposes and from different +clients. + +For more informations about the MapServer support, please refer to `the +official ZOO-Project Documentation `_. + +Conclusion +======== + +Now you know this three services, and you get a simple interface to interact +with your MapServer WFS and your ZOO-Project WPS Servers, you are ready to use +the Services in a different way, by chaining them using the JavaScript ZOO-API to build +more complexe and powerfull services. Index: /trunk/docs/workshop/2014/first_service.txt =================================================================== --- /trunk/docs/workshop/2014/first_service.txt (revision 574) +++ /trunk/docs/workshop/2014/first_service.txt (revision 574) @@ -0,0 +1,376 @@ +.. _first_service: + +******************************* +Creating your first ZOO Service +******************************* + +.. contents:: Table of Contents + :depth: 5 + :backlinks: top + +Introduction +============ + +In this part, you will create and publish a simple ZOO-Service named ``Hello`` which +will simply return a hello message containing the input value provided. It will be usefull +to present in deeper details general concept on how ZOO-Kernel works and handles +Execute requests. + +Service and publication process overview +======================================== + +Before starting developing a ZOO Service, you should remember that in +ZOO-Project, a Service is a couple made of: + + * a metadata file: a ZOO Service Configuration File (ZCFG) containing metadata + informations about a Service (providing informations about default / supported + inputs and outputs for a Service) + * a Services Provider: it depends on the programming language used, but for Python it + is a module and for JavaScript a script file. + +To publish your Service, which means make your ZOO Kernel aware of its presence, +you should copy a ZCFG file in the directory where ``zoo_loader.cgi`` is located (in this workshop, ``/usr/lib/cgi-bin``) or in any subdirectory. + +.. warning:: only the ZCFG file is required for the Service to be considerate as + available. So if you don't get the Service Provider, obviously your Execute + request will fail as we will discuss later. + +Before publication, you should store your ongoing work, so you'll start by +creating a directory to store the files of your Services Provider: + +.. code-block:: none + + mkdir -p /home/user/zoo-ws/ws_sp/cgi-env + +Once the ZCFG and the Python module are both ready, you can publish simply +by copying the corresponding files in the same directory as the ZOO-Kernel. + +Creating your first ZCFG file +============================= + +You will start by creating the ZCFG file for the ``Hello`` Service. Edit the +``/home/user/zoo-ws/ws_sp/cgi-env/Hello.zcfg`` file +and add the following content: + +.. code-block:: none + :linenos: + + [Hello] + Title = Return a hello message. + Abstract = Create a welcome string. + processVersion = 2 + storeSupported = true + statusSupported = true + serviceProvider = test_service + serviceType = Python + + [name] + Title = Input string + Abstract = The string to insert in the hello message. + minOccurs = 1 + maxOccurs = 1 + + dataType = string + + + + + [Result] + Title = The resulting string + Abstract = The hello message containing the input string + + dataType = string + + + + +.. note:: the name of the ZCFG file and the name between braket (here ``[Hello]``) + should be the same and correspond to the function name you will define in your + Services provider. + +As you can see in the ZOO Service Configuration File presented above it is divided into +three distinct sections: + #. Main Metadata information (from line 2 to 8) + #. List of Inputs metadata information (from 9 line to 19) + #. List of Outputs metadata information (from line 20 to 28) + +You can get more informations about ZCFG from `the reference documentation +`__. + +If you copy the ``Hello.zcfg`` file in the same directory as your ZOO Kernel +then you will be able to request for DescribeProcess using the ``Hello`` +``Identifier``. The ``Hello`` service should also be listed from Capabilities +document. + +.. code-block:: none + cp /home/user/zoo-ws/ws_sp/cgi-env/Hello.zcfg /usr/lib/cgi-bin + +Test requests +================= + +In this section you will tests each WPS requests : GetCapabilities, +DescribeProcess and Execute. Note that only GetCapabilities and DescribeProcess +should work at this step. + +Test the GetCapabilities request +-------------------------------- + +If you run the ``GetCapabilities`` request: + +.. code-block:: none + + http://localhost/cgi-bin/zoo_loader.cgi?request=GetCapabilities&service=WPS + +Now, you should find your Hello Service in a ``Process`` node in +``ProcessOfferings``: + +.. code-block:: xml + + + Hello + Return a hello message. + Create a welcome string. + + +Test the DescribeProcess request +-------------------------------- + +You can access the ``ProcessDescription`` of the ``Hello`` service using the +following ``DescribeProcess`` request: + +.. code-block:: none + + http://localhost/cgi-bin/zoo_loader.cgi?request=DescribeProcess&service=WPS&version=1.0.0&Identifier=Hello + +You should get the following response: + +.. code-block:: xml + + + + Hello + Return a hello message. + Create a welcome string. + + + name + Input string + The string to insert in the hello message. + + string + + + + + + + Result + The resulting string + The hello message containing the input string + + string + + + + + + +Test the Execute request +------------------------ + +Obviously, you cannot run your Service because the Python file was not published +yet. If you try the following ``Execute`` request: + +.. code-block:: none + + http://localhost/cgi-bin/zoo_loader.cgi?request=Execute&service=WPS&version=1.0.0&Identifier=Hello&DataInputs=name=toto + +You should get an ExceptionReport similar to the one provided in the following, +which is normal behavior: + +.. code-block:: xml + + + + Python module test_service cannot be loaded. + + + +Implementing the Python Service +================================ + +General Principles +------------------ + +The most important thing you must know when implementing a new ZOO-Services +using the Python language is that the function corresponding to your Service +returns an integer value representing the status of execution +(``SERVICE_FAILED`` [#f1]_ or ``SERVICE_SUCCEEDED`` [#f2]_) and takes three +arguments (`Python dictionaries +`__): + + - ``conf`` : the main environment configuration (corresponding to the main.cfg content) + - ``inputs`` : the requested / default inputs (used to access input values) + - ``outputs`` : the requested / default outputs (used to store computation result) + +.. note:: when your service return ``SERVICE_FAILED`` you can set + ``conf["lenv"]["message"]`` to add a personalized message in the ExceptionReport + returned by the ZOO Kernel in such case. + +You get in the following a sample ``conf`` value based on the ``main.cfg`` file you +saw `before `__. + +.. code-block:: javascript + :linenos: + + { + "main": { + language: "en-US", + lang: "fr-FR,ja-JP", + version: "1.0.0", + encoding: "utf-8", + serverAddress: "http://localhost/cgi-bin/zoo_loader.cgi", + dataPath: "/var/data", + tmpPath: "/var/www/temp", + tmpUrl: "../temp", + cacheDir: "/var/www/temp/" + }, + "identification": { + title: "ZOO-Project Workshop - FOSS4G 2014", + keywords: "WPS,GIS,buffer", + abstract: "Deploying Web Processing Services using ZOO-Project – Examples of Python based WPS using PgRouting", + accessConstraints: "none", + fees: "None" + }, + "provider": { + positionName: "Developer", + providerName: "ZOO-Project", + addressAdministrativeArea: "Lattes", + addressCountry: "fr", + phoneVoice: "False", + addressPostalCode: "34970", + role: "Dev", + providerSite: "http://www.zoo-project.org", + phoneFacsimile: "False", + addressElectronicMailAddress: "gerald.fenoy@geolabs.fr", + addressCity: "Denver", + individualName: "Gérald FENOY" + } + +In the following you get a sample outputs value passed to a Python or a JavaScript Service: + +.. code-block:: javascript + :linenos: + + { + 'Result': { + 'mimeType': 'application/json', + 'inRequest': 'true', + 'encoding': 'UTF-8' + } + } + +.. note:: the ``inRequest`` value is set internally by the ZOO-Kernel and can be used to determine from the Service if the key was provided in the request. + +ZOO-Project provide a ZOO-API which was originally only available for +JavaScript services, but thanks to the work of the ZOO-Project +community, now you have also access to a ZOO-API when using +the Python language. Thanks to the Python ZOO-API you don't have to remember anymore +the value of SERVICE_SUCCEDED and SERVICE_FAILED, you +have the capability to translate any string from your Python service +by calling the ``_`` function (ie: ``zoo._('My string to +translate')``) or to update the current status of a running service by +using the ``update_status`` [#f4]_ function the same way you use it from +JavaScript or C services. + +The Hello Service +------------------------ + +You can copy and paste the following into the +``/home/user/zoo-ws/ws_sp/cgi-env/test_service.py`` file. + +.. code-block:: python + + import zoo + def Hello(conf,inputs,outputs): + outputs["Result"]["value"]=\ + "Hello "+inputs["name"]["value"]+" from the ZOO-Project Python world !" + return zoo.SERVICE_SUCCEEDED + +Once you finish editing the file, you should copy it in the ``/usr/lib/cgi-bin`` directory: + +.. code-block:: none + + sudo cp /home/user/zoo-ws/ws_sp/cgi-env/* /usr/lib/cgi-bin + + +Interracting with your service using Execute requests +===================================================== + +Now, you can request for Execute using the following basic url: + +.. code-block:: none + + http://localhost/cgi-bin/zoo_loader.cgi?request=Execute&service=WPS&version=1.0.0&Identifier=Hello&DataInputs=name=toto + +You can request the WPS Server to return a XML WPS Response containing the result of +your computation, requesting for ResponseDocument or you can access the data directly +requesting for RawDataOutput. + +* Sample request using the RawDataOutput parameter: + +.. code-block:: none + + http://localhost/cgi-bin/zoo_loader.cgi?request=Execute&service=WPS&version=1.0.0&Identifier=Hello&DataInputs=name=toto&RawDataOutput=Result + +* Sample request using the default ResponseDocument parameter: + +.. code-block:: none + + http://localhost/cgi-bin/zoo_loader.cgi?request=Execute&service=WPS&version=1.0.0&Identifier=Hello&DataInputs=name=toto&ResponseDocument=Result + +When you are using ResponseDocument there is specific attribut you can use to ask +the ZOO Kernel to store the result: ``asReference``. You can use the following example: + +.. code-block:: none + + http://localhost/cgi-bin/zoo_loader.cgi?request=Execute&service=WPS&version=1.0.0&Identifier=Hello&DataInputs=name=toto&ResponseDocument=Result@asReference=true + +When computation take long time, the client should request the +execution of a Service by setting both ``storeExecuteResponse`` and +``status`` parameter to true to force asynchronous execution. This +will make the ZOO-Kernel return, without waiting for the Service execution +completion but after starting another ZOO-Kernel process responsible +of the Service execution, a ResponseDocument containing a ``statusLocation`` +attribute which can be used to access the status of an ongoing service +or the result when the process ended [#f3]_. + +.. code-block:: none + + http://localhost/cgi-bin/zoo_loader.cgi?request=Execute&service=WPS&version=1.0.0&Identifier=Hello&DataInputs=name=toto&ResponseDocument=Result&storeExecuteResponse=true&status=true + +Conclusion +========== + +Even if this first service was really simple it was useful to illustrate how the +ZOO-Kernel fill ``conf``, ``inputs`` and ``outputs`` parameter prior to load +and run your function service, how to write a ZCFG file, how to publish a Services +Provider by placing the ZCFG and Python files in the same directory as the +ZOO-Kernel, then how to interract with your service using both +``GetCapabilities``, ``DescribeProcess`` and ``Execute`` requests. We will see +in the `next section `__ how to write similar requests +using the XML syntax. + +.. rubric:: Footnotes + +.. [#f1] ``SERVICE_FAILED=4`` +.. [#f2] ``SERVICE_SUCCEEDED=3`` +.. [#f4] sample use of update_status is available `here `_ +.. [#f3] To get on-going status url in ``statusLocation``, you'll + need to setup the `utils/status + `_ + Service. If you don't get this service available, the ZOO-Kernel will + simply give the url to a flat XML file stored on the server which will + contain, at the end of the execution, the result of the Service + execution. For more informations please take a look into the + reference `documentation `__. Index: /trunk/docs/workshop/2014/index.txt =================================================================== --- /trunk/docs/workshop/2014/index.txt (revision 574) +++ /trunk/docs/workshop/2014/index.txt (revision 574) @@ -0,0 +1,70 @@ +.. _workshop-foss4g-2014: + +########################################## +Deploying Web Processing Services using ZOO-Project – Examples of Python based WPS using PgRouting +########################################## + +:Author: Gérald Fenoy, Nicolas Bozon, Venkatesh Raghavan +:Contact: gerald.fenoy at geolabs.fr, nicolas.bozon at gmail.com, venka at osgeo.org +:Last Updated: $Date$ + +**************************************** +FOSS4G 2014 Portland +**************************************** + +.. image:: ./images/FOSS4G_Ad_200x100_2x.jpg + :target: http://2014.foss4g.org/ + :align: center + +************** +Sponsored By +************** + +.. image:: ../../_static/images/geolabs-logo.png + :target: http://www.geolabs.fr/ + +.. image:: ../../_static/images/apptech-logo.png + :target: http://www.apptec.co.jp/ + +.. image:: ../../_static/images/neogeo-logo.png + :target: http://www-neogeo-online.net/ + +.. image:: ../../_static/images/3liz-logo.png + :target: http://www.3liz.com/ + +.. image:: ../../_static/images/gateway-logo.png + :target: http://www.gatewaygeomatics.com/ + +******************************************* +Special thanks to our Knowledge Partners +******************************************* + +.. image:: ../../_static/images/ocu-logo.png + :target: http://www.osaka-cu.ac.jp/english/ + +.. image:: ../../_static/images/logo-fem.png + :target: http://www.fondazioneedmundmach.it/ + +.. image:: ../../_static/images/polimi-logo.png + :target: http://geomatica.como.polimi.it/ + +.. image:: ../../_static/images/gucas-logo.png + :target: http://www.gucas.ac.cn/gscasenglish/index.aspx + +.. image:: ../../_static/images/cumtb-logo.png + :target: http://www.cumtb.edu.cn/ + +.. image:: ../../_static/images/logo-supsi.png + :target: http://www.supsi.ch/home.html + +**************************** +WorkShop table of content +**************************** +.. toctree:: + :maxdepth: 5 + + introduction + using_zoo_from_osgeolivevm + first_service + building_blocks_presentation + js_services_chaining Index: /trunk/docs/workshop/2014/introduction.txt =================================================================== --- /trunk/docs/workshop/2014/introduction.txt (revision 574) +++ /trunk/docs/workshop/2014/introduction.txt (revision 574) @@ -0,0 +1,60 @@ +.. _introduction: + +************** +Introduction +************** + +.. contents:: Table of Contents + :depth: 5 + :backlinks: top + +What is ZOO ? +============= + +ZOO-Project is a WPS (Web Processing Service) open source project released under a `MIT/X-11 `__ style license. It provides an OGC WPS compliant developer-friendly framework to create and chain WPS Web services. ZOO is made of three parts: + +* `ZOO Kernel `__ : A powerful server-side C Kernel which makes it possible to manage and chain Web services coded in different programming languages. +* `ZOO Services `__ : A growing suite of example Web Services based on various open source libraries. +* `ZOO API `__ : A server-side JavaScript API able to call and chain the ZOO Services, which makes the development and chaining processes easier and faster. + +ZOO was designed to make the service creation and deployment easy, by providing a powerful system able to understand and execute WPS compliant queries. It supports seven programming languages, thus allowing you to create Web Services using the one you prefer. It also lets you use an existing code and to turn it as a WPS Service. +The current supported programming languages are the following: + +* C/C++ +* Python +* Perl +* Java +* Fortran +* PHP +* JavaScript + +More information on the project is available on the `ZOO-Project official website `__ . + +How does ZOO works ? +==================== + +ZOO is based on a C Kernel which is the ZOO-Project core system (aka ZOO-Kernel). The latter is able to dynamically load libraries and to handle them as on-demand Web services. + +A ZOO-Service is a link composed of a ZOO metadata file (.zcfg) and the code for the corresponding implementation. The metadata file describes the function that can be called using a WPS Execute Request, as well as the supported input/output formats. Service contains the algorithms and functions, and can be implemented using any of the supported languages. + +ZOO-Kernel works as CGI through Apache and can communicate with cartographic engines and Web mapping clients. It simply adds the WPS support to your spatial data infrastructure and your webmapping applications. It can use every GDAL/OGR supported formats as input data and create suitable vector or raster output for your cartographic engine and/or your web-mapping client application. + +What are we going to do in this workshop? +=============================== + +You will learn how to use ZOO-Kernel and how to create ZOO-Services using the OSGeoLiveDVD 7.9 `iso image `_ provided at the begining of this workshop on MapMint USB Sticks. Despite a pre-compiled ZOO 1.3.0 package is provided inside the official OSGeoLive, some optional supports are not available in the default setup and the ZOO-Kernel made available correspond to the 1.4-dev version, so let say the current version. So you will use the binary version of ZOO-Kernel available on the iso image provided. Configuration file and basic ways to use ZOO-Kernel and ZOO-Service will be presented. Then you will be invited to start programming your own simple service using Python language. Some ZOO-Services will be presented and individually tested inside a ready-to-use OpenLayers application. Finally, this services will be chained using the server-side Javascript ZOO-API. + +The whole workshop is organized step-by-step and numerous code snippets are available. The instructors will check the ZOO-Kernel is functioning on each machine and will assist you while coding. Technical questions are of course welcome during the workshop. + +Usefull tips for reading +======================== + +.. code-block:: guess + + this is a code block + +.. warning:: This is a warning message. + +.. note:: This is an important note. + +**Let's go !** Index: /trunk/docs/workshop/2014/js_services_chaining.txt =================================================================== --- /trunk/docs/workshop/2014/js_services_chaining.txt (revision 574) +++ /trunk/docs/workshop/2014/js_services_chaining.txt (revision 574) @@ -0,0 +1,593 @@ +.. _ogr_base_vect_ops: + +*************************************************************** +Playing with buildign blocks - Creating JavaScript Web Services +*************************************************************** + +.. contents:: Table of Contents + :depth: 5 + :backlinks: top + +Introduction +============ + + +This section illustrate how you can use JavaScript on the server-side to chain +services together to build new ones. You will create a ZOO Services Provider +using the services you seen before and the WFS server using the ZOO-API. The +final goal is to query all POIs included in a buffer around a feature and +to highlight them using a mask around this buffer. The following screenshot show +you the expected result: + +.. image:: ./images/BufferMaskAndRequest_Level_15.png + :width: 650px + :align: center + +For the routing interface result should look like this: + +.. image:: ./images/BufferMaskAndRequest_Routing_Level_15.png + :width: 650px + :align: center + +You can decompose the result above in two different ones: the mask around the +buffer and the points included in the buffer. So you will create two different +Services: one called ``BufferMask`` and another one called ``BufferRequest``. + +But before implementing any JavaScript Service, you will get an overview of how +to use ZOO-API from your ZOO-Project installation in the next section. + +As before, you first create a new directory to store files for your new Services +Provider: + +.. code-block:: guess + + mkdir -p ~/zoo-ws/jschains/cgi-env/ + + +ZOO-API Overview +================ + +ZOO-API and ZOO-Kernel JavaScript support make you able to run services +implemented in JavaScript on the server side. JavaScript is a popular programing +language but mostly used on the client side. Let say from a browser, but here it +is a bit different. + +To support JavaScript language ZOO-Kernel use the +`SpiderMonkey `__ API to create a +javascript runtime environment from which it will load your JS file then extract +the function corresponding to the service to run it using the prefilled +parameters. The JavaScript runtime environment created by the ZOO-Kernel +depend on your setup. If you placed the ``ZOO-api.js`` and ``ZOO-proj4js.js`` in +the same directory as your ZOO-Kernel it means that your environment will +contains ZOO-API and Proj4js which will be loaded before your service. In such case you can access to the Classes defined in the JavaScript ZOO-API +to manipulate geographic data, for more informations please refer to the +`ZOO-API Documentation `__. + +Even if it can be useful to run JavaScript on the server side, you should +remember that some basic JavaScript functions you are familiar with does not +exist or get a different behavior. For instance the simple ``alert`` +function will display messages in apache error logs rather than in a window when +used from a browser. The ``alert`` function can be used as follow: + +.. code-block:: guess + + alert("My alert message"); + +There is no XMLHttpRequest available in the JavaScript evironement your service +will run into. Hopefully, the ZOO-Kernel expose a C function to the JavaScript +world named: ``JSRequest``. This function make you able from your JavaScript +services to call other WPS services (locally or remotelly) or other kind OGC +services such as WFS. When you are using the ZOO-API it is possible to call +Services using a ``ZOO.Process`` instance [#f3]_, to parse WPS Responses using +``ZOO.Format.WPS`` +(cf. `ref `__). + +As for Python services you already seen in previous sections, the functions +corresponding to a Service should take three arguments: ``conf``, ``inputs`` and +``outputs`` [#f4]_. Nevertheless, as the ZOO-Kernel is not able to access the +values modified [#f5]_ by the Service code, rather than returning an integer as +in Python, here you'll need to return both the integer value representing the +Status of your Service in a JavaScript Object and the resulting ``outputs`` +values as an Object [#f6]_. You can see in the following an example of a JavaScript +Service code: + +.. code-block:: none + + function SampleService(conf,inputs,outputs){ + var resultValue=someComputation(inputs); + return + { + result: ZOO.SERVICE_SUCCEEDED, + outputs: { "Result": { "mimeType": "application/json", "value": resultValue } } + }; + } + +Before starting to implement the Services we will need to get our final +BufferRequest service, let start with a simplier one. + +The Mask Service +================ + +In this section you will learn how to create your first JavaScript service which +will simply return a rectangular mask around a selected feature. To build this +mask you will use the Buffer service to create a buffer big enough around a +selected geometry to cover a significant part of your map. You can see the +expected result in the following screenshot: + +.. image:: ./images/Mask_Level_12.png + :width: 650px + :align: center + +As before, you will first start by writting the ZCFG, then you will write the +JavaScript source code and finish by publishing your Services Provider. + +The ZCFG +-------- + +Open a file named +``~/zoo-ws/jschains/cgi-env/Mask.zcfg`` +with your favorite text editor and add the following content: + +.. code-block:: none + :linenos: + + [Mask] + Title = Compute mask + Abstract = Compute mask around a geometry + processVersion = 1 + storeSupported = true + statusSupported = true + serviceProvider = foss4gws.js + serviceType = JS + + [InputData] + Title = The feature + Abstract = The feature to run the service with + minOccurs = 1 + maxOccurs = 1 + + + mimeType = text/xml + encoding = utf-8 + + + + + [Result] + Title = The resulting feature + Abstract = The feature created by the service. + + + mimeType = application/json + + + + +Here you simply define one default ``ComplexData`` for both ``inputData`` and +``Result``: a GML and a GeoJSON respectively [#f7]_. + +The JavaScript service +---------------------- + +As you will have to request the Buffer service many times from your service, you +will first define a ``Buffer`` function as follow. It uses the ``ZOO.Process`` +to request the Buffer service you seen in the previous section. + +Open a file named +``~/zoo-ws/jschains/cgi-env/foss4gws.js`` and +add the following content: + +.. code-block:: javascript + :linenos: + + var zoo_url='http://localhost/cgi-bin/zoo_loader.cgi'; + var mapfile="/var/data/maps/project_WS2014.map"; + var mapserv_url="http://localhost/cgi-bin/mapserv?map="+mapfile; + + function Buffer(inputData,bDist){ + + // Create all required ZOO.formats + var fJ=new ZOO.Format.JSON(); + var fGJ=new ZOO.Format.GeoJSON(); + var fWPS=new ZOO.Format.WPS(); + + // Pass the value as json + var myInputs = { + InputPolygon: { type: 'complex', value: fGJ.write(inputData), mimeType: "application/json"}, + BufferDistance: {type: 'float', "value": bDist } + }; + var myOutputs= { Result: { type: 'RawDataOutput', "mimeType": "application/json" } }; + var myProcess = new ZOO.Process(zoo_url,'BufferPy'); + var myExecuteResult=myProcess.Execute(myInputs,myOutputs); + + return fGJ.read(myExecuteResult); + + } + +From line 12 to 16, you give a GeoJSON string (created from ``inputData``) for +InputPolygon and, on line 15, you set the BufferDistance value to ``bDist``. +On line 17, you define Result as a RawDataOutput, so you won'tl have to parse the +WPS response using the ZOO.Format.WPS. + +On line 18, you create a +`ZOO.Process `__ +instance providing the ZOO-Kernel url and the Service name. Then, on line 19, you +run the request passing inputs and outputs previously defined (from line 12 to 15). On line 21 you return the GeoJSON red. + +Now, you get your ``Buffer`` function, it is time to create your first JavaScript +service. So, edit your ``foss4gws.js`` file you created before and add the following content: + +.. code-block:: javascript + :linenos: + + function Mask(conf,inputs,outputs){ + + // Create all required ZOO.formats + var fGML=new ZOO.Format.GML(); + var fGJ=new ZOO.Format.GeoJSON(); + + // Read the input GML + var inputData=fGML.read(inputs["InputData"]["value"]); + + // Compute Buffer + var bufferResultAsJSON=Buffer(inputData,0.015); + + // Create the Buffer result BBOX and store its geometry in a ZOO.Feature + var bbox = new ZOO.Bounds(); + var bounds=bufferResultAsJSON[0].geometry.getVertices(); + for(var t in bounds){ + bbox.extend(bounds[t]); + } + var finalG=bbox.toGeometry(); + var result=new ZOO.Feature(finalG,{"name": "Result1000"}); + + // Return the created feature + return { + result: ZOO.SERVICE_SUCCEEDED, + outputs: { "Result": { mimeType: "application/json", value: fGJ.write(result) } } + }; + + } + +Publish and use your Service +---------------------------- + +Now you get both your ZCFG and your service code ready, you need to deploy your +new Services Provider using the following command: + +.. code-block:: bash + + sudo cp ~/zoo-ws/jschains/cgi-env/* /usr/lib/cgi-bin + +Now you are ready to use your JavaScript service by loading the following `url +`__, click on a street then click on +the "Mask" button. + +BufferMask Service +================== + +In this section you will implement a simple JavaScript service which will be able create +a hole in the mask you created in `previous section <#mask-service>`__. This service +will be used to highlight the buffer zone around a selected fature. You get a preview of +the expected result in the following screenshot: + +.. image:: ./images/BufferMask_Level_15.png + :width: 650px + :align: center + + +The ZCFG +-------- + +Open the file named +``~/zoo-ws/jschains/cgi-env/BufferMask.zcfg`` +with your favorite text editor and copy / paste the following content: + +.. code-block:: none + :linenos: + + [BufferMask] + Title = Compute buffer mask + Abstract = Compute buffer mask around a geometry + processVersion = 1 + storeSupported = true + statusSupported = true + serviceProvider = foss4gws.js + serviceType = JS + + [InputData] + Title = The feature + Abstract = The feature to run the service with + minOccurs = 1 + maxOccurs = 1 + + + mimeType = text/xml + encoding = utf-8 + + + + + [Result] + Title = The resulting feature + Abstract = The feature created by the service. + + + mimeType = application/json + + + + +This ZCFG is similar to the previous one. Please, refer to comments in the +`previous section <#the-zcfg>`__ for more informations. + +The JavaScript service +---------------------- + +In this Service you will use same source code (until line 19) you used in the +`previous section <#the-javascript-service>`__. Indeed, you should compute the Mask +as you did before then compute Buffer for creating a hole in the mask (on line 22) to run +the Difference service (from line 25 to 40). + +.. code-block:: guess + :linenos: + + function BufferMask(conf,inputs,outputs){ + + // Create all required ZOO.formats + var fGML=new ZOO.Format.GML(); + var fGJ=new ZOO.Format.GeoJSON(); + + // Read the input GML + var inputData=fGML.read(inputs["InputData"]["value"]); + + // Compute Buffer + var bufferResultAsJSON=Buffer(inputData,0.015); + + // Create the Buffer result BBOX + var bbox = new ZOO.Bounds(); + var bounds=bufferResultAsJSON[0].geometry.getVertices(); + for(var t in bounds){ + bbox.extend(bounds[t]); + } + var finalG=bbox.toGeometry(); + + // Compute Buffer standard buffer + var bufferResultAsJSON=Buffer(inputData,0.0015); + + // Request Difference service using Buffer result and features in the BBOX + var result=new ZOO.Feature(finalG,{"name": "Result1000"}); + var myProcess2 = new ZOO.Process(zoo_url,'DifferencePy'); + var myInputs2 = { + InputEntity1: { + type: 'complex', + value: fGJ.write(finalG), + mimeType: "application/json" + }, + InputEntity2: { + type: 'complex', + value: fGJ.write(bufferResultAsJSON), + mimeType: "application/json" + } + }; + var myOutputs2= {Result: {type: 'RawDataOutput', mimeType: "application/json" } }; + var myExecuteResult4=myProcess2.Execute(myInputs2,myOutputs2); + + // Return the bbox + var result=new ZOO.Feature(finalG,{"name": "Result1000"}); + return { + result: ZOO.SERVICE_SUCCEEDED, + outputs: { "Result": {mimeType: "application/json", value: myExecuteResult4 } } + }; + + } + +Publish and use your Service +---------------------------- + +Now, you can publish your service as you did `before <#publish-your-service>`__. To +use your service, please use the following `url +`__. + +BufferRequest service +====================== + +In this section, you will create a new Service: ``BufferRequest`` which will request +POIs included in the Buffer around a selected feature [#f8]_. You will use the ``poi`` +layer served as WFS through your local mapserver installation. You can see in the +following screenshot the expected result: + +.. image:: ./images/BufferRequest_Level_15.png + :width: 650px + :align: center + +The ZCFG +-------- + +Open the file named +``~/zoo-ws/jschains/cgi-env/BufferRequest.zcfg`` +with your favorite text editor and copy / paste the following content: + +.. code-block:: none + :linenos: + + [BufferRequest] + Title = Compute buffer request + Abstract = Compute buffer request around a geometry + processVersion = 1 + storeSupported = true + statusSupported = true + serviceProvider = foss4gws.js + serviceType = JS + + [InputData] + Title = The feature + Abstract = The feature to run the service with + minOccurs = 1 + maxOccurs = 1 + + + mimeType = text/xml + encoding = utf-8 + + + + + [Result] + Title = The resulting feature + Abstract = The feature created by the service. + + + mimeType = application/json + + + + + +The JavaScript code +------------------- + +As in the previous Service, you will compute a buffer around the input feature. But then +you will request POIs available in the Buffer extent using a WFS request to use them to +run ``Intersection`` service using the initial Buffer. The WFS request is useful to limit +the number of points to use when requesting the ``Intersection`` Service. + +.. code-block:: javascript + :linenos: + + function BufferRequest(conf,inputs,outputs){ + + // Create all required ZOO.formats + var fGJ=new ZOO.Format.GeoJSON(); + var fGML=new ZOO.Format.GML(); + + // Read the input GML + var inputData=fGML.read(inputs["InputData"]["value"]); + + // Compute Buffer + var bufferResultAsJSON=Buffer(inputData,0.0015); + + // Create the Buffer result BBOX + var bbox = new ZOO.Bounds(); + var bounds=bufferResultAsJSON[0].geometry.getVertices(); + for(var t in bounds){ + bbox.extend(bounds[t]); + } + + // Request Intersection service using Buffer result and WFS request using the + // BBOX + var myProcess2 = new ZOO.Process(zoo_url,'Intersection'); + var req="&SERVICE=WFS&version=1.0.0&request=GetFeature&typename=poi1"; + req+="&SRS=EPSG:4326&BBOX="; + var myInputs2 = { + InputEntity1: { + type: 'complex', + value: fGJ.write(bufferResultAsJSON), + mimeType: "application/json" + }, + InputEntity2: { + type: 'complex', + xlink: mapserv_url+req+bbox.left+","+bbox.bottom+","+bbox.right+","+bbox.top, + mimeType: "text/xml" + } + }; + var myOutputs2= {Result: { type: 'RawDataOutput', "mimeType": "application/json" } }; + var myExecuteResult4=myProcess2.Execute(myInputs2,myOutputs2); + + return { + result: ZOO.SERVICE_SUCCEEDED, + outputs: [ {name:"Result", mimeType: "application/json", value: myExecuteResult4} ] + }; + + } + +.. warning:: to take advantage of the ZOO-Kernel cache system, you directly use the WFS + request as ``xlink:href`` rather than value for ``InputEntity2`` (from line 31 to 34) and use ``text/xml`` ``mimeType`` + (on line 40). Indeed, the ZOO-API doesn't use the internal cache mechanisms. + + +Publish and use your Service +---------------------------- + +Now, you can publish your service as you did `before <#publish-your-service>`__. To +use your service, please use the following `url +`__. + +.. note:: You can click on "Buffer Request and Mask" to get the same result as presented + in `the initial screenshot <#introduction>`__. + + +Add Union into the chain +=================================== + +As you can see in the following screenshot, when using the Buffer +service using a feature collection containing more than one geometry, +the result is made of multiple geometries. So, running Buffer service +on the routing interface will result in multiple buffer: + +.. image:: ./images/Buffer_Routing_Level_15.png + :width: 650px + :align: center + +So, to get the same result as you got when selecting a single +road, you should use Union of geometry (input or the one outputed by the +``Buffer`` Service). As you are using the JavaScript ZOO-API, you can +simply update the ``Buffer`` JavaScript function you defined earlier, to +first call the Union of each geometry avaible in a feature collection +prior to request (or after requesting) the Buffer Service. Hopefully, +there is already this Python Service available, its name is +``UnionOne1``, so you just need to add it in your Service chain. + +Here is the final code for the Buffer JavaScript function: + +.. code-block:: javascript + :linenos: + + function Buffer(inputData,bDist){ + + // Create all required ZOO.formats + var fJ=new ZOO.Format.JSON(); + var fGJ=new ZOO.Format.GeoJSON(); + var fWPS=new ZOO.Format.WPS(); + + // Call the UnionOne1 Service + var myInputs0 = { + InputPolygon: { type: 'complex', value: fGJ.write(inputData), mimeType: "application/json"}, + BufferDistance: {type: 'float', "value": bDist } + }; + var myOutputs0= { Result: { type: 'RawDataOutput', "mimeType": "application/json" } }; + var myProcess0 = new ZOO.Process(zoo_url,'UnionOne1'); + var myExecuteResult0=myProcess0.Execute(myInputs0,myOutputs0); + + // Call the BufferPy Service + var myInputs = { + InputPolygon: { type: 'complex', value: myExecuteResult0, mimeType: "application/json"}, + BufferDistance: {type: 'float', "value": bDist } + }; + var myOutputs= { Result: { type: 'RawDataOutput', "mimeType": "application/json" } }; + var myProcess = new ZOO.Process(zoo_url,'BufferPy'); + var myExecuteResult=myProcess.Execute(myInputs,myOutputs); + + return fGJ.read(myExecuteResult); + + } + + +Conclusion +========== + +After understanding how basic Geometric Operation Services works, here you built step by step new JavaScript services which reuse the previous ones and combine them in different ways. This was achieved using the ZOO-API, composed by C functions exposed by the ZOO-Kernel to the JavaScript services runtime environement and the JS files which can be optionally installed. + +.. rubric:: Footnotes + +.. [#f3] The ``ZOO.Process`` class uses ``JSRequest`` (cf. `ref + `__). You will get example + of use `later <#the-javascript-service>`__. +.. [#f4] So ``conf``, ``inputs`` and ``outputs`` are simple JavaScript objects, similar + to the Python dictionaries used in the `previous section `__. +.. [#f5] Such as ``conf``, ``inputs`` and ``outputs``. +.. [#f6] You can also return a conf Object if you get any informations updated from your JavaScript service (such as cookie for instance) +.. [#f7] Using one of the available ``ZOO.formats`` you are also able to support various + ``ComplexData`` for both input and output of the service. To simplify the + presentation here, you will use only this default ones. +.. [#f8] So in the hole you created in the previous section. Index: /trunk/docs/workshop/2014/using_zoo_from_osgeolivevm.txt =================================================================== --- /trunk/docs/workshop/2014/using_zoo_from_osgeolivevm.txt (revision 574) +++ /trunk/docs/workshop/2014/using_zoo_from_osgeolivevm.txt (revision 574) @@ -0,0 +1,218 @@ +.. _using_zoo_from_osgeolivevm: + +******************************************************************** +Configuration and ZOO-Kernel use +******************************************************************** + +.. contents:: Table of Contents + :depth: 5 + :backlinks: top + +ZOO-Kernel Configuration +======================== + +As already said in introduction, an OSGeoLive Virtual Machine has been booted on your computer, allowing you to use ZOO-Kernel in a development environment directly. + +.. note:: we will use ZOO-Kernel or ``zoo_loader.cgi`` script without any distinction + in this document. + +General ZOO-Kernel settings are set in the ``main.cfg`` file located in the same directory as the ZOO-Kernel, so in ``/usr/lib/cgi-bin/``. This informations will be accessible from each services at runtime, so when you wil use Execute requests. You can see a typical ``main.cfg`` content in the following: + +.. code-block:: guess + :linenos: + + [headers] + X-Powered-By=ZOO-Project@MapMint + + [main] + encoding=utf-8 + dataPath=/var/data + tmpPath=/var/www/temp + cacheDir=/var/www/cache + version=1.0.0 + sessPath=/tmp + msOgcVersion=1.0.0 + serverAddress=http://localhost/cgi-bin/mm/zoo_loader.cgi + lang=fr-FR,ja-JP + language=en-US + mapserverAddress=http://localhost/cgi-bin/mapserv.cgi + tmpUrl=http://127.0.0.1/temp/ + + [identification] + keywords=WPS,GIS,buffer,MapMint,ZOO-Project + title=ZOO-Project Workshop - FOSS4G 2014 + abstract= Deploying Web Processing Services using ZOO-Project – Examples of Python based WPS using PgRouting + accessConstraints=none + fees=None + + [provider] + positionName=Developer + providerName=GeoLabs SARL + addressAdministrativeArea=False + addressDeliveryPoint=1280, avenue des Platanes + addressCountry=fr + phoneVoice=+33467430995 + addressPostalCode=34970 + role=Dev + providerSite=http://www.geolabs.fr + phoneFacsimile=False + addressElectronicMailAddress=gerald@geolabs.fr + addressCity=Lattes + individualName=Gérald FENOY + + +The ``main.cfg`` file contains metadata informations about the identification and provider but also some important settings. The file is composed of various sections, namely ``[main]``, ``[identification]`` and ``[provider]`` per default. + +From the ``[main]`` section settings are as follow: + * ``lang``: the supported languages separated by a coma (the first is the default one), + * ``version``: the supported WPS version, + * ``encoding``: the default encoding of WPS Responses, + * ``serverAddress``: the url to access your ZOO-Kernel instance, + * ``dataPath``: the path to store data files (when MapServer support was activated, + this directory is used to store mapfiles and data). + * ``tmpPath``: the path to store temporary files (such as ExecuteResponse when + storeExecuteResponse was set to true), + * ``tmpUrl``: a url relative to ``serverAddress`` to access the temporary file, + * ``cacheDir``: the path to store cached request files [#f1]_ (optional), + * ``mapservAddress``: your local MapServer address (optional), + * ``msOgcVersion``: the version for all supported OGC Web Services output [#f2]_ + (optional). + +The ``[identification]`` and ``[provider]`` section are specific to OGC metadata and +should be set [#f3]_. + +Obviously, you are free to add new sections to this file if you need +more [#f8]_. Nevertheless, you have to know +that there is some specific names you should use only for specific +purposes: ``[headers]``, ``[mapserver]``, ``[env]``, ``[lenv]`` and ``[senv]``. + +.. warning:: ``[senv]`` and ``[lenv]`` are used / produced on runtime internaly by the ZOO-Kernel and should be defined only from the Service code. + +The ``headers`` section is used to define your own HTTP Response +headers. You may take a look at headers returned by web site such as +http://www.zoo-project.org by using curl command line tool for +instance and notice the specific heder ``X-Powered-By: Zoo-Project@Trac``. + +.. warning:: There is no reason to define basic headers such as + ``Content-Type`` or ``encoding`` as they will be overwritten at runtime by the + ZOO-Kernel. + +The ``mapserver`` section is used to store specific mapserver configuration +parameters such as `PROJ_LIB` and `GDAL_DATA` or any other you want to be set to +make your MapServer working. + +.. note:: the ``mapserver`` section is mainly used on WIN32 platform + + +The ``env`` section is used to store specific environment variables you want to be set +prior to load your Services Provider and run your Service. A typical example, is when your +Service requires to access to a X server running on framebuffer, then you will have to +set the ``DISPLAY`` environnement variable, in this case you would add +``DISPLAY=:1`` line in your ``[env]`` section. + +The ``lenv`` is used to store runtime informations automatically set by the +ZOO-Kernel before running your service and can be accesses / updated from it: + * ``sid`` (r): the service unique identifier, + * ``status`` (rw): the current progress value (value between 0 and 100, percent), + * ``cwd`` (r): the current working directory of the ZOO-Kernel, + * ``message`` (rw): an error message when returning ``SERVICE_FAILED`` (optional), + * ``cookie`` (rw): the cookie your service want to return to the client (for authentication + purpose or tracking). + +The ``senv`` is used to store session informations on the server +side. You can then access them automatically from service if the +server is requested using a valid cookie (as defined in ``lenv > +cookie``). The ZOO-Kernel will store on disk the values set in the +``senv`` maps, then load it and dynamically add its content to the one +available in the ``main.cfg``. The ``senv`` section should contain at +least: + * ``XXX``: the session unique identifier where ``XXX`` is the name included in the + returned cookie. + +.. _cookie_example: + +For instance, if you get the following in your Service source code [#f4]_ : + +.. code-block:: python + + conf["lenv"]["cookie"]="XXX=XXX1000000; path=/" + conf["senv"]={"XXX": "XXX1000000","login": "demoUser"} + +That means that the ZOO-Kernel will create a file ``sess_XXX1000000.cfg`` in the +``cacheDir`` and return the specified cookie to the client. Each time the client will +request the ZOO-Kernel using the Cookie, it will automatically load the value stored +before running your service. You can then easilly access this informations from your +service source code. This functionality won't be used in the following presentation. + +Testing the ZOO installation with GetCapabilities +================================================= + +Once you have a main.cfg file available in the same directory as your +ZOO-Kernel, then you can use `GetCapablities`. Indeed, to answer such +kind of requests, the ZOO-Kernel will simply parse the `main.cfg` file +(to gather global informations), then parse individually each zcfg +files (if any) contained in the same directory or in sub-directories +[#f9]_, then return a well formed `Capabilities` document. + +You can request ZOO-Kernel using the following link from your Internet browser: + +http://localhost/cgi-bin/zoo_loader.cgi?Request=GetCapabilities&Service=WPS + +You should get a valid Capabilities XML document, looking like the following : + +.. image:: ./images/GC.png + :width: 650px + :align: center + +Please note that some Process nodes are returned in the +ProcessOfferings section, as somes are available already on OSGeoLive +DVD. You can also run a GetCapabilities request from the command line, +using the following command: + +.. code-block:: bash + + cd /usr/lib/cgi-bin + ./zoo_loader.cgi “request=GetCapabilities&service=WPS” | less + +The same result as in your browser will be returned, as shown in the following screenshot: + +.. image:: ./images/GC_CL.png + :width: 450px + :align: center + +Invoking ZOO Kernel from the command line can be helpful during +development process of new Services for debugging purpose. If you +need to simulate POST request from the command line, then you can use +the following: + +.. code-block:: bash + + cd /usr/lib/cgi-bin + # Download the sample GetCapabilities request + curl -o /tmp/10_wpsGetCapabilities_request.xml http://schemas.opengis.net/wps/1.0.0/examples/10_wpsGetCapabilities_request.xml + # Define required environment settings + export REQUEST_METHOD=POST + export CONTENT_TYPE=text/xml + # Run the request downloaded + ./zoo_loader.cgi < /tmp/10_wpsGetCapabilities_request.xml | less + +You should have the same result as presented before. + +.. rubric:: Footnotes + +.. [#f1] when you use GET requests passed through ``xlink:href`` the ZOO-Kernel will + execute the request only once, the first time you will ask for this ressource and it will + store on disk the result. The next time you will need the same feature, the cached file + will be used which make your process running faster. If ``cachedir`` was not + specified in the ``main.cfg`` then ``tmpPath`` value will be used. +.. [#f2] since version 1.3.0, when MapServer is activated, your service can automatically + return a WMS, WFS or WCS request to expose your data. Your can set here the specific + version number you want to use to request your local MapServer setup. It depends + mostly on the client capability to deal with specific OGC Web Services version. +.. [#f3] since version 1.3.0, when MapServer is activated, the same metadata will be used + for setting metadata for OGC Web Services. +.. [#f8] you can take a quick look into the mapmint ``main.cfg`` file + which is available in `/usr/lib/cgi-bin/mm/` directory to have + example of sections use. +.. [#f4] If you're not familiar with ZOO-Project, you can `pass `__ this part and come to it after the next section. +.. [#f9] sub-directories listing is available from `revision 469 `__.