Le Blog

Si vous êtes intéressés par les standards de l’OGC vous avez sans doute déjà entendu parler de SLD (Styled Layer Descriptor) et peut-être l’avez-vous même déjà manipulé (au travers d’un QGIS, GeoServer, Mapserver ou que sais-je). En général, ce que l’on retient de SLD c’est quelque chose du genre :
« un langage compliqué pour écrire des styles simples en vue de publier des données vecteur en WMS ».

En vrai, c’est un peu plus compliqué :

• SLD est avant tout une extension/un profil de WMS proposant des opérations/paramètres supplémentaires permettant aux applications clientes de manipuler les styles des couches d’un service WMS
• SLD n’est plus aujourd’hui un langage de description de styles. Cette partie de SLD 1.0 a été externalisée dans un standard à part entière intitulé Symbology Encoding (SE) au moment du passage à SLD 1.1 (en 2005)
• SLD se limite bien aux services WMS mais la partie consacrée au langage de description des styles (que ce soit dans SLD 1.0 ou SE) peut très bien s’appliquer à n’importe quels logiciels capables de produire des cartes
• Ce langage n’est pas limité aux données vecteur. En effet, une de ses parties est consacrée aux styles appliqués aux rasters.

Sur le papier, SLD/SE se présente donc comme une bonne initiative pour favoriser l’interopérabilité graphique entre systèmes qui ont besoin d’échanger des styles :

• déployer des couches avec des rendus graphiques identiques sur des systèmes hétérogènes ;
• permettre aux applications clientes de fournir aux services WMS un style à appliquer à une couche ;
• écrire des styles avec un outil et les déployer avec d’autres.

Si j’écris cet article avec ce titre vous vous doutez bien que ce n’est pas pour dresser un tableau tout rose de SLD/SE, n’est-ce pas ? Vous avez peut-être/sans doute (rayez la mention inutile) noté dans la description synthétique de SLD du premier paragraphe ce « un langage compliqué pour décrire des styles simples ». L’adoption de SLD aurait été plus facile et générale si cette phrase ressemblait plutôt à ceci : « un langage simple pour décrire des styles compliqués » [vous aviez sans doute déjà noté que l’informatique et la standardisation ne font pas toujours des miracles]. Cette dualité complexité/simplicité aboutit sans surprise à :

• rares sont les outils dont toute la richesse graphique peut être décrite au travers de SLD/SE ;
• rares sont les solutions techniques qui mettent en avant le support de SLD/SE ;
• la réelle interopérabilité entre solutions autour de SLD n’est pas toujours au rendez-vous : publier dans GeoServer un style SLD écrit avec QGIS nécessite des retouches manuelles (entre autres sur les paramètres correspondant à des longueurs tels que les épaisseurs de trait par exemple) (corrigé depuis peu – cf. commentaire de René-Luc D’Hont)  ;
• la complexité de SLD/SE pousse certains éditeurs à proposer des alternatives pas forcément interopérables dans le domaine de l’information géographique : CSS par exemple au niveau de TileMill et de GeoServer. CSS est plus compact et plus facile à lire que le langage XML utilisé par SE mais n’est pas une solution pour décrire des styles complexes ;
• pour prendre en compte des besoins graphiques non pris en compte par SE certaines solutions ont été enrichies avec des extensions de SLD/SE qui leurs sont propres (donc non interopérables) : cf ici http://docs.geoserver.org/stable/en/user/styling/sld-extensions/index.html pour GeoServer.

En fait d’interopérabilité, nous nous retrouvons avec des initiatives qui délitent l’intérêt de SLD/SE et une communauté géospatiale pas franchement dynamique ni unie autour de ces standards. Que se passe-t-il depuis 2005 à l’OGC sur ce sujet ? Peut-on encore espérer que SE s’impose réellement ? Lors du geoCom 2016 à Bordeaux, Erwan Bocher a présenté les derniers travaux menés par le groupe chargé de produire une nouvelle version de SE. Elle permettrait de produire des styles plus complexes (donc plus adaptés aux besoins des utilisateurs) et elle s’abstrairait des lourdeur d’XML (que de bonnes choses donc). J’apprécie la tentative de redynamiser la communauté autour de ces problématiques. Malheureusement, nous sentons bien que les contributeurs de cette nouvelle version luttent pour imposer leurs idées sans réel support des éditeurs ou des communautés des principales solutions du marché (les standards de l’OGC qui n’ont été publiés que par l’énergie et la conviction d’une poignée de personnes ne sont pas rares).

Pourquoi la communauté se mobiliserait-elle autour de ces sujets ? Il faut bien constater que la situation actuelle a bien changé depuis la première publication de SLD (2002). A l’époque la seule manière réaliste d’appliquer des styles riches avec des services en ligne se trouvait plutôt du côté serveur (là où les données étaient stockées) surtout si les données étaient très volumineuses. Ce n’est plus le cas aujourd’hui, on transmet de plus en plus de données vecteur au navigateur en lui demandant de faire le boulot graphique. Depuis quelques années, les tuiles vecteurs optimisées pour la diffusion sur le web (notez au passage que l’OGC a loupé le passage aux tuiles vecteur) remplacent les tuiles raster. Le besoin pour les applications clientes d’envoyer les styles aux serveurs chargés de produire les images se réduit donc progressivement. Sans oublier que les technologies évoluent nettement plus vite que les standards de l’OGC : à grand regret vous aviez mis de côté SE au profit de CartoCSS et on vous apprend que ce dernier est mort. Comment pourriez-vous encore croire en un sursaut de SE ?