Guten Morgen, Freunde freier Geodaten und freier Geosoftware. Wir kommen jetzt zum letzten Vortrag und der knüpft an die beiden Vorträge an, die wir gerade gehört haben. Es sind ja einige Probleme aufgeworfen worden

und im nächsten Vortrag wird unter dem Stichwort Geodateninfrastruktur Deutschlands versucht, diese Probleme anzugehen und wie das im Einzelnen funktioniert, das hören wir jetzt von Armin Retterath. Schönen guten Morgen zusammen und erstmal eine Frage in die Runde weg.

Hat mal die WMS Spezifikation, die UGC WMS Spezifikation gelesen? Wer hat die WMS Spezifikation des UGC mal komplett durchgelesen? Das ist überschaubar. In dem Vortrag versuche ich jetzt mal eine der Lösungen vorzustellen,

die die öffentliche Verwaltung angeht, um die Probleme, die wir eben gehört haben, den beiden vorangehenden Vorträgen in den Griff zu kriegen. Wir haben schon gehört, die Inspire-Richtlinie hat dazu geführt, dass Geodaten grundsätzlich auffindbar sind in Europa und auch gewisse Standards, die die Inspire-Richtlinie uns gesetzt hat, haben auch dazu geführt,

dass der Zugriff auf Geodaten stark vereinfacht worden ist. Der Part, den ich jetzt hier vorstellen will, ist die Antwort von Deutschland aufgrund der Entwicklungen der letzten Jahre darzustellen. Wir haben also Ende letzten Jahres einen neuen Standard beschlossen, die GDI.de

und der gibt Regelungen vor, wie WMS und WMTS-Dienste in Deutschland zu konfigurieren sind, damit sie interoperabel verwendet werden können und auch rechtssicher genutzt werden können. Ich gehe mal kurz rein. Also erstmal würde ich ein paar Sätze zu den allgemeinen Zielen sagen.

Den Anwendungsbereich kurz festlegen, etwas über die historische Entwicklung der Standardisierung im Bereich, Darstellungsdienste oder WMS auflisten und dann konkret die Regelungen, die wichtigsten neuen Regelungen des Standards darlegen und am Ende ein paar Beispiele bringen,

wie die umgesetzt werden können und welche Vorteile wir von diesem neuen Standard bekommen werden. Allgemeine Ziele, das ist relativ einfach. Das Ziel der Geodateninfrastruktur und der Standardisierung, die wir hier betreiben, und das schon seit zwölf Jahren, ist eine interoperable Bereitstellung von Geodaten der öffentlichen Verwaltung, das was wir eben in den beiden vorangehenden Vorträgen auch gehört hatten,

über die Nutzung von offenen Standards. Und was wir auch haben wollen, das haben wir im ersten Vortrag gehört, ist eine dauerhafte Integrationsmöglichkeit dieser Daten, die die öffentliche Verwaltung publiziert oder produziert und publiziert, dann auch in Prozesse und Anwendungen über die Persistierung von URIs. Das war in dem Vortrag über Semantikweb eigentlich ganz gut rüber gekommen,

dass wir versuchen wollen dauerhafte URIs zu schaffen, um auf Daten zugreifen zu können. Nächster Punkt ist, dass wir eine maximale Kompatibilität auch erreichen wollen mit internationalen Standards. Da spreche ich dann eben die European Inspire Standards an und auch die ISO Standards, die halte vom OGC dann entwickelt werden im Bereich Geodaten. Und was wir auch machen wollen, ist natürlich eine Rechtssicherheit schaffen,

d.h. mehr Informationen dazu bereitstellen, wie diese Daten, die publiziert werden, auch genutzt werden können. Wir haben gehört, es gibt immer wieder Probleme bei der Interpretation der Metadaten, der Inhalte in Metadaten. Was darf ich überhaupt mit den Daten machen, wenn ich sie denn gefunden habe? Und in der Stelle versuchen wir, über diesen neuen Standard da auch eine Lösung zu schaffen.

Anwendungsbereich, genau, normale WMS-Dienst oder Darstellungsdienste sind dazu gedacht, Karteninformationen im Internet zu publizieren, d.h. einen Online-Zugriff zu realisieren. Der Standard selber hier soll für Deutschland gelten und auch für die Inspire Darstellungsdienste, d.h. diese Dienste, die für die Inspire-Richtlinie oder die Umsetzung der Inspire-Richtlinie erstellt worden sind.

Da versuchen wir dann noch zusätzliche Anforderungen zu definieren, die uns dann den Umgang mit diesen Diensten und den Daten nachher erleichtern. Historie, die WMS-Spezifikation wurde 1999 entwickelt im UGC, ist dann 2000 erstmalig publiziert worden und war dann auch einer der Startschüsse gewesen,

um diese Geodateninfrastrukturkonzepte eben da aufzubauen. Wir hatten, ich komme mal kurz auf die Entwicklung der Geodateninfrastruktur Deutschland ein, einen politischen Beschluss gehabt, 2003, der im Endeffekt dann

durch die Chefs der Staats- und Senatskanzleien von Bund und Ländern den Startschuss gesetzt hat zu dem Aufbau der Geodateninfrastruktur Deutschland. Das war 2003 gewesen, dann haben wir 2005 eine Organisationsstruktur geschaffen mit Koordinierungsstelle, Lenkungsgremium und einer politischen Aufsicht halt

für diese GDIDE-Organisation und 2006 hatten wir angefangen quasi die erste Standardisierung zu betreiben. Wir haben uns die WMS-Spezifikation angeschaut vom UGC und haben überlegt, welche Regelungen müssen wir in Deutschland treffen, um diese WMS-Dienste, die damals noch sehr heterogen konfiguriert waren

und auch sehr schlecht mit Metadaten ausgestattet waren, teilweise auch gar nicht richtig kompatibel zum Standard waren, eben zu verbessern. Und das hatten wir dann damals 2006 publiziert als WMS-DE-Profil der GDIDE. Hat das jemand mal gelesen? Das ist jetzt schon zwölf, ne, 13 Jahre her.

Einer, zwei, drei, also ist auch überschaubar die Wirkung dieses Standards. Schauen wir mal weiter. 2007, das ist eben im vorangegangenen Vortrag dokumentiert worden, gab es die EU-Inspire-Richtlinie, die dazu geführt hat, dass wir im Anschluss daran zwei Jahre später 16 Geodateninfrastrukturregelungen

oder gesetzliche Regelungen zur Umsetzung dieser Richtlinie in Deutschland bekommen haben aufgrund unseres föderalen Systems. Die Inspire-Richtlinie selber gibt den technischen Rahmen vor, wie die europäische Geodateninfrastruktur aufzubauen ist und beschäftigt sich eben wie auch die GDIDE mit der Standardisierung des Austauschs von Geodaten und insbesondere eben auch mit WMS-Diensten bzw. Darstellungsdiensten.

2009 hat die Kommission und auch durch das Parlament eben verabschiedet eine Regulation, also eine Rechtsverordnung, die ein bisschen konkreter definiert, wie diese Infrastruktur von Europa aussehen soll und wie die Daten ausgetauscht werden sollen. Das ist vielleicht jetzt schlecht zu sehen ganz hinten. Wir haben hier an dem Punkt

der Begriff View Service stehen. Der Begriff View Service ist ein abstrakter Begriff, der nichts anderes beschreibt als die Funktionalität von einem Webmapservice. Der wird halt nur eben nicht als Webmapservice bezeichnet, sondern will da in den rechtlichen Regelungen nicht so konkret werden, sondern die konkrete Umsetzung

dann in technischen Anleitungen dokumentieren. Das bedeutet, der Begriff Darstellungsdienste, der auch ein bisschen seltsam anmutet, der kommt aus dem europäischen Kontext und deswegen verwenden wir den jetzt hier an der Stelle wieder. 2011 bis 2013 oder 2013 nochmal überarbeitet, gab es dann eine Publikation eines

technischen Standards, wie Inspire Darstellungsdienste zu publizieren sind, was da alles eingestellt werden muss, wie die konfiguriert werden müssen, wie die Metadaten auszusehen haben. Das ist von einem IOC Task Force, also von einer Arbeitsgruppe auf europäischer Ebene erstellt worden und versucht und hat versucht dann konkret die ganzen Unzulänglichkeiten des Standards

in den Griff zu kriegen und damit halt eine funktionierende Geodateninfrastruktur auf europäischer Ebene überhaupt erst zu ermöglichen. Dieses Dokument haben wir dann auf Ebene von GDI.de direkt mit begleitet in den Erstellungsprozess des Dokuments und haben dann auch deutschsprachige

Handlungsempfehlungen herausgegeben. Hat die jemand gelesen? Ja, auch nur wenige. Aber das ist im Endeffekt die deutsche Regelung dazu, wie Inspire-konforme Darstellungsdienste oder View-Services zu konfigurieren sind, um die Anforderungen der EU-Richtlinie zu erfüllen. Und jetzt gehen wir ein paar Jahre weiter.

2018, November 2018, das habe ich eben schon mal erwähnt, sind wir dann jetzt zu einem neuen Standard gekommen in Deutschland, der allgemeine Vorgaben macht, wie WMS- und WMTS-Dienste in Deutschland konfiguriert werden müssen, damit sie interoperabel nutzbar sind und auch rechtssicher nutzbar sind. Das Dokument heißt einfach Vorgaben der GDI.de zur Bereitstellung von

Darstellungsdiensten, ist beschlossen worden von dem zuständigen Gremium. Es gibt aber bisher keine Beschlussfassung im IT-Planungsrat, sodass wir das dann irgendwie verbindlich festlegen könnten. Bei der Erstellung des Dokuments gab es zwei öffentliche Reviews und da sind dann 600 Anregungen und Kommentare eingearbeitet worden. Also das ist auch gestreut worden in dem Rahmen der öffentlichen Verwaltung hauptsächlich

und ist vom Qualitätsstand denke ich eigentlich ganz gut geworden. Hat davon jemand was gehört, dass dieses Dokument beschlossen worden ist oder irgendwo veröffentlicht worden ist? Auch nur wenige. Deswegen nutzen wir jetzt die Foskis dazu, das ein bisschen weiter zu verbreiten.

Ok, Regelungen, konkrete Regelungen, die in dem Dokument enthalten sind. Also das Dokument trifft Aussagen zu WMS- und WMTS-Interfaces, ähnlich wie die Europäische Kommission das auch für ihre View-Services gemacht hat und der Begriff Darstellungsdienst umfasst dann eben beide Interfaces. Wir haben 25 konkrete Anforderungen, die für die Interoperabilität zwingend notwendig sind, formuliert

und 24 Empfehlungen, die die Interoperabilität verbessern würden, wenn man es einhält, aber die sind halt nicht zwingend erforderlich. Und das Dokument selber klädert sich in einen Anforderungs- und Erläuterungsteil, damit es auch nicht zu umfangreich wird.

Konkrete Regelungen, was das Dokument beinhaltet. Im Bereich WMS wird gesagt, wenn WMS-Dienst oder Darstellungsdienst auf Basis von WMS-Interfaces zu publizieren sind, sollen beide Standards unterstützt werden, WMS-130 und WMS-111, aufgrund der Rückwärtskompatibilität, die notwendig ist und nicht jede Softwarekomponente unterstützt auch WMS-13.

Bisher im Bereich WMTS wird keine Verpflichtung dokumentiert, sondern es wird gesagt, das WMTS-Interface für die Darstellungsdienste ist optional, kann bei Bedarf eben auch konfiguriert und publiziert werden. Wir haben einen regulären Ausdruck eingeführt für Layernamen,

um da die Probleme bei den seltsamen existierenden Layernamen mit Umlauten und Sonderzeichnungen in den Griff zu kriegen. Das ist der wichtigste Punkt und der aufwendigste in der Umsetzung, eine Verpflichtung mit übernommenen Dokumenten zur Publikation von Service-Metadaten.

Wer kennt sich hier mit Geo-Metadaten nach ISO 1939 aus? Wer kennt überhaupt Geo-Metadaten? Die Inspire-Richtlinie erwartet für die Bereitstellung von Diensten Geo-Datensätzen, sowohl beschreibende Metadaten für die Datensätze, als auch jeweils Metadaten für die Dienste, um die über Kataloge austauschen zu können.

Das Problem, das wir eigentlich bei den Darstellungsdiensten haben und warum wir auch eigentlich gar keine rechtssichere Geodateninfrastruktur in Deutschland betreiben können, ist ein Problem, dass die Abbildung von Lizenzen in diesen Capabilities-Dokumenten, die serverseitig konfiguriert werden, nicht ausreichend sicher ist. Da kann ich nur zwei Freitextfelder ausfüllen

und das ist normalerweise nicht ausreichend, um halt Lizenzinformationen mit zu übertragen beim Austausch von Metadaten. Deswegen haben wir diese Verpflichtung der Bereitstellung von Service-Metadatendokumenten mit von Inspire übernommen. Genauso gibt es jetzt auch eine Verpflichtung darin,

diese Layer, die publiziert werden, auch mit Daten-Metadaten zu koppeln. Das bedeutet, diese Metadata, URL-Elemente oder Text in den Capabilities-Dokumenten wirklich auf Daten-Metadatensätze verlinken zu lassen, um die Beziehung zwischen Daten und Dienst nachher auch in der GDI wieder auflösen zu können.

Das hört sich jetzt ein bisschen aufwendig an, aber ich kann das vielleicht nachher am Beispiel vom Map-Server zeigen. In den letzten Jahren, zwei Jahren, sind auch da Entwicklungen passiert, die mit den Open-Source-Tools relativ einfach machen, diese Verpflichtungen hier zu erfüllen, auch gerade im Hinblick auf die Umsetzung der EU-Inspire-Richtlinie. Weitere Regelungen, wir versuchen zu empfehlen,

dass man keine Copyright-Vermerke in diese statischen oder diese Karten einblendet, weil wenn ich jetzt verschiedene Datenanbieter miteinander kombinieren will und hab dann überall Copyright-Vermerke drin, sieht das ziemlich scheußlich aus und die Daten können eigentlich gar nicht mehr richtig verwendet werden. Das ist das Ergebnis davon. Dann haben wir auch was mit übernommen,

was wir vor 10 Jahren oder vor 12 Jahren nicht hätten fordern können. Aufgrund der Rechnerleistung, die da gestiegen ist, fordern wir jetzt mal die Mindestgröße eines Kartenbildes von 3000 x 3000 Pixeln. Das ist für die interoperable Nutzung von diesen WMS-Interfaces extrem wichtig, insbesondere auch auf den Tablets und auf den hochauflösenden Bildschirmen,

die heutzutage in der Verwendung sind. Und da wir jetzt WMTS nicht als Pflichtinterface erwarten, müssen wir auch mit dem WMS umgehen können und erwarten das Auslieferung des Kartenbildes in einer einzigen Kachel. Was wir auch gemacht haben oder versuchen zu machen, ist die Standardisierung der Rückgabe,

Lehrer Get-Feature-Info-Anfragen. Wer das schon mal gesehen hat, wenn ich einen Dienst von einer externen Stelle nutze und klicke dann irgendwo rein, wo kein Objekt liegt, dann machen viele Kleines dann einfach ein leeres Fenster auf oder so weiter. Das ist nicht schön und um sowas zu vermeiden, sollten wir da in dem Bereich eben ein leeres HTML-Dokument definieren können,

worauf die Kleines reagieren können, um dieses Öffnen eines neuen Fensters zu unterbinden. Koordinatenreferenzsysteme, da hat sich eigentlich nichts zum letzten Standard geändert, sind geografische Koordinaten im WGS 84 und UTM-Koordinaten in ETRS 89.

Das sind die verpflichtend zu unterstützenden Koordinatenreferenzsysteme für die Darstellungsstandards. Weitere Regelungen, das war der größte Diskussionspunkt, deswegen hat es zwei Jahre gedauert, um dieses Dokument dadurch die Gremien zu bekommen. Wir haben ein einheitliches Kachel-Set für UTM 32 definiert,

mit einer geraden Maßstabsfolge, um das dann auch wirklich sinnvoll nutzen zu können, diese WMTS-Interfaces. Genau, und wenn Dienst abgesichert ist, fordern wir hier jetzt eine Minimal-Authentifizierungsmöglichkeit mit RFC 2617, also HTTP Authentication. Wir empfehlen auch die Verwendung von Core-Headern, um dann einfacher mit JavaScript-Klines

mit diesen Datenquellen kommunizieren zu können, und wir verweisen bei der Publikation von zeitlich oder höhenvariablen Daten auf ein Best-Practice-Paper des OGCs, was auch vom Deutschen Wetterdienst mitentwickelt worden ist 2014, sodass man dann auch mehrdimensionale Daten über WMTS-Interfaces interoperabel nutzen kann.

Das sind also einige Punkte, die sich da geändert haben. Ich würde jetzt in die praktische Dokumentation einsteigen und würde jetzt einfach nochmal zeigen, wie so ein Inspire-Capabilities-Dokument aussieht, oder wie diese Service-Meter-Daten gemäß der Inspire-Anforderungen zu verknüpfen sind.

Hat das hier schon jemand mal gesehen? Diese Erweiterung der Capabilities-Dokumente zur Abbildung von Service-Meter-Daten, das ist das, was wir jetzt auch deutschlandweit fordern, um die Lizenzen sauber abbilden zu können.

Und die Server-Komponenten, jetzt nehme ich mal Map-Server und auch Geo-Server als Beispiel, die haben auch Dokumentation, verfügen über Dokumentation, wie wir diese Links a priori erzeugen und befüllen können. Das ist bei Map-Server dokumentiert durch die Inspire-Richtlinie, und bei Geo-Server gibt es auch eine gute Dokumentation dazu,

indem ich halt diese Inspire-Extended-Capabilities aktiviere, und dann verfügen die Capabilities-Dokumente dieser Service-Komponenten um die notwendigen Voraussetzungen. Daten-Meter-Daten müssen auch im Capabilities-Dokument verlinkt werden, das zeige ich jetzt nochmal kurz an einem anderen Beispiel.

Das ist die Nutzung dieser Metadata-URL-Referenz, die jetzt hier steht, und auch dieses automatisierte Erstellen dieser Metadata-URL-Referenz ist gerade im Map-Server-Bereich, das habe ich eben schon mal kurz erwähnt, relativ einfach geworden.

Seit der 7.2. oder 7.2.4. Version von Map-Server gibt es eine neue Operation, die ist nur Map-Server-spezifisch, die heißt Get Layer Metadata, und damit bin ich in der Lage direkt a priori in der Map-Server-Konfigurationsdatei schon dieses XML-Dokument vorzukonfigurieren und dann eben mit anzugeben.

Ich glaube von der Zeit sind wir jetzt relativ knapp, ich zeige jetzt nochmal einen konkreten Beispiel, kurz diese Zeitvariable-Layer-Bereitstellung, zum Beispiel des deutschen Wetterdienstes, wie das nachher aussehen kann

und wie dann auch dann man Mehrwerte da erzeugen kann bei der Nutzung dieser Layer. Der deutsche Wetterdienst macht das schon seit Längerem, dass er halt quasi zum Beispiel die Satellitenbildinformation, ein Wolkenbedeckungslayer eben mit zeitlichen Filtern über WMS-Interfaces publiziert.

Das lässt sich dann relativ einfach nutzen. Okay, und da wir jetzt von der Zeit am Ende sind, würde ich jetzt gerne Fragen beantworten. Vielen Dank Armin, es scheint ja so als wenn die Voskis dazu beitragen kann,

dass dieser Standard jetzt tatsächlich auch mal bekannt wird in den Behörden untereinander und dass dann für die Anwender dann einfacher und transparenter wird, diese Daten dann auch zu nutzen. Und ich denke mal es gibt auch Fragen, da oben bitte. Zum Koordinatensystem, wieso ist ein 25833 da nicht dabei?

War eine lange Diskussion. Naja, das ist aber ganz schlecht, wenn das nicht dabei ist, weil wir als Stadt in Brandenburg stellen 32 nicht bereit. Haben wir halt mit der Nutzung von 32er-Diensten ernsthaft das Problem, weil die Schriften nämlich schief stehen. Und insofern ergibt sich da jetzt mittlerweile wieder eine entsprechende Insellösung.

Die 32er-Diskussion 3233 haben wir 2005 lange geführt. Und im 2006er-Standard war das auch schon auf UTEM 32 definiert gewesen. Und die Diskussion ist jetzt auch wieder aufgekocht und wir haben sie mit dem gleichen Ergebnis beendet.

Ja, mag sein, dass sich das aber heutzutage, sollte technologisch kein größeres Problem sein, verschiedene Koordinatensysteme von der Service-Komponente unterstützen zu lassen. Wir wollen Interoperabilität erreichen und das machen wir nicht mit zwei verschiedenen Koordinatensystemen. Das ist einfach hart vielleicht, klingt hart, aber macht Sinn. Der ist ja bereit.

Es ist aber normalerweise kein Problem. Der Server kann das ja out of the box. Warum denn nicht 330, wenn kein Problem ist?

Weil wir eins haben wollten und nicht zwei verschiedene. So, weitere Fragen. Ach so, Entschuldigung, ich wollte ganz kurz nochmal auf die Frage. Auch eine Sache, die Begründung war dieser WMTS-Kachelset,

was auch zwei Jahre lang gebraucht hat, um da durchzukommen durch dieses Gremium. Die Diskussion war noch härter gewesen und die haben immer argumentiert mit der Sache, wenn ich mehrere Koordinatensysteme unterstützen müsste, brauche ich natürlich auch doppelt so viel Speicherplatz, um diese Kacheln abzulegen. Also haben wir die Zahl der Referenzsysteme natürlich auch ein bisschen reduziert.

Warum ist WMTS nach wie vor optional? Weil die maximale Interoperabilität mit WMTS und Flexibilität mit WMTS Interfaces zu erreichen ist und WMTS aus unserer Sicht ist nice to have, nicht mehr und nicht weniger.

Und wir auch nicht wussten, ob wir die Diskussion mit einem einheitlichen Kachelset überhaupt erfolgreich beenden würden. Weitere Wortmeldungen aus dem Plenum. Ich wollte nur einen Kommentar abgeben.

Ich war vor ein paar Tagen in der Schweiz und die Schweizer Vermesser waren damals mit, ist jetzt Schaffhausen gewesen und haben diese Inspire Veranstaltungen in Baden-Württemberg, als das sozusagen publik gemacht wurden miterlebt und haben die Schütteln mit dem Kopf und sagt, wie ihr mit diesen Inspire-Diensten das alles machen wollt, verstehen die Schweizer nicht.

Ich gebe nur einfach den Kommentar weiter. Deutschland ist der größte Datenanbieter von Inspire-konformen Diensten und Datensätzen und Metadaten in Europa. Das ist einfach so. Das funktioniert, das hat gefruchtet, insbesondere bei den Bundeseinrichtungen, bei den großen,

die natürlich automatisch die ganzen Metadaten und Dienste konfigurieren. D-Status haben wir eben gehört, die haben seit Jahren da ein System auf Mapserver-Basis, das out of the box alles über eine Fassadentechnologie generiert und das funktioniert problemlos. Und das machen andere Bundeseinrichtungen, BAFG, Bundesanbieter für Gewässerkunde, auch so.

Und auch andere große Institutionen, Landesinstitutionen bei uns, die machen das auch und das scheint zu funktionieren. Die Technologie ist da, man muss nur richtig einsetzen. Alles ist auch nicht schlecht.

Aber wir wollen natürlich auch eine Interoperabilität zu Europa herstellen. Das heißt, wir wollen nicht dem widersprechen, was in Europa schon festgelegt ist und wir haben nur diese Richtlinie. Das ist der einzige gesetzliche Zwang, mit dem wir Interoperabilität erreichen können. Sonst gibt es nichts. Das ist das Problem. Und der IT-Planungsrat ist da auf beiden Ohren etwas taub für diese Geodatenstandards, glaube ich.

Das Auditorium ist weiterhin gefragt. Alles klar. Gut, dann wird das ja in Zukunft wunderbar funktionieren, hoffen wir. Vielen Dank. Recht vielen Dank nochmal an Armin.