Vorgaben der GDI-DE zur Bereitstellung von Darstellungsdiensten

Aus Geoportalwiki
Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

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:

<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&amp;outputFormat=iso19139&amp;Id=24124
</inspire_common:URL>
<inspire_common:MediaType>application/vnd.iso.19139+xml</inspire_common:MediaType>
</inspire_common:MetadataUrl>
</inspire_vs:ExtendedCapabilities>
</VendorSpecificCapabilities>

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:
<Keyword vocabulary="ISO 19115:2003">geoscientificInformation</Keyword><Keyword vocabulary="GEMET - INSPIRE themes">Administrative units</Keyword>

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

<Layer>
...
<!-- Definition geodatenhaltende Stelle-->
<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>
<!-- Verlinkung auf Geodaten -->
<Identifier authority="SGD-Nord – AG GIS">
c2019e4f3a3b1caf5c6198a4343bf249
</Identifier>
...
<!-- Verlinkung auf Metadaten zu den Geodaten -->
<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>


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

<wms:Layer>
<!-- BoundingBox ...-->
...
<!-- Definition geodatenhaltende Stelle-->
<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>
<!-- Verlinkung auf Geodaten -->
<wms:Identifier authority="by_verw">
125cce16-7ae1-3cf0-96e2-05a4453f3cb1
</wms:Identifier>
...
<!-- Verlinkung auf Metadaten zu den Geodaten -->
<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>


Beispiel für wmts:

<Layer>
...
<ows:Identifier>DOP_20_C</ows:Identifier>
<!-- Verlinkung auf Metadaten zu den Geodaten -->
<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>


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

<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>
<!-- Die Wetter-Daten sind täglich verfügbar von 1999-01-01 bis 2000-08-22. -->
<Dimension name="time" units="ISO8601" default="2000-08-22">
1999-01-01/2000-08-22/P1D
</Dimension>
<Layer>

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.

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 -->
    <html lang="de">
      <head>
         <meta http-equiv="content-type" content="text/html; charset=utf-8">
            <title>template_statistik</title>
 </head>
...

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

...
 <FeatureInfoFormats>
  <GetFeatureInfoFormat>
   <File>../customformat.gfi</File>
   <Format>text/html</Format>
  </GetFeatureInfoFormat>
 </FeatureInfoFormats>
  ...
 <FeatureInfoFormats>
  <GetFeatureInfoFormat>
   <XSLTFile gmlVersion="GML_32">../customformat.xsl</XSLTFile>
   <Format>text/html</Format>
  </GetFeatureInfoFormat>
 </FeatureInfoFormats>
  ...

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

<!DOCTYPE html>
  <html lang="de">
       <head>
          <meta http-equiv="content-type" content="text/html; charset=utf-8">
          <title>Leerer GetFeature request</title>
       </head>
       <body class="getfeatureinfo-isempty">
       Daneben! 
Ihre Datenabfrage liefert eine leere Ergebnismenge innerhalb des abgefragten Layers. </body> </html>

Beispiel ArcGIS Server

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


Beispiel XML-Dokument für GetFeatureInfo Request:


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


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

    <?xml version="1.0" encoding="UTF-8"?> 
    <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:esri_wms="http://www.esri.com/wms" xmlns="http://www.esri.com/wms"> 
    <xsl:output 
            method="xml"
            version="1.0"
            indent="yes"
            omit-xml-declaration="yes"
            encoding="UTF-8" />
    <xsl:template match="/"> 
        <html> 
        <head>
          <title>WMS GetFeatureInfo Response</title>
          <meta http-equiv="content-type" content="text/html; charset=UTF-8"/>	
          <style type="text/css">
            table { border:1px solid; width: 100%; border-spacing: 0px}
            th, td { border:1px solid #bbbbbb; padding:0px; }
	  </style>
        </head>        
        <xsl:choose> 
            <xsl:when test="count(esri_wms:FeatureInfoResponse/esri_wms:FeatureInfoCollection) = 0">            
                <body class="getfeatureinfo-isempty"> 
                    <p>Die Abfrage lieferte keine Treffer</p> 
                </body> 
            </xsl:when> 
            <xsl:otherwise> 
                <body> 
                <div> 
                    <xsl:for-each select="esri_wms:FeatureInfoResponse/esri_wms:FeatureInfoCollection"> 
                        <table> 
                          <caption>layer names: '<xsl:value-of select="@layername"/>'</caption> 
                            <tbody> 
                                <tr><th>Attribut</th><th>Wert</th></tr>
                                    <xsl:for-each select="esri_wms:FeatureInfo[1]/esri_wms:Field">
                                        <tr>
                                            <td>
                                                <xsl:value-of select="esri_wms:FieldName"/>
                                            </td>
                                            <td>
                                                <xsl:value-of select="esri_wms:FieldValue"/>
                                            </td>
                                        </tr>
                                    </xsl:for-each> 
                            </tbody> 
                        </table> 
                    </xsl:for-each> 
                </div> 
                </body> 
            </xsl:otherwise> 
        </xsl:choose> 
        </html> 
    </xsl:template> 
    </xsl:stylesheet>

Beispiel HTML Ausgabe mit leerer Ausgabe:


  <!DOCTYPE html><html xmlns:esri_wms="http://www.esri.com/wms">
  <head>
    <title>WMS GetFeatureInfo Response</title>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8" />
    <style type="text/css">
	table {	border:1px solid; width: 100%; border-spacing: 0px}
	th, td { border:1px solid #bbbbbb; padding:0px; }
    </style>
  </head>
  <body class="getfeatureinfo-isempty">
    <p>Die Abfrage lieferte keine Treffer</p>
  </body>
  </html>

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:

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


Beispiel Capabilities:

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


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

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

Beispiel Capabilities

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


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.

Meine Werkzeuge
Namensräume

Varianten
Aktionen
Navigation
Werkzeuge