Diese Seite dient dem Austausch von Fragestellungen und Problemen im Zusammenhang mit der Verwendung von SLD.

Die Standards SLD (Styled Layer Descriptor) und SE (Symbology Encoding) gehören eng zusammen. Mit den beiden Standards ist es möglich, nachhaltig identische Signaturen für Objekte mit einem gemeinsamen Objektartenmodell zu verwenden. Die auf diese Art und Weise hinterlegten Signaturen können beliebig von jedermann verwendet werden. Aus diesem Grunde ist es vorgesehen, ein so genannte Portrayal-Register in der GDI-DE Registry zu führen. Hat eine Institution bereits die entsprechenden Signaturen entwickelt, können sie frei nachgenutzt werden. Ein Beispiel ist die einheitliche Erstellung digitaler Planzeichen gemäß Planzeichen-Verordnung, ein weiteres Bespiel sind die Darstellungsvorschriften für das INSPIRE-Datenmodell. Über die GDI-DE Registry ist es dann auch möglich, nationale Erweiterungen eines solchen Modells zu pflegen und ebenfalls mit z. B. aussagekräftigeren Signaturen zu versehen, die überall gleichermaßen verstanden werden.

OGC Styled Layer Descriptor: https://www.ogc.org/standards/sld
OGC Symbology Encoding: https://www.ogc.org/standards/se

OGC eLearning tutorials: https://opengeospatial.github.io/e-learning/sld/text/main.html

19 Kommentare

  1. Renate Zweer sagt:

    Wir stellen unsere Kartendarstellungen in der GDI-BE auf eine Ausprägung über SLD um. Dabei haben die Kolleg*innen ein Problem bei der Darstellung von Symbolen an Polygonen:

    In der Hochwasserrisikokarte sind die gefährdeten und betroffenen Gebiete mit Symbolen an den Polygonen dargestellt https://fbinter.stadt-berlin.de/fb/index.jsp?loginkey=showMap&mapId=k02_23_4hwrkhigh2019@senstadt

    Eine Umstellung auf SLD ist bislang nicht geglückt. 


    Wir freuen uns auf einen Austausch! 




    1. Dr. Guido Schwichtenberg sagt:

      Renate Zweer

      Da wir ebenfalls Probleme hatten, auf einfache Weise benötigte SLDs zu erstellen, haben wir Ende letztes Jahres einen Auftrag vergeben, die SLD-Export-Funktion in QGIS (entsprechend unserer Anforderungen) zu ergänzen bzw. zu verbessern. Dieser Auftrag konnte Anfang des Jahres abgeschlossen werden und ist bereits in die aktuelle QGIS-Version eingeflossen (vgl. Changelog for QGIS 3.30 - Improved SLD Export Options). Soweit ich weiß, wurde diese Funktion auch als Backport in die LTR-Version 3.28 übernommen.

      Vielleicht können Sie Ihre Visualisierungen mit dieser neuen QGIS-Funktion nun doch auf SLDs umstellen. Viel Erfolg!

      1. Renate Zweer sagt:

        Vielen Dank für die Rückmeldung! Dr. Guido Schwichtenberg 

        Ich habe die Information weitergeleitet und bin gespannt ob die Umstellung auf SLD damit glückt.  


  2. Renate Zweer sagt:

    Aus aktuellem Anlass haben wir weitere Fragen zur Bereitstellung von SLD-Dateien und zur Informationsweitergabe darüber:

    • Wie können SLD-Dateien - auch jenseits der Registry – für Nutzende bereitgestellt werden und wie kann die Bereitstellung kommuniziert werden? Erfolgt das über den WFS und falls ja, an welcher Stelle und wie sind die Styles abrufbar? Oder sind die SLD-Dateien in den Dienste-Metadaten des WFS aufzuführen (transferOptions)? (In Berlin stellen wir über die transferOptions sog. „technische Beschreibungen“ bereit um u.a. die Aliasnamen im WFS mitzugeben).
    • Werden in Ihren/Euren GDIn SLDs für die Nachnutzung geteilt und falls ja, wie passiert das?

    Danke für den Austausch. Ich habe die Frage auch per Mail an Vertreterinnen und Vertreter der Kontaktstellen und die Leitungen des AK Geodienste und des AK Metadaten gestellt

    1. Madlen Dering sagt:

      Hallo Frau Zweer,


      uns (Kontaktstelle GDI-LSA) ist nicht bekannt, dass die SLDs mittels WFS transportiert werden (können). Als Darstellungsbeschreibung sind diese Teil der WMS. Die bei uns im System für INSPIRE hinterlegten SLDs sind nicht von außen erreichbar.

      Die Bereitstellung von durch die Bund-Länder-AGs/Fachgremien abgestimmten SLDs über die Registry wird begrüßt.


      Bisher werden die SLDs nicht für die Nachnutzung geteilt, da bisher diesbezüglich kein bekannter Bedarf bestand.

      1. Renate Zweer sagt:

        Vielen Dank, Frau Dering. Ich bin gespannt, ob der AK Geodienste und Armin Retterath mehr weiß als wir. 

  3. Anja Loddenkemper sagt:

    Im Rahmen des Nds. Projekts PlanDigital hat das Nds. Landwirtschaftsministerium (zuständig für die Raumordnung und Landesplanung) ein grundsätzliches Plugin für QGIS "X_Styles" erstellen lassen. Dieses Plugin wird nun sukzessive von hiesigen Fachleuten mit Signaturen für das Objektartenmodell XPlanung versehen. Dabei stehen insbesondere die Regionalen Raumordnungsprogramme (der Landkreise) und Flächennutzungspläne (FNP) im Fokus des Interesses.

    Ziel ist es, beispielsweise aus einem WFS Daten im Objektartenmodell XPlanung herunterladen zu können, sie in QGIS lokal einzulesen und diese Daten dann durch einen simplen Klick auf den Button des Plugins zumindest in QGIS ad hoc zu layouten. QGIS kann die Styles jedoch nicht als SLD speichern, sondern verwendet eine daran angelehnte Möglichkeit, aber ebenfalls gut lesbares XML. Angedacht ist es ausgehend von diesen QGIS-Styles auch WMS, die auf XPlanung-Daten basieren, layouten zu können. Diverse Dienste-Software arbeitet entsprechend mit QGIS zusammen und so kann ggf. das einmal für alle entwickelte Layout auch für die Abbildung per WMS genutzt werden. Das Plugin ist derzeit nur über das Ministerium zu beziehen, wird aber bereits von weiteren Stellen im Rahmen des derzeit Möglichen genutzt. Sobald ausreichend Signaturen enthalten sind, soll es im normalen QGIS-Repository bereitgestellt werden.

    Ich glaube das ist für uns hier ein guter Anfang, aber zugleich sehe ich es auch als mahnendes Beispiel: Wer ein Objekteartenmodell entwickelt, muss zwingend auch an den zugehörigen Signaturenkatalog / die Legende denken. Damit Vektoren von der Fachwelt verstanden werden können, ist es notwendig, sie fachlich korrekt und lesbar abzubilden. Auch muss man bedenken, dass Vektoren nur dann auf ihre fachliche Richtigkeit hin überprüft werden können, wenn sie sich angemessen präsentieren lassen. Die technische Richtigkeit im Hinblick auf eine Umsetzung des Datenmodells und die fachliche Richtigkeit gehen Hand in Hand. Nur wenn beides angemessen berücksichtigt wird, kann sich ein Datenmodell zum Wohle der Nutzer inhaltlich-fachlich und technisch weiterentwickeln.

    Dabei ist es ganz gleich, ob ich von einem Objektartenmodell XPlanung schreibe oder vom INSPIRE Datenmodell. Nur was wir verstehen, können wir beurteilen und ggf. für nützlich befinden. Nur die nützlichen Dinge werden sich positiv weiter entwickeln, weil viele an ihrer Umsetzung interessiert sind. Und Vektoren aus komplexen Datenmodellen ohne Layout sind maximal von mathematischem Interesse, für die Geodaten-Fachwelt jedoch belanglos.

    1. Renate Zweer sagt:

      Vielen Dank für die Informationen, Anja. Ich leite daraus ab, dass dir auch keine Möglichkeit bekannt ist, SLD-Dateien über den WFS bereitzustellen oder in den Dienste-Metadaten zu kommunizieren.  

      1. Anja Loddenkemper sagt:

        SLD-Daten sind ja nur XML-Dateien mit einer Designvorschrift. Ein WFS kann aber ja nur Vektordaten abgeben. Vektordaten aus dem WFS plus Nutzung der SLD-Signaturierung und Abgabe per WMS funktioniert. Ein WMS würde man allerdings nicht aus einem WFS speisen. Das wäre ja sehr langsam. Man greift also mit dem WMS auf die Vektordaten direkt und designed sie mit der SLD-Vorschrift. Genau da möchte ich eigentlich hin.

        Wenn man eine Zeichenvorschrift über einen Dienste-Metadatensatz für WFS bereitstellen wollte, so müsste man die SLD-Datei in ein Webverzeichnis legen und den Link auf die Datei im Metadatensatz (beispielsweise unter <transferOptions> mit dem Hinweis "Signaturierung der Vektoren", 'download') verlinken. Das ist in jedem Falle eine große Hilfe für den Nutzenden (m/w/d), weil er so sehen kann, wie er am schnellsten auch lokal in seinem GIS das Aussehen, was er womöglich aus dem WMS kennt, herstellen kann.

        Optimal wäre es, wenn wir in den <transferOptions> dann nicht nur diese eine schnöde Datei verlinken könnten, sondern eine zentrale Stelle hätten, wo grundsätzlich alle SLD gelagert werden, die dann gekoppelt beispielsweise mit dem Ressourcenidentifikator (MD_Identifier/code) auch wissen, zu welchen Daten sie gehören. Dann könnte man womöglich einen weiteren Automatismus herstellen, dass die Daten über die Metadaten wissen, wie ihr optimales Layout ist. (Das ist jetzt nur spontan hingeschrieben.)

        1. Renate Zweer sagt:

          Danke Anja,

          Zu „Einem WMS würde man allerdings nicht aus einem WFS speisen“. Nein, das tun wir auch nicht und haben wir auch nicht vor (Lächeln).

          Ich sehe es wie du: SLD teilen ist wichtig bei gleichen Datenmodellen (INSPIRE,  XPlan, ...). Ich habe mich noch einmal nach dem hier vorliegenden Anwendungsfall erkundigt: Er ist nicht belastbar begründet. Im Laufe des November soll er entweder erhärtet oder wegdiskutiert werden.

          Die <transferOptions> hatte ich auch im Blick für die Kommunikation. Allein, wir wissen ja um die Unschärfe dieser Information. Ich habe das Thema inzwischen auf unserer nächsten Sitzung des AK Metadaten eingetragen. Die "zentrale Stelle" (SLD-Register) hatte ich gedanklich "außen vor" gelassen - bis es dort irgendwann weitergeht.     

          (Bei der anderen "Kommunikationsschiene" "WFS selbst" hatte ich mehr an die Capabilities gedacht, als an das GetFeature)

    2. Anja Loddenkemper sagt:

      Die Stadt Wilhelmshaven will nach eigener Aussage in einer gestrigen Veranstaltung unter Federführung Nds. ML testen, ob die QGIS-Styles zu XPlanGML als SLD abgespeichert mit einem QGIS-Server-Dienst nachgenutzt werden können. Aus meiner Sicht hängt das auch sehr davon ab, ob QGIS in der Lage ist die eigenen Styles komplett nach SLD zu transformieren, so dass designtechnisch nichts verloren geht.

      1. Dr. Guido Schwichtenberg sagt:

        Anja Loddenkemper : Zu der neuen Möglichkeit des Exports von SLDs aus QGIS: s. mein Kommentar weiter oben. 

  4. Iris Heine sagt:

    Dr. Rene Höfer der Austausch könnte interessant für Sie sein

  5. Dr. Rene Höfer sagt:

    Sorry, dass ich erst jetzt in den Austausch einsteigen kann.
    Wir haben uns am BfN, auch als ein Ergebnis aus der LANA Ad-hoc AG, mit SLDs beschäftigt und für die Themen Schutzgebiete und Lebensraumtypen SLDs erstellt und bereitgestellt. 
    Dies erfolgte innerhalb der Steckbriefe der Fachnetzwerke z.B. Fachnetzwerk-->Schutzgebiete-->technischeUmsetzung mit Dokumentation des Aufbaus.Felix Portmann  und auch Kollegen aus NRW hatten auf jeden Fall schon mal einen Blick auf die SLDs geworfen. 

    Bei uns liegen die SLDs auf einem von extern erreichbaren Server. Tatsächlich haben wir in den Dienstmetadaten oder Capabilities darauf nicht aufmerksam gemacht. Nehme das aber mal mit. 

    Am Ende hängt die Weiterverwendung am genutzten ArcGIS Server. Dieser unterstützt nur "ältere" SLD Varianten (1.0), welche sich Maßgeblich von der Version 1.1. unterscheidet, so dass eine Weitergabe oder Weiterverwendung erschwert wird. Wir würden hier auch gern QGIS unterstützen müssten aber eine zweite Version erstellen. 


    Anmerkung: Im INSPIRE Kontext haben wir gerade technische Probleme, dass der INPSIRE-Dienst nicht auf die SLDs zugreift.

    1. Renate Zweer sagt:

      Vielen Dank auch an Sie, Herr Höfer, für Ihre Rückmeldung und die Erinnerung an die SLD für das INSPIRE-Thema PS. Dass die SLD nicht softwareübergreifend genutzt werden kann: Schlimm. Wie ich Ihrer readme entnommen habe, haben Sie sich an Anpassungen für verschiedene Softwaren versucht.

      Unser Fachbereich für das Thema PS kennt die Festlegungen aus dem Fachnetzwerk m.W. immer noch nicht. Schade. 


  6. Renate Zweer sagt:

    Aus der GDI Hessen hat mich die Information erreicht, dass "keine SLDs für die Nachnutzung geteilt" werden.

  7. Renate Zweer sagt:

    Unabhängig davon, dass der in unserer GDI an mich herangetragene Anwendungsfall nicht belastbar ist, fasse ich den bisherigen Erkenntnisstand zusammen. Enthalten sind auch Aspekte, die auf der Sitzung des AK Metadaten am 2.11.2022 genannt wurden:

    • SLD teilen ist sinnvoll bei Anwendungsfällen, in denen Daten im gleichen Datenmodell abgegeben werden (INSPIRE, X-Planung, …)
    • In diesen Fällen liegt die Information über ggf. vorhandene SLDs in den Fachnetzwerken (sowieso) vor.
    • Die geplante SLD-Bereitstellung für diese Anwendungsfälle über die Registry GDI-DE ist ins Hintertreffen geraten. Ein zentrales INSPIRE-Register wurde vor ca. 4 Jahren durch die Kst GDI-DE über die MIG-T angefragt.
    • Sofern über eine vorhandene SLD strukturiert informiert werden soll, sind die Dienste-Metadaten denkbar, hier die oben schon angesprochenen <transferOptions>. Da eine SLD – wenn dann – beim WFS benötigt wird, erscheint am ehesten eine Ergänzung der Dienste-Metadaten des WFS sinnvoll.
    • In dem Zusammenhang ist der Hinweis gegeben worden, dass Geoserver im WMS 1.1.1 die GetStyle-Operation unterstützt.
    • In dem Zusammenhang ist auch der Hinweise gegeben worden, dass der Style im GeoPackage mitgegeben wird. Zweifel, ob die Softwaren das lesen können, wurden geäußert
    • Meine Kollegen konkretisieren wie oben geschrieben entweder ihren Anwendungsfall oder die Sache ist für mich hiermit erledigt.

    Herzlichen Dank an alle, die mitdiskutiert haben!

  8. Peter Kochmann sagt:

    Der Vollständigkeit halber (egal, ob man dies jemals in diesem Kontext nutzen wird) hier noch der Verweis auf die Möglichkeit gem. ISO 19115, in den Metadaten den Zweig MD_PortrayalCatalogueReference zu nutzen, der über MD_Metadata/portrayalCatalogueInfo angesprochen wird und gem. der deutschen Übersetzung "Information über das Regelwerk für die Darstellung einer Ressource" vorhalten kann. Technisch verbirgt sich dahinter jedoch die bekannte Struktur CI_Citation mit den Elementen title, alternateTitle, date etc., allesamt Freitextfelder und nicht wirklich für Verlinkungen geeignet. Ausnahme: das Element identifier, das hier für einen (auflösbaren) Identifikator dienen und zu einem hinterlegten Dokument führen könnte.


  9. Tobias Kraft sagt:

    Ein Beispiel ist die einheitliche Erstellung digitaler Planzeichen gemäß Planzeichen-Verordnung (...)

    Für XPlanungsdaten sind SE-Regeln hier veröffentlicht https://gitlab.opencode.de/diplanung/ozgxplanung/-/tree/main/xplan-workspaces/src/main/workspace/styles/xplansyn/default

    Diese basieren auf einem XPlanungsversion-übergreifenden, flachen Schema, was in den meisten Fällen für die Darstellungsregeln jedoch keine Rolle spielt und nutzen deegree-spezifische Erweiterungen wie ogc:Functions für die Bestimmung der Geometrieart.