Open WPS Platform

Comment utiliser le support W*S MapServer interne

Authors:Nicolas Bozon, Gérald Fenoy, Jeff McKenna
Last Updated:$Date$

L’idée clé de l’implémentation du support W*S MapServer est qu’elle ne nécessite pas de changer une seule ligne du code source du service pour activer la publication automatique de votre résultat en tant que ressource WMS/WFS ou WCS. Vous avez simplement besoin de modifier le fichier zcfg correspondant à votre service pour le faire fonctionner.

Vous trouverez ici un aperçu de la manière d’ installer le support W*S MapServer, la configuration requise et les mécanismes internes.

Comment le faire fonctionner ?

Prérequis

  • version trunk du dernier ZOO-Kernel

  • Version de MapServer >= 6.0.1

Etapes d’installation

En premier, téléchargez le dernier répertoire zoo-kernel disponible sur le svn. Faites ça depuis le répertoire de votre précédent checkout (où les répertoires zoo-api, zoo-services et zoo-kernel sont disponibles), nous utiliserons <PREV_SVN_CO> ici pour ce répertoire:

cd <PREV_SVN_CO>
svn checkout http://svn.zoo-project.org/svn/trunk/zoo-kernel zoo-kernel-ms

Décompressez l’archive MapServer (c’est à dire mapserver-6.0.1.tar.bz2) dans /tmp/zoo-ms-src, puis compilez MapServer en utilisant la commande suivante:

cd /tmp/zoo-ms-src/mapserver-6.0.1
./configure --with-ogr=/usr/bin/gdal-config --with-gdal=/usr/bin/gdal-config \
               --with-proj --with-curl --with-sos --with-wfsclient --with-wmsclient \
               --with-wcs --with-wfs --with-postgis --with-kml=yes --with-geos \
               --with-xml --with-xslt --with-threads --with-cairo
make
cp mapserv /usr/lib/cgi-bin

Autotools a été mis à jour pour ajouter l’option configure --with-mapserver. Depuis le répertoire trunk SVN de votre ZOO-Project, compilez le ZOO-Kernel en utilisant la commande suivante:

cd zoo-kernel-ms
autoconf
./configure --with-python --with-mapserver=/tmp/zoo-ms-src/mapserver-6.0.1
make
cp zoo_loader.cgi /usr/lib/cgi-bin

Etapes de configuration

Fichier de configuration principal

Ajoutez le contenu suivant à votre fichier /usr/lib/cgi-bin/main.cfg

dans la section [main]:

dataPath = /var/www/temp/
mapserverAddress=http://localhost/cgi-bin/mapserv

Le répertoire dataPath doit exister et être disponible en écriture pour l’utilisateur apache. Dans ce répertoire, un fichier symbols.sym doit être présent, contenant ce qui suit:

SYMBOLSET
SYMBOL
  NAME "circle"
  TYPE ellipse
  FILLED true
  POINTS
    1 1
  END
END
END

Une seule définition de symbole est requise avec n’importe quel nom, utilisé pour la sortie du service WMS.

Maintenant, votre ZOO-Kernel a le support de MapServer prêt à être utilisé. Notez que si vous n’ajoutez pas mapserverAddress alors cela impliquera une erreur de segmentation du ZOO-Kernel (la vérification de la valeur NULL devrait corriger ce comportement).

Ici vous pouvez optionnellement ajouter un paramètre msOgcVersion pour spécifier quelle version du WebService OGC vous voulez utiliser pour chaque service. Par exemple, si vous voulez forcer la version 1.0.0, vous pouvez définir ce qui suit dans la section [main] de votre fichier main.cfg:

msOgcVersion=1.0.0

Fichier de configuration de service

Pour activer les sorties des WebServices MapServer pour un service, vous devez ajouter un paramètre spécifique dans le bloc <Default> ou <Supported>: useMapserver. Cela peut prendre la valeur true ou ne doit pas apparaître. Si true, cela signifie que le résultat en sortie est un source de données compatible OGR / GDAL et que vous voulez qu’elle soit mise à disposition comme une instance de serveur web OGC (WMS/WFS/WCS).

Vous obtenez un paramètre optionnel, pour utiliser un bloc de style MapServer personnalisé (utilisé pour les sources de données vecteur seulement): msStyle. Par exemple:

msStyle = STYLE COLOR 125 0 105 OUTLINECOLOR 0 0 0 WIDTH 3 END

Vous avez le même paramètre optionnel msOgcVersion comme pour le main.cfg. Il spécifiera que c’est la version du protocole spécifique que le service veut utiliser (ainsi, vous pourrez peut être aussi définir localement le service plutôt que globalement).

Quand vous ajoutez l’option useMapserver à un bloc de sortie <Default> ou <Supported>, alors vous devez savoir quels sont les mimeType sensibles:

  • text/xml: implique que la donnée en sortie sera accessible via une requête GetFeature WFS (le protocole par défaut est la version 1.1.0)

  • image/tiff: implique que la donnée en sortie sera accessible via une requête GetCoverage WCS (le protocole par défaut est la version 2.0.0)

  • n’importe quel autre type de mimeType couplé avec l’option useMapserver: implique que la donnée en sortie sera accessible via une requête GetMap WMS (vous avez à vous limiter à ce que votre installation MapServer supporte, un requête GetCapabilities renvoie l’information sur les mimeType supportés en sortie) (le protocole par défaut est la version 1.3.0)

Comment cela fonctionne-t-il ?

Quoi que votre service retourne comme sortie mimeType par défaut, celui-ci sera utilisé quand une sortie incluant l’option useMapserver a été trouvée.

Ainsi si vous avez les blocs suivants <Default> et <Supported> dans le fichier de configuration ZOO de votre service:

<Default>
 mimeType = text/xml
 encoding = UTF-8
 schema = http://schemas.opengis.net/gml/3.1.0/base/feature.xsd
</Default>
<Supported>
 mimeType = image/png
 useMapserver = true
</Supported>

Cela signifie que par défaut, votre service retourne des objets GML 3.1. Quand le client demande un mimeType=image/png, alors le ZOO-Kernel détectera que ce mimeType a l’option useMapServer définie à true, ainsi il:

  1. exécutera le service utilisant la définition du bloc <Default> (cela doit être compréhensible pour GDAL/OGR)

  2. stockera le résultat du service sur le disque (dans [main] > répertoire dataPath)

  3. écrira un Mapfile (dans le [main] > répertoire dataPath) utilisant API C de MapServer pour configurer à la fois les services WMS et WFS.

Note

même si vous ne demandez pas cela, le Mapfile résultant inclue à la fois la configuration pour le WMS et le WFS dans le cas des sources de données vecteur.

Si votre sortie de service renvoie un fichier raster, alors le comportement est assez similaire excepté que le ZOO-Kernel configurera à la fois les services WMS et WCS pour le résultat du service. Ici vous ne pouvez définir votre propre style. Cependant, quand une bande raster est retournée alors le ZOO-Kernel peut utiliser ses propres définitions par défaut pour classifier le raster en utilisant des intervalles équivalents (vous pouvez facilement voir cela dans le Mapfile produit), cette classification est spécifique au protocole WMS. Vous devriez ajouter un paramètre msClassify et le définir à true dans votre noeud ComplexData de sortie <Default> ou <Supported> pour activer cette classification. Note spéciale pour les implémentations clientes

Notez qu’en fonction de la requête, le ZOO-Kernel peut retourner un en-tête d’emplacement.

Différents types de requêtes:

  • ResponseDocument=XXXX@asReference=true - dans ce cas, le Kernel retournera la requête GetMap/GetFeature/GetCoverage sous forme KVP dans le href du résultat.

  • ResponseDocument=XXXX@asReference=false - dans ce cas, le Kernel retournera le résultat qu’il obtiendra en utilisant la requête GetMap/GetFeature/GetCoverage sous forme KVP utilisée pour le href dans le cas précédent.

  • RawDataOutput=XXXX@asReference=true/false - dans ce cas, le Kernel retournera la requête GetMap/GetFeature/GetCoverage sous forme KVP dans l’en-tête d’emplacement spécifique, qui implique que le navigateur doive suivre et interroger MapServer directement.

Cas d’utilisations exemples simples

Considérez le service existant BufferPy de zoo-services/ogr-base-vect-ops-py. Définissez le contenu suivant vers votre fichier BufferPy.zcfg local dans la définition de sortie Result, ensuite copiez-le dans /usr/lib/cgi-bin/:

<Default>
 mimeType = text/xml
 encoding = UTF-8
 schema = http://schemas.opengis.net/gml/3.1.0/base/feature.xsd
 useMapserver = true
</Default>
<Supported>
 mimeType = image/png
 useMapserver = true
 asReference = true
 msStyle = STYLE COLOR 125 0 105 OUTLINECOLOR 0 0 0 WIDTH 3 END
</Supported>
<Supported>
 mimeType = image/tif
 useMapserver = true
 asReference = true
 msStyle = STYLE COLOR 125 0 105 OUTLINECOLOR 0 0 0 WIDTH 3 END
</Supported>
<Supported>
 mimeType = application/vnd.google-earth.kmz
 useMapserver = true
 asReference = true
 msStyle = STYLE COLOR 125 0 105 OUTLINECOLOR 0 0 0 WIDTH 3 END
</Supported>

Ces modifications rendent votre service prêt pour retourner les résultats comme requêtes GetMap WMS ou GetFeature WFS. Notez que certains bugs ont lieu localement en utilisant la sortie application/vnd.google-earth.kmz.

En utilisant le code de service simple suivant, nous obtenons un service capable de produire en sortie n’importe quel type de fichiers internet (utile pour tester cette fonctionnalité):

import zoo
def HelloPy(conf,inputs,outputs):
        outputs["Result"]["value"]=inputs["a"]["value"]
        return zoo.SERVICE_SUCCEEDED

Définissez la sortie [Result] dans votre fichier HelloPy.zcfg avec le contenu du bloc ComplexData suivant:

<Default>
 mimeType = image/png
 useMapServer = true
</Default>
<Supported>
 mimeType = image/tiff
 useMapServer = true
</Supported>
<Supported>
 mimeType = text/xml
 useMapServer = true
</Supported>

Cela signifie que mimeType en sortie par défaut est image/png, ainsi une requête GetMap WMS sera retournée, ou l’image/tiff résultante sera retournée comme une requête GetCoverage WCS.

Avec ce simple service, vous pouvez tester les nouvelles capacités à produire un résultat comme un WebServices pour chacun des mimeTypes. Notez, que que vous aurez probablement un mimeType faux, comme celui par défaut a été défini à image/png.

Il y a un support pour les ShapeFiles zippés mais je doute qu’il soit vraiment utile. De toute façon, comme il est présent vous pouvez le tester facilement en passant un fichier zip dans xlink:href pour la valeur a du service HelloPy.

Essais

En utilisant le code de service HelloPy simple, vous pouvez utiliser les urls suivantes, notez que cela suppose que vous ayez un fichier http://localhost/data/data.zip disponible contenant un ShapeFile et un http://localhost/data/demo.tif:

Test 1: Accéder à un Shapefile distant zippé en tant que requête GetFeatures WFS

http://localhost/cgi-bin/zoo_loader.cgi?request=Execute&service=WPS&version=1.0.0&Identifier=HelloPy&DataInputs=a=Reference@xlink:href=http://localhost/data/data.zip&ResponseDocument=Result@asReference=true@mimetype=text/xml

Test 2: Accéder à un Shapefile distant zippé en tant que requête GetMap WMS

http://localhost/cgi-bin/zoo_loader.cgi?request=Execute&service=WPS&version=1.0.0&Identifier=HelloPy&DataInputs=a=Reference@xlink:href=http://localhost/data/data.zip&ResponseDocument=Result@asReference=true@mimetype=image/png

Test 3: Accéder à un tiff distant en tant que requête GetMap WMS:

http://localhost/cgi-bin/zoo_loader.cgi?request=Execute&service=WPS&version=1.0.0&Identifier=HelloPy&DataInputs=a=Reference@xlink:href=http://localhost/data/data.tiff&ResponseDocument=Result@asReference=true@mimetype=image/png

Test 4: Accéder à un tiff distant en tant que requête GetMap WCS:

http://localhost/cgi-bin/zoo_loader.cgi?request=Execute&service=WPS&version=1.0.0&Identifier=HelloPy&DataInputs=a=Reference@xlink:href=http://localhost/data/data.tiff&ResponseDocument=Result@asReference=true@mimetype=image/tiff