Répondre au commentaire

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. Notez que certaines informations sont issus de mes tests personnels sur une version non finalisée. Certaines informations peuvent être incorrectes (notamment l'optimisation du moteur de rendu, les dépendances, les nouvelles fonctionnalités, etc.). Merci de ne pas m'en tenir rigueur.

Au niveau des nouveautés de cette version majeure, nous trouvons l'utilisation de la bibliothèque AGG pour le rendu des images, la possibilité de modifier le mapfile par l'url, la gestion des tables de couleurs pour les raster, la création de graphique en barre et de camemberts, des modifications dans l'utilisation des paramètres SIZE et ANGLE et la priorisation des étiquettes.

Attention, certaines évolutions entraînent une incompatibilité arrière avec certains mapfiles. Reportez-vous à la documentation, et testez bien vos mapfiles !

Date des sorties versions intermédiaires :

• Sortie prévue : 12-09-2007
• Version RC : 5-09-2007
• Versions béta : 25-07-2006, 01-08-2007, 8-08-2007, 15-08-2007, 22-08-2007, 29-09-2007
• Prochaine version : 5.1, début 2008

Remerciements

Je tiens à remercier la liste MapServer pour l'aide qu'elle m'apporte dans l'utilisation de MapServer ainsi qu'aux réponses qu'elle m'a apportées lors de la rédaction de cet article, et plus particulièrement :

• Thomas Bonfort : pour la précision sur les différentes configuration du paramètre OUTPUTFORMAT pour AGG et la relecture de l'article.

Nouveautés

Les nouveautés étant importantes, et certains changements n'étant pas détaillés ici, je vous engage à lire la page de migration de mapserver 4.10 à 5.0

Ajout d'un lien entre les attributs des paramètres de styles et d'étiquettes

• RFC 19 : http://mapserver.gis.umn.edu/development/rfc/ms-rfc-19/

Pour l'instant MapServer gère la liaison des propriétés des étiquettes (LABEL) et des styles (STYLE) pour quelques attributs (par exemple ANGLE). Cependant, il est maladroit d'ajouter de nouvelle liaison qui entraine une structure complexe inutile qui est difficile à maintenir.

Les options tels que SIZEITEM et ANGLEITEM ont été enlevées. À la place, une syntaxe plus logique est utilisée :

STYLE
  SIZE [mySizeItem]
  ANGLE [myAngleItem]
  COLOR 255 0 0
  SYMBOL 'square'
END

Les crochets ont été utilisé dans les modèles de MapServer et les expressions pour lier les attributs, ils sont donc un choix naturel pour annoncer des liaisons des attributs dans ce cas.

De même MapScript perdra la possibilité de définir/obtenir les propriétés xxxITEM. À la place les objets STYLE et LABEL auront les méthodes setBinding et deleteBinding :

(en Perl)

$style->setBinding($mapscript::MS_STYLE_BINDING_SIZE, 'mySizeItem');
$style->deleteBinding($mapscript::MS_STYLE_BINDING_COLOR);

Correction des couleurs des Raster par une table de couleur

• RFC 21 : http://mapserver.gis.umn.edu/development/rfc/ms-rfc-21/

Ajout de la gestion des courbes de correction de couleur à la volée (tables de consultation) des images raster.

Détails techniques : Le moteur de rendu des raster de MapServer a été étendue pour gérer une option de PROCESSING indiquant un fichier de correction de couleur à appliquer à la volée lorsque des données raster doivent être lu sur le disque. L'option de PROCESSING prendra la forme suivante :

PROCESSING "LUT=<lut_specification>"

Pour une simple table de conversion (c'est à dire lut, look-up table) appliquée à toutes les bandes ou :

PROCESSING "LUT_<color#>=<lut_specification>"

Pour une lut appliquée seulement à une bande. <lut_specification> peut être le nom d'un fichier contenant un LUT, ou une définition d'une lut incluse. La définition d'une lut incluse ressemble à ceci :

<lut_specification>=<in_value>:<out_value>,<in_value>:<out_value>[,<in_value>:<out_value>]*

Le fichier texte prend la même forme, sauf qu'il peut être multi-ligne (les lignes seront implicitement réunies séparées par des virgules). Ainsi une forme typique est :

PROCESSING "LUT=0:0,128:150,255:255"
PROCESSING "LUT_2=green_lut.txt"

Remarquez que des fichiers de définition d'une LUT seront recherchés relatif à la carte si un chemin relatif est fournit.

La LUT sera appliquée avant l'échantillonnage en 8bit. Donc seulement les valeurs en 8bit en entrée et sortie (0-255) sont gérées.

Une LUT de 256 entrée sera crée par interpolation linéaire entre les points de contrôle de la table. Remarquez que cela est différent d'une approche basée sur une véritable courbe où une sorte de correspondance avec la courbe est effectuée avec les points de contrôles. Pour un nombre significatif de points de contrôle la différence ne sera pas importante, mais cela peut l'être pour une table avec peu de points de contrôle (par exemple 3). Il pourrait être possible de calcul sa propre courbe, mais cela nécessite des recherches et des développements supplémentaires.

Si aucun point de contrôle n'existe pour les valeurs en entrée de 0 et 255, un mappage de “0:0” et “255:255” sera présumé.

Autres formats de courbe

Le format de courbe ASCII de GIMP est géré directement. Puisque le fichier de courbe de GIMP contient plusieurs courbes (pour différentes bandes) il peut être nécessaire de sélectionner laquelle doit être utilisée dans le paramètre PROCESSING. Par exemple :

PROCESSING "LUT_2=GIMP_red:gimp.crv"

Implications dans le mapfile

Toutes les nouvelles options sont sélectionnées par les nouvelles options de PROCESSING. Il n'y a pas de changement dans la syntaxe du mapfile. IL ne devrait pas avoir de problème d'incompatibilité avec les anciens mapfiles.

Implications dans MapScript

Il n'y a pas d'ajout ou de changement à l'API de MapScript. Les nouvelles options sont contrôlées par l'information de PROCESSING sur les couches ce qui est déjà gérable par MapScript.

Ajout de la priorité des étiquettes

• RFC 27 : http://mapserver.gis.umn.edu/development/rfc/ms-rfc-27/

Cette nouveauté ajoute un paramètre PRIORITY au paramètre LABEL. Ce nouveau paramètre peut être définie à 5 par exemple ou bien par un attribut de la table.

...
LABEL
  PRIORITY 5
  ...
END
...

ou

...
LABEL
  PRIORITY [Attribut]
  ...
END
...

Ajout de graphiques dynamiques (camembert et graphique en bar)

• RFC 29 : http://mapserver.gis.umn.edu/development/rfc/ms-rfc-29/
• Documentation : http://mapserver.gis.umn.edu/docs/howto/dynamic-charting/

MapServer inclut maintenant la possibilité de dessiner automatiquement des camemberts ou des barres graphiques dont les valeurs sont récupérées et ajustées à partir des attributs d'une source de données.

Un nouveau type de couche appelé CHART est crée et le développement initial gère les graphiques en bar et camembert.

Les directives PROCESSING sont utilisées pour définir CHART_SIZE et CHART_TYPE (pie ou bar) de la couche.

Nous avons alors une class pour chaque part du camenbert ou barre pour le graphique en bar. Pour chaque CLASS, le paramètre STYLE COLOR définie la couleur de la part du camembert ou de la barre du graphique, et le paramètre STYLE SIZE est utilisé pour définir la taille relative (valeur) de chaque part du camembert ou de la barre. Cela est principalement utile en combinaison des liaisons d'attributs bien sur.

Exemple :

LAYER
    NAME "Ages"
    TYPE CHART
    CONNECTIONTYPE postgis
    CONNECTION "blabla"
    DATA "the_geom from demo"
    PROCESSING "CHART_TYPE=pie"
    PROCESSING "CHART_SIZE=30"
    STATUS ON
   CLASS
      NAME "Population Age 0-19"
      STYLE
        SIZE [v1006]
        COLOR 255 244 237
      END
    END
    CLASS
      NAME "Population Age 20-39"
      STYLE
        SIZE [v1007]
        COLOR 255 217 191
      END
    END
    CLASS
      NAME "Population Age 40-59"
      STYLE
        SIZE [v1008]
        COLOR 255 186 140
      END
    END
END

Dans l'exemple ci-dessus, si pour un objet donné nous avons v1006=1000, v1007=600 et v1008=400 alors les parts du camembert pour chaque class seront respectivement de 50 %, 30 % et 20 % de la taille totale du camembert. Si nous produisons des graphiques en barre, les valeurs représenteront alors la hauteur relative des barre avec la valeur la plus grandes (la plus haute barre) ayant 100 % de la hauteur de la barre.

Voici un exemple de carte produite avec un graphique en camembert https://trac.osgeo.org/mapserver/attachment/ticket/1800/chart-test.jpg

La légende des couches se comporte comme d'habitude et produit une couleur par class.

Problèmes et limitations

• L'implémentation initiale ne gère que les formats de sortie avec GD. Cependant Thomas Bonfort a proposé d'implémenter une version avec AGG dès que celui-ci sera disponible.
• La valeur de chaque CLASS est récupéré à partir du paramètre SIZE du STYLE correspondant, ce qui est maladroit du point de vue de la syntaxe (mais qui permet d'éviter la création d'un nouveau mot-clé).

Nouveau mécanisme pour charger/décharger des objets par l'url en utilisant la syntaxe des mapfiles

• RFC 31 : http://mapserver.gis.umn.edu/development/rfc/ms-rfc-31/

Les paramètres dans l'url ont été complètement modifié au profit d'une définition objet. Ainsi, au lieu d'écrire quelque chose comme cela :

...map_scalebar_units=meters&map_scalebar_intervals=5&map_scalebar_size=300+2...

Vous devrez écrire maintenant :

...map_scalebar=UNITS+METERS+INTERVALS+5+SIZE+300+2...

Les objets principaux seront toujours référéncés par map_scalebar, map_legend ou map_layername, mais toutes les autres propriétés seront chargées par des snippets. Les paramètres DUMP et CONNECTION ne sont pas modifiable par l'url pour d'évidentes raisons de sécurité.

De plus, cette configuration de l'URL n'est pas un comportement par défaut mais doit être activé explicitement. Pour se faire vous devez rajouter un paramètre dans l'objet WEB : URLCONFIG [motif], NULL par défaut. Le motif doit être une expression régulière qui peut s'appliquer pour n'importe quelles variables map_*. Il est donc possible de limiter les changement seulement pour l'objet de l'échelle graphique avec URLCONFIG 'scalebar' ou en autoriser d'autre avec URLCONFIG '.'. Le comportement par défaut n'autorise aucune configuration par l'URL.

Compatibilité arrière : Le changement de l'URL casse la compatibilité arrière mais cela étant relativement peu utilisé, ce changement sera plutôt bénéfique.

Ajout de la gestion pour le rendu de carte en utilisant la bibliothèque AGG pour une meilleure qualité de rendu

• RFC 32 : http://mapserver.gis.umn.edu/development/rfc/ms-rfc-32/

Pour utiliser cette nouvelle bibliothèque vous devez l'installer (http://www.antigrain.com/). Notez que AGG peut avoir besoin de libSDL2.1-devel, à installer en cas d'erreur concernant *SDL*. Cependant, il est possible d'installer AGG sans devoir installer libSDL2.1-devel.

Puis installer Mapserver, faites comme ceci :

$ ./configure [..] --with-agg=/usr/local/

Au niveau du mapfile, le paramètre OUTPUTFORMAT pourrait être ceux-ci :

Pour une sortie basique (24 bit) :

OUTPUTFORMAT
  NAME 'AGG'
  DRIVER AGG/PNG
  IMAGEMODE RGB
END

ou toujours au format png, avec un nombre de couleur réduit avec “quantization” :

OUTPUTFORMAT
  NAME 'AGGJ'
  DRIVER AGG/PNG
  IMAGEMODE RGB
  FORMATOPTION "QUANTIZE_FORCE=ON"
  FORMATOPTION "QUANTIZE_DITHER=OFF"
  FORMATOPTION "QUANTIZE_COLORS=256"
END

24 bit png, avec un arrière-plan transparent :

OUTPUTFORMAT
  NAME 'AGGA'
  DRIVER AGG/PNG
  IMAGEMODE RGBA
END

Output en 24 bit jpeg :

OUTPUTFORMAT
  NAME 'AGG_JPEG'
  DRIVER AGG/JPEG IMAGEMODE RGB
END

cependant, du fait de l'amélioration grandissante de la qualité de l'image (antialiasing), la taille de l'image augmente d'une manière importante, ce qui peut poser problème lors d'une mise en production. Le paramètre OUTPUTFORMAT proposé ci-dessus permet d'optimiser la taille de l'image. Au niveau des performances, le moteur de rendu par AGG a continuellement été optimisé pour obtenir des performances similaires à celle avec GD. Cependant, il n'est pas possible de créer des images au format JPEG avec AGG contrairement avec GD. Ceci entraine une taille des images en sortie plus importante (le format PNG étant plus important à qualité égale). Enfin, notez qu'il est possible d'activer l'antialiasing avec la bibliothèque GD. Pour l'une l'antialiasing est activée par défaut et ne peut être désactivée (AGG), pour l'autre elle doit être activée explicitement (GD).

Voici deux captures d'écran pour comparer l'évolution :

D'autres tests ont été effectués, notamment ici : http://boston.freemap.in/agg-demo.html

Correction de problèmes

• MS RFC 17 : utilisation d'allocation dynamique pour les symboles, les couches, les classes et les styles (suppression du nombre limite statique de chacun d'entre eux dans une carte).
• MS RFC 24 : amélioration de la gestion de la mémoire et des vielles collections pour MapScript
• MS RFC 26 : nettoyage de la terminologie (La TRANSPARENCY des couches a été renommé OPACITY, SCALE est devenu SCALEDENOM, les styles des symbole est devenu motif de symbol)
• MS RFC 28 : amélioration du mécanisme de débug/journalisation pour faciliter la résolution des problèmes et du tuning des applications. Ajout de la gestion pour le multiple niveau de débugage et plus de contrôle sur la localisation de la sortie.
• … et plusieurs corrections et améliorations non listées ici.