Autoren

Entwurf

Einleitung

Ziel der Geodateninfrastrukturen in Deutschland (GDI-DE) ist es, vorhandene Geodaten und Geodatendienste von Bund, Ländern und Kommunen für Wirtschaft, Wissenschaft, Verwaltung und Bürger interoperabel bereitzustellen. Für ein zukunftsfähiges E-Government in Deutschland ist eine Verwendung von Standards über offene und normierte Schnittstellen eine Grundvoraussetzung für funktionierende Geodateninfrastrukturen.

Für die Visualisierung von Geodaten durch Geodatendienste werden in der GDI-DE Kartengraphiken erzeugt, die durch sogenannte Geodatendienste, in diesem Fall Darstellungsdienste, dem Nutzer zur Verfügung stehen. Durch diese Aufbereitung der Geodaten und Geodienste wird ein Online-Zugriff auf grafische Präsentationen von verteilten Geodaten ermöglicht, welche sich direkt in Verwaltungsprozesse und Applikationen integrieren lassen.

Die GDI-DE basiert grundsätzlich auf einer dezentralen Bereitstellung von Geodaten mittels standardisierter Webservices, der sogenannten "Service Orientierten Architektur" (SOA -https://de.wikipedia.org/wiki/Serviceorientierte_Architektur). Die verwendeten Dienste basieren auf internationalen Standards und Normen, welche aufgrund ihrer weltweiten Verwendung einen großen Anwendungsspielraum zulassen.

Dieses Dokument ist ein Applikationsprofil der GDI-DE zur Bereitstellung von Darstellungsdiensten und beinhaltet einheitliche Vorgaben für eine interoperable Bereitstellung von Web Map Services (WMS) und Web Map Tile Services (WMTS)innerhalb der GDI-DE. Es legt die Anforderungen der INSPIRE Richtlinie (INSPIRE: Infrastructure for Spatial Information in the European Community) zur Schaffung einer Geodateninfrastruktur innerhalb der Europäischen Union (http://inspire.ec.europa.eu/) fest. Dabei werden die internationalen Standards der OGC (OGC: Open Geospatial Consortium) und der ISO (ISO: International Organization for Standardization) berücksichtigt.

Das vorliegende Applikationsprofil gliedert sich in zwei Teile. Der erste Teil umfasst die konkreten Anforderungen an Darstellungsdienste, der zweite Teil stellt Erläuterungen und Hintergrundinformationen bereit.

Das bisher in der GDI-DE gültige WMS-DE Applikationsprofil vom 17.10.2006 (GDI-DE Profil WMS-DE_1.0) wird durch dieses Dokument ersetzt.

Anforderungen

Art der Bereitstellung

Um ein höchstes Maß an Interoperabilität und Flexibilität zu erreichen, sollen Geodaten grundsätzlich über WMS Schnittstellen bereitgestellt werden.

Das Anbieten einer WMTS Schnittstelle ist möglich, aber nicht verpflichtend. Über WMS und WMTS hinaus können beliebige zusätzliche Schnittstellen angeboten werden.

Persistenz/Identität

Wie schon in der Einleitung erwähnt, ist es bei einer SOA wie einer GDI systemrelevant, dass die Datenquellen dauerhaft referenzierbar sind. Im Falle von Darstellungsdiensten auf Basis der OGC-Standards WMS und WMTS gibt es für jeden Server eine URL, über die weitere Metadaten zum Dienst in Form von Capabilities-Dokumenten verfügbar gemacht werden. Die Capabilities-Dokumente beinhalten zum einen die Zugriffsadressen (URLs) zu den jeweiligen technischen Operationen(GetMap, GetFeaureInfo...), zum anderen Metadaten über den Inhalt, der über den Dienst publiziert wird (Layerstruktur, Layer, etc.).

Das Hauptziel einer GDI ist die Integration der Dienste in Verwaltungsprozesse und Applikationen. Dies geschieht über das Einbinden der URL auf das Capabilities-Dokument in die Applikation oder den Prozess. Die Anwendung kommuniziert somit selbständig via Internet mit der jeweiligen Datenquelle und erhält auf Anfrage die benötigten Informationen (in diesem Falle Kartengraphiken) zurück.

Die eindeutige Referenzierung des Datensatzes (Layers) erfolgt dabei durch eine Kombination der URL des Servers mit dem name/identifier Element des jeweiligen Layers. Dienst-URL und name/identifier von Layern sollen nach Veröffentlichung eines Dienstes nicht mehr verändert werden.

Mit dem optionalen Parameter updateSequence der GetCapabilities Operation kann eine Anwendung feststellen, ob sich ein Capabilities-Dokument seit dem letzten Zugriff geändert hat.

Empfehlung

Unterstützung des updateSequence Parameters der GetCapabilities Operation.

Zu unterstützende Versionen

WMS

WMS-DE_1.0 - 3.2 - 1

Es gibt zwei meist genutzte Versionen des OGC WMS Standards mit unterschiedlichem Verbreitungsgrad, Version 1.1.1 und Version 1.3.0. Aktuell unterstützen die meisten Server die neuere WMS 1.3.0 (ISO19128) Version. Die Cliententwicklung ist jedoch langsamer. Viele Clients haben Probleme beide WMS Standards parallel zu verwenden. Das liegt insbesondere an der unterschiedlichen Interpretation der Reihenfolge der Koordinatenachsen beim Aufruf der Operationen. Deshalb sollten mittelfristig noch beide Versionen implementiert sein.

Empfehlung

Als Datenanbieter ist es sinnvoll eine Software zu verwenden, die sowohl die Version 1.1.1 als auch die Version 1.3.0 des WMS Standards unterstützt.

Anforderung

Sollte nur eine Version angeboten werden können, so ist die aktuellere Version 1.3.0 zu verwenden.

WMTS

Anforderung

Der Kartenserver muss mindestens die WMTS Version 1.0.0 unterstützen.

Darstellung von Copyright Vermerken

In der Rückgabegraphik eines GetMap/GetTile Request dürfen keine statistischen Informationen wie z.B. Copyright-Vermerken oder Logos eingeblendet werden. Copyright-Vermerke und Nutzungsbedingungen werden in den Metadaten des Dienstes eingetragen. Hier gibt es das Datenfeld fees oder im Falle von Zugriffsbeschränkungen das Feld accessConstraints.

Hintergrund: Insbesondere bei der Kombination mehrerer Datenquellen führen diese zu einer extremen Verschlechterung der Nutzbarkeit. Die Positionierung solcher Informationen im Bild sind nicht zu verallgemeinern und beschränken die gewünschte Interoperabilität stark. Ein Beispiel hierzu finden Sie in dem Erläuterungsteil des Dokumentes.

Anforderung

Das angeforderte Kartenbild muss frei von eingeblendeten statischen Informationen (wie z.B. Copyright-Vermerken) sein.

Koordinatenreferenzsysteme

WMS-DE_1.0 - 2.1

WMS

Um eine einheitliche Präsentation der verteilten Datenquellen zu ermöglichen, müssen die Kartenserver Kartenbilder liefern, die in einem gemeinsamen Koordinatenreferenzsystem (CRS) angeboten werden. Für Deutschland ist dies das Koordinatensystem ETRS89 mit der Abbildung UTM32N (EPSG:25832). Um eine globale Interoperabilität zu erreichen, muss als Minimum zusätzlich das geographische Referenzsystem WGS84 (EPSG:4236) unterstützt werden.

Um eine bessere Integration der Daten mit dem weltweit sehr stark verbreiteten (z.B. Google/OSM) WGS84-Pseudo Mercator Systems (EPSG:3857) zu erhalten, wird empfohlen, auch dieses CRS zu unterstützen.

Alle INSPIRE relevanten Dienste müssen darüber hinaus im Koordinatenreferenzsystem (EPSG:4258) angeboten werden.

Anforderung

Die Kartenserver müssen Graphikanfragen zumindest für folgende Koordinatenreferenzsysteme unterstützen: EPSG:25832 und EPSG:4326.

Empfehlung

Die Kartenserver sollten außerdem Graphikanfragen für folgende zusätzliche Koordinatenreferenzsysteme unterstützen: EPSG:3857 und EPSG:4258.

WMTS

in die Erläuterungen pushen Die hohe Performanz eines WMTS basiert darauf, dass die Rasterdaten vorprozessiert in einer optimalen Struktur vorliegen. Das heißt, es werden Caches in vordefinierten Maßstäben und vordefinierten CRS erzeugt. Will man mit einem WMTS hochperformant mehrere CRS unterstützen, so ist es nötig, für jedes CRS einen eigenen Cache zu errechnen und vorzuhalten. Bei hochauflösenden Daten, wie z.B. Luftbildern führt das zu einem großen Speicherbedarf.

Eine Empfehlung, welche Koordinatensysteme für WMTS zu unterstützenden sind, wird aufgrund der starren und ressourcenintensiven Auslegung des WMTS nicht ausgegeben. Die tiles sets (Kachelarchive) sind spezifisch für die Koordinatensysteme/Anwendungen zu erstellen. Der WMTS sollte angepasst an den Nutzerkreis in den meistgenutzten Koordinatensystemen bereitgestellt werden.

Sprache

WMS-DE_1.0 - 2.2

Die Inhalte von Textfeldern in der Antwort auf die GetCapabilities Anfrage werden grundsätzlich in deutscher Sprache veröffentlicht. Sollen weitere Sprachen bereitgestellt werden, ist das über den zusätzlichen Parameter „Language“ im GetCapabilities Dokument möglich.

Anforderung

Die Textfelder im Capabilities Dokument sind in deutscher Sprache zu verfassen. Werden weitere Sprachen angeboten, so erfolgt dies analog zu den Handlungsempfehlungen für die INSPIRE Darstellungsdienste.

http://www.geoportal.de/DE/GDI-DE/Media-Center/Dokumente/dokumente.html?lang=de

Verfügbarkeit

Im Rahmen der Umsetzung der EU INSPIRE-Richtlinie wurde eine Rechtsverordnung erlassen, die eine Verfügbarkeit von 99% für die Netzdienste der europäischen Geodateninfrastruktur vorgibt. Erst mit einer hohen Verfügbarkeit können die Ziele einer GDI erreicht werden. Die Nutzer sollen direkt über das Internet auf die Geodaten zugreifen können und die Notwendigkeit des Vorhaltens von Sekundärdaten damit entfallen. Dies kann nur gewährleistet werden, wenn die Zuverlässigkeit von Dienste-Zugriffen gesichert ist.

Ausführliche Informationen finden Sie in den Handlungsempfehlungen zum Darstellungs- und Downloaddienst welche auf der Seite der GDI-DE heruntergeladen werden können.

Empfehlung

Kartenserver sollten so konfiguriert werden, dass eine Verfügbarkeit von mindestens 99% gewährleistet werden kann.

Layername / Identifier

Der Layername des WMS beziehungsweise der Identifier des WMTS Layers sind Identifikatoren, die grundsätzlich von der Software genutzt werden (Maschine-Maschine Kommunikation). Um Fehler auszuschließen, sollten sich diese Identifikatoren nur aus Zeichen zusammensetzen, deren Verwendung in unterschiedlichen Programmiersprachen unbedenklich sind. Außerdem sollte die Zahl der verwendeten Zeichen nicht zu groß sein, da es sonst bei Clients, die die Kartenanfragen per http-get umsetzen, durch die Beschränkung der URL-Länge, zu Abbrüchen kommen kann (stark abhängig vom verwendeten Browser).

Innerhalb eines Dienstes darf der gleiche Layer-Identifikator nicht mehrfach vorkommen, da dieser ansonsten vom Client nicht mehr unterschieden werden kann.

Anforderung

Layernamen, bzw. -Identifikatoren müssen innerhalb eines Dienstes eindeutig sein und müssen folgenden regulären Ausdrücken entsprechen: [0-9a-zA-Z.\-_:]+ WMS-DE_1.0 - 3.2 - 6

Empfehlung

Die Zahl der zu verwendenden Zeichen im Layernamen bzw. -Identifikator sollte so klein wie möglich sein.

Zeichenkodierung von textbasierten Rückgabewerten

Anforderung

Textbasierte Rückgabewerte, wie zum Beispiel Antworten auf GetCapabilities, GetFeatureInfo sowie Service Exceptions müssen UTF-8 kodiert zurückgeliefert werden.

GetMap

Formate

WMS-DE_1.0 - 3.2 - 2

Anforderung

Für die Operation GetMap, ist mindestens image/png als valides Rückgabeformat zu unterstützen.

GetFeatureInfo

Formate

Anforderung

Für die Operation GetFeatureInfo, ist zumindest der MIME type text/html als valides Rückgabeformat zu unterstützen. WMS-DE_1.0 - 3.2 - 8

Empfehlung

Aufgrund der weiten Verbreitung, sowie der einfachen Interpretierbarkeit des Formates, sollte zusätzlich application/vnd.ogc.gml (WMS 1.1.1) und application/vnd.ogc.gml/3.1.1 bzw. application/gml+xml; version=3.1 (WMS 1.3.0) als Rückgabeformat unterstützt werden.

Leere Rückgabe

Um zu verhindern, dass bei GetFeatureInfo Abfragen, die kein Ergebnis erzielen, leere Fenster geöffnet werden, ist es notwendig, eine leere HTML Seite zu definieren. Hier gibt es beim W3C je nach HTML-Version unterschiedliche Vorgaben, die von Clients unterschiedlich interpretiert werden.

Anforderung

Wird über eine GetFeatureInfo Anfrage kein Objekt identifiziert und wurde die Anfrage mit dem Mimetype text/html durchgeführt, so muss in den body-Tag der leeren HTML Seite das Attribut class="getfeatureinfo-isempty" eingeführt werden.

Absicherung

Empfehlung

Sollen Darstellungsdienste nur bestimmten Nutzergruppen zugänglich gemacht werden, so sind hierzu die Standardverfahren (httpauth (RFC2617 – HTTP-Authentication), IP oder WSS) zur Authentifizierung des http-Protokolls zu verwenden. Hinweis: Geschieht die Absicherung über httpauth ist darauf hinzuweisen, dass die HTTP-BASIC Authentication Nutzername und Passwort im HTTP-HEADER im Klartext überträgt und der Dienst daher nur über eine sichere https-Verbindung genutzt werden sollte.

Anforderung

Geschützte Darstellungsdienste sollen mindestens mit einem Standardverfahren zur Authentifizierung abgesichert werden.

Header der Capabilities Dokumente

Anforderung

Die Header der Capabilities Dokumente müssen alle Informationen beinhalten, die es einem Client erlauben ihren Inhalt zu validieren. Im Fall des WMS 1.3.0 sind das Verweise auf die jeweiligen Schemadateien, beim WMS 1.1.1 ist es die zugehörige DTD Datei. Die Nutzung der INSPIRE Erweiterungen erfordert für den WMS 1.3.0 und den WMTS zusätzlich die Angabe des INSPIRE Schemas. Beim WMS 1.1.1 ist eine umfangreiche Erweiterung im Header selbst erforderlich. Weitere Hinweise zur Umsetzung können den Handlungsempfehlungen für die INSPIRE Darstellungsdiensten entnommen werden.

Service Level Metadaten im Capabilities Dokument

WMS-DE_1.0 - 3.2 - 5
Die Metadaten im Service-Bereich der Capabilities beschreiben den kompletten Dienst, nicht die Datenquellen des Dienstes. Die folgende Tabelle stellt die Metadaten der jeweiligen Schnittstellen in ihren Versionen gegenüber. Grau unterlegte Felder sind verpflichtend, weiße Felder sind optional.

Angaben zum Zugang und zur Nutzung von Diensten

Die Angaben zum Zugang und zur Nutzung von Ressourcen umfassen nach den Konventionen-Dokument des AK-Metadaten:

Nutzungseinschränkungen - Einschränkungen, die die Eignung der Ressource oder Metadaten betreffen; (Nutzungseinschränkungen werden im Element useLimitation des Dienst-Metadatensatzes als Freitext dokumentiert, zur semantischen Klarstellung beginnt der Eintrag daher mit "Nutzungseinschränkungen:")

Nutzungsbedingungen - Einschränkungen zum Schutz der Privatsphäre oder des geistigen Eigentums sowie andere besondere Einschränkungen oder Warnungen bezüglich der Nutzung der Ressource; (Nutzungsbedingungen werden im Element useConstraints des Dienst-Metadatensatzes über eine Codeliste oder als zusätzliches Freitext dokumentiert. Für INSPIRE identifizierte Dienste werden die Nutzungsbedingungen zusätzlich im Feld useLimitations als Freitext dokumentiert, zur semantischen Klarstellung beginnt der Eintrag dort mit "Nutzungsbedingungen:")

Zugriffseinschränkungen - Beschränkungen des öffentlichen Zugangs; (Zugriffseinschränkungen werden im Element AccessConstraints des Dienste-Metadatensatzes über eine Codeliste oder als zusätzliches Freitextfeld dokumentiert)

Für die Bereitstellung von Diensten in der GDI-DE sollen daher folgende Vereinbarungen gelten: Die Angaben zum Zugang und zur Nutzung von Diensten sind sowohl im Dienst-Metadatensatz (ISO 19139) als auch im Capabilities Dokument eines Dienstes verpflichtend anzugeben. Um Missverständnissen vorzubeugen, sollen die Angaben gleich lauten. Dabei ist folgendes zu beachten:

Die Angaben aus dem accessConstraints-Element des Dienst-Metadatensatzes sollen den Angaben des AccessConstraints-Elements der Capabilities entsprechen. Weiterhin sollen die Angaben aus dem useConstraint-Element des Dienst-Metadatensatzes den Angaben des Fees-Elements entsprechen. Sofern es auch Nutzungseinschränkungen gibt, werden diese im useLimitations-Element des Dienst-Metadatensatzes angegeben.

Anforderung

Die Angaben im useConstraints-Element des Dienst-Metadatensatzes sollen den Angaben im Fees-Element des Capabilities Dokumentes entsprechen.

Anforderung

Die Angaben im accessConstraints-Element des Dienst-Metadatensatzes sollen den Angaben im AccessConstraints- Element des Capabilities Dokumentes entsprechen.

Empfehlung

Sofern es noch Nutzungseinschränkungen gibt, sollen diese mit im Fees-Element aufgenommen werden.

Empfehlung

Sind in den Dienst-Metadatensätzen die Elemente useConstraints und accessConstraints mehrfach vorhanden, so sollten diese in den jeweiligen Freitextfeldern der Capabilities Dokumente durch ein | getrennt aufgeführt werden.

Verlinkung des Dienst-Metadatensatzes im Capabilities Dokument

Anforderung

Zusätzlich zu den von der Spezifikation geforderten Informationen, muss im Capabilities Dokument ein Dienst-Metadatensatz referenziert werden. Die Verlinkung hat entsprechend der INSPIRE Vorgaben zu erfolgen.

Beispiel: <source lang="html5"> <VendorSpecificCapabilities> <inspire_vs:ExtendedCapabilities> <inspire_common:MetadataUrl xsi:type="inspire_common:resourceLocatorType"> <inspire_common:URL> http://www.geoportal.rlp.de/mapbender/php/mod_layerISOMetadata.php?SERVICE=WMS&outputFormat=iso19139&Id=24124 </inspire_common:URL> <inspire_common:MediaType>application/vnd.iso.19139+xml</inspire_common:MediaType> </inspire_common:MetadataUrl> </inspire_vs:ExtendedCapabilities> </VendorSpecificCapabilities> </source>

Hinweis: Die Nutzung der von INSPIRE vorgesehenen Erweiterung erfordert das Anpassen des XML Headers der Capabilities Dokumente. Bei Software, die diese Anpassung nicht automatisch umsetzt, müssen die Capabilities Dokumente händisch angepasst werden.

Bildgrößenbeschränkung

WMS

Die auslieferbare Bildgröße sollte in der Regel einer Beschränkung unterliegen, um beispielsweise gewisse Leistungsvorgaben (Bilder/sec) erfüllen zu können. Da die Darstellungsdienste grundsätzlich auf eine Online-Nutzung ausgerichtet sind, ist es nicht notwendig sehr große Bilder über die WMS-Schnittstelle abzugeben.

In folgenden Anwendungsfällen, sind auch größere Bilddaten sinnvoll:

1. Hochauflösende Druckaufbereitung
2. Nutzung des WMS zur Datenabgabe (z.B. im GeoTIFF Format)

Die Information für die maximale Pixelzahl liefert der WMS 1.3.0 als Metadatenelement im Capabilities Dokument. Der WMS 1.1.1 beinhaltet diese Möglichkeit nicht.

Anforderung

Darstellungsdienste auf Basis einer WMS Schnittstelle sollten mindestens dazu in der Lage sein ein Bild der Größe 3000x3000 Pixel ausliefern zu können.

Anforderung

Darstellungsdienste auf Basis der WMS 1.3.0 Schnittstelle müssen die Metadatenelemente MaxWidth und MaxHeight liefern, sofern Obergrenzen für die maximal mögliche Pixelzahl existieren.

Content Level Metadaten im Capabilities Dokument

Empfehlung

Die Größe der angegebenen BoundingBox soll der wahren räumlichen ausdehnung (Extent) der bereitgestellten Daten entsprechen.

Anforderung

Die Angabe der Maßstabsbereiche soll den realen Einstellungen auf dem Server entsprechen.

Anforderung

Bei der Berechnung der Maßstabszahlen ist von einer Bildschirmauflösung von 90,714 dpi auszugehen.

Anforderung

Werden die eingestellten Maßstabsbereiche unter- bzw. überschritten, soll der Dienst leere, transparente Bilder liefern.

Empfehlung

Sollen Keywords dazu verwendet werden, Layer thematisch zu klassifizieren, so kann dies seit der WMS 1.3.0 Version durch die Angabe eines Thesaurus erfolgen. Beispiel: <source lang="html5"><Keyword vocabulary="ISO 19115:2003">geoscientificInformation</Keyword><Keyword vocabulary="GEMET - INSPIRE themes">Administrative units</Keyword></source>

Styles / Legenden

WMS

Um mittels WMS unterschiedliche kartographische Ausprägungen einzelner Produkte publizieren zu können, ist es sinnvoll den dafür vorgesehenen Style Parameter zu verwenden. Es handelt sich dabei um eine zusätzliche Dimension mit der ein Nutzer die Möglichkeit erhält, unter verschiedenen graphischen Ausgestaltungen des gleichen Produktes zu wählen. Nicht sinnvoll ist es, Styles auf verschiedene Nutzergruppen beschränken zu wollen. In diesem Fall wird empfohlen eigene Dienste (Produkte) zu generieren und diese mittels einfacher Authentifizierungsverfahren den jeweiligen Gruppen zugänglich zu machen.

Empfehlung

Bei der Bereitstellung von Diensten, die die gleichen Daten in verschiedenen graphischen Ausprägungen bereitstellen sollen, soll von der Style-Option der WMS Schnittstelle Gebrauch gemacht werden.

Empfehlung

Bei der Bereitstellung von Grafiken über das LegendURL Element im Layer Style, soll vermieden werden die Layer Titel mit in die Ausgabegrafik zu rendern. Grundsätzlich soll die Darstellung der Legenden vom Client aus beeinflussbar sein. Das erhöht z.B. die Flexibilität bei mehrsprachigen Anwendungen. Diese Empfehlung ist erst in der WMS 1.3.0 Spezifikation enthalten.

Empfehlung

Bei Bereitstellung von Layern auf Basis von Vektordaten, deren Darstellung abhängig vom Maßstab variiert, soll der bereitstellende WMS die Operation GetLegendGraphic und den zugehörigen Parameter "Scale" unterstützen.

WMTS

Transparenz

Anforderung

Der Parameter "Transparent" muss unterstützt werden.

Handling von Exceptions

Je nach WMS Version müssen unterschiedliche MIME types verwendet werden.

Empfehlung

Der WMS Dienst 1.1.1 soll als Rückgabeformate für Service Exceptions die folgenden MIME types unterstützen:

• application/vnd.ogc.se_xml
• application/vnd.ogc.se_inimage
• application/vnd.ogc.se_blank

Der WMS Dienst 1.3.0 soll als Rückgabeformate für Service Exceptions mindestens folgendes MIME types unterstützen:

• XML
• INIMAGE
• BLANK

Daten-Dienste-Kopplung

Die Daten-Dienste-Kopplung aus Sicht des Dienstes (OGC Capabilities) erfolgt über die Angabe einer oder mehrere MetadataURL Einträge am jeweiligen Layer. Diese verlinken auf die Metadaten der Datensätze, die durch den Layer visualisiert werden. Um hier eine maximale Interoperabilität zu erreichen, soll der INSPIRE-Ansatz Verwendung finden. Dieser legt fest, dass für jeden Layer des Darstellungsdienstes ein Ressourcenidentifikator angegeben wird, der durch die Elemente AuthorityURL und Identifier (Datensatzidentifikator) repräsentiert wird. Die AuthorityURL bezeichnet zumeist die geodatenhaltende Stelle in Form eines Namensraumes. Dieser Namensraum kann über die GDI-DE Registry verwaltet werden und setzt sich in diesem Fall aus einem für alle Namensräume festen Präfix „https://registry.gdi-de.org/id/“ und einem domänenspezifischen Teil zusammen, der die geodatenhaltene Stelle repräsentiert. Der domänenspezifische Teil entsteht erst durch Registrierung des Namensraumes in der GDI-DE Registry und wird z.B. wie folgt aussehen „de.by.gv“ (Deutschlandkürzel.Länderkürzel.Behördenkürzel). Der Datensatzidentifikator identifiziert den Geodatensatz, der über den jeweiligen Layer bereitgestellt wird. Dieser Identifier benutzt den von der AuthorityURL bereitgestellten Namensraum (CodeSpace). Nähere Erläuterungen sind unter 3.2.3.2 in den Handlungsempfehlungen zu den INSPIRE Darstellungsdiensten nachzulesen.
Ein vollständiger Ressourcenidentifikator nach GDI-DE Registry könnte dementsprechend wie folgt aussehen:
https://registry.gdi-de.org/id/de.by/125cce16-7ae1-3cf0-96e2-05a4453f3cb1

Beispiel für WMS 1.1.1 (Konventionen zu Metadaten):
https://github.com/gdi-de/ak-geodienste/blob/master/handlungsempfehlung-darstellungsdienste/wms111/inspire-metadata-service.xml <source lang="html5">

<Layer> ... <AuthorityURL name="SGD-Nord – AG GIS"> <OnlineResource xmlns:xlink=http://www.w3.org/1999/xlink xlink:type="simple" xlink:href="https://registry.gdi-de.org/id/de.rp/"/> </AuthorityURL> <Identifier authority="SGD-Nord – AG GIS"> c2019e4f3a3b1caf5c6198a4343bf249 </Identifier> ... <MetadataURL type="TC211"> <Format>text/xml</Format> <OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple" xlink:href="http://map1.naturschutz.rlp.de/metadaten_sgdn/ajax/getxml.php?id=4280"/> </MetadataURL> ... </Layer>

</source>

Beispiel für 1.3.0 (INSPIRE TG VS 3.1):
https://github.com/gdi-de/ak-geodienste/blob/master/handlungsempfehlung-darstellungsdienste/wms130/inspire_capabilities.xml

<source lang="html5"> <wms:Layer> ... <wms:AuthorityURL name="by_verw"> <wms:OnlineResource xmlns:xlink=http://www.w3.org/1999/xlink xlink:type="simple" xlink:href="https://registry.gdi-de.org/id/de.by/"/> </wms:AuthorityURL> <wms:Identifier authority="by_verw"> 125cce16-7ae1-3cf0-96e2-05a4453f3cb1 </wms:Identifier> ... <wms:MetadataURL type="ISO19115:2003"> <Format>text/xml</Format> <OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple" xlink:href="https://registry.gdi-de.org/id/de.by/125cce16-7ae1-3cf0-96e2-05a4453f3cb1"/> </MetadataURL> ... </Layer>

</source>

Beispiel für wmts:
<source lang="html5">

<Layer> ... <ows:Identifier>DOP_20_C</ows:Identifier> <ows:Metadata xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.metadaten.geoportal-bw.de/geonetwork/srv/ger/csw?Service=CSW&Request=GetRecordById&Version=2.0.2&id=4927a198-e9ce-da9a-a5ef-c11f21ff173f&outputSchema=http://www.isotc211.org/2005/gmd&elementSetName=full" xlink:type="simple"/> ... </Layer> </source>

Anforderung

Wenn ein Dienst einen oder mehrere Datensätze besitzt, so müssen diese Datensätze mit dem Dienst verlinkt werden.

Anforderung

Das Attribut type des Elementes MetadataURL soll immer „TC211“ (WMS 1.1.1) oder „ISO19115:2003“ (WMS 1.3.0) sein.

Anforderung

Das xlink:href Attribut des OnlineResource Elements soll auf ein valides ISO19139 Dokument oder auf eine GetRecordById Response eines Katalogdienstes verweisen. Je nach Dokumententyp ist im Format - Tag entweder application/vnd.ogc.csw.GetRecordByIdResponse_xml oder application/xml.

Um nach einer Katalogrecherche eine einfache Möglichkeit zu erhalten, den jeweils richtigen Layer zu referenzieren, ist es notwendig, die Datensatzidentifikatoren im Capabilities Dokument am Layer anzugeben. Hierzu soll das von INSPIRE vorgeschlagene Verfahren genutzt werden.

Empfehlung

Verwendung des AuthorityURL Elementes zur Angabe des Codespaces des Datensatzidentifikators.

Empfehlung

Verwendung des Identifier Elementes zur Angabe des Codes des Datensatzidentifikators.

Maßstabsbereiche (WMTS)

Ein WMTS liefert vorgefertigte Kacheln in bestimmten Maßstäben und für spezifische Koordinatensystemen aus. Zur Konfiguration wird eine tile matrix verwendet und in den Capabilities bekannt gemacht.

Clients, die nicht in der Lage sind die Bilder zu skalieren oder bei der Verwendung anderer Koordinatenreferenzsysteme umzuprojezieren, werden diese nur nutzen können, wenn eine Konvention über das Koordinatenreferenzsystem und die benutzten Maßstäbe besteht. Diese Konvention wird als „well-known scale set“ bezeichnet. Ein „well-known scale set“ ist eine Vorgabe für Diensteanbieter zur spezifischen Einrichtung eines Dienstes und für Clients zur Anpassung daran. Ziel ist es auch Clients die Entscheidung mit Hilfe des „well-known scale set“ zu ermöglichen, ob ein WMTS genutzt werden kann oder nicht.

Empfehlung

Für Inspire konforme WMTS: InspireCRS84Quad

Empfehlung

Für die Darstellung amtlicher Daten in Deutschland ist ein „well-known scale set“ für gebräuchliche, ganze Maßstäbe im Koordinatenreferenzsystem EPSG:25832 erforderlich. Dafür sollte der nachstehende well-known scale set: gdi_de_25832 verwendet werden.

Ausdehnung in km 1433,6 bei 256*256 Pixel

Bei der Zoomstufe 0 wird die nachstehende bounding box mit 2*2 Kacheln abgedeckt

Bereitstellung multidimensionaler Daten

TIME Parameter

Zeit kann als Parameter in einem WMS als einzelner Zeitpunkt, als eine Liste von Zeitpunkten (nicht bei WMTS möglich) oder als Zeitintervall angefragt werden. Innerhalb der WMS Capabilities muss hierfür zum entsprechenden zeitvarianten Layer eine entsprechende Metadatenbeschreibung hinterlegt werden. Für die Definition von Zeitparametern als zusätzliche Dimension muss der Wert TIME (name=time) verwendet werden. Es ist ein Standardzeitpunkt (default value) anzugeben, der bei Anfragen ohne TIME-Parameter für die Datenauslieferung verwendet wird. Das Abbildungsformat für zeitliche Dimensionsangaben entspricht dabei der ISO 8601:2000 (Data elements and interchange formats — Information interchange — Representation of dates and times) und ist beschrieben im Annex D (Web Map Service profile of ISO 8601) der WMS Spezifikation.

Beispiel für die Festlegung der zeitlichen Dimension in einem Layer

<source lang="html5"> <Layer queryable="1">

 <Title>Weather Forecast Data</Title>
 <CRS>CRS:84</CRS>
 <EX_GeographicBoundingBox>
   <westBoundLongitude>-180</westBoundLongitude>
   <eastBoundLongitude>180</eastBoundLongitude>
   <southBoundLatitude>-90</southBoundLatitude>
   <northBoundLatitude>90</northBoundLatitude>
 </EX_GeographicBoundingBox>

<Dimension name="time" units="ISO8601" default="2000-08-22"> 1999-01-01/2000-08-22/P1D </Dimension> <Layer> </source>

Festlegungen außerhalb des Regelungsbereichs der Standards und Spezifikationen für Darstellungsdienste

Verwendung von CORS Headern

Die Nutzung von standardisierten Darstellungsdiensten in Webapplikationen erfolgt größtenteils unter Zuhilfenahme von javascript-Bibliotheken wie z.B. Openlayers oder Leaflet. Diese Bibliotheken ermöglichen eine einfache Nutzung von Diensten in Webanwendungen. Die Bildquellen werden dabei i.d.R. direkt vom Browser des jeweiligen Nutzers angefragt (verteilte Architektur auf http Basis). In manchen Fällen kann es jedoch notwendig sein, dass die Webanwendung die verteilten Server eigenständig abfragen muss (z.B. Abfrage von Metadaten oder Capabilities-Dokumenten). Aufgrund der Same-origin policy - einer Sicherheitseinstellung des Browsers - wird das Aufrufen von verteilten Ressourcen grundsätzlich verhindert. Abhilfe schafft hier die Empfehlung des W3C zum Cross-Origin Resource Sharing (CORS).

Empfehlung

Zur Verbesserung der Nutzungsmöglichkeiten der Darstellungsdienste durch Webanwendungen soll der HTTP Header (serverseitig) bei den jeweils bereitgestellten Operationen folgenden Eintrag enthalten: Access-Control-Allow-Origin: *

Absicherung

WMS-DE_1.0 - 3.5.2

Empfehlung

Sollen Darstellungsdienste nur gewissen Nutzergruppen zugänglich gemacht werden, so sollen hierzu die Standardverfahren zur Authentifizierung des http-Protokolls verwendet werden (RFC2617 – HTTP-Authentication). Hier ist darauf hinzuweisen, dass die HTTP-BASIC Authentication Nutzername und Passwort im Klartext im HTTP-HEADER überträgt und daher nur über eine sichere https-Verbindung genutzt werden darf.</ref>

Anforderung

Darstellungsdienste dürfen nicht nur ausschließlich mit proprietären Methoden gegen unberechtigte Zugriffe geschützt werden.

WMTS Schnittstellen

Im WMTS-Standard sind die prozessorientierten Schnittstellen KVP und SOAP sowie die ressourcenorientierte Schnittstelle REST vorgesehen. Der Standard sieht die Unterstützung von mindestens einer der drei Schnittstellen vor, wobei die Unterstützung von KVP und/oder REST empfohlen wird.

Anforderung

Ein WMTS soll mindestens die KVP Variante angeboten werden.

Erläuterungen

Copyright

Wenn in einem oder in mehreren Diensten Copyright Vermerke aufgeführt werden, so stört es den eigentlichen Informationsgehalt der Karte.
Im Beispiel sind bei einer Kartenzusammenstellung vier Copyright Vermerke zu sehen.

Datei:Copyright bild klein.png

UpdateSequens und Name/Identifier
Armin

Punkt 3.11.1 Empfehlung zu Mime Type

Wie kann das im Mapserver und Geoserver Degree umgesetzt werden. Beispiel:
Alex für Geoserver, Sascha für Degree und Adam für Mapserver, Holger K für Arc Gis Server

Beispiel Mapserver

In einen Mapserver View Service können GetFeatureInfos (Queries) nur dann bereitgestellt werden, wenn diese entsprechend aktiviert werden. Für die Anforderungen der Handlungsempfehlungen zum MIME type text/html ist es notwendig, das Templating zu aktivieren. Dies geschieht im jeweiligen Mapfile des Dienstes, indem das LAYER-Element um den Eintrag TEMPLATE z.B. "template_name.html" erweitert wird. Der default MIME type des Mapservers ist bereits text/html. Im unten stehenden Bsp. wird hier template_name.html als Name der Template-Datei genutzt.

Auszug MAP-Datei

...
 LAYER
     NAME "statistik_fuer_getfeature"
     TYPE POLYGON
     STATUS ON
     include "db.conf"
     DATA 'GEOMETRIE from WFS_STATISTIK USING UNIQUE ESRI_OID SRID 25832'
     PROCESSING "CLOSE_CONNECTION=DEFER"
     
     TEMPLATE "template_statistik.html"
  ...
  END
  ...

Weiterhin ist es notwendig in WEB-Element, im Unterelemt METADATA den Eintrag "wms_feature_info_mime_type" "text/html" aufzunehmen.

  WEB
    METADATA
      ...
      "wms_feature_info_mime_type" "text/html"
    END
  ...

Damit die Template-Datei als solche erkannt wird, ist es notwendig ''<!-- MapServer Template -->'' in die erste Zeile zu schreiben. Im head der Datei wird der MIME-Type nochmals festgelegt.

Auszug Template-Datei

<!-- MapServer Template -->

    
       
          ''''''
             
  
 ...

=====Beispiel GeoServer===== 
Der GeoServer untestützt generell viele Ausgabe Formate und eine einfache Implementierung von neuen Rückgabeformaten ist nicht vorgesehen. Jedoch ist die Implementierung eigener html-Templates möglich, die eine angepasste Variante von GetFeatureInfos zurückliefern.


Eine Anleitung für die jeweils aktuelle Version findet man unter: http://docs.geoserver.org/latest/en/user/tutorials/GetFeatureInfo/index.html

=====Beispiel deegree===== 
deegree untestützt ohne explizite Konfiguration generell mehrere Ausgabeformate (z.B. text/plain, text/xml, text/html und application/vnd.ogc.gml). Die Generierung eigener HTML-Templates wie auch die Umsetzung weiterer eigener Formate ist sowohl über einen deegree spezifischen Template-Mechanismus möglich als auch über XSLT-Skripte.


Im unten stehenden Bsp. werden in der WMS Konfigurationsdatei spezielle Templates für die HTML-Ausgabe angesprochen 


 ...
  
   
    ../customformat.gfi
    text/html
   
  
   ...
  
   
    ../customformat.xsl
    text/html
   
  
   ...

Weitere Informationen sowie Beispiele für die Templates finden sich für die verschiedenen deegree Versionen unter: http://www.deegree.org/documentation
===Punkt 3.11.2 Leere Rückgabe=== 

=====Beispiel Mapserver===== 
Die NoData Vorgabe sieht einen einheitlichen Wert vor, falls keine Ergebnisse (leere Rückgabe) zur GetFeatureInfo zurückgeliefert werden.
Dieses Verhalten wird direkt im Map file mit dem Element [http://mapserver.org/mapfile/web.html "EMPTY"] gesteuert. Hierzu wird zusätzlich zum normalen GetFeature-Template ein weiteres Template für die NoData Rückgabe auf dem Server bereitgestellt, im Beispiel ''empty.html''. Bitte beachten, das NoData Template, hier empty.html muss in einem Bereich abgelegt werden der für den Zugriff von außen im Webserver (i.d.R. für Apache unter Windows Server in /htdocs/, bei Linux z.B. unter /var/www/html/) freigegeben ist.


'''Auszug Map Datei'''
   ...
   WEB  
     METADATA
     ...
     END
     

     '''EMPTY "http://.../empty.html"'''
   END
   ...


'''Beispiel '''
   
 
   
        
           
           
        
        
        Daneben! 
Ihre Datenabfrage liefert eine leere Ergebnismenge innerhalb des abgefragten Layers.
        
   

Beispiel ArcGIS Server

Im ArcGIS Server ab Version 10 kann die Ausgabe der GetFeatureInfo über XSL-T Templates angepasst werden. Als Input dient ein XML-Dokument (Beispiel XML-Dokument für GetFeatureInfo Request) auf welches ein XSL-T Template (siehe Beispiel XSL-T Template mit Behandlung der leeren Rückgabe) angewendet wird. Im Ergebnis wird ein HTML-Dokument geliefert (siehe Beispiel HTML Ausgabe mit leerere Rückgabe).

Beispiel XML-Dokument für GetFeatureInfo Request:

<source lang="xml">

   <?xml version="1.0" encoding="UTF-8"?>
   <esri_wms:FeatureInfoResponse version="1.3.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:esri_wms="http://www.esri.com/wms" xmlns="http://www.esri.com/wms">
     <esri_wms:FeatureInfoCollection layername="fields">
       <esri_wms:FeatureInfo>
         <esri_wms:Field>
           <esri_wms:FieldName><![CDATA[OBJECTID]]></esri_wms:FieldName>
           <esri_wms:FieldValue><![CDATA[1]]></esri_wms:FieldValue>
         </esri_wms:Field>
         <esri_wms:Field>
           <esri_wms:FieldName><![CDATA[Shape]]></esri_wms:FieldName>
           <esri_wms:FieldValue><![CDATA[Polygon]]></esri_wms:FieldValue>
         </esri_wms:Field>
         <esri_wms:Field>
           <esri_wms:FieldName><![CDATA[Shape_Area]]></esri_wms:FieldName>
           <esri_wms:FieldValue><![CDATA[0.009079]]></esri_wms:FieldValue>
         </esri_wms:Field>
           ...
           ...
       </esri_wms:FeatureInfo>
       ...
       ...
     </esri_wms:FeatureInfoCollection>
     ...
     ...
   </esri_wms:FeatureInfoResponse>

</source>

Beispiel XSL-T Template mit Behandlung der leeren Rückgabe:

<source lang="html5">

   <?xml version="1.0" encoding="UTF-8"?> 
   <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:esri_wms="http://www.esri.com/wms" xmlns="http://www.esri.com/wms"> 
   <xsl:output 
           method="xml"
           version="1.0"
           indent="yes"
           omit-xml-declaration="yes"
           encoding="UTF-8" />
   <xsl:template match="/"> 
        
        
          
          	
          
                
         
                        
                 
                    
Die Abfrage lieferte keine Treffer
 
                 
             
             
                 
                
 
                     
                        
                                        
 
                          
layer names: ''
 
                            
 
                                
Attribut
Wert
                                    

                                            

                                                
                                            
                                            

                                                
                                            
                                        
                                     
                            
 
                        
 
                     
                
 
                 
             
         
         
   </xsl:template> 
   </xsl:stylesheet> 

</source>

Beispiel HTML Ausgabe mit leerer Ausgabe:

<source lang="html5">

 <!DOCTYPE html>
  
    
    
    
  
  
    
Die Abfrage lieferte keine Treffer
  
    

</source>

Punkt 3.14 Empfehlungen

Der wahre Extent ist der Bereich worauf sich die Geodaten beziehen. Z.B. Stellt ein Bundesland in einem Dienst nur die Daten einer Gemeinde dar, so sind die Ausmaße der wahren BoundingBox ein Rechteck um die Gemeinde, nicht die des Landes.

Angaben zu fees und accessconstraints

Beispiel für Nutzungsbedingungen und Zugriffsbeschränkungen

Beispiel Dienst-Metadatensatz: <source lang="html5"> <gmd:resourceConstraints> <gmd:MD_Constraints> <gmd:useLimitation> <gco:CharacterString>Nutzungsbedingungen: geldleistungsfrei, Datenlizenz Deutschland – Namensnennung – Version 2.0, URL: https://www.govdata.de/dl-de/by-2-0</gco:CharacterString> </gmd:useLimitation> </gmd:MD_Constraints> </gmd:resourceConstraints> <gmd:resourceConstraints> <gmd:MD_LegalConstraints> <gmd:accessConstraints> <gmd:MD_RestrictionCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources /codelist/ML_gmxCodelists.xml#MD_RetrictionCode" codeListValue="otherRestrictions">otherRestrictions</gmd:MD_RestrictionCode> </gmd:accessConstraints> <gmd:otherConstraints> <gco:CharacterString>Datenlizenz Deutschland – Namensnennung – Version 2.0; URL: https://www.govdata.de/dl-de/by-2-0

Die Namensnennung der Vermessungs- und Katasterverwaltung Rheinland-Pfalz als Rechteinhaberin hat in folgender Weise zu erfolgen:
©GeoBasis-DE / LVermGeoRP (Jahr des Datenbezugs), dl-de/by-2-0, http://www.lvermgeo.rlp.de [Daten bearbeitet]; Es gelten folgende Regelungen
zu Gewährleistung und Haftung; URL:http://www.lvermgeo.rlp.de/index.php?id=7198</gco:CharacterString>

</gmd:otherConstraints> </gmd:MD_LegalConstraints> </gmd:resourceConstraints> </source>

Beispiel Capabilities: <source lang="html5">

<Fees> Nutzungsbedingungen: geldleistungsfrei, Datenlizenz Deutschland – Namensnennung – Version 2.0, URL: https://www.govdata.de/dl-de/by-2-0 </Fees> <AccessConstraints> Datenlizenz Deutschland – Namensnennung – Version 2.0; URL: https://www.govdata.de/dl-de/by-2-0 Die Namensnennung der Vermessungs- und

Katasterverwaltung Rheinland-Pfalz als Rechteinhaberin hat in folgender Weise zu erfolgen: ©GeoBasis-DE / LVermGeoRP (Jahr des Datenbezugs),
dl-de/by-2-0, http://www.lvermgeo.rlp.de [Daten bearbeitet]; Es gelten folgende Regelungen zu Gewährleistung und Haftung;
URL:http://www.lvermgeo.rlp.de/index.php?id=7198

</AccessConstraints>

</source>

Beispiel für keine Nutzungsbedingungen und Zugriffseinschränkungen
Beispiel Dienst-Metadatensatz

<source lang="html5">

<gmd:resourceConstraints>

       <gmd:MD_LegalConstraints>
           <gmd:useLimitation>Nutzungsbedingungen: keine</gmd:useLimitation>
           <gmd:accessConstraints>
               <gmd:MD_RestrictionCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/ML_gmxCodelist.xml#MD_RestrictionCode" codeListValue="noRestriction" />
           </gmd:accessConstraints>    
       </gmd:MD_LegalConstraints>
   </gmd:resourceConstraints>

</source>

Beispiel Capabilities

<source lang="html5">

   <WMT_MS_Capabilities>
       <Service>
          <Fees>Nutzungsbedignungen: keine</Fees>
          <AccessConstraints>keine Zugriffseinschränkungen</AccessConstraints>
       </Service>
   </WMT_MS_Capabilities>

</source>

Punkt 3.3.2 Rest

Erläutern was REST und was KVP ist
Beispiel und Erläuterung Armin (ich habe mal was eingetragen Gruß Markus


REST = Representational State Transfer
REST ist ein Architekturstil für das Internet, wo definiert ist wie eine Anwendungen im Web bereit zu stellen ist.
Webseiten in der REST Architektur sind z.B. Facebock, Amazon, Google usw.
Bei REST werden keine Sessions oder Cookies bei einer Nutzung verwendet. Die Kommunikation ist zustandslos. Jede Anfrage wird immer neu geschickt.
Beispiel:
www.google.de/?rct=j#q=gws+tee/start30
Der Server speichert diese Anfrage nicht, sondern der Client, z.B. der Browser Firefox.
In der Anfrage können alle Elemente ausgetauscht werden, Tee durch Kaffee die Seitenzahl 30 durch 5 usw.

Jede Ressource (Webseite) die Angesprochen werden soll, muss mit einer URI (Unique Resource Identifier =. URL mit einem Identifier) eindeutig adressierbar sein. (Eine Ressource ist alles was im web greifbar ist, z.B. Webseiten, Tabellen, Musik, Karten.)
Es muss eine einheitliche Schnittstelle für den Zugriff verwendet werden, das wären die Standard-HTTP-Methoden wie GET, POST, PUT Delete… .
Die Ressource muß entkoppelt sein, das heißt, dass ein Client eine Ressource in z.B. XML oder JSON anfordern kann.

Die http Standard Methode GET: nur für lesen.

Die http Standard Methode POST: zum Erstellen von neuen Ressourcen.

Die http Standard Methode PUT: zum Erstellen oder bearbeiten von Ressourcen mit bekannter URI.

Punkt 3.11 Mime Type

MIME steht für Multipurpose Internet Mail Extensions, wird aber grundsätzlich für die Kommunikation zwischen Server und Client definiert. Der MIME Type teilt der interpretierenden Software, z.B. dem GIS-Client mit, um welchen Datentyp es sich bei der angeforderten Information handelt. Bei Standard-Dateiformaten sollten unbedingt die MIME-Typ-Angaben verwendet werden, die hierfür etabliert sind. Eine Übersicht der Media-Typen befindet sich im IANA-Verzeichnis.

Ein MIME-Typ besteht aus zwei Teilen: der Angabe eines Medientyps und der Angabe eines Subtyps. Beide Angaben werden durch einfachen Schrägstrich voneinander getrennt. Beispiele:
text/html
image/png
text/xml
... .
Moderne Browser (dies sind auch Clients) akzeptieren in der Regel sehr viele MIME Types. Falls sie einen MIME-Typ nicht kennen, bieten sie dem Anwender den Download der Daten an. Geodaten-Server und -Clients sind dagegen spezifischer. MIME-Typen die sie nicht kennen, verarbeiten sie nicht. Die letztlich zu verwendenden MIME Types ergeben sich aus der Schnittmenge der vom Server und Client unterstützten Types und des Einsatzzwecks.

[[2016:selfhmtl]]

Punkt 3.11.2 Anforderung

Erläuterung zum Body Tag Im Body Tag des HTML Template soll der Text class="getfeatureinfo-isempty" eingetragen werden. Dieses hat zur Folge, dass alle Clients einen eindeutigen, einheitlichen Wert für eine leere Ergebnismenge (keine Daten) erhalten.

Punkt 3.xx CORS

Armin ... [https://www.w3.org/TR/cors/]

Punkt 3.13 Tabelle

XPath
XPath ist eine vom W3C entwickelte Sprache zur Abfrage von XML Dokumenten. Diese kann z.B. für die einfache Beschreibung von Bestandteilen eines XML-Dokumentes, wie im Beispiel unten verwendet werden bzw. für XML-Transformationen via XSL-T. Es existieren zum Zeitpunkt der Redaktion die Versionen XPath 1.0 und XPath 2.0.

Beispiel

XML Ausschnitt von ISO TC211 Metadatensatz:

 <?xml version="1.0" encoding="utf-8" ?>
 <gmd:MD_Metadata xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.isotc211.org/2005/gmd http://schemas.opengis.net/csw/2.0.2/profiles/apiso/1.0.0/apiso.xsd">
   <gmd:fileIdentifier>
     <gco:CharacterString xmlns:gco="http://www.isotc211.org/2005/gco">ADB575F8-6BA6-48B6-A1EB-9D5980935F37</gco:CharacterString>
   </gmd:fileIdentifier>
   ...
 </gmd:MD_Metadata>  

XPATH Ausdruck zur Beschreibung des FileIdentifiers in ISO TC211 Metadatensatz:

/gmd:MD_Metadata/gmd:fileIdentifier/gco:CharacterString

Referenzen:
XPath 1.0: http://www.w3.org/TR/xpath/
XPath 2.0: http://www.w3.org/TR/xpath20/

Punkt 3.13.2.1 Anforderung

Warum 3000 Pixel Der höhere Wert wird empfohlen, um eine qualitativ gute Druckausgabe des Dienstes zu gewährleisten. Einige Clients fordern für die Druckausgabe eine höhere Pixeldichte an. Weiterhin ist die hohen Anzahl an Pixel für die Darstellung von WMS Diensten bei großen Monitoren nötigt.

3.2.0 WMTS Schnittstellen

TODO: kurze Erläuterung in 1-2 Sätzen + Weblink

SOAP = Simple Object Access Protocol
Mit SOAP können serverseitige Objekte aufgerufen werden, die dann z.B. im XML Format mit dem http Proptokoll übermittelt werden. Der Datenaustausch erfolgt zwischen Systemen.
Das Problem bei SOAP ist, dass die XML Dateien sehr groß werden können.
SOAP regelt, wie Daten in einer Übertragung abzubilden und zu interpretieren sind, und gibt eine Konvention für entfernte Prozeduraufrufe mittels SOAP-Nachrichten vor. Das W3C Consortium hat viele weitere Unterspezifikationen für SOAP entwickelt, die sogenannte WS-. Z.B. WS-Trust was zur Autorisierung mit einem Token genutzt wird.

Erläuterungen zu den Vorgaben der GDI-DE

Allgemein

Operationen

Die Darstellungsdienste WMS und WMTS werden über Operationen angefragt:

• GetCapabilitiesInformationen zum Dienst
• GetMap/GetTile Definiert den Bildausschnitt
• GetFeatureInfoSachinformationen zu den dargestellten Objekten
• GetLegendGraphicLegende (nur WMS)

Diese Operationen benötigen weitere verpflichtende Parameter um einen gültigen Request zu bilden. Diese können in beliebiger Reihenfolge hinter den Präfix aufgelistet werden. Das Präfix muß mit einem "?" enden. Die Parameterwerte müssen der UpperCamelCase Schreibweise entsprechen.

Die Operationen mit ihren Parametern sind vom OGC allgemein beschrieben: http://www.opengeospatial.org/standards/common .

Die dienstespezifischen Parameter werden im Kapitel zum jeweiligen Dienst näher erläutert. Operation GetCapabilities

Mit der Operation GetCapabilities werden die Metadaten des Dienstes aufgerufen. Anhand der gelieferten Informationen kann die GetMap/GetTile-Anfrage generiert werden.

Diese Metadaten enthalten beispielsweise Angaben zum Dienstebereitsteller, enthaltene Layer mit Ausdehnung usw. im XML-Format.

Operation GetMap/GetTile

Der GetMap (WMS) / GetTile (WMTS) Request definiert den Bildausschnitt. Als Ergebnis wird ein Kartenbild gemäß der im Request angegebenen Parametern geliefert.

Operation GetFeatureInfo (optional)

Ein GetFeatureInfo-Request ist eine Anfrage an einen WMS um Sachinformationen zu den dargestellten Objekten anzufordern. Als Antwort (Response) werden Informationen zu den Objekten zurückgeliefert.

Operation GetLegendGraphic (optional, nur WMS)

GetLegendGraphic gibt eine Legende zu den dargestellten Layern aus.

Web Map Service (WMS)

(Steffi, Markus, Johannes), Bounding Boxen für Länder definieren, Anzahl von Pixeln festlegen

Operationen

Die im WMS 1.3.0 Standard vom OGC (konform zur ISO 19128:2005(E)) als verpflichtende Elemente beschrieben werden, sind auch für den WMS-Dienst der GDI-DE die Basis.

GetCapabilities

Verpflichtende Elemente, die bei einer Antwort (Response) auf eine Anfrage (Request) über die verpflichtenden Elemente aus dem OGC-Standard hinaus geliefert werden müssen, sind:

Zusätzlich zu den von der Spezifikation geforderten Informationen, wird empfohlen im Capabilities Dokument einen Servicemetadatensatz zu verlinken. Die Verlinkung hat entsprechend der INSPIRE Vorgaben zu erfolgen. Beispiel: <source lang="html5"> <VendorSpecificCapabilities> <inspire_vs:ExtendedCapabilities> <inspire_common:MetadataUrl xsi:type="inspire_common:resourceLocatorType"> <inspire_common:URL> http://www.geoportal.rlp.de/mapbender/php/mod_layerISOMetadata.php?SERVICE=WMS&outputFormat=iso19139&Id=24124 </inspire_common:URL> <inspire_common:MediaType>application/vnd.iso.19139+xml</inspire_common:MediaType> </inspire_common:MetadataUrl> </inspire_vs:ExtendedCapabilities> </VendorSpecificCapabilities> </source>

Angaben, die über die verpflichtenden Elemente aus dem OGC-Standard im Element Layer hinaus, geliefert werden müssen:

Für einen Request sind folgende Parameter bereitzustellen:

 V=Verpfichtend O=Optional

*Kann nur verwendet werden, wenn der Server eine Versionierung für seine Metadaten pflegt. Wird hier nicht weiter betrachtet.

  Beispielaufruf:

http://www.gds-srv.hessen.de/cgi-bin/lika-services/ogc-free-maps.ows?request=GetCapabilities&version=1.3.0&service=WMS&format=Text/xml

INFO: Die Parameterwerte müssen der UpperCamelCase (erster Buchstabe groß) Schreibweise entsprechen.

GetMap

Für einen GetMap Request sind folgendeParameter bereit zu stellen:

V=Verpfichtend O=Optional

Beispiel eines GetMap Request 

http://www.gds-srv.hessen.de/cgi-bin/lika-services/ogc-free-maps.ows?version=1.3.0&service=WMS&request=GetMap&layers=huek&styles=&bbox=400338,5470000,603876,5734000&crs=epsg:25832&width=2000&height=2000&format=Image/png

Graphik (Beispiel) von Markus fehlt noch

GetFeatureInfo

Als Rückgabeformat ist HTML ist zu unterstützen Das Rückgabeformat XML wird empfohlen. Die HTML-Ausgabe ist in einem Fenster zu gestalten und in tabellarischer Form sein, beginnend mit der Überschrift der abgefragten Informationen.

Beispiel

Unterhalb der Tabelle kann ein Logo und ein Link zu weiterführenden Informationen eingefügt werden.

Beispiel

Beipiel Markus

Vorlage einer HTML Implementierung für die GetFeatureInfo Darstellung

http://www.github.com/gdi-de/

<source lang="html5"> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

</source>

Namespace: gdi-de http://www.gdi-de.org/geodatendienste

TODO: XHtml-Schema-Beispiel

DescribeLayer

Sobald ein SLD-WMS mit vordefinierten Layern die Möglichkeit bietet, Styles durch den Nutzer anzugeben (UserStyle), ist die Operation zu unterstützen.

Mit dieser Operation werden vom Client Informationen zu den vordefinierten Layern von Server angefordert.

Beispiel Anfrage:

http://www.gds-srv.hessen.de/cgi-bin/verwaltungseinheiten/he_verwaltungseinheiten.ows?Request=DescribeLayer&service=WMS&version=1.3.0&sld_version=1.1.0&layers=AU.AdministrativeBoundary_03,AU.AdministrativeBoundary_02&width=20&height=20

Ergebnis:

<source lang="html5"> <?xml version="1.0" encoding="ISO-8859-1" ?> - <DescribeLayerResponse xmlns="http://www.opengis.net/sld" xmlns:ows="http://www.opengis.net/ows" xmlns:se="http://www.opengis.net/se" xmlns:wfs="http://www.opengis.net/wfs" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink" xsi:schemaLocation="http://www.opengis.net/sld http://schemas.opengis.net/sld/1.1.0/DescribeLayer.xsd">

 <Version>1.1.0</Version>

- <LayerDescription>

 <owsType>wfs</owsType>
 <se:OnlineResource xlink:type="simple" xlink:href="http://www.gds-srv.hessen.de/cgi-bin/verwaltungseinheiten/he_verwaltungseinheiten.ows?" />

- <TypeName>

 <se:FeatureTypeName>AU.AdministrativeBoundary_03</se:FeatureTypeName>
 </TypeName>
 </LayerDescription>

- <LayerDescription>

 <owsType>wfs</owsType>
 <se:OnlineResource xlink:type="simple" xlink:href="http://www.gds-srv.hessen.de/cgi-bin/verwaltungseinheiten/he_verwaltungseinheiten.ows?" />

- <TypeName>

 <se:FeatureTypeName>AU.AdministrativeBoundary_02</se:FeatureTypeName>
 </TypeName>
 </LayerDescription>
 </DescribeLayerResponse>

</source>

GetLegendGraphic

Die Legende dient zur Erläuterung, der in der Karte abgebildeten Features. Die Legende kann über statische Legendenbilder generiert werden, oder dynamisch aus dem Styles der einzelnen Layers.

Da eine Legende für Rasterbilder nicht als sinnvoll erachtet wird, ist diese Operation nur für Vektordaten zwingend erforderlich. Die Operation GetLegendGraphic stammt originär aus dem SLD-Standard und wurde für den WMS-Standard übernommen.

Daher ist der SLD-Standard in der Version 1.1.0 zu unterstützen.

In der folgenden Tabelle werden nur die verpflichtenden Parameter aufgeführt. Zu diesem gibt es noch weitere optionale Parameter, diese können Sie den jeweiligen Dokumentationen der Map Software (Geoserver, MapServer usw.) entnehmen.

Viele Map Server generieren die Legende aus dem Style und den Namen der einzelnen Layer automatisiert, so das für einem Administrator nur ein geringer Pflegeaufwand besteht.

Mit der Operation GetLegendGraphic kann immer nur ein einzelner Legendeneintrag abgefragt werden.

  V=Verpfichtend O=Optional

*SLD=Styled Layer Descriptor

Beispielaufruf:

http://www.gds-srv.hessen.de/cgi-bin/verwaltungseinheiten/he_verwaltungseinheiten.ows?request=GetLegendGraphic&service=WMS&version=1.3.0&sld_version=1.1.0&layer=AU.AdministrativeBoundary_03&format=Image/png

Beispiel einer Darstellung

Beispiel Markus

Capabilities Dokument

SLD

WMS-T

Time, Elevation, Other Dimensions

Web Map Tile Service (WMTS)

Der Standard Web Map Tile Service (WMTS) ist ein Dienst, der Geodaten kachelbasiert zur Verfügung stellt. Des WMTS Standard ermöglicht die performante Darstellung von vorgenerierten, einzelnen Kacheln (engl. tiles). Diese liegen statisch, in fixen Maßstäben und einem vordefiniertem Koordinatensystem in einem Zwischenspeicher (tile cache) vor. Im Vergleich zum WMS gibt es Einschränkungen, die vom endlichen Speicherplatz des Hostsystems getrieben sind. So können bei einem WMS viele Koordinatensysteme oder die clientbasierte Beeinflussung der Darstellung der Layer mittels Style Layer Descriptor (SLD) erfolgen. Um diese Freiheitsgrade mittels WMTS zu realisieren, müssten alle möglichen Varianten der Dienste bereitgestellt werden.Daher kann der WMTS zwar als die schnellere, aber weniger flexible Darstellungsdienstvariante betrachtet werden.

Ein WMTS kann mittels eines WMS bereitgestellt werden.

Die Handlungsempfehlungen zum WMTS basieren auf dem OpenGIS Web Map Tile Service Implementation Standard (OGC 07 - 057r7) in der Version 1.0.0 und den Technical Guidance for the implementation of INSPIRE View Services in der Version 3.11. Hierbei gilt, dass INSPIRE View Services alle verpflichtende Anforderungen des OGC Web Map Tile Services 1.0.0 erfüllen müssen [IR74].

Schnittstellen

Die REST-Schnittstelle ist die einfachste Implementierung des WMTS. Die KVP-Schnittstelle bietet im Vergleich zur REST-Schnittstelle ein feineres exception handling. Fehler beim Zugriff auf den Service werden beim REST nur mit HTTP Status Codes beantwortet. Die KVP-Schnittstelle bietet differenzierte Angaben zum Fehler, die per XML zurückgeliefert werden.

Operationen

Zu unterstützende Operationen

Die WMTS Operationen sind an die WMS Operationen angelehnt. Dabei werden verpflichtende und optionale Operationen unterschieden.

Der WMTS 1.0.0 Standard definiert die drei Operationen GetCapabilities, GetTile und GetFeatureInfo (KVP, SOAP) bzw. die drei Ressourcen ServiceMetadata, Tile und FeatureInfo (REST).

Verpflichtend für einen INSPIRE konformen Dienst sind umzusetzen [IR75]:

• GetCapabilities: Diese Operation ist eine Basisfunktionalität des WMST Standards. Sie ermöglicht die Abfrage von allgemeinen Informationen über den WMTS. Als Antwort liefert das System ein XML-Dokument mit Informationen zum Dienst, zum Beispiel zu den unterstützen Koordinatensystemen und vorhandenen Layern.
• GetTile: Über die Methoden können einzelne Kacheln angefragt werden. Als Antwort liefert das System das entsprechende Bild im angefragten Format zurück.
• Get View Services Metadata: Liefert INSPIRE-Metadaten zum jeweiligen Darstellungsdienst.Diese Operation wird mit der WMTS Operation GetCapabilities identifiziert. Neben den normalen Metadaten, die ein OGC Dienst allgemein schon enthält, wird aber zusätzlich gefordert, dass alle INSPIRE Metadatenelemente ebenfalls enthalten sind. Näheres kann dem Abschnitt 3: Integration von INSPIRE Metadaten in Service-Capabilities entnommen werden.[AL1] 
• Get Map: Liefert die Karte für das angeforderte Gebiet.
• Link View Service: Erlaubt die Verlinkung von weiteren Darstellungsdiensten [IR60].Bei der Umsetzung der von INSPIRE geforderten Funktionalität „Link View Service“ handelt es sich nicht um neue Operation im eigentlichen Sinn. Unter „Link View Service“ wird die Veröffentlichung des Dienstes in der Europäischen Geodateninfrastruktur verstanden. Diese Anforderung ist erfüllt, wenn der Dienst mit INSPIRE-konformen Metadaten beschrieben ist und diese über den Geodatenkatalog-DE für INSPIRE veröffentlicht wurden.Die „Link View Service“ Operation muss zum INSPIRE Discovery Service [INSPIRE TG DiscoveryServices] kompatibel sein [IR76].

Anfragen an den WMTS Server können über HTTP POST und HTTP GET gestellt werden. Die Nutzung der GET-Methode ist vorzuziehen.

Parameter der Darstellungsdienst Operationen

Die allgemeinen Request Parameter der Operationen eines Darstellungsdienstes sind [IR77]:

Get View Services Metadata Operationen

Die folgenden Metadaten-Parameter müssen in der Antwort auf einen „Get View Service Metadata“-Request enthalten sein [IR78]:

- View Service Metadata;- Operations Metadata;- Layers Metadata;- Languages.Die meisten der erforderlichen Metadaten können durch die Service Capabilities, wie im WMTS Standard [OGC 07-057r7], Kapitel 7.1.1 definiert, veröffentlicht werden. Diese Capabilities sind verpflichtend und werden beim Erstellen des WMTS definiert. Sie beinhalten Informationen zu Server, unterstützten Operationen und Parametern. Zusätzliche Empfehlungen zu Operations Metadata und Layers Metadata sind im Folgenden erläutert.

Die Layer müssen einen Link zu den beschreibenden Metadaten des räumlichen Datensatzes unter Verwendung des “ows:Metadata”-Elements als Teil der Layer-Metadaten enthalten [IR79]. Dieses Element muss eine URL beinhalten, die den Zugriff auf einen eindeutig identifizierbaren Metadatensatz ermöglicht. Die URL kann auch ein: HTTP/GET-Aufruf der GetRecordById-Operation eines Discovery-Service unter Verwendung des Identifier des Metadaten-Dokuments sein.

Beispiel:

<Layer>

<ows:Title>etopo2</ows:Title>

...

<ows:Metadata

xlink:href="http://.../discovery?Service=CSW&Request=GetRecordById&Version=2.0.2&id=

[METADATA_IDENTIFIER]&outputSchema=http://www.isotc211.org/2005/gmd&elementSetName=f

ull"/>

...

</Layer>

Operations Metadata

Die GetCapabilities Operation und die Antwort darauf haben gemäß den Vorgaben der OGC Spezifikationen umgesetzt zu sein. Die Operation “Link View Service” muss verpflichtend in der „Discover Metadata“ Operation des Darstellungsdienstes, mit der die Metadaten des Dienstes abgefragt werden, enthalten sein. Dies erlaubt die Bereitstellung eines Darstellungsdienst in einem nationalen Kartendienst (z.B. Web-Atlas DE) bei gleichzeitiger Einhaltung entsprechender Leistungsfähigkeit [IR80].[AL1] 

Hierbei gilt für, dass die Operations Metadata stets auf das Element <ows:Operation name="GetCapabilities"> abgebildet sein müssen. [IR81]. Die Metadaten der Operation GetTile müssen auf das Element <ows:Operation name="GetTile"> abgebildet werden. Der Dienst muss entweder das Format PNG oder GIF (ohne LZW Kompression) unterstützen [IR82].

Die Verwendung der „Discover Metadata”-Operation des INSPIRE Discovery Service wird für die Implementierung der „Link View Service“-Operation empfohlen [IR83].

Layers Metadata

Die Beschreibung eines Layers muss Elemente verwenden, die in [OGC 07-057r7] für die Bereitstellung der Capabilities definiert wurden. Folgende Beschreibung spezifiziert die Rolle wichtiger Parameter des INSPIRE Darstellungsdienstes, wie in [INSPIRE TG ViewServices 3.1] festgelegt:

Für die einzelnen Metadatenelemente gelten folgende Bedingungen.

Layer title:

Der Titeleintrag eines Layers wird beispielsweise für die Bezeichnung des Layers innerhalb von Kartenanwendungen (Clients) verwendet und ist mit dem OGC-Element <ows:Title> besetzt.Der harmonisierte Titel eines INSPIRE Datenthemas ist in der [Directive 2007/2/EC] definiert und sollte mehrsprachig verfasst sein [IR85].

Layer abstract:

Kurzbeschreibung des Layers. Dieser sollte mehrsprachig verfügbar sein. Der layer abstract wird dem OGC-Element <ows:Abstract> zugeordnet [IR86].

Additional Keywords:

Durch Schlüsselwörter wird der Layer näher beschrieben und eine Auffindbarkeit über eine Katalogsuche erleichtert, Schlüsselwörter werden dem OGC-Element <ows:Keywords> zugeordnet [IR87]. Die Schlüsselwörter haben den Vorgaben der Technical Guidance for the implementation of INSPIRE Discovery Services zu entsprechen.

Geographic Bounding Box:

Die geographische Bounding Box wird verwendet, um eine räumliche Suche zu erleichtern. Sie ist dem OGC-Element <ows:WGS84BoundingBox> zugeordnet. Das minimale Begrenzungsrechteck ist unabhängig vom verwendeten Koordinatenreferenzsystem des TileMatrixSet im Koordinatenreferenzsystem WGS:84 (in Dezimalgrad) anzugeben [IR88].

Coordinate reference systems:

Es ist zwingend ein geographisches Koordinatenreferenzsystem auf der Basis von ETRS89 in Kontinentaleuropa bzw. ITRS außerhalb Kontinentaleuropas zu verwenden [IR89]. Dieses ist dem Element <ows:SupportedCRS> zuzuordnen.

Jeder Layer eines WMTS ist an einen Kacheldatensatz (TileMatrixSet) inklusive aller vorgerechneten Pyramidenlayer (TileMatrix) gekoppelt. Damit definiert der Kacheldatensatz die Struktur der einzelnen Pyramidenlayer.

Abbildung 1: Aufbau eines Kacheldatensatzes (TileMatrixSet)

Styles:

Die Darstellung muss dem <Style>-Element zugeordnet sein. Die sprechende Bezeichnung (vom Nutzer lesbarer Titel) muss dem <ows:Title> Element zugeordnet sein. Der Unique Identifier (eindeutige Identifikator) ist dem <ows:Identifier> Element zuzuordnen [IR90].

Legend URL:

Da das Capabilities-Dokument ein einsprachiges Dokument ist, können internationalisierte Legenden für jeden Wert des LANGUAGE-Parameters in weiteren Capabilities-Dokumenten abgelegt werden. Die Legende muss dem <ows:LegendURL> Element zugeordnet sein [IR91].

Get Map/Get Tile Operation

Analog zum GetMap Aufruf des WMS verfügt der WMTS über die Operation GetTile. Diese Funktion erlaubt es eine bestimmte Kacheln oder einen bestimmten Kacheldatensatz im vordefinierten Format anzufordern.

Die folgende Zuordnung der Parameter eines OGC WMTS zu jedem jeweiligen INSPIRE Parametern ist umzusetzen:

GetTile Aufruf

Die Kernfunktionen/Parameter für den GetTile Aufruf sind:

Link View Service Operation

Diese Operation wird mittels eines Discovery Dienstes realisiert.

Language Requirements

Die Sprachspezifikation gemäß der ISO 1928 anzubieten.

Interoperability: TileMatrixSet

Für alle INSPIRE WMTS wird empfohlen den InspireCRS84Quad Kacheldatensatz basierend auf den Well Known Scale Sets [OGC 07-057r7] zu nutzen. Dieser bietet insgesamt 17 Pyramidenlayer.

 [AL1]Diese Anforderung ist im original etwas kompliziert beschrieben. Ich hoffe das richtig gedeutet zu haben.

 [AL1]prüfen auf Unterschiede zw. WMTS Metadaten-Kopplung und WMS

Tile Matrix Sets

Für jeden WMTS ist mindestens ein Tile Matrix Set („Kachelarchiv in einer Projektion“) bereitzustellen. Ein Tile Matrix Set besteht aus n-Tile Matrices („Zoomstufen“), für die jeweils folgende Festlegungen in den Capabilities beschrieben werden [OGC WMTS][Weichand 2014]:

• Identifikator: Identifier
• Maßstab: ScaleDenominator
• Obere, linke Ecke der BoundingBox (X, Y): TopLeftCorner
• Breite der Kachel [px]: TileWidth
• Höhe der Kachel [px]: TileHeight
• Anzahl der Kachelspalten: MatrixWidth
• Anzahl der Kachelreihen: MatrixHeight

ScaleDenominator vs. PixelSize

Im Gegensatz zur PixelSize ("Bodenauflösung pro Pixel") ist die Angabe des ScaleDenominator bei Rasterbildern nicht eindeutig. Der Maßstab hängt von der darzustellenden Bildpunktgröße (DPI-Zahl) ab. Zwei Werte haben sich hier etabliert:

• 0,28mm/Pixel (OGC)
• 96 dpi (96 Bildpunkte pro Inch bzw. 25,4mm)

Beide Zahlen stehen im Verhältnis:

SD_96 0,28

----- = -------- = 1,0583

SD_28 25,4/96

Daher ist auch die Definition eines TileMatrixSets mit festen Maßstäben, z.B. 1:1 Mio. wird nicht möglich.

Well Known Scale sets

Ein WMTS unterstützt nur die Projektionen und Maßstabsstufen, die in den Tile Matrix Sets angegeben werden. Da WMTS-Clients meist nicht in der Lage sind Koordinatentransformationen und Bildskalierungen vorzunehmen, sollte für eine höhere Interoperabilität Well Known Scale Sets ("Vordefinierte Kachelarchive") verwendet werden. Ein Well Known Scale Set ist eine verbreitete Kombination von Projektion und Maßstabsstufen. Damit ein Tile Matrix Set zu einem Well Known Scale Set konform ist, müssen Projektion und ScaleDenominator Werte übereinstimmen. Das Tile Matrix Set muss nicht zwingend alle Maßstäbe aus dem Well Known Scale Set definieren. Es reicht wenn vom größten bis zu einem kleineren ScaleDenominator Wert angegeben werden.

Folgende ScaleSets werden durch OGC und INSPIRE definiert:

Capabilities Dokument

TODO

Beispiele

WMS Capabilities

1.1.1

1.3.0

WMTS Capabilities

Sonstiges

Datenquellen

Rasterdaten

Vektordaten (Live-Rendering)

Datumstransformationen

u. a. Hinweis auf NTv2-Ansatz BeTA 2007

RESTful OGC-Webdienste

Vergleich WMS 1.1.1 / WMS 1.3.0

Unterschiede in den Versionen

Hier sind die gravierenden Unterschiede zwischen den Web Map Service (WMS) der Versionen 1.1.1 und 1.3.0 darstellt.

Die Spezifikation zu den Versionen wurde vom Open Geospatial Consortium (OGC) verfasst. Angesprochen werden die Achsenreihenfolgeproblematik, die Konformitätsanforderungen an SLD-WMS, Unterschiede beim Get Map Request, die äquivalente Einträge der Metadatentabelle WMS Version 1.3.0 sowie die Implementationsunterschiede der Versionen.

Web Map Service Implementation Specification

Zur Diskussion für Alle. Wir sind nicht sicher, ob dieser Abschnitt hier richtig und sinnvoll ist.

Metadaten WMS Version 1.3.0 (nur äquivalente Einträge)

Bei Verwendung der WMS-Version 1.3.0 ist darauf zu achten, dass die Beziehungen der einzelnen Elemente aus ISO 19128 (Layer property) und ISO 19115 (Metadata element) einander entsprechen.

Die folgende Tabelle zeigt die Beziehungen zwischen ISO19128 und ISO19115 Metadatenfeldern

Get Map Request

In Tabelle 3 werden die Abweichungen bei den Parametern des getMapRequest dargestellt.

Diese beziehen sich auf WMS 1.1.1

...

(Dokument OGC 01-068r3; Abschnitt 7.2.2

...

und folgende) und WMS 1.3.0

...

(Dokument OGC® 06-042 ; Abschnitt 7.3.3 und folgende).

Tabelle 3

SLD

Zu den SLD-Versionen ist anzumerken, dass sie nicht nur einfach ein SLD-Schema normieren, sondern darüber hinaus die WMS-Schnittstelle erweitern.Darüber hinaus sind die Änderungen zwischen den SLD-Versionen 1.0.0 und 1.1.0 verwirrend. Mit dem Versionswechsel nach 1.1.0 wurde die SLD-Norm zum Profil der WMS-Schnittstelle in der Version 1.3.0.Gleichzeitig wurde der die eigentlichen Signaturen enthaltende Teil ausgegliedert und bildet ein eigenes Symbology-Encoding-Schema (SE) mit der Version 1.1.0.

Tabelle 4: Konformitätsanforderungen an SLD-WMS

Konformitätsklassen

1. A: Integrated SLD-WMS
2. B: Component SLD-WMS
   • B1: Feature Portrayal Service
   • B2: Coverage Portrayal Service

Integrierter SLD-WMS - Komponenten SLD-WMS

Der integrierte WMS ist fest mit seiner(n) Datenquellen verbunden und generiert nur Kartenbilder aus diesen.Ein Komponenten WMS benutzt Web Services (WFS,WCS) als Datenquellen.

Tabelle 5: Capabilities-Elemente in Komponenten SLD-WMS und integriertem SLD-WMS

Achsenreihenfolgeproblematik

Die WMS-Spezifikation Version 1.1.1 schreibt die Reihenfolge der Achsen wie folgt vor: Länge (Longitude, x, easting), Breite (Latitude, y, northing).

Dagegen wird sich in der WMS-Spezifikation Version 1.3.0 auf die in den EPSG-Spezifikationen festgelegten Achsenreihenfolgen bezogen. Es wird die Reihenfolge verwendet, die dort für jedes Koordinatensystem definiert ist.

Ein WMS-Client, der Requests der WMS-Version 1.3.0 an einen Server richtet, muss Kenntnis über die jeweils zu verwendende Achsenreihenfolge haben. Die kann er z.B. durch Zugriff auf eine EPSG-Datenbank erlangen. Durch eine entsprechend formulierte Anfrage an die EPSG-Datenbank lassen sich weit über 2100 EPSG-Codes ermitteln, deren Achsen mit der Bezeichnung Longitude, easting oder x nicht auf Platz eins in der Achsenreihenfolge liegen.

Folgende Tabelle zeigt die für Deutschland wichtigsten EPSG-Codes, deren Achsenreihenfolgen abhängig von der WMS-Version differieren.

Vergleich WMS / WMTS

Vorteile

• Durch die Ausgabe von vorprozessierten Kacheln sind sehr kurze Antwortzeiten möglich.
• Durch die Ausgabe von vorprozessierten Kacheln wird wenig Rechenleistung benötigt.

Nachteile

• Die vorprozessierten Kacheln können nur in festen Bodenauflösungen („Zoomstufen“) zur Verfügung gestellt werden.
• Aus Speicherplatzgründen können nur für wenige Projektionen Kacheln vorprozessiert werden.
• U. U. sind komplexe Mechanismen für partielle Kachelaktualisierungen notwendig.
• Der WMTS-Standard wird im Vergleich zum WMS-Standard von deutlich weniger Clients implementiert.

Der schnelle und ressourcenschonende Zugriff wird zu Lasten der Flexibilität erreicht. Daher hat sich die Bereitstellung von WMTS-Diensten über WMS-Dienste bewährt. Der WMS dient hierbei als Kachelproduzent für den WMTS, d. h. die GetTile-Anfrage wird in eine GetMap-Anfrage umgewandelt und das Ergebnisbild für eine bestimmte Zeit gecached. Kunden, die auf einen möglichst flexiblen Zugriff angewiesen sind, kann so weiterhin der flexiblere WMS zur Verfügung gestellt werden [Weichand 2014].

Gegenüberstellung der Parameter

Referenzen

• Rechtsakte der EU (INSPIRE):

[1] Richtlinie 2007/2/EG des Europäischen Parlaments und des Rates vom 14. März 2007 zur Schaffung einer Geodateninfrastruktur in der Europäischen Gemeinschaft (INSPIRE) - http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2007:108:0001:0014:DE:PDF

[2] Verordnung (EG) Nr. 976/2009 der Kommission vom 19. Oktober 2009 zur Durchführung der Richtlinie 2007/2/EG des Europäischen Parlaments und des Rates hinsichtlich der Netzdienste (es existiert noch ein Amendment) - http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:274:0009:0018:DE:PDF

[3] Verordnung (EG) Nr. 1205/2008 der Kommission vom 3. Dezember 2008 zur Durchführung der Richtlinie 2007/2/EG des Europäischen Parlaments und des Rates hinsichtlich Metadaten Text von Bedeutung für den EWR- http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2008:326:0012:0030:DE:PDF

[4] Verordnung (EG) Nr. 1089/2010 der Kommission vom 23. November 2010 zur Durchführung der Richtlinie 2007/2/EG des Europäischen Parlaments und des Rates hinsichtlich der Interoperabilität von Geodatensätzen und -diensten (es existiert noch ein Amendment)- http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2010:323:0011:0102:DE:PDF

• ISO Normen:

[5] ISO19139 - Geographic information -- Metadata -- XML schema implementation - http://www.iso.org/iso/catalogue_detail.htm?csnumber=32557

[6] ISO19119 - Geographic information – Services – http://www.iso.org/iso/catalogue_detail.htm?csnumber=39890, http://portal.opengeospatial.org/files/?artifact_id=1221

[7] ISO19115 - Geographic information – Metadata - http://www.iso.org/iso/catalogue_detail.htm?csnumber=26020

[8] ISO19128 - Geographic information -- Web map server interface - http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=32546, http://portal.opengeospatial.org/files/?artifact_id=14416

<references/>