• 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.

A eux deux ils vont conjuguer leurs efforts pour nous proposer GeoInWeb, globalement autour des mêmes thématiques.

On y apprend par exemple que l’IGN et Geoconcept vont mettre en oeuvre des WebServices OGC permettant aux utilisateurs de GeoConcept d’avoir accès aux orthophotos du Géoportail jusqu’au 16000e. On en parle aussi ici. Mais si lesdits services sont conformes aux spécifications de l’OGC, pourquoi seul Géoconcept devrait y avoir accès ? Pourquoi les utilisateurs détenteurs de licence Géoconcept auraient un accès gratuit à une donnée produite sur fonds publics et pas les autres ? C’est Géoconcept qui finance les campagnes de prise de vue désormais ? Non, ça ne doit pas être ça, il doit y avoir quelquechose que je n’ai pas compris… Renaud et Audrey, si vous avez des tuyaux, je suis preneur !

Bon vent à GeoInWeb !

Via import cartography.