UMN MapServer est un serveur cartographique prenant en charge un grand nombre de formats de fichier. Il est possible de l'utiliser en mode CGI ou à travers des langages de script tels que PHP, Ruby, Java, C#, etc à l'aide de MapScript. MapServer constitue donc un environnement de développement d'outils plus qu'un outil en lui même prêt à être installé et à être utilisé directement.
Cet article a pour but de présenter les différentes nouveautés et corrections importantes de cette nouvelle version. Cette présentation n'est pas forcément exhaustive et il est préférable de se tourner vers le site officiel de MapServer. Ce document est composé de diverses traductions des RFC et documentations écrites suite à ces changements. Il se peut que certaines parties n'aient pas été développées, la documentation n'ayant pas encore été mise à jour !
Au niveau des nouveautés de cette version majeure (1), nous trouvons au niveau du coeur de MapServer : une API d'interface de rendu, le refactoring de l'interpréteur des Expressions dans MapServer (MS RFC 64) et les requêtes en une seule passe (MS RFC 65), au niveau des améliorations : la sortie KML, amélioration de la gestion des étiquettes, amélioration de la gestion des styles des features, de nouveaux formats pour la requête GetFeature du service WFS, un visualiseur OpenLayers interne, une meilleure gestion des fichiers temporaires, la possibilité d'activer ou pas les services OGC, la fusion et le cluster des features.
Comme d'habitude d'autres améliorations sont également présentes. Celles-ci améliorent encore MapServer, pour une liste de ces améliorations lisez le fichier History.
Comme pour chaque version de MapServer, mais en particulier pour celle-ci, nous vous invitons à lire le fichier de migration réalisé par l'équipe de développeur de MapServer : http://trac.osgeo.org/mapserver/browser/trunk/mapserver/MIGRATION_GUIDE.txt.
Date des sorties des versions intermédiaires
- Sortie prévue : 13-05-2011
- Version RC : 28-04-2011, 06-05-2011
- Versions béta : 09-03-2011, 18-03-2011, 23-03-2011, 30-03-2011, 06-04-2011, 13-04-2011, 20-04-2011
- Prochaine version : 6.0.1,
Nouveautés
Nouveautés qui peuvent modifier le comportement des applications
API de rendu d'interface (MS RFC 54)
- Développeur(s) : Thomas Bonfort et Frank Warmerdam
- http://mapserver.org/trunk/development/rfc/ms-rfc-54.html#rfc54
L'objet de ce développement est de créer une API pour brancher des moteurs de rendu différents en fonction du format de sortie voulu, pour l’anecdote cette API fonctionne d'une manière similaire à la lecture des données.
La raison de ce refactoring est que dans le code actuel chaque moteur est responsable à la fois des fonctionnalités de dessin bas niveau (par exemple les tirets, le remplissage, la sémiologie) et de l'interprétation de haut niveau de la combinaison des mots-clé du mapfile (par exemple ajustement des tailles en fonction de l'échelle, orientation en fonction de la direction de la ligne pour les symboles, etc.). Cela entraine beaucoup trop de duplication de code et une difficulté dans sa maintenance (source : RFC).
Dans un premier temps le moteur cairo (http://cairograhpics.org) sera ajouté à cette architecture, et supportera les formats raster traditionnels (png, jpeg) ainsi que les formats vecteurs (pdf, svg). Les gestions d'OpenGL et du KML seront ajoutés de la même manière. Lors de cette phase, les nouveaux moteurs de rendu existeront en parallèle avec les anciens et les moteurs existants ne seront pas affectés (source : RFC).
Dans une deuxième phase, les moteurs existants seront portés vers la nouvelle architecture. Idéalement tous les moteurs seront portés à la nouvelle architecture en fonction du temps et du financement. Les moteurs PDF et SVG pourront être remplacés directement par ceux fournis par cairo.
Le moteur GD ne sera pas porté vers cette nouvelle API car les performances n'auraient pas été au rendez-vous.
Révision du parseur d'expression de MapServer (MS RFC 64)
- Développeur(s) : Steve Lime
- http://mapserver.org/trunk/development/rfc/ms-rfc-64.html#rfc64
L'objet de cette RFC est de revoir le parseur d'expression (i.e. le code qui interprète les expressions utilisées dans le mapfile, par exemple [name] = “Yves”) et en particulier les endroits où celui-ci est utilisé. Les modifications pouvant avoir un impact sur les expressions des requêtes et particulièrement aux bases de données. Un objectif de ces modifications est l'implémentation des expressions de filtres de l'OGC en une seule passe et indépendamment du pilote.
Le fonctionnement des anciennes versions est celui-ci :
- duplication de la chaîne d'expression
- substitution des attributs dans la chaîne (par exemple '[name]' ⇒ 'Anoka')
- interprétation avec le parseur
Les avantages sont que cela est simple et cela fonctionne. Les désavantages sont qu'on ne peut pas réaliser des expressions complexes et la substitution et le parsage doit être réalisé pour chaque feature.
Un certain nombre de changements va avoir lieu, le changement majeur implique la manière dont les expressions locales fonctionnent. Des fonctionnalités additionnelles vont être apportées à ce changement majeur pour apporter des nouvelles possibilités à MapServer.
Extension de la grammaire du parseur pour gérer les opérateurs spatiaux
Il y a deux types de tokens liés aux géométries : 1) une liaison avec les géométries, une référence aux géométries est évaluée et 2) géométries au format texte, les géométries décrites en tant que WKT au sein de la chaîne d'expression. Par exemple :
Dans l'expression :
EXPRESSION (fromText('POINT(500000 5000000)') Intersects [shape])
1) fromText('POINT(500000 5000000)') définie une chaîne littérale d'une géométrie 2) [shape] est la liaison avec la géométrie
Extension de la grammaire pour gérer les fonctions spatiales
Au travers de la gestion des objets complexes de nouvelles fonctions apparaissent :
EXPRESSION (area([shape]) < 100000)
ou également sur des opérateurs géographiques.
Traitement sensible au contexte
Le parseur est censé renvoyer une valeur booléenne (true ou false) jusqu'aux versions actuelles, maintenant il n'est plus limité à ces valeurs et permet de réaliser des traitements dans d'autres situations. Deux endroits sont maintenant possible.
- Class TEXT Parameter
Pour le moment vous pouvez écrire :
CLASS
...
TEXT ([area] acres)
END
Cela se comporte comme si la valeur TEXT est une expression (et elle était stockée en tant que telle) mais n'est pas évalué en tant qu'expression. Une demande présentant ce qui peut être fait se trouve dans le ticket http://trac.osgeo.org/mapserver/ticket/2950, des fonctions toString, round et commify peuvent maintenant être utilisées :
TEXT (commify(toString([area]*0.000247105381,"%.2f")) + ' ac')
ce qui converti des surfaces des m² en acres, truncate le résultat à deux décimals ajoute une virgule : 213234.123455 ⇒ 213,234.12 pour un meilleur affichage.
- Style GEOMTRANSFORM
GEOMTRANSFORM est maintenant utilisée comme expression contrairement à l'implémentation originelle. Le parseur a été étendu pour gérer l'opérateur spatial Buffer :
STYLE
GEOMTRANSFORM (buffer([shape], -3))
...
END
Cela réalise un buffer sur la géométrie avant le rendu. Cet effet est appliqué au niveau de la CLASS, après que la carte ait été convertie en image. La valeur du buffer est en pixel.
Expression utilisée ailleurs
Les expressions sont également utilisées dans les paramètres REQUIRES/LABELREQUIRES et avec les rasters. Dans le cas des paramètres REQUIRES/LABELREQUIRES le fonctionnement ne sera pas modifié.
L'utilisation de cette nouvelle version du parseur devrait permettre un traitement des rasters sensiblement plus rapide mais également utiliser des fonctions spatiales comme par exemple créer un masque pour n'afficher que les pixels dans une géométrie.
Problèmes de compatibilité arrière
Très peu. Ces modifications seront transparentes pour l'utilisateur. Les opérateurs additionnels, fonctions et contextes sont de nouvelles fonctionnalités.
Sommaire de la grammaire (les nouveaux sont en gras) :
- Operateurs logiques : AND, OR, NOT
- Opéateurs de comparaison : =, =*, !=, >, <, >=, ⇐, ~, ~*, in
- Opérateurs de comparaison spatial : intersects, disjoint, touches, overlaps, crosses, within, contains, beyond, dwithin
- Fonctions : length, commify, round, tostring
- Fonctions spatiales : fromtext, area, distance, buffer
Modification de la requête en seule passe (MS RFC 65)
- Développeur(s) : Steve Lime
- http://mapserver.org/trunk/development/rfc/ms-rfc-65.html#rfc65
Ces modifications consistent à une simplification du travail qui a été effectué lors de la release précédente (la 5.6). À ce moment un premier travail a été effectué mais il s'avère insuffisant même s'il a amélioré les choses. Avant la 5.6, une première requête permettait de récupérer les géométries potentielles, puis n requêtes plus petites pour récupérer les résultats, cela été lent particulièrement pour les serveurs de bases de données. À partir de la 5.6, seulement deux requêtes sont effectuées.
Les modifications apportées seront invisibles pour l'utilisateur (bien que plus rapide) sauf pour MapScript.
Améliorations et nouvelles fonctionnalités
Gestion du rendu OpenGL (MS RFC 50)
- Développeur(s) : Toby Rahilly, Jonathan Bourke
- http://mapserver.org/trunk/development/rfc/ms-rfc-50.html#rfc50
Cette nouvelle fonctionnalité apporte l'utilisation du module Opengl pour le rendu à MapServer pour un rendu plus rapide des images.
Jusqu'à maintenant MapServer gérait le rendu via la bibliothèque AGG pour des images de haute qualité et anti-aliasées. De plus elle est significativement plus rapide que le rendu par GD. Mais elle n'est pas assez rapide dans certain cas comme le rendu à la demande.
OpenGL est une solution pour fournir des rendus performants en utilisant du matériel conçu pour le rendu en temps réel. Les tests effectués ont montré qu'OpenGL augmentait la rapidité de rendu significativement par rapport à celle avec AGG.
Solution technique
Le moteur de rendu OpenGL est similaire à celui d'AGG. L'atout d'OpenGL est qu'il peut réaliser des pré-rendu pour les textures. Tous les symbols peuvent être pré-générés et stockés comme texture OpenGL et simplement copiés dans l'image lors de leurs utilisations. Cela accroit grandement la vitesse de rendu de symboles complexes et fortement utilisés, comme les symboles des réseaux routiers, car non seulement ils ne sont pas utilisés qu'une fois mais OpenGL gère la répétition et la transformation des textures. Les étiquettes bénéficient également de cette méthode, puisque l'alphabet peut être pré-généré et stocké sous forme de textures. Lorsqu'une étiquette courbe doit être dessinée, le module OpenGL place et réalise une rotation des textures.
Les textures pré-générées des symbols peuvent aussi être partagées au sein de différentes instances de rendu de carte. Lorsqu'un mapfile est utilisé pour un rendu via OpenGL, tous les symbols sont pré-générés et stockés. Cela améliore les performances de rendu par batch.
Mapfiles
Un objet OUTPUTFORMAT ressemblera à ceci :
OUTPUTFORMAT
NAME 'OGL_PNG24'
DRIVER OGL/PNG
IMAGEMODE RGB
END
Kml Output (MS RFC 58)
- Développeur(s) : Dvaid Kana, Thomas.Bonfort, Yewondwossen Assefa, Michael Smith
- http://mapserver.org/trunk/development/rfc/ms-rfc-58.html
Le travail initial a été réalisé par David Kana lors du Google Summer of Code de 2009. Le code pour le rendu KML est basé sur la nouvelle API du moteur de rendu décrit dans la RFC 54. La première intention était d'utiliser la bibliothèque KML originale, fournie par Google, mais celle-ci était trop complexe et la bibliothèque libxml2, déjà incluse dans MapServer, a été utilisée.
Le nom par défaut pour ce format est kml et celui-ci peut être utilisé pour définir le paramètre imagetype dans le mapfile.
Le format peut aussi être défini dans le mapfile :
OUTPUTFORMAT
NAME kml
DRIVER "KML"
MIMETYPE "application/vnd.google-earth.kml+xml"
IMAGEMODE RGB
EXTENSION "kml"
FORMATOPTION 'ATTACHMENT=gmap75.kml' #name of kml file returned
END
La sortie kmz est également gérée. Les objets gérés sont listée dans la RFC que je vous invite à regarder si cela vous intéresse (http://mapserver.org/trunk/development/rfc/ms-rfc-58.html#map).
Amélioration des étiquetages : possibilité d'annuler les étiquettes ANGLE FOLLOW si trop de caractères se superposent (MS RFC 60)
- Développeur(s) : Daniel Morissette, Alan Boudreault
- http://mapserver.org/trunk/development/rfc/ms-rfc-60.html
Lorsque des étiquettes étaient placées sur une ligne à forte courbure et que ces étiquettes devaient suivre la ligne (ANGLE FOLLOW) il arrivait que des caractères se chevauchent rendant illisible le texte. L'amélioration ici consiste à détecter ce genre de problème et à sauter l'emplacement qui pose problème. Le prochain emplacement qui ne présente pas ce problème affichera l'étiquette. La stratégie est la suivante et permettra de comprendre le nouveau mot-clé : l'angle des deux caractères consécutifs est comparé et s'il est supérieur à 22.5° l'étiquette ne sera pas affichée.
Un nouveau mot-clé MAXOVERLAPANGLE apparait dans l'objet LABEL et permet de définir cet angle à partir duquel l'étiquette ne sera pas affichée. Ce filtre sera activé par défaut à partir de la version 6.0 de MapServer et la valeur par défaut sera de 22.5 degrés (cela est aussi la valeur par défaut dans GeoServer). Les utilisateurs pourront définir d'autres valeurs en fonction de leur besoin. La valeur 0 permettra de désactiver ce filtre et de revenir au même comportement que les anciennes versions de MapServer.
Voici un exemple de MapFile :
MAP
...
LABEL
ANGLE FOLLOW
...
MAXOVERLAPANGLE 30
END
...
END
n'oubliez pas que vous pouvez utiliser les autres paramètres REPEATDISTANCE et MINDISTANCE en parallèle :
MAP
...
LABEL
ANGLE FOLLOW
...
MAXOVERLAPANGLE 22.5
REPEATDISTANCE 400
MINDISTANCE 100
END
...
END
Cliquez ici pour voir l'image générée : http://trac.osgeo.org/mapserver/attachment/ticket/3523/mapserver-collisions-repeatdistance-400-min-100.png
Amélioration de la gestion des styles dans MapServer (MS RFC 61)
- Développeur(s) : Tamas Szekeres
- http://mapserver.org/trunk/development/rfc/ms-rfc-61.html
L'idée ici est de pouvoir utiliser des styles stockés avec la géométrie. Seul le pilote OGR gère le rendu avec le style lié à la géométrie. De plus théoriquement seuls quelques formats gèrent le stockage des styles avec la géométrie (comme MapInfo, AutoCAD DXF, Microstation DGN), cependant ces styles peuvent facilement être transférés sous forme d'attributs en utilisant l'option SQL d'ogr2ogr, comme ceci :
ogr2ogr -sql "select *, OGR_STYLE from srclayer" "dstlayer" "srclayer"
Ainsi le format final contient un attribut style. Il est possible de renommer le nom de l'attribut au cours du transfert :
ogr2ogr -sql "select *, OGR_STYLE as mystyleattribute from srclayer" "dstlayer" "srclayer"
Ce style n'était que lisible via le pilote OGR dans MapServer.
Le fonctionnement de STYLEITEM sera étendu pour gérer un attribut en paramètre : STYLEITEM “mystyleattribute”. Les styles MapServer et OGR seront gérés. Le style MapServer suit la syntaxe des objets STYLE et CLASS au format mapfile comme cela :
"STYLE BACKGROUNDCOLOR 128 0 0 COLOR 0 0 208 END"
En spécifiant un objet CLASS complet, au lieu d'un STYLE, permet d'utiliser plus d'options (comme définir des expressions, des attributs pour les étiquettes, des styles multiples) au niveau des features.
En plus du style MapServer, le format des styles OGR sont gérés comme décrit dans la page suivante : http://www.gdal.org/ogr/ogr_feature_style.html
Le format du style sera évalué lors de la lecture ce qui permettra d'utiliser des formats de styles différents dans la même couche.
Gestion de formats de sortie supplémentairs pour le GetFeature du WFS (MS RFC 62)
- Développeur(s) : Frank Warmerdam
- http://mapserver.org/trunk/development/rfc/ms-rfc-62.html
L'amélioration ici consiste à définir différents formats de sortie pour la requête GetFeature du service WFS. Rien ne vaut un exemple pour expliquer ceci :
OUTPUTFORMAT
NAME "CSV"
DRIVER "OGR/CSV"
MIMETYPE "text/csv"
FORMATOPTION "LCO:GEOMETRY=AS_WKT"
FORMATOPTION "STORAGE=memory"
FORMATOPTION "FORM=simple"
FORMATOPTION "FILENAME=result.csv"
END
OUTPUTFORMAT
NAME "OGRGML"
DRIVER "OGR/GML"
FORMATOPTION "STORAGE=filesystem"
FORMATOPTION "FORM=multipart"
FORMATOPTION "FILENAME=result.gml"
END
OUTPUTFORMAT
NAME "SHAPEZIP"
DRIVER "OGR/ESRI Shapefile"
FORMATOPTION "STORAGE=memory"
FORMATOPTION "FORM=zip"
FORMATOPTION "FILENAME=result.zip"
END
L'objet OUTPUTFORMAT possède un paramètre FORMATOPTION qui prend comme chaîne des paramètres issue d'OGR.
Visualiseur OpenLayers interne (MS RFC 63)
- Développeur(s) : Frank Warmerdam
- http://mapserver.org/trunk/development/rfc/ms-rfc-63.html
Les utilisateurs ont souvent demandés un moyen simple de tester les mapfiles. Cette amélioration permet un moyen simple de visualiser, tester et naviguer dans un mapfile en utilisant un visualiseur interne basé sur OpenLayers. Il ne doit servir que pour tester et développer et non pas en production !
Cette fonctionnalité se base sur un template interne qui sera utilisé pour générer une page html de la manière suivante :
- en utilisant mode=browse&template=openlayers : le visualiseur sera initialisé sur les valeurs par défaut du mapfile, et certains paramètres du cgi mapserv pourront fonctionner (tels que la taille de carte, la sélection des couches, etc.)
- en utilisant FORMAT=application/openlayers dans la requête GetMap d'un service WMS : les autres paramètres de la requête GetMap seront utilisés pour configurer la carte à visualiser (BBOX, WIDTH, HEIGHT, LAYERS, etc.)
Meilleur prise en charge des fichiers temporaires (MS RFC 66)
- Développeur(s) : Alan Boudreault, Daniel Morissette
- http://mapserver.org/trunk/development/rfc/ms-rfc-66.html
Jusqu'à maintenant, MapServer écrit les fichiers temporaires dans un répertoire IMAGEPATH accessible par le web, ce qui n'est pas optimal mais pouvait être suffisant mais au fur et à mesure que les fichiers temporaires étaient de plus en plus utilisés, il fallait mettre en place une meilleure prise en charge.
Il est maintenant possible de définir le chemin des fichiers temporaires. Les fichiers seront toujours écrits sur le disque mais le répertoire peut être défini de deux manières différentes :
- la variable d'environnement MS_TEMPPATH.
- dans le mapfile :
WEB
TEMPPATH "/tmp/"
END
Si le chemin des fichiers temporaires n'est pas défini, MapServer essayera l'emplacement standard en fonction du système : ”/tmp/” pour Linux/Mac et “C:/temp” pour Windows.
Activer/Désactiver des couches dans les services web OGC (MS RFC 67)
Jusqu'à maintenant il n'était pas possible de cacher/désactiver une couche de service web OGC, cela est maintenant possible. Vous pouvez trouver une discussion sur ce sujet dans le wiki : http://trac.osgeo.org/mapserver/wiki/HidingLayersInOGCWebServices
Cas d'utilisation
Voici quelques cas d'utilisation pour montrer le besoin d'avoir des couches cachées :
- Il faut la possibilité de cacher les couches TILEINDEX à tous les services OGC
- Dans un mapfile WMS où il y a plusieurs couches dépendantes de l'échelle dans un groupe commun, nous voulons que seul le groupe apparaisse dans la requête GetCapabilities et pas les couches individuelles. Cependant les couches ne doivent pas être complétement désactivées puisqu'elles doivent être visibles dans la requête GetMap et interrogeable avec la requête GetFeatureInfo. Ce cas d'utilisation est commun avec le service WMS et peut, ou non, s'appliquer aux autres services OGC.
- On peut vouloir offrir une couche donnée via le service WMS, mais pas via le WFS (ou toute combinaison de services). En d'autres termes, nous avons besoin de la capacité de choisir dans quels services OGC une couche donnée est exposée.
- Le copyright (i.e. une couche avec le statut DEFAULT) ne doit pas apparaître dans la sortie du GetCapabilities et ne doit pas être interrogeable.
- Ne pas cacher une couche complète, mais définir la capacité de permettre pour une couche donnée de retourner la géométrie au format gml dans une réponse GetFeatureInfo du wms
- Manipuler des Wms_group_layers comme couches réelles (pertinentes pour INSPIRE), mais déplacer la partie rendu en couches cachées afin d'éviter les configurations redondantes de style dans le groupe de couches et les sous-couches.
Solution proposée
La principale préoccupation était de minimiser les modifications dans les mapfiles des utilisateurs. Le moyen le plus simple, qui a été choisi pour procéder, est d'utiliser des métadonnées, comme nous le faisons actuellement pour certains paramètres OWS.
Tous les services OWS seront désactivés par défaut, sauf s'ils sont activés au niveau de la carte ou de la couche. Les services OWS peuvent être activés en utilisant les métadonnées suivantes :
- ows_enable_request : s'applique à tous les services web OGC
- wms_enable_request : s'applique au Web Map Service (WMS)
- wfs_enable_request : s'applique au Web Feature Service (WFS)
- sos_enable_request : s'applique au Sensor Observation Service (SOS)
- wcs_enable_request : s'applique au Web Coverage Service (WCS)
La valeur de la métadonnée est une liste de requêtes à activer :
"GetMap GetFeature GetFeatureInfo"
Les valeurs possibles sont les noms des requêtes pour chaque type de service tel que défini dans la spécification OGC.
Pour plus de commodité, il y a aussi deux caractères spéciaux que nous pouvons utiliser dans la liste des requêtes :
- * : utilisé seul, signifie toutes les requêtes ;
- ! : placé devant le nom d'une requête, signifie désactive cette requête ;
- !* : signifie désactive toutes les requêtes.
Exemples :
WMS activé complètement :
wms_enable_request "*"
Activer le service WMS, toutes les requêtes sauf GetFeatureInfo :
wms_enable_request "* !GetFeatureInfo"
Activer le service WMS avec les requêtes GetMap et GetFeatureInfo seulement :
wms_enable_request "GetMap GetFeatureInfo"
Active toutes les requêtes de tous les services OGC :
ows_enable_request "*"
Désactive toutes les requêtes de tous les services OGC, utile au niveau de la couche pour la cacher :
ows_enable_request "!*"
Héritage
Une particularité de cette solution est qu'il y a un concept d'héritage entre la carte (l'objet map) et les couches (objet layer). Le paramétrage au niveau de la carte s'applique à toutes les couches sauf si un paramétrage spécifique a été définie au niveau d'une couche. Exemple :
WFS activé complètement pour toutes les couches au niveau de la carte :
wfs_enable_request "*"
Désactiver la requête WFS GetFeature dans une couche définie (toutes les autres requêtes resteront activées) :
wfs_enable_request "!GetFeature"
Problème de compatibilité
Tous les services OWS seront désactivés par défaut. Cela implique que tous les utilisateurs devront modifier leur mapfile et ajouter la ligne suivante pour que leur service OGC fonctionne comme avant :
ows_enable_request “*”
Gestion de la combinaison de features à partir de différentes couches (MS RFC 68)
- Développeur(s) : Tamas Szekeres
- http://mapserver.org/trunk/development/rfc/ms-rfc-68.html
Aperçu
Aujourd'hui, vous pouvez combiner plusieurs fichiers en utilisant la fonction TILEINDEX, mais seulement si ces données ont les mêmes attributs et description. Il peut être intéressant d'être en mesure d'avoir des couches sources multiples qui ont des attributs semblables et d'être en mesure de les combiner en une seule couche (appelé couche “union”) en utilisant un sous-ensemble compatible des colonnes attributaires sources de sorte que la couche combinée peut être considérée comme une seule couche. On pourrait alors utiliser cette seule couche de la même manière que toute autre couche lors de la création des styles, classes et étiquettes.
Solution
Cette fonctionnalité a été développée sous forme d'un type de connexion séparé : CONNECTIONTYPE=UNION. La couche union utilisera le paramètre CONNECTION pour définir les couches sources dans le mapfile comme cela :
LAYER
CONNECTIONTYPE UNION
CONNECTION "layer1,layer2,layer3" # référence aux couches sources
NAME "union-layer"
PROCESSING "ITEMS=itemname1,itemname2,itemname3"
...
END
LAYER
CONNECTIONTYPE OGR
NAME layer1
...
END
LAYER
CONNECTIONTYPE SHAPE
NAME layer2
...
END
LAYER
CONNECTIONTYPE SHAPE
NAME layer3
...
END
La couche Union et les couches sources doivent avoir le même type géométrique sinon une erreur sera générée.
Gestion des attributs des couches (items)
En général, les couches sources doivent fournir les attributs qui seront nécessaires lors du rendu de la couche d'union, toutefois, les données peuvent contenir des attributs supplémentaires. Lorsque tous les attributs sont demandés (dans les opérations de recherche) alors la couche union ne fournira que certains attributs agrégés (comme le nom de la couche ou le nom du groupe de la couche source auquel appartient la géométrie). L'ensemble des attributs peuvent être remplacés manuellement (et d'autres attributs peuvent être exposés) en utilisant l'option de traitement des éléments existants. À ce stade du développement, le pilote va exposer les attributs supplémentaires suivants :
- Combine:SourceLayerName - le nom de la couche source auquel appartient la géométrie
- Combine:SourceLayerGroup - le groupe de la couche source auquel appartient la géométrie
Projections
Il est suggéré d'utiliser la même projection pour la couche d'union et les couches sources. Le fournisseur de la couche gère toutefois la reprojection des features entre les couches sources et la couche d'union.
Gestion des classes et des styles
Nous pouvons définir la symbologie et l'étiquetage des couches union de la même manière que toute autre couche en précisant les classes et les styles. En outre, l'option STYLEITEM AUTO pour la couche d'union est gérée, ce qui est essentiel pour afficher les caractéristiques de la même manière que les couches sources. Les couches sources peuvent également utiliser le paramètre AUTO STYLEITEM si la source de données sous-jacente le prévoit.
Réalisation des requêtes
Le pilote va créer (et réaliser) une copie des couches sources qui permettra de maintenir les couches sous-jacentes en mémoire jusqu'à ce que la couche union soit utilisée. Les requêtes sur la couche union se comportent de la même manière qu'avec les autres couches.
Gestion des clusters de géométries dans les couches ponctuelles (MS RFC 69)
- Développeur(s) : Tamas Szekeres
- http://mapserver.org/trunk/development/rfc/ms-rfc-69.html
Aperçu
Afin de rendre les cartes pertinentes pour une vue donnée, nous pouvons avoir besoin de limiter le nombre d'éléments affichés qui normalement se chevauchent les uns sur les autres. Nous pouvons maintenant réaliser un rendu des symboles sous forme de cluster à une échelle particulière. Selon l'exemple à http://trac.osgeo.org/mapserver/attachment/ticket/3700/cluster.png le nombre de traits formant les groupes sont affichés dans les étiquettes pour chaque feature dans le cluster.
Solution
Cette fonctionnalité met en œuvre un paramètre spécifique. Les paramètres de regroupement peuvent être spécifiés pour chaque type de couche comme suit :
LAYER
TYPE POINT
CONNECTIONTYPE OGR
NAME cluster
CLUSTER
MAXDISTANCE 20 # en pixels
REGION ellipse # peut être un rectangle ou une ellipse
GROUP (expression) # nous pouvons définir une expression pour créer des groupes séparés pour chaque valeur
FILTER (expression) # nous pouvons définir une expression logique pour définir des conditions de regroupement
END
...
END
On peut aussi utiliser plusieurs classes pour afficher les formes en cluster. L'exemple ci-dessus utilise la définition de la couche suivante :
LAYER
CLUSTER
MAXDISTANCE 50
REGION "rectangle"
END
LABELITEM "Cluster:FeatureCount"
CLASSITEM "zoomcode"
CLASS
TEMPLATE "query.html"
STYLE
SYMBOL "image4"
END
LABEL
...
END
EXPRESSION "Cluster:Empty"
END
CLASS
TEMPLATE "query.html"
STYLE
SYMBOL "image1"
END
LABEL
...
END
EXPRESSION "5"
END
CLASS
TEMPLATE "query.html"
STYLE
SYMBOL "image2"
END
LABEL
...
END
EXPRESSION "4"
END
CLASS
TEMPLATE "query.html"
STYLE
COLOR 0 0 255
SYMBOL "image3"
END
LABEL
...
END
EXPRESSION "3"
END
...
END
Gestion des attributs des feature (items)
La couche cluster elle-même fournira les attributs agrégés suivants :
- Cluster:FeatureCount - nombre des features dans la géométrie du cluster
- Cluster:Group - la valeur de groupe du cluster
Ces attributs peuvent être utilisés pour configurer les étiquettes des features et peuvent également être utilisés dans des expressions. La couche cluster gére également la récupération d'autres attributs de la source de données d'origine qui est référencée dans la configuration de la couche. L'option de traitement des éléments peut être utilisée pour spécifier des attributs supplémentaires à partir de la couche source en fonction de la préférence des utilisateurs.
Si nous récupérons l'attribut original, alors le fournisseur de la couche ne fournira que des valeurs qui sont les mêmes pour chaque forme du clsuter. Les autres valeurs sont définies comme “Cluster: Empty”. À l'avenir, les développeurs pourront sans doute étendre cette mise en œuvre par des fonctions d'agrégation pour définir les attributs, comme min ([attributename]) ou max ([attributename]).
Gestion des classes et des styles
Nous pouvons définir la symbologie et l'étiquetage des couches en clusters de la même manière que toute autre couche en précisant les classes et les styles. STYLEITEM AUTO n'est pas considéré comme pris en charge à ce stade.
Réalisation des requêtes
Dans les opérations de requête, les fonctionnalités clusters sont récupérées sous forme de formes simples avec l'ensemble des attributs comme spécifié dans l'option de traitement ITEMS. Les features en clusters sont conservées jusqu'à ce que la couche soit ouverte, de sorte que la démarche d'un seul passage pour la requête soit fournie par ce driver.
Autres nouveautés
- Autres formats de sortie :
- KML from Google SOC project (Assefa)
- Any OGR Format (Frank)
- GML3 (Steve - maybe during sprint?)
- Cairo (PDF, SVG)
- Lecture des mapfiles XML : run-time compilation (XML/XSLT ⇒ .map)
- Amélioration des étiquettes (label precision and display of labels along curved lines)
- Styles des étiquettes
- Gestion des Larges Shapefiles (fichier dbf > 2 Go)
- Support du WCS 2.0 et de la méthode POST dans le service WCS 1.1
Le futur ?
Voilà une version majeure de MapServer, d'autres versions amélioreront, à n'en pas douter, ces nouvelles fonctionnalités mais déjà on peut prédire qu'elle sera bien accueillie par la communauté. Le projet MapServer étant un projet dynamique et fructueux, le futur sera radieux.
Pour revenir au projet et à une première tentative de prévision du futur, on notera que deux projets sont en instance d'intégration comme sous projet au sein de MapServer. TinyOWS et Mod-Geocache apporteront chacunes des fonctionnalités attendues à MapServer : le service WFS-T pour le premier et la mise en cache pour le deuxième. L'idée est de simplifier pour ces deux fonctionnalités leur utilisation et leur configuration. TinyOWS propose déjà d'être configuré via un mapfile.
Que manque t'il à MapServer ? Un éditeur de mapfile intégré au projet, ou pas … Gageons que la prochaine version apportera son lot de nouveautés, et pourquoi pas un éditeur de mapfile ?!
Merci à l'équipe du projet qui a permis cette nouvelle release majeure et pour la transparence des informations qui ont permis la rédaction de ce document (issus des RFC proposées par les développeurs).
"Yves Jacolin @camptocamp"
(1) http://trac.osgeo.org/mapserver/wiki/60ReleasePlan
Site officiel :
MapServer 
