Skip to Content

Sortie de MapServer version 6.0.0

ven 27-05-2011 Yves Jacolin

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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


Creative Commons License
licence Creative Commons Paternité-Partage des Conditions Initiales à l'Identique Commerciale 2.0 France

  • 28956 lectures
  • Email this page
  • del.icio.us
  • Facebook
  • LinkedIn
  • Twitter

Commentaires

Poster un nouveau commentaire

Le contenu de ce champ sera maintenu privé et ne sera pas affiché publiquement.

Similar entries



Theme by Dr. Radut.