GeoServer SLD Editor

Was ich vor gut einem Jahr in meiner Diplomarbeit versuchte, aber zeitlich nicht auf die Reihe bekommen habe, hat die GeoServer Community jetzt auf die Beine gestellt: Einen browser-basierten SLD-Editor.

Der Editor ist als Extension für GeoServer verfügbar und basiert auf dem gerade frisch aufgelegtem GeoExt JavaScript Framework. Ich selbst habe das Plug-in noch nicht ausprobiert, aber die Screenshots sehen vielversprechend aus.

Zu Ron Lakes Kritik an aktuellen WMS-Implementierungen

In dem Beitrag WMS, WFS, and Community Schemas hat sich Ron Lake zu den Interoperabiltätsproblemen derzeitiger Implementierungen der Web Map Service oder Web Feature Service Spezifikation geäßert. Er kritisiert darin, dass nachwievor Schwächen bei der Unterstützung so genannter Community Schemas bestehen. Insbesondere die fehlenden Möglichkeiten zur Abbildung von verschiedenen Datenbankschemas auf ein gemeinsames Community Schema sieht er als großes Problem, das die Datenintegration in einer Geodateninfrastruktur behindert.

Auch die weite Verbreitung so genannter Integrated WMS Architekturen, also Architekturen bei denen Map Service und Datenquelle fest gekoppelt sind, führt er auf dieses Problem zurück. Er fordert daher die Entkopplung von Map Services und den zu visualisierenden Daten, was als Component WMS bekannt ist. Demnach wird im GetMap-Request die URL einer Datenquelle mittels REMOTE übergeben. Der WMS fordert die Daten dann von einem WFS oder WCS durch einen GetFeature oder GetCoverage-Requests an. Ein WMS kann dann also Daten von verschiedenen Datenservices integriert darstellen.

Die Kritik Lakes in Bezug auf die fehlende Unterstützung für Community Schemas ist verständlich, da eine Integration von Daten, die zwar der gleichen thematischen Bereich angehören, allerdings von verschiedenen Anbietern bereit gestellt werden, so nicht möglich ist. Allerdings wird die Component WMS Architektur auch heute schon von verschiedenen Implementierungen (z.B. GeoServer oder MapServer) unterstützt — zumindest für die Visualisierung von Daten eines Web Feature Service. Prinzipiell ist die integrierte Visualisierung von Daten also möglich. Nur die Datenintegration in einem Layer könnte aufgrund unterschiedlicher Datenmodelle problematisch sein. Es handelt sich also hierbei nicht um eine Problem, das auf die Architektur zurück zu führen ist, sondern lediglich auf die fehlende Unterstützung von Community Schemas.

Laut Lake würde eine Component WMS Architektur auch das Problem umgehen, dass keine Möglichkeiten zur Steuerung der Visualisierung von Geodaten bestehen, weil das zu Grunde liegende Datenschema nicht einsehbar ist. Das gilt aber nur dann, wenn der WMS nicht zusätzlich Teile eines WFS-Interfaces bereit stellt. Bei vielen Produkten, z.B. Geoserver oder MapServer, werden neben der WFS-Spezifikation auch WFS oder WCS unterstützt. In dem Fall is es möglich, mit dem DescribeLayer-Request des WMS-Infaces die Basis-URL des zugehörigen WFS zu ermitteln und dann den DescribeFeatureType-Request des WFS-Interfaces zu nutzen, um eine Beschreibung der zu Grunde liegende Datenstruktur zu bekommen. Mit Styled Layer Descriptor kann dann auf dieser Basis vom Client aus die Visualisierung der Daten durch den WMS beeinflusst werden.

Die Implementierung eines WMS als Component Architektur ist nicht immer sinnvoll ist. Denn ein Component WMS, der offen zur Verfügung steht, kann natürlich auch von jedem zur Visualisierung von Daten genutzt werden. Das kann zu erheblichen Traffic und zu erhöhten Kosten für den jeweiligen Anbieter führen. Ob das dann im Sinne des Anbieters ist, ist fraglich. Es müsste also Möglichkeiten geben, die Nutzung solcher Anwendungen nur für bestimmte Nutzer zu erlauben und vielleicht sogar eine Auswahl nutzbarer Datenservices zu definieren.

Lakes Kritikpunkte sind also teilweise nachzuvollziehen, geht aber zum Teil auch einen Schritt zu weit. Denn Coupled WMS Architekturen sind einerseits schon möglich, sind aber andererseits nicht zwangsläufig die perfekte Lösung für jeden Anwendungsfall.