Vorgaben der GDI-DE zur Bereitstellung von Darstellungsdiensten

Aus Geoportal
Version vom 23. Mai 2019, 14:11 Uhr von Felde (Diskussion | Beiträge) (Diese Seite wurde zum Übersetzen freigegeben)
Die druckbare Version wird nicht mehr unterstützt und kann Darstellungsfehler aufweisen. Bitte aktualisiere deine Browser-Lesezeichen und verwende stattdessen die Standard-Druckfunktion des Browsers.

<translate>

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:

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

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

Anforderung
Darstellungsdienste auf Basis einer WMS Schnittstelle sollten mindestens dazu in der Lage sein ein Bild der Größe 3000x3000 Pixel ausliefern zu können.
Anforderung
Darstellungsdienste auf Basis der WMS 1.3.0 Schnittstelle müssen die Metadatenelemente MaxWidth und MaxHeight liefern, sofern Obergrenzen für die maximal mögliche Pixelzahl existieren.

Content Level Metadaten im Capabilities Dokument

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

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

</source>


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

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

</source>


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

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


Anforderung
Wenn ein Dienst einen oder mehrere Datensätze besitzt, so müssen diese Datensätze mit dem Dienst verlinkt werden.
Anforderung
Das Attribut type des Elementes MetadataURL soll immer „TC211“ (WMS 1.1.1) oder „ISO19115:2003“ (WMS 1.3.0) sein.
Anforderung
Das xlink:href Attribut des OnlineResource Elements soll auf ein valides ISO19139 Dokument oder auf eine GetRecordById Response eines Katalogdienstes verweisen. Je nach Dokumententyp ist im Format - Tag entweder application/vnd.ogc.csw.GetRecordByIdResponse_xml oder application/xml.

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

Empfehlung
Verwendung des AuthorityURL Elementes zur Angabe des Codespaces des Datensatzidentifikators.
Empfehlung
Verwendung des Identifier Elementes zur Angabe des Codes des Datensatzidentifikators.

Maßstabsbereiche (WMTS)

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

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

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

Ausdehnung in km 1433,6 bei 256*256 Pixel

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

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

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

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

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

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

Verwendung von CORS Headern

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

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

Absicherung

WMS-DE_1.0 - 3.5.2

Empfehlung
Sollen Darstellungsdienste nur gewissen Nutzergruppen zugänglich gemacht werden, so sollen hierzu die Standardverfahren zur Authentifizierung des http-Protokolls verwendet werden (RFC2617HTTP-Authentication). Hier ist darauf hinzuweisen, dass die HTTP-BASIC Authentication Nutzername und Passwort im Klartext im HTTP-HEADER überträgt und daher nur über eine sichere https-Verbindung genutzt werden darf.</ref>
Anforderung
Darstellungsdienste dürfen nicht nur ausschließlich mit proprietären Methoden gegen unberechtigte Zugriffe geschützt werden.

WMTS Schnittstellen

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

Anforderung
Ein WMTS soll mindestens die KVP Variante angeboten werden.

Erläuterungen

Copyright

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

Datei:Copyright bild klein.png





UpdateSequens und Name/Identifier
Armin

Punkt 3.11.1 Empfehlung zu Mime Type

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


Beispiel Mapserver

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

Auszug MAP-Datei

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

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

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

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

Auszug Template-Datei

<!-- MapServer Template -->

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


<source lang="xml">

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

</source>


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

<source lang="html5">

   <?xml version="1.0" encoding="UTF-8"?> 
   <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:esri_wms="http://www.esri.com/wms" xmlns="http://www.esri.com/wms"> 
   <xsl:output 
           method="xml"
           version="1.0"
           indent="yes"
           omit-xml-declaration="yes"
           encoding="UTF-8" />
   <xsl:template match="/"> 
        
        
          WMS GetFeatureInfo Response
          	
          
                
         
                        
                 
                    

Die Abfrage lieferte keine Treffer

layer names: ''
AttributWert
</xsl:template> </xsl:stylesheet>

</source>

Beispiel HTML Ausgabe mit leerer Ausgabe:


<source lang="html5">

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

<source lang="html5">

<gmd:resourceConstraints>

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

</source>

Beispiel Capabilities

<source lang="html5">

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

</source>


Punkt 3.3.2 Rest

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


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

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

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

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

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

Punkt 3.11 Mime Type

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

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


[[2016:selfhmtl]]

Punkt 3.11.2 Anforderung

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

Punkt 3.xx CORS

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

Punkt 3.13 Tabelle

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


Beispiel

XML Ausschnitt von ISO TC211 Metadatensatz:


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


XPATH Ausdruck zur Beschreibung des FileIdentifiers in ISO TC211 Metadatensatz:

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

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

Punkt 3.13.2.1 Anforderung

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

3.2.0 WMTS Schnittstellen

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



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

Erläuterungen zu den Vorgaben der GDI-DE

Allgemein

Operationen

Die Darstellungsdienste WMS und WMTS werden über Operationen angefragt:

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

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

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

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

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

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

Operation GetMap/GetTile

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

 

Operation GetFeatureInfo (optional)

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

Operation GetLegendGraphic (optional, nur WMS)

GetLegendGraphic gibt eine Legende zu den dargestellten Layern aus.

Web Map Service (WMS)

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

Operationen

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

GetCapabilities

 

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


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* 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 Kann leer bleiben, dann wird der default Style genommen

oder in einer nach Komma getrennten Liste, mit den definierten Styles 

 BBOX 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 Kartenbreite in Pixel
 HEIGHT V Kartenhöhe in Pixel
 FORMAT V Ausgabeformat als MIME-Type
 BGCOLOR Hintergrundfarbe im Hexadezimalcode (Standard ist weiß)
 TRANSPARENT Legt fest, ob die Hintergrundfarbe Transparent sein soll (Standard ist False)
 ELEVATION Ist für die Nutzung von Höhenschichten zu verwenden
 TIME 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  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 Kann leer bleiben, dann wird der default Style genommen

oder in einer nach Komma getrennten Liste, mit den definierten Styles 

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

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

 <Version>1.1.0</Version>

- <LayerDescription>

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

- <TypeName>

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

- <LayerDescription>

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

- <TypeName>

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

</source>

GetLegendGraphic

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

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

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

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

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

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


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

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

Integrierter SLD-WMS - Komponenten SLD-WMS

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

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

 


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 – Serviceshttp://www.iso.org/iso/catalogue_detail.htm?csnumber=39890, http://portal.opengeospatial.org/files/?artifact_id=1221

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

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


<references/>

</translate>