Autoren

Name	Vorname	Institution
Behnke	Markus	Hessisches Landesamt für Bodenmanagement und Geoinformation
Böhme	Sven	Bundesamt für Kartographie und Geodäsie
Breitlow	Kerstin	Landesamt für Digitalisierung, Breitband und Vermessung BY
Enzweiler	Ilka	Bezirksregierung Köln, Geobasis NRW
Ettwein	Angelika	Landesamt für Geoinformation und Landentwicklung BW
Feinhals	Jürgen	Geschäftsstelle der GIW-Kommission
Kamping	Holger	Bundesanstalt für Geowissenschaften und Rohstoffe
Klein	Olaf	Landesamt für Geoinformation und Landesentwiklung BW
Lemke	Frank	SGD Nord (Landschaftsinformationssystem)
Luks	Adam	Eisenbahn-Bundesamt
Müller	Steffi	Landesvermessung und Geobasisinformation Brandenburg
Retterath	Armin	Zentrale Stelle GDI-RP
Schmidt	Alexander	Landesamt für Geoinformation und Landentwicklung BW
Thalheim	Dirk	Bundesamt für Kartographie und Geodäsie - Geodatenzentrum
Tegtmeyer	Sascha	Landesbetrieb Geoinformation und Vermessung HH
Thunig	Holger	Landesamt für Geoinformation und Landentwicklung BW
Tüngerthal	Sebastian	Senatsverwaltung für Stadtentwicklung und Umwelt Berlin
Weichand	Jürgen	Landesamt für Digitalisierung, Breitband und Vermessung Bayern
Ziebarth	Ralf	Bundesanstalt für Geowissenschaften und Rohstoffe

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.

WMS 1.1.1	WMS 1.3.0	WMTS 1.0.0	Erläuterung	ISO19139 XPATH
Name	Name	-	Technischer Name des Dienstes
Title	Title	ows:Title	Titel des Dienstes	/gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:citation/gmd:CI_Citation/gmd:title/gco:CharacterString
Abstract	Abstract	ows:Abstract	Beschreibung des Dienstes	/gmd:MD_Metadata/gmd:identificationInfo/gmd:MD_DataIdentification/gmd:abstract/gco:CharacterString
KeywordList	KeywordList	ows:Keywords	Liste der Schlüsselwörter	/gmd:MD_Metadata/gmd:identificationInfo/srv:SV_ServiceIdentification/gmd:descriptiveKeywords
OnlineResource	OnlineResource	ows:ProviderSite	Link zur Webseite des Diensteanbieters	/gmd:MD_Metadata/gmd:contact/gmd:CI_ResponsibleParty/gmd:contactInfo/gmd:CI_Contact/gmd:onlineResource/gmd:CI_OnlineResource/gmd:linkage/gmd:URL
ContactPerson	ContactPerson	ows:IndividualName	Kontaktperson	/gmd:MD_Metadata/gmd:contact/gmd:CI_ResponsibleParty/gmd:individualName/gco:CharacterString
ContactOrganisation	ContactOrganisation	ows:ProviderName	Kontaktorganisation	/gmd:MD_Metadata/gmd:contact/gmd:CI_ResponsibleParty/gmd:organisationName/gco:CharacterString
AddressType	AddressType	-	Art der Kontaktadresse
Address	Address	ows:DeliveryPoint	Strasse und Hausnummer	/gmd:MD_Metadata/gmd:contact/gmd:CI_ResponsibleParty/gmd:contactInfo/gmd:CI_Contact/gmd:address/gmd:CI_Address/gmd:deliveryPoint/gco:CharacterString
City	City	ows:City	Ort	/gmd:MD_Metadata/gmd:contact/gmd:CI_ResponsibleParty/gmd:contactInfo/gmd:CI_Contact/gmd:address/gmd:CI_Address/gmd:city/gco:CharacterString
StateOrProvince	StateOrProvince	ows:AdministrativeArea	Bundesland der postalischen Kontaktadresse. Angaben erfolgen per ISO3166-II Code (Bsp.: "DE-RP") zur Unterstützung automatischer Auswertungen.WMS-DE_1.0 - 3.2 - 5	/gmd:MD_Metadata/gmd:contact/gmd:CI_ResponsibleParty/gmd:contactInfo/gmd:CI_Contact/gmd:address/gmd:CI_Address/gmd:administrativeArea/gco:CharacterString
PostCode	PostCode	ows:PostalCode	Postleitzahl	/gmd:MD_Metadata/gmd:contact/gmd:CI_ResponsibleParty/gmd:contactInfo/gmd:CI_Contact/gmd:address/gmd:CI_Address/gmd:postalCode/gco:CharacterString
Country	Country	ows:Country	"DE" WMS-DE_1.0 - 3.2 - 5	/gmd:MD_Metadata/gmd:contact/gmd:CI_ResponsibleParty/gmd:contactInfo/gmd:CI_Contact/gmd:address/gmd:CI_Address/gmd:country/gco:CharacterString
ContactVoiceTelephone	ContactVoiceTelephone	ows:Voice	Telefonnummer der Kontaktorganisation	/gmd:MD_Metadata/gmd:contact/gmd:CI_ResponsibleParty/gmd:contactInfo/gmd:CI_Contact/gmd:phone/gmd:CI_Telephone/gmd:voice/gco:CharacterString
ContactElectronicEmailAddress	ContactElectronicEmailAddress	ows:ElectronicMailAddress	E-Mailadresse der Kontaktorganisation	/gmd:MD_Metadata/gmd:contact/gmd:CI_ResponsibleParty/gmd:contactInfo/gmd:CI_Contact/gmd:address/gmd:CI_Address/gmd:electronicMailAddress/gco:CharacterString
Fees	Fees	ows:Fees	Angaben zu Nutzungseinschränkungen und Nutzungsbedingungen (Kosten, Gebühren, Lizenzen, Quellenangabe, etc.)	/gmd:MD_Metadata/gmd:identificationInfo//gmd:resourceConstraints//gmd:otherConstraints/gco:CharacterString
AccessConstraints	AccessConstraints	ows:AccessConstraints	Angaben zu Einschränkungen des öffentlichen Zugangs	/gmd:MD_Metadata/gmd:identificationInfo//gmd:resourceConstraints//gmd:accessConstraints
	MaxWidth		Maximale Breite des zurückgelieferten Bildes
	MaxHeight		Maximale Höhe des zurückgelieferten Bildes

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:

Hochauflösende Druckaufbereitung
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

WMS 1.1.1	WMS 1.3.0	WMTS 1.0.0	Erläuterung
Title	Title	ows:Title	Titel des Layers
Name	Name	ows:Identifier	Technischer Name des Layers
Abstract	Abstract	ows:Abstract	Beschreibung des Layers
KeywordList	KeywordList	ows:Keywords	Liste der Schlüsselwörter
BoundingBox	BoundingBox	ows:BoundingBox	räumliche Ausdehnung des Layers (minimales Rechteck im Koordinatenreferenzsystem des Layers)
Dimension			Angabe einer zusätzlichen Dimension
AuthorityURL	AuthorityURL		Referenzierung auf die URL der geodatenhaltenden Stelle
Identifier	Identifier		Angabe des Resourcenidentifikators (gemäß ISO19128 CI_Citation.identifier)
MetadataURL	MetadataURL	ows:Metadata	Link zu einem ISO19139 kodierten Metadatensatz der Datengrundlage dieses Layers. (Hinweis: Die genaue Umsetzung der Daten-Dienste Kopplung wird in einem eigenen Abschnitt erläutert.)
ScaleHint	MinScaleDenominator / MaxScaleDenominator		Wert für die Berechnung bzw. Angabe des Minimalen und Maximalen Maßstab des Layers

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">

</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>

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

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

BBox	-46133,17000000	6301219,54000000	1387466,83	4867619,54

CRS	Zoomstufe	Maßstab	Pixelgröße (m)
urn:ogc:def:crs:EPSG::25832	0	10 * 10⁶	2800
	1	5 * 10⁶	1400
	2	2.5 * 10⁶	700
	3	1*10⁶	280
	4	5*10⁵	140
	5	2.5*10⁵	70
	6	1*10⁵	28
	7	50000	14
	8	25000	7
	9	10000	2,8
	10	5000	1,4
	11	2500	0,7
	12	1000	0,28
	13	500	0,14
	14	250	0,07
	15	100	0,028

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

 <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>

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 '''' in die erste Zeile zu schreiben. Im head der Datei wird der MIME-Type nochmals festgelegt.

Auszug Template-Datei

    
       
          ''''''
             template_statistik
  
 ...

=====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 '''
   
 
   
        
           
           Leerer GetFeature request
        
        
        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:

   <?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:

   <?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="/"> 
        
        
          WMS GetFeatureInfo Response
          	
          
                
         
                        
                 
                    Die Abfrage lieferte keine Treffer 
                 
             
             
                 
                 
                     
                        
                                         
                          layer names: '' 
                             
                                Attribut Wert
                                    
                                            
                                                
                                            
                                            
                                                
                                            
                                        
                                     
                             
                         
                     
                 
                 
             
         
         
   </xsl:template> 
   </xsl:stylesheet>

</source>

Beispiel HTML Ausgabe mit leerer Ausgabe:

<!DOCTYPE html> WMS GetFeatureInfo Response

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

<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

   <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:

Elemente	Beschreibung	Beispiel
Name	Zwingende Eingabe: WMS	<Name>WMS</Name>
Title	Ein selbsterklärende Bezeichnung	<Title>Hessen Geodaten</Title>
Abstract	Erläuterungen	<Abstract>Geobasisdaten © Hessische Verwaltung für Bodenmanagement und Geoinformation</Abstract>
KeywordList	Liste von Schlagwörtern	<KeywordList><Keyword>inspireidentifiziert</Keyword></KeywordList>
Fees	Nutzungsgebühren des Dienstes	<Fees>Die kostenfreie Nutzung der Daten ist nur für interne Zwecke erlaubt</Fees>
AccessConstraints	Zugangsbeschränkungen des Dienstes	<AccessConstraints>Die Weitergabe an Dritte oder jede gewerbliche Nutzung bedarf der schriftlichen Genehmigung durch das Landesamt</AccessConstraints>
OnlineResource	Web-Adresse des Dienstes	<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.gds-srv.hessen.de/cgi-bin/lika-services/ogc-free-maps.ows?" />
ContactPerson	Ansprechpartner für den Dienst	<ContactPerson>Max Mustermann</ContactPerson>
ContactOrganisation	Organisation die für den Dienst verantwortlich ist	<ContactOrganization>Landesamt für Vermessung</ContactOrganization>
City	Sitz der Organisation	<City>Musterhausen</City>
ContactElectronicMailAddress	E-Mail-Adresse der Kontaktperson	<ContactElectronicMailAddress>max.mustermann@example.org</ContactElectronicMailAddress>
MaxWidth	Maximale Ausgabebreite der Karte in Pixeln	<MaxWidth>4000</MaxWidth>
MaxHeight	Maximale Ausgabehöhe der Karte in Pixeln	<MaxHeight>4000</MaxHeight>
Layer	Im Layerelement muss das Attribut "queryable" angegeben werden.	<Layer queryable="0"></Layer>

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:

Elemente	Beschreibung	Beispiel
AuthorityURL	Name und Link zur Institution, auf die sich der folgende Identifier bezieht	<AuthorityURL>http://www.example.org</AuthorityURL>
Identifier	Code(UUID nach RFC 4122) für den Layerinhalt nach der in AuthorityURL genannten Institution	<Identifier>7a10ffb0-9491-11e3-baa8-0800200c9a66</Identifier>
MetadataURL	Link zu ISO19119 Metadaten zu der Datengrundlage dieses Layers	<MetadataURL>http://www.example.org/csw?Request=GetRecordByID&service=CSW&version=2.0.2&resultType=results&typeNames=csw:Record&elementSetName=full&ID=592cc850-9492-11e3-baa8-0800200c9a66</MetadataURL>

Für einen Request sind folgende Parameter bereitzustellen:

Request Parameter	V/O	Beschreibung
REQUEST=GetCapabilities	V	Ruft die Metadaten zum Dienst auf
SERVICE=WMS	V	Gibt an um welchen Dienst es sich handelt
VERSION	V	Gibt die Version des Dienstes an
FORMAT=Mime_type	O	Legt das Ausgabeformat fest
UPDATESEQUENCE*	O	Fordert eine bestimmte Version an

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:

Request Parameter	V/O	Beschreibung
REQUEST=GetMap	V	Verpflichtend GetMap als Name der Anfrage
SERVICE=WMS	V	Verpflichtend WMS, gibt an um welchen Dienst es sich handelt
VERSION	V	Gibt die Version des Dienstes an
LAYERS	V	Liste der gewünschten Layernamen, nach Komma getrennt auf
STYLES	V	Kann leer bleiben, dann wird der default Style genommen oder in einer nach Komma getrennten Liste, mit den definierten Styles
BBOX	V	Nach Komma getrennten Liste der Eckkoordinaten (unten links und oben rechts)
CRS	V	Koordinatensystem auf das sich die BBOX bezieht und das Ausgabeformat der Karte
WIDTH	V	Kartenbreite in Pixel
HEIGHT	V	Kartenhöhe in Pixel
FORMAT	V	Ausgabeformat als MIME-Type
BGCOLOR	O	Hintergrundfarbe im Hexadezimalcode (Standard ist weiß)
TRANSPARENT	O	Legt fest, ob die Hintergrundfarbe Transparent sein soll (Standard ist False)
ELEVATION	O	Ist für die Nutzung von Höhenschichten zu verwenden
TIME	O	Intervall oder Zeitpunkt, welcher in der Karte dargestellt werden soll
DIM_<Name>	O	Kann genutzt werden, wenn in den Service-Metadaten Dimensionen eingegeben sind. Der Parametername ist als case-insensitive an zu geben.
EXEPTIONS	O	Ausgabeformat für Fehlermeldungen (Standard ist XML, möglich ist auch INIMAGE, BLANK)

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

Request Parameter	V/O	Beschreibung
VERSION=1.3.0	V	Gibt die Version des Dienstes an. Verpflichtend 1.3.0
REQUEST=GetFeatureInfo	V	Name der Operation
QUERY_LAYERS	V	Liste,der Layer, die abgefragt werden
INFO_FORMAT	V	Ausgabeformat für die Feature-Informationen
I	V	Pixel-Spaltenwert der angefragten Position
J	V	Pixel-Zeilenwert der angefragten Position
LAYERS	V	Liste der gewünschten Layernamen, nach Komma getrennt auf
STYLES	V	Kann leer bleiben, dann wird der default Style genommen oder in einer nach Komma getrennten Liste, mit den definierten Styles
BBOX	V	Nach Komma getrennten Liste der Eckkoordinaten (unten links und oben rechts)
CRS	V	Koordinatensystem auf das sich die BBOX bezieht und das Ausgabeformat der Karte
WIDTH	V	Kartenbreite in Pixel
HEIGHT	V	Kartenhöhe in Pixel
FORMAT	V	Ausgabeformat als MIME-Type

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

Informationen zu den Straßen
Attribute	Wert
Schlüssel	55140445514077
Klasse	L
Straße	L3063

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"> Formatvorlage

Informationen zu dem Dienst XY
Attribute		Wert
Id		[inspireId]
Name		[name]

Homepage: http://www.hompage_XY

Logo XY

</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:

 <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.

Request Parameter	V/O	Beschreibung
REQUEST=GetLegendGraphic	V	Verpflichtend GetLegendGraphic als Name der Anfrage
SERVICE=WMS	V	Verpflichtend WMS, gibt an um welchen Dienst es sich handelt
VERSION	V	Gibt die Version des Dienstes an
SLD_VERSION	V	Gibt die Version der mit der SLD* übersandten Style Information des Dienstes an
LAYER	V	Legt den Layer fest von welchem die Legende angefordert wird
Format	V	Dateiformat für die Legendengrafik

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).

Operation	Ressource	Bedeutung
GetCapabilities	ServiceMetadata	Anforderung der Dienstebeschreibung
GetTile	Tile	Anforderung einer Kachel (Tile)
GetFeatureInfo	FeatureInfo	Anforderung von Sachinformationen

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]:

Parameter	Beschreibung
SERVICE	Der SERVICE Parameter identifieziert den Servicetyp. Der Wert muss auf “WMTS” gesetzt werden.
REQUEST	Der REQUEST Parameter ist verpflichtend anzubieten. Er zeigt die verwendete Service Operation an. Der Wert muss eine Operation des Web Map Tile Service sein.
LANGUAGE	Die Vorgaben zum Language Parameter sind identisch mit denen des WMS (siehe ...).

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:

Metadatenelemente	OGC-WMTS-Elemente in <wmts:Layer>
Resource Title	ows:Title
Resource Abstract	ows:Abstract
Keyword	ows:Keywords
Geographic Bounding Box	ows:WGS84BoundingBox
Unique Resource Identifier	ows:Identifier
Name	ows:Identifier
Coordinate Reference Systems	TileMatrixSetLink
Styles	Style
Legend URL	Style/LegendURL
Dimension Pairs	Dimension[@name,@units]
Zuordnung der Metadatenelemente einer INSPIRE-Ebene zu den OGC-WMTS-Elementen

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:

INSPIRE Parameter	WMTS (OGC 07-057r7) Parameter
Layers	LAYER
Styles	STYLE
Coordinate Reference System	TILEMATRIXSET
Bounding box	TILEMATRIX + TILEROW / TILECOL
Image width	TILEMATRIXSET
Image height	TILEMATRIXSET
Image format	FORMAT
Language	Keine. Siehe Beschreibung zu LANGUAGE in Kapitel LANGUAGES der [INSPIRE TG ViewServices 3.1]
Dimension Pairs	Dimension[@name,@units]
Zuordnung der Parameter eines INSPIRE Dienstes zu den OGC-WMTS Prametern

GetTile Aufruf

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

Aufruf Parameter	Verpflichtend /Optional	Beschreibung
VERSION=1.0.0	V	Versionabfrage
REQUEST=GetTile	V	Abfragename
LAYER=name	V	Kennung entsprechend der Definition in den Metadaten.
STYLE=name	V	Kennung entsprechend der Definition in den Metadaten. Wenn kein Style Parameter übergeben wurde, dann werden die default Einstellungen für alle Layer des Dienstes verwendet.
FORMAT=image/png	V	Wert der durch das ServiceMetadata Dokument definiert wird.
TILEMATRIXSET= InspireCRS84Quad	V	Kennung entsprechend der Definition in den Metadaten.
TILEROW=integer	V	Wert zwischen 0 MatrixHöhe -1 des Pyramidenlayers entsprechend der Definition in den Metadaten.
TILECOL=integer	V	Wert zwischen 0 MatrixBreite -1 des Pyramidenlayers entsprechend der Definition in den Metadaten.
Other sample dimension(s)	O	Ein einzelner Listenwert oder ein Wertebereich entsprechend der Definition in den Metadaten.
Kernfunktionen/Prameter für den GetTile Aufruf

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:

Name	Quelle	Projektionen	Bemerkungen
GlobalCRS84Scale (urn:ogc:def:wkss:OGC:1.0:GlobalCRS84Scale)	[OGC WMTS]	CRS:84	Well Known Scale Sets für globale Kartenprodukte Gerundete Maßstäbe für intuitive kartographische Repräsentation von Vektordaten
GlobalCRS84Pixel (urn:ogc:def:wkss:OGC:1.0:GlobalCRS84Pixel)	[OGC WMTS]	CRS:84	Well Known Scale Sets für globale Kartenprodukte Gerundedete Maßstäbe für intuitive kartographische Repräsentation von Rasterdaten. Einige Werte wurden für bestimmte Produkte (STRM, GTOPP oder ETOPO)
GoogleCRS84Quad (urn:ogc:def:wkss:OGC:1.0:GoogleCRS84Quad)	[OGC WMTS]	CRS:84	Well Known Scale Sets für Quadtree Pyramiden in CRS84. Level 0 erlaubt Darstellung der gesamten Erde in einem 256x256 Pixel Bild. Alle folgenden Levels werden werden durch Zweierpotenz gebildet.
GoogleMapsCompatible (urn:ogc:def:wkss:OGC:1.0:GoogleMapsCompatible)	[OGC WMTS]	EPSG:3857	Well Known Scale Sets kompatibel zu Google Maps und Microsoft Live Ma. Level 0 erlaubt Darstellung der gesamten Erde in einem 256x256 Pixel Bild. Alle folgenden Levels werden werden durch Zweierpotenz gebildet.
InspireCRS84Quad	INSPIRE View Services	CRS:84	Entspricht GoogleCRS84Quad beginnend ab Level 1. Darstellung optimiert für Europa
AdV TileMatrixSets (Grad)	AdV WMTS Profil Version 1.0.0Stand 11.03.2014	CRS:84	Entspricht InspireCRS84Quad ab Level 4. Darstellung optimiert für Deutschland.
AdV TileMatrixSets (metrisch)	AdV WMTS Profil Version 1.0.0Stand 11.03.2014	EPSG:3857 EPSG:25832 EPSG:25833	Entspricht GoogleMapsCompatible ab Level 5. Darstellung optimiert für Deutschland.

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

	OGC 01-068r3 (Version 1.1.1)	OGC 06-042 (Version 1.3.0 / ISO 19128)
HTTP POST	6.2The basic WMS specification only defines HTTP GET for invoking operations.	6.3.4A WMS may support the “POST” method of the HTTP protocol (IETF RFC 2616). When POST is used, the request message is formulated as an XML document.
FORMAT	6.5.3 If a request contains a Format not offered by a particular server, the server shall throw a Service Exception (with code "InvalidFormat").	6.9.3 If a request contains a format not offered by a particular server, the server shall respond with the default format for that operation if one has been defined, or throw a service exception (with code “InvalidFormat”) if no default has been defined.
EXCEPTION		Zusätzlicher Service exception code OperationNotSupported.Request is for an optional operation that is not supported by the server.
GetCapabilities		Zusätzlicher optionaler Request parameter FORMAT=MIME_type.Output format of service metadata. Every server shall support the default text/xml format. Support for other formats is optional. default: text/xml
General service metadata	7.1.4.2The Service Name shall be "OGC:WMS" in the case of a Web Map Service.	7.2.4.3The Service Name shall be “WMS” in the case of a WMS.
	7.1.4.2A list of keywords or keyword phrases should be included to help catalog searching. Currently, no controlled vocabulary has been defined.	7.2.4.3A list of keywords or keyword phrases describing the server as a whole should be included to help catalogue searching. Each keyword may be accompanied by a “vocabulary” attribute to indicate the defining authority for that keyword. One “vocabulary” attribute value is defined by this International Standard: the value “ISO 19115:2003” refers to the metadata topic category codes defined in ISO 19115:2003, B.5.27; information communities may define other “vocabulary” attribute values. No particular vocabulary is mandated by this International Standard.
Layer properties		Siehe:WMS 1.3.0; OGC® 06-042 Absatz: 7.2.4.6.1 und Tabelle 5The <Layer> element can enclose child elements providing metadata about the Layer. Some of the metadata values, and additional metadata, may be available in ISO 19115 or FGDC-STD-001-1998 [1] format as referenced via the <MetadataURL> element defined below. Table 2 (Tabelle 2) shows the relationship between Layer Properties in this International Standard and ISO 19115 metadata elements. When documenting layers with ISO 19115 metadata, service providers should ensure that fields listed as equivalent in Table 5 have identical values in the full 19115 and in the summary 19128 layer properties
GetMap Request		Siehe nachfolgende Tabelle 3.
SRS - CRS	Der Name des Parameters für die Angabe des Koordinatenreferenzsystems lautet SRS.	Der Name des Parameters für die Angabe des Koordinatenreferenzsystems lautet CRS. Weitere Hinweise im Abschnitt Achsenreihenfolgeproblematik am Ende dieses Abschnittes.

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

ISO 19128 layer property	ISO 19115 Metadata element	Relationship
Title	CI_Citation.title	equivalent
Abstract	MD_DataIdentification.abstract	equivalent
Keyword element in KeywordList	MD_TopicCategoryCode	equivalent if “vocabulary” attribute of 19128 <Keyword> element is “ISO 19115:2003”. Other vocabularies are permitted by 19128.
EX_GeographicBoundingBox	EX_GeographicBoundingBox	equivalent
DataURL	MD_metadata.dataSetURI	equivalent

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

Parameter	1.1.1	1.3.0	Bemerkung
VERSION	M	M	Request version.
REQUEST	M	M	Request name.
LAYERS	M	M	Comma-separated list of one or more map layers.1.1.1 Optional if SLD parameter is present.
STYLES	M	M	Comma separated list of one rendering style per layer.1.1.1 Optional if SLD is present.
SRS / CRS	M	M	1.1.1 Spatial Reference System.1.3.0 Coordinate reference system.
BBOX	M	M	Bounding box corners (lower left, upper right) in SRS / CRS units
WIDTH	M	M	Width in pixels of map picture.
HEIGHT	M	M	Height in pixels of map picture.
FORMAT	M	M	Output format of map.
TRANSPARENT	O	O	Background transparency of map (default=FALSE).
BACKGROUNDCOLOR / BGCOLOR	O	O	Hexadecimal red-green-blue colour value for the background color (default=0xFFFFFF).
EXCEPTIONS	O	O	The format in which exceptions are to be reported by the WMS1.1.1 (default=SE_XML)1.3.0 (default=XML)

TIME	O	O	Time value of layer desired.
ELEVATION	O	O	Elevation of layer desired.
Other sample dimension(s)	O	O	Value of other dimensions as appropriate.

SLD	O Siehe: OGC 01-068r3 URL of Web Feature Service providing features to be symbolized using SLD.	O Siehe: OGC 05-078r4 Styled Layer Descriptor profile of the Web Map Service Implementation Specification Version: 1.1.0 (revision 4)	Siehe: Styled Layer Descriptor profile of the Web Map Service Implementation Specification Version: 1.1.0 (revision 4) und Absatz SLD dieses Abschnittes.
WFS	O		1.1.1 URL of Web Feature Service providing features to be symbolized using SLD.

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

SLD 1.0.0 (OGC 01-068r3)

SLD 1.1.0 (OGC 05-078r4)

SLD-Dokument muss gegen das Schema validierbar sein.

Schnittstelle nicht spezifiziert.

Schnittstelle ist ein Profil des WMS 1.3.0.Sie definiert spezielle Operationen sowie zusätzliche Parameter und Einträge in den Service-Metadaten.

Das SLD-Profil zu WMS 1.3.0 enthält folgende Ergänzungen zum WMS Standard:

SLD-XSD Schema
Erweiterung der WMS-Capabilities um ein Element UserDefinedSymbolization
Zusätzliche Parameter für die GetMap Operation
- SLD/SLDBODY
- REMOTE_OWS_TYPE
- REMOTE_OWS_URL
Neue optionale Operationen:
- DescribeLayer
- GetLegendGraphic
Bei integriertem WMS (s. Tabelle 5) kommen die Operationen DescribeFeatureType bzw.DescribeCoverage hinzu.

Konformitätsklassen

A: Integrated SLD-WMS
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

Bereich	Element/Attribut	Component WMS (B)		Integrated WMS (A)
		Feature Portrayal Service (B1)	Coverage Portrayal Service (B2)
Attribute von UserDefinedSymbolization	SupportSLD	M	M	M
	UserLayer	M	M	-
	UserStyle	M	M	M
	RemoteWFS	M	-	-
	InlineFeatureData	O	-	-
	RemoteWCS	-	M	-
Operationen im Element Request	Describe Layer	-	-	M
	DescribeFeatureType	-	-	M
	DescribeCoverage	-	-	M
	GetLegendGraphic	O	O	O

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.

EPSG	WMS 1.1.1	WMS 1.3.0	Koordinatensystem
4326	Länge, Breite	Breite, Länge	WGS84
31466	Länge, Breite	Breite, Länge	DHDN / 3-degree Gauss-Kruger zone 2
31467	Länge, Breite	Breite, Länge	DHDN / 3-degree Gauss-Kruger zone 3
32468	Länge, Breite	Breite, Länge	DHDN / 3-degree Gauss-Kruger zone 4
31469	Länge, Breite	Breite, Länge	DHDN / 3-degree Gauss-Kruger zone 5

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

Anonym

Suche

Vorgaben der GDI-DE zur Bereitstellung von Darstellungsdiensten

Autoren

Entwurf

Einleitung

Anforderungen

Art der Bereitstellung

Persistenz/Identität

Zu unterstützende Versionen

WMS

WMTS

Darstellung von Copyright Vermerken

Koordinatenreferenzsysteme

WMS

WMTS

Sprache

Verfügbarkeit

Layername / Identifier

Zeichenkodierung von textbasierten Rückgabewerten

GetMap

Formate

GetFeatureInfo

Formate

Leere Rückgabe

Absicherung

Header der Capabilities Dokumente

Service Level Metadaten im Capabilities Dokument

Angaben zum Zugang und zur Nutzung von Diensten

Verlinkung des Dienst-Metadatensatzes im Capabilities Dokument

Bildgrößenbeschränkung

WMS

Content Level Metadaten im Capabilities Dokument

Styles / Legenden

WMS

WMTS

Transparenz

Handling von Exceptions

Daten-Dienste-Kopplung

Maßstabsbereiche (WMTS)

Bereitstellung multidimensionaler Daten

TIME Parameter

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

Verwendung von CORS Headern

Absicherung

WMTS Schnittstellen

Erläuterungen

Copyright

Punkt 3.11.1 Empfehlung zu Mime Type

Beispiel Mapserver

Beispiel ArcGIS Server

Punkt 3.14 Empfehlungen

Angaben zu fees und accessconstraints

Punkt 3.3.2 Rest

Punkt 3.11 Mime Type

Punkt 3.11.2 Anforderung

Punkt 3.xx CORS

Punkt 3.13 Tabelle

Punkt 3.13.2.1 Anforderung

3.2.0 WMTS Schnittstellen

Erläuterungen zu den Vorgaben der GDI-DE

Allgemein

Operationen

Web Map Service (WMS)

Operationen

GetCapabilities

GetMap

GetFeatureInfo

DescribeLayer

GetLegendGraphic

Capabilities Dokument

SLD

WMS-T

Web Map Tile Service (WMTS)

Schnittstellen

Operationen

Zu unterstützende Operationen

Parameter der Darstellungsdienst Operationen

Get View Services Metadata Operationen

Operations Metadata