L’échange de données vectorielles entre SIG hétérogènes est actuellement à peu près correctement maitrisé (via des formats de fichiers communs – shapefile, KML, GML par exemple – ou des protocoles spécifiques – WFS notamment). On ne peut pas en dire autant de l’échange des styles graphiques à appliquer aux données. Il manque encore dans ce domaine un standard reconnu et implémenté par la majorité des solutions logicielles. Il existe bien Symbology Encoding de l’OGC (dérivé de Style Layer Descriptor) mais on ne peut pas dire que son adoption soit généralisée ou tende à l’être. Les principaux reproches que l’on peut faire à Symbology Encoding :
- sa verbosité (héritée de celle de XML) ;
- sa relative complexité (reproche que l’on entend régulièrement à l’endroit des travaux de l’OGC) ;
- ses écarts par rapport à la modélisation des représentations cartographiques élaborée par l’ISO TC211 (cf. ISO 191171 – Geographic information — Portrayal)
Selon moi, le principal défaut de Symbology Encoding réside dans ses capacités restreintes à gérer des représentations graphiques complexes. Les représentations spécifiques de certains métiers (informations tactiques des militaires, cartes météorologiques et océanographiques, cartes géologiques par exemple) atteignent facilement ces limites. Symbology Encoding n’est pas non plus adapté pour produire des cartes incluant des graphiques (camemberts et histogrammes notamment). C’est la raison pour laquelle des travaux sont régulièrement entrepris pour essayer d’améliorer les capacités de ce standard. Par exemple : le projet européen Orchestra et, du côté de l’OGC, le groupe de travail MetOcean, le test-bed OWS-6 et le groupe de travail SLD.
Globalement, on ne peut pas dire que Symbology Encoding progresse très vite. Certains n’attendent pas que les organismes de standardisation avancent et étendent les standards pour les adaptés à leurs besoins. C’est le cas de GeoServer qui a intégré quelques extensions maison (cf. SLD Extensions in GeoServer).
Une autre initiative de la communauté géospatiale libre est également en cours : MapCSS. Il s’agit d’un langage déclaratif de styles cartographiques inspiré du format CSS (format utilisé pour définir les styles de pages web). MapCSS fait suite à différents travaux menés de droite et de gauche pour utiliser des styles CSS pour produire des cartes : Styling GeoServer Layers with CSS, Cartagen – GSS et Cascadenik.
Il ne faut pas forcément s’attendre à ce que MapCSS soit une alternative plus prometteuse que Symbology Encoding en termes de capacités graphiques. Non, MapCSS est plutôt une alternative basée sur un standard très largement répandu (CSS) qui a l’avantage d’être plus compact, d’être plus lisible que Symbology Encoding et d’être plus familier pour les développeurs de sites web.
MapCSS en est à ses débuts et il n’est pas sûr qu’il bénéficie d’un engouement suffisant pour qu’il sorte réellement de l’anonymat et devienne quelque chose de moins confidentiel. On peut néanmoins constater que les choses avancent vite :
- un groupe de discussion s’est mis en place au sein de l’OSGeo pour faire progresser la définition de MapCSS (cf. ici). Il semble plus actif que le groupe SLD de l’OGC ;
- des implémentations de MapCSS existent déjà (cf. là). Parmi ces implémentations on peut noter Potlatch2 (la future version de l’outil de saisie en ligne d’OpenStreetMap – cf. ici et là). Si vous souhaitez tester en ligne MapCSS, je vous invite à essayer Halcyon (qui utilise le même moteur de rendu que Potlatch2).
Une initiative à surveiller donc.