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 ?

SLD est-il mort ?
Étiqueté avec :        

6 pesnées sur “SLD est-il mort ?

    • 2 juin 2016 à 12:59
      Permalien

      Merci à toi pour cette précision et surtout pour ton travail sur QGIS !

      Répondre
  • 14 juin 2016 à 11:56
    Permalien

    Je profite pour rebondir en 5 points :
    (1) compliqué pour qui ? … SLD/SE est utilisé dans son langage par les développeurs d’éditeurs IHM de style et développeurs/configurateurs de services cartographiques … pas par l’utilisateur d’applications cartographiques qui cachent la complexité. Aussi, qu’est-ce qui est compliqué ? … le fond ou la forme ? la logique du modèle de symbologie ou la syntaxe XML ?
    (2) la dualité évoquée et ses conséquences trouvent racines dans la pauvreté du langage, les ambiguités de la spécification (ex. MarkIndex) et un cadre modulaire d’extensibilité et de conformance faiblement défini
    (3) les alternatives syntaxiques sont légitimes, c’est une question de goût, surtout quand on a des réactions épidermiques de type « XML c’est lourd à éditer, beurk ! » (rappellons que comme pour tout langage il existe de très bons IDE XML qui facilitent la tâche). Mais cet aspect « encoding » ne doit pas cacher les questions de fond, ce n’est qu’un petit bout du challenge plus ambitieux visant une intéropérabiltié cartographique véritablement fonctionnelle. Par ailleurs, pourquoi dis-tu qu’une syntaxe « à la CSS » ne pourrait pas décrire des styles complexes ?
    (4) autant le dire, animer un groupe de normalisation à l’OGC n’est pas chose facile. Les choses n’y avancent qu’avec ce que les membres actifs apportent (je ne parle pas des observateurs attentistes). Les principales forces vives de ce groupe ont puisé les ressources mobilisables dans un cadre académique. La Ra&D académique a fait son travail, la problématique est étudiée, des propositions sont faites et même une expérimentation est disponible (une publication chez PeerJ Computer Science sur le sujet est imminente). Il ne reste donc plus qu’à transformer l’essai, ce qui nécessite un soutien fort comme tu le soulignes très bien. De récentes observations (y.c. à geoCamp) montrent que les communautés SDI sont entrain de se voir au pied du mur, avec un besoin grandissant d’intéropérabilité des représentations cartographiques, tout en constatant les lacunes des standards en vigueur à l’OGC. Une telle vision doit logiquement amener à supporter les initiatives en cours pour transformer cet essai. En tous les cas, la suite de l’histoire se fera avec ces supports ou ne se fera pas.
    (5) finalement, les tuiles vecteurs viennent enrichir tes cas d’utilisation. C’est la tendance en effet, un pas de plus pour la convergence du web et du desktop. Or comme tu dis « (SE) peut très bien s’appliquer à n’importe quels logiciels capables de produire des cartes », et si la description de style n’est plus envoyée au serveur, c’est le client qui récupère une description, car il va bien falloir qu’il applique un style sur ses vecteurs. Et considérant la diversité des outils clients, cela fait qu’un standard type SE garde toute sa pertinence.

    Merci Benjamin pour ce beau résumé de situation.

    Répondre
    • 14 juin 2016 à 15:11
      Permalien

      Merci Olivier pour tes rebonds.

      J’apprécie beaucoup ton engagement en vue d’une réelle interopérabilité malgré les difficultés que l’on rencontre tous à animer des communautés dont les membres n’ont pas beaucoup de temps à consacrer à des productions « bénévoles ».

      Pour les tuiles vecteur, tu raison sur le fait qu’un standard a aussi sa place pour ce type d’usage mais le besoin d’interopérabilité des styles du point du vue de l’application cliente est plus faible car celle-ci n’a plus besoin de s’assurer que ses styles soient interprétables par un autre système. Dans ce cas de figure, j’ai l’impression que la problématique d’interopérabilité se déplace au niveau de l’échange des données et non de l’échange des styles.

      Sur le fond/la forme : tu as raison sur le principe. Malgré tout, dans nos métiers, le nombre relativement faible d’implémentations complètes et ergonomiques fait que la complexité interne resurgit sur l’utilisateur. Ce souci au niveau des implémentations risque d’être renforcé avec un standard abstrait qui permettra de multiples manières d’implémenter la chose.

      Je relève juste une espèce de contradiction entre faire quelque chose de très riche et l’esprit (de mon point de vue) d’un standard dans le domaine de l’interopérabilité : se mettre d’accord sur un minimum commun. Trouver un consensus sur quelque chose de très riche (comme HTML) nécessite une réelle implication de la communauté des éditeurs et utilisateurs. J’espère qu’ils sauront s’investir.

      Répondre
  • 15 juin 2016 à 16:02
    Permalien

    Passionnant sujet n’est-ce pas ? Ton point de vue n’est pas contradictoire à mon sens. L’idée n’est pas de faire quelque-chose de riche mais de faire en sorte que cela puisse s’enrichir sur la base d’une structure modulaire, pensée extensible (le X de XML signifie ne suffit pas) et sous contrôle à long terme : le minimum commun peut évoluer dans le temps. Ceci devrait favoriser l’adoption du standard avec des implémentations qui pourront mettre en oeuvre la richesse step-by-step. Une souplesse qui devrait aussi améliorer la qualité en terme de complétude/conformité (ergonomie? : pas sûr de te comprendre). Un cadre, du moment qu’il est extensible apporte une certaine souplesse. Sans oublier la gouvernance du tout.

    Répondre
    • 15 juin 2016 à 16:10
      Permalien

      Oui, je crois être passionné.
      Pour l’ergonomie : jette un oeil à l’interface de saisie des styles dans GeoServer ; je crois que tu comprendras tout de suite ce que je veux dire.

      Répondre

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *