Embed Size (px)
Citation preview
Geodateninfrastruktur Bayern
Einrichten von Web Feature Services
Leitfaden
2 WFS-Leitfaden
Impressum
Herausgeber: Geschäftsstelle Geodateninfrastruktur Bayern http://www.gdi.bayern.de
Autoren: Jürgen Weichand, Astrid Feichtner, Yvonne Clerico, Mihaela Schmidt, Manuela Sanders
Version: 1.0
Datum: 13.11.2013
Dieses Dokument steht unter der Creative-Commons-Lizenz Namensnennung - Weitergabe unter gleichen Bedingungen 4.0 International. Um eine Kopie dieser Li-zenz zu sehen, besuchen Sie http://creativecommons.org/licenses/by-sa/4.0/. Die
Namensnennung hat in folgender Weise zu erfolgen: "Geodateninfrastruktur Bayern – www.gdi.bayern".
WFS-Leitfaden 3
Inhaltsverzeichnis
Über dieses Dokument .................................................................................. 4 1 WFS-Grundlagen ................................................................................... 5
1.1 Was ist ein WFS und wie funktioniert er? ......................................... 5 1.2 Normen, Standards und Spezifikationen .......................................... 5 1.3 Operationen ..................................................................................... 6 1.4 Konformitätsklassen ....................................................................... 10
2 Bereitstellung eines WFS .................................................................... 12 2.1 Wahl der gewünschten Konformitätsklasse .................................... 12 2.2 Wahl eines geeigneten Softwareproduktes .................................... 12 2.3 Konfiguration der Feature Types .................................................... 13 2.4 Konfiguration der Koordinatenreferenzsysteme.............................. 14 2.5 Konfiguration von Stored Queries .................................................. 15 2.6 Konfiguration der Capabilities ........................................................ 16
2.6.1 Allgemeine Angaben ................................................................... 17 2.6.2 Kontaktinformationen .................................................................. 18 2.6.3 Operationen und Konformitätsklassen ......................................... 20 2.6.4 Feature Types ............................................................................. 22 2.6.5 Filter ............................................................................................ 24 2.6.6 Erweiterte Capabilities für INSPIRE Downloaddienste................. 24
2.7 Absicherung des WFS ................................................................... 26 2.7.1 Beschränkung der Anzahl der abrufbaren Features .................... 26 2.7.2 Zugriffskontrolle auf den Dienst oder einzelne Operationen ........ 26
2.8 Anforderungen bzgl. Dienstqualität ................................................ 27 2.8.1 Leistung ...................................................................................... 27 2.8.2 Kapazität ..................................................................................... 27 2.8.3 Verfügbarkeit ............................................................................... 27
2.9 Test ................................................................................................ 28 Quellenverzeichnis ...................................................................................... 29 Anhang ......................................................................................................... 30
A Abkürzungsverzeichnis .................................................................. 30 B Beispiel: Spezifikation WFS Hauskoordinaten Bayern .................... 31 C Beispiele für Stored Queries .......................................................... 37 D Beispiele für Capabilities-Dokumente ............................................. 41 E Testvorgehen ................................................................................. 42
4 WFS-Leitfaden
Über dieses Dokument
Dieses Dokument bietet Hilfestellung bei der Bereitstellung von Web Feature Services (WFS) und deren Beschreibung im Capabilities-Dokument. Es erläutert die wichtigsten Ei-genschaften und Funktionalitäten eines WFS und berücksichtigt Anforderungen, die sich aus den INSPIRE Technical Guidelines für Downloaddienste [INSPIRE TG DS] ergeben. Darüber hinaus werden weitere Empfehlungen für die Umsetzung von WFS in Bayern ge-geben.
Für einzelne Fachbereiche oder spezielle Anwendungen kann es sinnvoll sein, weitere Vor-gaben festzulegen. Für die Vermessungsverwaltung werden beispielsweise Vorgaben im AdV-WFS-Profil festgelegt.
Anhang B dieses Dokuments enthält ein Beispiel für die fachliche Spezifikation eines WFS. Eine solche Spezifikation eignet sich zur Dokumentation des Dienstes, erleichtert die Ab-stimmung verschiedener beteiligter Stellen und kann Grundlage für die technische Imple-mentierung des Dienstes sein.
Nach erfolgter Implementierung muss zu jedem WFS in jeder unterstützten Version ein Capabilities-Dokument im XML-Format vorliegen. Beispiele für WFS-Capabilities-Dokumente in den Versionen 1.0.0, 1.1.0 und 2.0.0 sind in Anhang D referenziert.
Es wird empfohlen, den WFS vor Freigabe hinsichtlich der im vorliegenden Dokument ge-nannten Vorgaben bzw. im Falle einer fachlichen Spezifikation hinsichtlich dieser Spezifika-tion zu testen. Anhang E beinhaltet einen Vorschlag zur Vorgehensweise beim Test.
WFS-Leitfaden 5
1 WFS-Grundlagen
1.1 Was ist ein WFS und wie funktioniert er?
Ein WFS ist ein Web Service, mit dem Vektordaten in Form von Geoobjekten (engl. „Fea-tures“) mit Sachinformationen bereit gestellt werden können. Die Geoobjekte können vom Nutzer abgefragt und – je nach Funktionsumfang des Dienstes – ggf. auch modifiziert wer-den. Die Features werden als Ergebnis der Abfrage in der Regel in der Geography Markup Language (GML) - einer XML-basierten Sprache speziell für Geodaten – zurückgeliefert. Für die Bereitstellung eines WFS kommen beispielsweise Geodatenbanken (z. B. PostGIS, Oracle Spatial, etc.) sowie Vektordateien (z. B. ESRI Shapefiles) als Datenquelle in Frage [Weichand 2013].
1.2 Normen, Standards und Spezifikationen
Die im Folgenden aufgelisteten, für WFS grundlegenden Normen, Standards und Spezifika-tionen kommen in diesem Leitfaden zur Anwendung. Bei Fortschreibung der unten genann-ten Dokumente ist der Leitfaden der GDI-BY ebenfalls fortzuschreiben.
Grundsätzlich sind die Vorgaben und Empfehlungen des jeweils aktuellen Architekturkon-zeptes der GDI-DE zu berücksichtigen.
Architektur der Geodateninfrastruktur Deutschland (GDI-DE): http://www.geoportal.de/DE/GDI-DE/Arbeitskreise/Architektur/architektur.html
Ausgangsbasis für die Umsetzung ist der WFS-Standard des Open Geospatial Consortium (OGC). Dieser Leitfaden geht von einer Implementierung basierend auf der aktuellen Versi-on 2.0.0 dieses Standards, die der Norm ISO 19142:2010 Geographic Information - Web Feature Service entspricht und sowohl im Architekturkonzept der GDI-DE als auch zur Um-setzung der Vorgaben für INSPIRE-Downloaddienste empfohlen wird, aus. Ergänzend wird auf die derzeit gebräuchliche Version 1.1.0 des Standards verwiesen.
OpenGIS Web Feature Service 2.0 Interface Standard (bzw. OpenGIS Web Feature Service Implementation Specification, Version: 1.1.0): http://www.opengeospatial.org/standards/wfs
Der WFS-Standard referenziert weitere Standards und Spezifikationen, die für die Umset-zung eines WFS relevant sind. Die wichtigsten Spezifikationen werden im Folgenden ge-nannt.
Allgemeine Beschreibungen zum Dienst werden in der OWS Common Spezifikation defi-niert.
OGC Web Service Common Implementation Specification, Version 1.1.0 (OGC 06-121-r3) (bzw. OWS Common Implementation Specification, Version 0.3.0): http://www.opengeospatial.org/standards/common
Die Methoden zur Auswahl von Objekten bei der Anfrage an einen Dienst werden im Filter Encoding Standard festgelegt.
6 WFS-Leitfaden
OpenGIS Filter Encoding 2.0 Encoding Standard (entspricht ISO 19143) (bzw. OpenGIS Filter En-coding Implementation Specification, Version 1.1.0): http://www.opengeospatial.org/standards/filter
Die GML kommt bei der Kodierung von Abfrageergebnissen sowie ggf. bei der Formulie-rung von Abfragen an den Dienst zum Einsatz.
OpenGIS Geography Markup Language (GML) Encoding Standard, Version 3.2.1 (entspricht ISO 19136:2007) (bzw. Open GIS: http://www.opengeospatial.org/standards/gml
Hierbei müssen die in der folgenden Tabelle angeführten Versionsabhängigkeiten berück-sichtigt werden. D. h. beispielsweise, dass ein WFS in der Version 2.0.0 standardmäßig die Nutzung der GML Version 3.2.1 vorsieht.
Web Feature Service Web Service Common Filter Encoding Geography Markup Language
WFS 2.0.0 OWS 1.1.0 FE 2.0.0 GML 3.2.1
WFS 1.1.0 OWS 0.3.0 FE 1.1.0 GML 3.1.1
WFS 1.0.0 - FE 1.0.0 GML 2.1.1
Weitere Vorgaben werden durch die INSPIRE-Verordnung für Netzdienste [INSPIRE VO ND] sowie die entsprechende technische Umsetzungsanleitung (engl. „Technical Guidance“) [INSPIRE TG DS] festgelegt. Die INSPIRE-spezifischen Anforderungen sind im Text durch einen orangen Balken gekennzeichnet.
Verordnung (EG) Nr. 976/2009 der Kommission vom 19. Oktober 2009 zur Durchführung der Richtli-nie 2007/2/EG des Europäischen Parlaments und des Rates hinsichtlich der Netzdienste: http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CONSLEG:2009R0976:20101228:DE:PDF
Technical Guidance for the implementation of INSPIRE Download Services, Version 3.1: http://inspire.jrc.ec.europa.eu/documents/Network_Services/Technical_Guidance_Download_Services_v3.1.pdf
1.3 Operationen
Der Funktionsumfang eines WFS wird durch die Auswahl der unterstützen Operationen und Filtermethoden bestimmt. Folgende Operationen sind u. a. für die OGC WFS in den Versi-onen 1.0.0, 1.1.0 und 2.0.0 definiert.
Operation Beschreibung WFS 1.0.0
WFS 1.1.0
WFS 2.0.0
GetCapabilities Liefert Metadaten, die die Eigenschaften des Diens-tes beschreiben (z. B. Dienstanbieter, unterstütze Operationen und Filterfunktionen, bereitgestellte Feature Types), in Form eines XML-Dokuments zu-rück.
X X X
DescribeFeatureType Liefert eine Beschreibung der Struktur eines Feature Types in Form eines GML-Anwendungsschemas zu-rück.
X X X
WFS-Leitfaden 7
GetFeature Liefert Features (ggf. gemäß einer in der Anfrage über Filter festgelegten Auswahl) zurück, standardmäßig als GML-Dokument.
X X X
GetGMLObject Ermöglicht den Abruf einzelner GML-Elemente durch Auflösung eines XLinks auf den Identifikator des Elements.
X
GetPropertyValue Gibt den Wert eines Attributs ausgewählter Features zurück.
X
Transaction Ermöglicht es, Features in der Datenquelle neu anzulegen, zu verändern, zu ersetzen oder zu löschen.
X X X
LockFeature Ermöglicht es, Features zu sperren, damit nur eine Transaction gleichzeitig ausge-führt werden kann.
X X X
GetFeatureWithLock Liefert Features zurück, wobei diese gleichzeitig mit einer Sperre belegt werden.
X X X
ListStoredQueries Liefert eine Liste der beim Server gespei-cherten vordefinierten Abfragen zurück.
X
DescribeStored-Queries
Liefert Metadaten, die die einzelnen Stored Queries beschreiben.
X
CreateStoredQuery Ermöglicht es, eine Stored Query anzule-gen.
X
DropStoredQuery Ermöglicht es, eine angelegte Stored Query zu löschen.
X
Im Folgenden wird eine Auswahl der wichtigsten Parameter, die beim Aufruf der Operatio-nen GetCababilites, DescribeFeatureType und GetFeature eines WFS 2.0 verwendet wer-den können, beschrieben [Weichand 2013; OGC WFS 2.0.0; OGC OWS 1.1.0; OGC FE 2.0.0]. Die verpflichtend anzugebenden Parameter sind dabei jeweils fett gedruckt. Der WFS 2.0 Standard definiert für die GetFeature Operation zwei unterschiedliche Typen von Abfragen (engl. „Queries“) – ad-hoc-Abfragen (engl. „Adhoc Query“), die bereits aus der WFS Version 1.1.0 bekannt sind und nun zusätzlich auch gespeicherte Abfragen (engl. „Stored Query“). Beim erstgenannten Typ kann die Auswahl der abzurufenden Features durch nutzerdefinierte Anfragen an den Server – ggf. unter Verwendung von Filtermethoden – beliebig festgelegt werden. Bei der StoredQuery Action kann der Nutzer Features nur un-ter Verwendung vordefinierter Anfragen abrufen (s. Kapitel 2.5.)
8 WFS-Leitfaden
Parameter Beschreibung
Basis-Parameter für alle Operationen
SERVICE Dienstetyp, hier „WFS“
VERSION (verpflichtend bei allen außer GetCapabilities)
Version des WFS-Standards, hier „2.0.0“, „1.1.0“ bzw. „1.0.0“
REQUEST Name der Operation, z. B. „GetCapabilities“
Operation GetCababilites
ACCEPTVERSIONS Version des WFS-Standards, hier „2.0.0“ bzw. „1.1.0“
Operation DescribeFeatureType
TYPENAME Durch Komma getrennte Liste der Namen von Feature Types, für die ei-ne Beschreibung abgefragt werden soll.
Operation GetFeature
Stan
dard
Pre
sent
atio
n
STARTINDEX Index innerhalb der Treffermenge, ab dem die Treffer im Ergebnis-Dokument übermittelt werden – im Falle einer Übertragung der Treffer-menge verteilt auf mehrere Anfragen („Paging“) (Standardwert: 1).
COUNT Maximale Anzahl der Treffer, die beim Paging in der Ergebnisliste über-mittelt werden sollen.
OUTPUTFORMAT Format, in das Ergebnis der Abfrage (d.h. die Features) zurückgeliefert wird (Standardwert: „application/gml+xml; version=3.2“).
RESULTTYPE Art des Ergebnisses (Standardwert: „results“). Alternativwert: „hits“, über den statt des vollständigen Ergebnisses lediglich die Anzahl der Treffer, die sich aus der Anfrage ergäben, übermittelt wird.
Adh
oc Q
uery
TYPENAMES Durch Komma getrennte Liste der Namen von Ressourcen (z. B. Feature Types bei einer GetFeature Abfrage), die abgefragt werden sollen.
SRSNAME Wahl des Koordinatensystems. (Standard-Format für Angabe: „urn:ogc:def:crs:EPSG::XXXXX“)
PROPERTYNAME Attribut eines Feature Types, auf das ein Filter angewendet werden soll.
FILTER1 Filterausdruck gemäß Filter Encoding Standard (s. u.) .
RESOURCEID1 Identifikator eines bestimmten Features, das abgefragt werden soll.
BBOX1 Begrenzungsrechteck (BoundingBox). Features, die innerhalb der BoundingBox liegen oder diese schneiden, werden abgefragt.
1 Angabe schließt sich gegenseitig aus, d. h. es kann entweder der „FILTER“ oder der RESOURCEID“ oder der „BBOX“ Parameter angegeben werden.
WFS-Leitfaden 9
SORTBY Angabe, nach welchen Attributwerten die Features in der Antwort auf die Abfrage aufsteigend („ASC“) oder absteigend („DESC“) sortiert werden sollen.
Stor
ed Q
uery
STORED-QUERYID
Identifikator der aufzurufenden Stored Query.
stored-query_parameter=value
Angabe eines Wertes für einen in der Stored Query definierten Parame-ter, der mit Namen identifiziert wird.
In einem Filterausdruck können u. a. die folgenden Operatoren verwendet werden [OGC FE 2.0.0]:
Operator Beschreibung
Vergleichsoperatoren
(engl. „comparison operators“)
Bsp:
• ist gleich („PropertyIsEqualTo“)
• ist ungleich („PropertyIsNotEqualTo“)
• ist kleiner als („PropertyIsLessThan“)
• ist größer als (“PropertyIsGreaterThan”)
• ist kleiner oder gleich („PreopertyIsLessThanOrEqualTo“)
• ist größer oder gleich („PropertyIsGreaterThanOrEqualTo“)
Logische Operatoren
(engl. „logical operators“)
• und („And“)
• oder („Or“)
• nicht („Not“)
Räumliche Operatoren
(engl. „spatial operators“)
Bsp.:
• ist gleich („Equals“)
• ist disjunkt („Disjoint“)
• berührt („Touches“)
• liegt innerhalb („Within“)
• schneidet („Intersects“)
• enhält („Contains“)
• Begrenzungsrechteck („BBOX“)
Zeitliche Operatoren
(engl. „temporal operators“)
Bsp.:
• während („During“)
• vor („Before“)
• nach („After“)
10 WFS-Leitfaden
1.4 Konformitätsklassen
Je nachdem, welche Auswahl an Operationen (s. Kapitel 1.3) ein WFS unterstützt, wird er einer bestimmten OGC WFS Konformitätsklasse (engl. „Conformance Class“) zugeord-net. Die folgende Tabelle listet eine Auswahl der Konformitätsklassen für WFS 2.0.0 inklu-sive der jeweils zu unterstützenden Operationen auf. Im Vergleich zur WFS Version 1.1.0 muss ein „Basic WFS“ in der Version 2.0.0 die zusätzliche Operation GetPropertyValue un-terstützen. Darüber hinaus wurde in der Version 2.0.0 eine zusätzliche Klasse „Simple WFS“ eingeführt, die die Operation GetFeature nur mit Stored Queries unterstützt [OGC WFS 2.0.0].
OGC WFS Conform-ance Class
Zu unterstützende Operationen / Behaviour
Simple WFS • GetCapabilities • DescribeFeatureType • GetFeature (nur StoredQuery, mindestens eine StoredQuery, die den Ab-
ruf von Features über den Identifikator ermöglicht) • ListStored Queries • DescribeStoredQueries
Basic WFS Alle „SimpleWFS“ Operationen, und zusätzlich: • GetFeature (Adhoc Query) • GetPropertyValue
Transactional WFS Alle „Basic WFS“ Operationen, und zusätzlich: • Transaction
Locking WFS Alle „Transactional WFS“ Operationen, und zusätzlich: • GetFeatureWithLock oder • LockFeature
HTTP GET Kodierung der Parameter für Operationen in Form von Schlüssel-Wert-Paaren ( „KVPEncoding“)
HTTP Post Kodierung der Parameter für Operationen unter Verwendung der XML („XMLEncoding“)
Response Paging „Durchblättern“ (engl. „Paging“) des Ergebnisses beispielsweise einer Get-Feature-Anfrage („ImplementsResultPaging“)
Standard joins Joins (d.h. die Verknüpfung mehrerer Feature Types in einer Anfrage) mit allen außer räumlichen und zeitlichen Operatoren
Spatial joins Joins mit räumlichen Operatoren
Temporal Joins Joins mit zeitlichen Operatoren
Manage stored queries • CreateStoredQuery • DropStoredQuery
WFS-Leitfaden 11
Je nachdem, welche Auswahl an Filtermethoden und Operatoren (s. Kapitel 1.3) ein WFS unterstützt, wird er einer der OGC Filter Encoding Konformitätsklassen, die im Folgenden aufgelistet sind, zugeordnet [OGC FE 2.0.0].
OGC Filter Encoding Conformance Classes
Zu unterstützende Operatoren
Query
Ad hoc Query
Resource Identification ResourceId
Minimum Standard Filter Vergleichsoperatoren:
• PropertyIsEqualTo
• PropertyIsNotEqualTo
• PropertyIsLessThan
• PropertyIsGreaterThan
• PreopertyIsLessThanOrEqualTo
• PropertyIsGreaterThanOrEqualTo
Standard Filter Alle Vergleichsoperatoren, alle logischen Operatoren
Minimum Spatial Filter BBOX
Spatial Filter BBOX und einen oder mehrere weitere räumliche Operatoren
Sorting
Minimum XPath
Minimum Temporal Filter During
Temporal Filter During und einen oder mehrere weitere zeitliche Operatoren
Version navigation ResourceId mit Parametern, die die Abfrage bestimmter Versio-nen ermöglichen (version, startTime, endTime)
Functions Funktionen, die über Filter Encoding Standard hinaus gehen
Extended Operators Weitere Operatoren, die über Filter Encoding Standard hinaus gehen
Schema Element Function schema-element() XPath Funktion
12 WFS-Leitfaden
2 Bereitstellung eines WFS
2.1 Wahl der gewünschten Konformitätsklasse
Bei der Wahl der Konformitätsklasse sollte die Hauptzielgruppe des Dienstes berücksichtigt werden. Soll die Nutzung so einfach wie möglich sein, bietet sich die Bereitstellung eines „Simple WFS“ mit vordefinierten Abfragen (Stored Queries), die der Nutzer nur noch aufru-fen muss, an. Wenn es Experten ermöglicht werden soll, beliebige Abfragen (Adhoc Queries) ggf. unter Verwendung von Filterausdrücken selbst zu formulieren, so empfiehlt sich ein „Basic WFS“ mit den entsprechenden Filter-Konformitätsklassen. Besteht darüber hinaus die Anforderung, dass der Nutzer Features modifizieren können soll, ist ein „Transactional WFS“ zu wählen.
Wenn der Datenbestand, der über einen WFS bereitgestellt werden soll, unter die INSPIRE-Richtlinie fällt, muss dieser als INSPIRE-Downloaddienst (engl. „Download Ser-vice“) realisiert werden. Ein solcher muss mindestens der OGC WFS 2.0 Konformitätsklas-se „Simple WFS” entsprechen, um damit den in der INSPIRE Verordnung zu Netzdiensten [INSPIRE VO ND] geforderten Download vordefinierter Datensätze ermöglichen. Zusätzlich können auch die beiden Operationen GetFeature (mit AdhocQuery) sowie GetPropertyValue eines Basic WFS unterstützt werden, um einen „Direktzugriffs-Downloaddienst“ gemäß der Verordnung zu Netzdiensten zu realisieren. Ein als „Simple WFS“ realisierter INSPIRE-Downloaddienst muss mindestens die „Query“ Filter-Konformitätsklasse unterstützen; ein als „Basic WFS“ implementierter Dienst mindestens die Konformitätsklassen Ad hoc Query, Resource Identification, Minimum Standard Filter, Minimum Spatial Filter, Minimum XPath und Minimum Temporal Filter. Diese und weitere Implementierungsanforderungen können der technischen Umsetzungsanleitung zu INSPI-RE-Downloaddiensten [INSPIRE TG DS] entnommen werden. Hinweise zur Umsetzung geben ferner die vom Arbeitskreis Geodienste der GDI-DE herausgegebenen Handlungs-empfehlungen für die Bereitstellung von INSPIRE konformen Downloaddiensten [GDI-DE DLS 2013].
2.2 Wahl eines geeigneten Softwareproduktes
Für die Bereitstellung eines WFS steht eine Reihe von Softwareprodukten bereit – sowohl Open Source als auch proprietär.
Neben den üblichen Kriterien bei der Softwareauswahl muss hier v. a. darauf geachtet wer-den, dass das Produkt die gewünschte Version des WFS-Standards und die jeweils gefor-derten Konformitätsklassen unterstützt. Die Version 2.0.0 wurde bisher (Stand September 2013) nur in wenigen Softwareprodukten implementiert.
WFS-Leitfaden 13
2.3 Konfiguration der Feature Types
Bei der Einrichtung eines WFS muss festgelegt werden, welche Geoobjekttypen (Feature Types) über den WFS bereitgestellt werden sollen, welche Attribute (sowohl Sach- als auch Geometrieeigenschaften) diese Feature Types haben, welche Datentypen und welche Kar-dinalität die Attribute haben und ob Beziehungen zwischen Feature Types bestehen. Damit werden die Inhalte des Schemas der Feature Types definiert.
Abhängig vom Datenbankmanagementsystem, in dem die bereitzustellenden Daten gehal-ten werden, sowie von der Software, mit der der WFS eingerichtet wird, kann dies i. d. R. auf mehreren verschiedenen Wegen geschehen:
Das Schema kann durch die WFS-Software automatisch on-the-fly auf Basis der beste-henden Datenbankstruktur (beispielsweise einer PostGIS-Datenbank) erzeugt werden.
Die Feature Types können auch auf der Ebene der Datenbank durch Mapping von in der Datenbank vorhandenen Elementen konfiguriert werden (Database Configuration).
Sofern die Daten bereits einem GML-Anwendungsschema entsprechen, können die Fea-ture Types über den Import dieses Schemas automatisch konfiguriert werden. Dies kann beispielsweise der Fall sein, wenn die Ausgangsdaten vor der Bereitstellung über einen WFS bereits in ein INSPIRE-Datenmodell transformiert wurden und damit einem INSPI-RE-GML-Anwendungsschema entsprechen.
Unter Berücksichtigung der bestehenden Struktur der bereitzustellenden Daten sowie der Anforderungen an den WFS muss bei der Konfiguration entschieden werden, ob einfach strukturierte Feature Types ausreichend sind, oder ob auch komplex strukturierte Feature Types notwendig sind [Weichand 2013].
Wenn der über einen WFS bereitzustellende Datenbestand unter die INSPIRE-Richtlinie fällt, muss die Bereitstellung zu den in der INSPIRE-Richtlinie festgelegten Terminen kon-form zur Verordnung (EU) Nr. 1089/201 [INSPIRE VO INT] erfolgen, d.h. passend zum IN-SPIRE-Datenmodell / GML-Anwendungsschema für das Geodatenthema, dem der Daten-bestand zugeordnet ist. Für bestehende Daten, die unter Anhang I der Richtlinie fallen, ist dies beispielsweise bis 13.11.2017 umzusetzen. Die INSPIRE-Schemata enthalten teilwei-se auch komplex strukturierte Feature Types.
Der GML-Standard [OGC GML 3.2.1] definiert eine große Menge von Elementen, die in Schemata Verwendung finden können, darunter beispielsweise eine Vielzahl unterschiedli-cher Geometrietypen für die Beschreibung der geometrischen Eigenschaften eines Fea-tures. Im OGC „Simple Features“ Profil zum Standard GML 3.2.1 [OGC SF 2.0] ist eine Teilmenge hiervon zur Modellierung einfach strukturierter Features definiert. Dies kann aus-reichend sein, wenn ein bestehender, einfach strukturierter Datenbestand möglichst einfach bereitgestellt werden soll. In dem Profil sind drei unterschiedliche Konformitätsebenen und damit drei „Einfachheitsgrade“ definiert. Für die unterste Ebene („SF-0) gelten dabei die meisten Einschränkungen bzgl. der bei der Modellierung verwendbaren Elemente.
14 WFS-Leitfaden
Einschränkungen Konformitätsebene
SF-0 SF-1 SF-2
Standard-Datentypen für nicht-räumliche Attribute beschränkt auf string, integer, measurement, date, real, binary, boolean, URI)
ja ja ja
Datentypen für geometrische Attribute beschränkt auf Point, Curve oder LineString (mit LineStringSegment, Arc, Circle oder CircleByCen-terPoint als Segmenten), Surface oder Polygon, MultiPoint, MultiCurve, MultiSurface
ja ja ja
Möglichkeit für Nutzer, eigene Datentypen zu definieren nein ja ja
Kodierung von Nullwerten bei Attributen durch das XML-Attribut nillable / xsi:nil
nein ja ja
Zulässige Kardinalitäten der Attribute 0 oder 1 0…* 0…*
Referenzen als Werte von nicht-räumlichen Attributen ja* ja* ja
Referenzen als Werte von geometrischen Attributen ja* ja* ja
* nur über gml:ReferenceType
2.4 Konfiguration der Koordinatenreferenzsysteme
Für einen in der GDI-BY bereitgestellten WFS gelten folgende Vorgaben und Empfehlun-gen bzgl. der zu unterstützenden Koordinatenreferenzsysteme:
INSPIRE (verpflichtend): EPSG:4258 oder eine Projektion basierend auf ETRS89 (z.B. EPSG:3034, 3035, 3044, 3045, 25832 oder 25833)
GDI-DE (verpflichtend): EPSG:4258 GDI-DE (empfohlen): EPSG:3034, 3035, 3044, 3045, 25832 und 25833 AdV (verpflichtend): Koordinatenreferenzsystem, in dem die Daten originär geführt wer-
den und EPSG:4258 GDI-BY (empfohlen): EPSG:31467 und 31468
Erläuterung der EPSG-Codes:
EPSG:3034: ETRS89 - Lambert Conformal Conic (ETRS89-LCC, Lambertsche Schnitt-kegelprojektion)
EPSG:3035: ETRS89 - Lambert Equal Area (ETRS89-LAEA, Lambertsche flächentreue Azimutalprojektion)
EPSG:3044: ETRS89 – Transversale Mercator-Projektion, Meridianstreifen 32 (ETRS89 / TM32)
EPSG:3045: ETRS89 - Transversale Mercator-Projektion, Meridianstreifen 33 (ETRS89 / TM33)
EPSG:4258: ETRS89 mit geografischen Koordinaten (2D)
WFS-Leitfaden 15
EPSG:25832: ETRS89 – Universale Transversale Mercator-Projektion, Meridianstreifen 32 Nord (ETRS89 / UTM 32N)
EPSG:25833: ETRS89 – Universale Transversale Mercator-Projektion, Meridianstreifen 33 Nord (ETRS89 / UTM 33N)
EPSG:31467: Gauß-Krüger-Projektion, 3. Meridianstreifen (GK3) EPSG:31468: Gauß-Krüger-Projektion, 4. Meridianstreifen (GK4)
Hinweise:
Die Koordinatenreferenzsysteme EPSG:3044 und 25832 sowie 3045 und 25833 unter-scheiden sich jeweils nur durch die Achsreihenfolge.
Der OGC WFS-Standard sieht ab der Version 2.0.0 die Angabe von Koordinatenreferenz-systemen beispielsweise in GetFeature-Abfragen unter Verwendung eines URN-Musters (z. B. urn:ogc:def:crs:EPSG::31468) vor. Die Koordinaten in der auf eine derart formulierte An-frage hin gelieferten Datei werden dann unter Verwendung der in der EPSG-Registry für GK-Koordinaten (z. B. EPSG: 31467, 31468) definierten Reihenfolge Hochwert, Rechtswert ausgegeben. Dies wird nach derzeitigem Stand von einer Reihe von GIS-Clients nicht kor-rekt verarbeitet, so dass die Geometrie u. U. achsengespiegelt dargestellt wird. Als „Work-around“ hat sich bei diesen Clients die alternative Angabe des Koordinatenreferenzsystems lediglich unter Verwendung des EPSG-Codes (z.B. EPSG:31468) etabliert [Weichand 2013].
2.5 Konfiguration von Stored Queries
Wie in Kapitel 1.3 beschrieben, bietet die Version 2.0.0 des WFS-Standards die Möglich-keit, Features über vordefinierte, server-seitig gespeicherte Abfragen („Stored Queries“) abzurufen. Die ListStoredQueries Operation liefert eine Liste der beim Server gespeicher-ten Abfragen zurück. Mit der DescribeStoredQueries Operation können Metadaten abgeru-fen werden, die die einzelnen StoredQueries beschreiben. Darüber hinaus besteht die Op-tion, neue vordefinierte Abfragen mit der CreateStoredQuery Operation auf dem Server an-zulegen und mit der DropStoredQuery Operation wieder zu löschen. Alternativ können die vordefinierten Abfragen auch über einen direkten Zugriff auf dem Server abgelegt werden, ohne dafür die WFS-Funktionalität zu nutzen. Sofern das Anlegen und Löschen von Stored Queries über die o. g. WFS Operationen erfolgen soll, ist zu beachten, dass vom Standard keine Zugriffseinschränkungen vorgesehen sind, d. h. jeder Nutzer könnte solche Abfragen auf dem Server anlegen, verändern und löschen. Hier sind also Absicherungsmechanismen notwendig. Einige Software-Implementierungen für WFS-Server bieten hier die Möglichkeit, einzelne Operationen mit einem Zugriffsschutz zu versehen.
Beispiele für Stored Queries können Anhang C entnommen werden.
Wird der WFS als INSPIRE-Downloaddienst umgesetzt, so ist gemäß der INSPIRE TG DS eine Stored Query bereitzustellen, die den Download eines Datensatzes in allen möglichen Kombinationen der vom Dienst unterstützen Koordinatenreferenzsysteme und Sprachen er-laubt. Hierfür sind in der Stored Query die folgenden Template-Parameter anzulegen:
Koordinatenreferenzsystem („CRS“) Datensatz-ID unter Verwendung von „DataSetIdCode“ und „DataSetIdNamespace“
16 WFS-Leitfaden
Sprache („Language“)
Für die Stored Query soll der folgende Identifikator (URI) verwendet werden: http://inspire.ec.europa.eu/operation/download/GetSpatialDataset
2.6 Konfiguration der Capabilities
Im Capabilities-Dokument werden die folgenden Gruppen von Eigenschaften des WFS do-kumentiert:
Eigenschaften Dokumentiert in Capabilities-Abschnitt s. u., Kapitel
allgemeine Angaben „ServiceIdentification“ 2.6.1
Kontaktinformationen „ServiceProvider“ 2.6.2
unterstützte Operationen „OperationsMetadata“ 2.6.3
unterstützte Filterfunktionen “Filter_Capabilities” 2.6.5
Feature Types „FeatureTypeList“ 2.6.4
In den folgenden Kapiteln werden die einzelnen beschreibenden Elemente eines Capabili-ties-Dokuments aufgelistet und erläutert.
Einige dieser Elemente müssen bei der Einrichtung des WFS mit eigenen Angaben verse-hen werden (z. B. allgemeine Angaben, Kontaktinformationen). Ein Großteil der restlichen Angaben wird i. d. R. in Abhängigkeit der in den Kapiteln 2.1 bis 2.5 beschriebenen, bei der Einrichtung eines WFS vorgenommenen Konfiguration durch die WFS-Server-Software au-tomatisch befüllt.
Wie in Kapitel 1.2 angesprochen, referenziert der WFS-Standard weitere Standards und Spezifikationen. Dies spiegelt sich auch im Capabilities-Dokument wieder. Da es für jeden Standard ein eigenes XML-Schema gibt, wird zur Zuordnung der verschiedenen Elemente im Capabilities-Dokument zu einem bestimmten Schema jeweils ein XML-Namensraum de-finiert. Im Capabilities-Dokument eines WFS können daher u. a. folgende Namensräume und Präfixe auftreten:
Namensraum Präfix Verweis auf
http://www.opengis.net/wfs/2.0* wfs* WFS 2.0. Standard
http://www.opengis.net/ows/1.1 ows OWS Common 1.1. Spezifikation
http://www.opengis.net/gml/3.2 gml GML 3.2 Standard
http://www.opengis.net/fes/2.0 fes Filter Encoding 2.0 Standard
http://inspire.ec.europa.eu/schemas/inspire_dls/1.0 inspire_dls INSPIRE Download Services 1.0 Spezifikation
http://inspire.ec.europa.eu/schemas/common/1.0 inspire_common INSPIRE Common 1.0 Spezifikation
*ist bei den im Folgenden verwendeten Beispielen als Standard-Namensraum definiert und wird daher bei den ent-sprechenden Elementen nicht zusätzlich angegeben
Im Folgenden wird bei den Angaben zu den einzelnen Capabilities-Elementen in den Tabel-len von einer WFS 2.0.0 Implementierung ausgegangen. In Fällen, in denen sich für einen WFS in der Version 1.1.0 Abweichungen ergeben, sind diese angegeben. Beispiele für
WFS-Leitfaden 17
WFS-Capabilities-Dokumente in den Versionen 1.0.0, 1.1.0 und 2.0.0 sind in Anhang C re-ferenziert.
In den unten stehenden Tabellen werden zur Angabe, ob ein Element im Capabilities-Dokument verpflichtend anzugeben ist oder nicht, folgende Kennzeichnungen verwendet:
fett: verpflichtend gemäß OGC Standards fett*: verpflichtend gemäß INSPIRE INSPIRE VO ND fett+: verpflichtend gemäß INSPIRE INSPIRE VO ND, kann auch über die in Kapitel
2.6.6 beschriebene Verlinkung eines Dienst-Metadatensatzes abgedeckt werden *: in der GDI-BY zusätzlich empfohlen
2.6.1 Allgemeine Angaben
Folgende beschreibende Angaben können zu einem WFS im Capabilities-Dokument (im Abschnitt <ows:ServiceIdentification>) gemacht werden.:
Nr.: Angabe zum Dienst
Beschreibung Bemerkung
2.6.1.1 Titel des Dienstes
Kurzer, menschenlesbarer Titel des WFS, welcher in der Applikati-on angezeigt wird.
XML-Tag: <ows:Title>
Sollte aussagekräftig und inhaltsbezogen sein, d.h. nicht nur „Web Feature Ser-vice“.
2.6.1.2 Beschreibung des Dienstes+
Allgemeine, kurze (Anhaltspunkt: 255 Zeichen) inhaltliche Beschrei-bung des Dienstes.
XML-Tag: <ows:Abstract>
Sollte inhaltlich aussagekräftig sein.
2.6.1.3 Liste von Schlüssel-wörtern, die den Dienst be-schreiben+
Liste von beliebigen Schlüsselwör-tern zu den Inhalten des Dienstes zur Unterstützung der Katalogsu-che.
Entspricht nicht den Schlüsselwör-tern für die Feature Types (s. 2.6.4.4)
XML-Tag: <ows:Keyword> in <ows:Keywords>
Neben Schlüsselwörtern zur themati-schen Einordnung ist z.B. die Aufnahme von gängigen Abkürzungen wie „DFK“ für „Digitale Flurkarte“ sinnvoll.
INSPIRE: mindestens „infoFeatureAccessService“
2.6.1.4 Art des Diens-tes
Angabe der Art des Dienstes, hier „WFS“
XML-Tag: <ows:ServiceType>
2.6.1.5 Version des Dienstes
Angabe aller unterstützten Versio-nen.
Je Version ein Tag: <ows:ServiceTypeVersion>
Ältere Versionen sollten unterstützt wer-den, z.B. bei WFS 2.0.0 auch Version 1.1.0 und 1.0.0, um den Dienst auch für Clients nutzbar zu machen, die die neu-este Version noch nicht unterstützen.
18 WFS-Leitfaden
Nr.: Angabe zum Dienst
Beschreibung Bemerkung
2.6.1.6 Gebühren+ Angaben über Gebühren und Ent-gelte sowie Nutzungsbedingungen des Dienstes.
XML-Tag: <ows:Fees>
Als Volltext oder als URL, wenn keine Gebühren erhoben werden, dann „none“
INSPIRE: falls zutreffend „no condi-tions apply“ oder „conditions un-known“
2.6.1.7 Zugriffsbe-schränkun-gen+
Angaben zu Zugriffs-beschränkungen.
XML-Tag: <ows:AccessConstraints>
Als Volltext oder als URL, wenn keine Zugriffsbeschränkungen greifen, dann „none“
2.6.2 Kontaktinformationen
Folgende Angaben können zum Datenanbieter im Capabilities-Dokument (im Abschnitt <ows:ServiceProvider>) gemacht werden. Die Einträge und die Struktur des XML-Dokuments orientieren sich an den Klassen CI_OnlineResource und CI_ResponsibleParty der Metadaten-Norm ISO 19115:2003 Geographic Information – Metadata (mit teilweise geänderten Pflichtfeldern):
Nr.: Angaben zum Dienst
Beschreibung Bemerkung
2.6.2.1 Dienstanbie-ter
Name der Organisation
XML-Tag <ows:ProviderName>
2.6.2.2 Website des Dienstanbie-ters
Angabe einer URL
XML-Tag <ows:ProviderSite xlink:href=…>
2.6.2.3 Kontaktinfor-mationen zum Dienstanbieter
Einzelne Elemente, die hierunter geführt werden können, sind un-ter 2.6.2.3.x angegeben.
XML-Tag: <ows:ServiceContact>
Übergeordneter XML-Tag zur Strukturie-rung
2.6.2.3.1 Ansprech-partner
Name einer Kontaktperson
XML-Tag: <ows:IndividualName>
2.6.2.3.2 Abteilung / Position
Position oder Funktion der Kon-taktperson
XML-Tag: <ows:PositionName>
WFS-Leitfaden 19
2.6.2.3.3 Kontaktin-formationen+
XML-Tag: <ows:ContactInfo> Übergeordneter XML-Tag zur Strukturie-rung
2.6.2.3.3.1 Telefonnum-mer*
Telefonnummer des Dienstan-bieters
XML-Tag: <ows:Voice> in <ows:Phone>
Empfohlenes Format: +49-89-2129-1111
2.6.2.3.3.2 Fax-Nummer Fax-Nummer des Dienstanbie-ters
XML-Tag: <ows:Facsimile> in <ows:Phone>
Empfohlenes Format: +49-89-2129-1113
2.6.2.3.3.3 Straße u. Hausnummer
XML-Tag: <ows:DeliveryPoint> in <ows:Address>
2.6.2.3.3.4 Stadt* XML-Tag: <ows:City> in <ows:Address>
2.6.2.3.3.5 Bundesland* XML-Tag: <ows:AdministrativeArea> in <ows:Address>
Vorschlag: Bezeichnung der Bundeslän-der nach ISO 3166-2 (für Bayern: DE-BY)
2.6.2.3.3.6 Postleitzahl* XML-Tag: <ows:PostalCode> in <ows:Address>
2.6.2.3.3.7 Land* Tag: <ows:Country> in <ows:Address>
Bezeichnung der Länder nach ISO 3166-2 (für Deutschland DE)
2.6.2.3.3.8 E-Mail+ E-Mail-Adresse des Diensteanbieters
XML-Tag: <ows:ElectronicMailAddress> in <ows:Address>
2.6.2.3.3.9 URL zu weite-ren Kontakt-informationen
XML-Tag: <ows:OnlineResource xlink:href=…>
2.6.2.3.3.10 Erreichbarkeit Erreichbarkeit des Datenanbie-ters
XML-Tag: <ows:HoursOfService>
2.6.2.3.3.11 Hinweise Hinweise zum Kontakt
XML-Tag: <ows:ContactInstructions>
20 WFS-Leitfaden
2.6.2.3.3 Rolle Rolle des Kontakts
XML-Tag: <Role>
Erlaubte Werte s. Codelist ISO 19115 B.5.5 CI_RoleCode (z.B. „resourceProvider“ o. „pointOfContact“)
2.6.3 Operationen und Konformitätsklassen
Die Auswahl der vom Dienst unterstützten Operationen (s. Kapitel 1.3) ist im Capabilities-Dokument (im Abschnitt <ows:OperationsMetadata>) angegeben und mit Parametern be-schrieben. Der Großteil dieser Angaben wird dabei ebenfalls automatisch befüllt. In den fünf folgenden Tabellen werden die Operationen GetCapabilites, DescribeFeatureType, Get-Feature, GetPropertyValue, ListStoredQueries und DescribeStoredQueries aufgeführt. Alle Operationen könnten über eine eigene URL angesprochen werden, daher wird die URL bei jeder Operation angegeben.
Für die Operation GetCapabilities können im Capabilities-Dokument folgende Angaben gemacht werden:
Nr.: Eigenschaften der Operation
Beschreibung Bemerkung
2.6.3.1 URL zum Aufruf des Capabili-ties-Dokuments
xlink:href im XML-Tag <ows:Get> bzw. <ows:Post>
Wird i.d.R. automatisch vom Server ein-gestellt.
2.6.3.2 Unterstützte Versionen
XML-Tag: <ows:Parameter name=”AcceptVersions“>
Wird i.d.R. automatisch vom Server ein-gestellt; entspricht der WFS-Version.
2.6.3.3 Unterstützte Formate
XML-Tag: <ows:Parameter name=”AcceptFormats“>
Wird i.d.R. automatisch vom Server ein-gestellt, gemäß der WFS-Version.
Standardwert: "text/xml", ggf. weitere MIME types
2.6.3.4 Enthaltene Ab-schnitte
XML-Tag: <ows:Parameter name=”Sections“>
Wird i.d.R. automatisch vom Server ein-gestellt, mögliche Abschnitte:
• ServiceIdentification
• ServiceProvider
• OperationsMetadata
• FeatureTypeList
• Filter_Capabilities
WFS-Leitfaden 21
Für die Operation DescribeFeatureType können im Capabilities-Dokument folgende An-gaben gemacht werden:
Nr.: Eigenschaften der Operation
Beschreibung Bemerkung
2.6.3.5 URL für die An-frage
xlink:href im XML-Tag <ows:Get> bzw. <ows:Post>
Wird i.d.R. automatisch vom Server ein-gestellt.
2.6.3.6 Ausgabeformate XML-Tag: <ows:Parameter name=“outputFormat“>
Wird i.d.R. automatisch vom Server ein-gestellt.
Standardwert: "application/gml+xml; version=3.2", ggf. weitere unterstützte GML-Versionen
Für die Operation GetFeature können im Capabilities-Dokument folgende Angaben ge-macht werden:
Nr.: Eigenschaften der Operation
Beschreibung Bemerkung
2.6.3.7 URL für die An-frage
xlink:href im XML-Tag <ows:Get> bzw. <ows:Post>
Wird i.d.R. automatisch vom Server ein-gestellt.
2.6.3.8 Ausgabeformate XML-Tag: <ows:Parameter name=”outputFormat“>
Wird i.d.R. automatisch vom Server ein-gestellt.
Standardwert: "application/gml+xml; version=3.2", ggf. weitere unterstützte GML-Versionen und Datenformate (z.B. "SHAPE-ZIP")
2.6.3.9 resolve Angabe, welche Art von Referen-zen auf Ressourcen aufgelöst werden können.
XML-Tag: <ows:Parameter name=”resolve“>
Standardwerte: "none" (keine) und "lo-cal" (lokale); ggf. zusätzlich "remote" (über xlink:href) und "all" (alle Arten)
Für die Operation GetPropertyValue können im Capabilities-Dokument folgende Angaben gemacht werden:
Nr.: Eigenschaften der Operation
Beschreibung Bemerkung
2.6.3.10 URL für die An-frage
xlink:href im XML-Tag <ows:Get> bzw. <ows:Post>
Wird i.d.R. automatisch vom Server ein-gestellt.
2.6.3.11 Ausgabeformate XML-Tag: <ows:Parameter name=”outputFormat“>
Wird i.d.R. automatisch vom Server ein-gestellt.
Standardwert: "application/gml+xml; version=3.2", ggf. weitere unterstützte
22 WFS-Leitfaden
GML-Versionen und Datenformate (z.B. "SHAPE-ZIP")
2.6.3.12 resolve Angabe, welche Art von Referen-zen auf Ressourcen aufgelöst werden können.
XML-Tag: <ows:Parameter name=”resolve“>
Standardwerte: "none" (keine) und "lo-cal" (lokale); ggf. zusätzlich "remote" (über xlink:href) und "all" (alle Arten)
Für die Operationen ListStoredQueries und DescribeStoredQueries werden neben der URL keine weiteren Parameter angegeben.
Nr.: Eigenschaften Operation
Beschreibung Bemerkung
2.3.5.1 URL für die An-frage
• xlink:href im XML-Tag <ows:Get> bzw. <ows:Post>
Wird i.d.R. automatisch vom Server ein-gestellt.
Treffen bestimmte Parameter für alle Operationen zu, dann können diese auch global im Abschnitt <ows:OperationsMetadata> des Capabilities-Dokuments definiert werden. Ob eine WFS-Konformitätsklasse (s. Kapitel 1.4) unterstützt wird, ist ebenfalls im Abschnitt <ows:OperationsMetadata> innerhalb von <ows:Constraint> Elementen durch die bool-schen Operatoren „TRUE“ (d.h. wird unterstützt) oder „FALSE“ (d.h. wird nicht unterstützt) anzugeben. Diese Angaben werden i.d.R. automatisch befüllt, gemäß der Konfiguration des Servers.
2.6.4 Feature Types
Die über einen WFS verfügbaren FeatureTypes und einige beschreibende Angaben zu die-sen werden im Abschnitt <FeatureTypeList> des Capabilites-Dokuments aufgelistet.
Nr. Angaben zum FeatureType
Beschreibung Bemerkungen
2.6.4.1 FeatureType Definition des für den Feature Type gültigen XML-Namensraums (s. Ka-pitel 2.6).
XML-Tag <FeatureType xmlns:…=“…“>
Übergeordneter XML-Tag. Bsp.: xmlns:bvv="http://www.geodaten.bayern.de"
2.6.4.1.1 Name des FeatureType
Ein zusammenhängendes Wort un-ter Verwendung des oben definierten Namensraum-Präfix, dient als Identi-fikator für den FeatureType (maschinenlesbar).
XML-Tag: <Name>
Darf nur Buchstaben (ohne Umlaute und ß), Zahlen, Minuszeichen, Doppel-punkte und Unterstriche enthalten
Bsp: „bvv:Flurstuecke“
WFS-Leitfaden 23
2.6.4.1.2 Titel des FeatureType
Kurzer, menschenlesbarer Titel des FeatureTypes, welcher in der Appli-kation angezeigt wird.
XML-Tag: <Title>
Der Titel sollte aussagekräftig und nicht identisch mit dem Titel des Dienstes sein.
2.6.4.1.3 Beschreibung des Feature-Types*
Allgemeine kurze Beschreibung des FeatureTypes.
XML-Tag: <Abstract>
2.6.4.1.4 Liste von Schlüsselwör-tern
Liste von Schlüsselwörtern, die den FeatureType beschreiben.
Je Schlüsselwort ein XML-Tag <ows:Keyword> in <ows:Keywords>
2.6.4.1.5 Standard-Koordi-natenrefe-renzsystem
Koordinatenreferenzsystem (CRS), in dem die Features ausgegeben werden, wenn in kein CRS explizit definiert wird.
XML-Tag: <DefaultCRS> (bzw. <DefaultSRS> bei Version 1.1.0)
Angabe als URN. Bsp.: „urn:ogc:def:crs:EPSG::31468”
2.6.4.1.6 Weitere Koor-dinatenrefe-renzsysteme
Weitere vom Server unterstützte CRS
XML-Tag: <OtherCRS> (bzw. <OtherSRS> bei Version 1.1.0)
s. Kapitel 2.4
2.6.4.1.7 Kein Koordi-natenrefe-renzsystem
Angabe bei FeatureTypes, die kei-nen Raumbezug aufweisen (reine Sachdaten).
XML-Tag: <NoCRS> (bzw. <NoSRS> bei Version 1.1.0)
2.6.4.1.8 Ausgabefor-mate
XML-Tag: <OutputFormats> Wird das Ausgabeformat hier nicht an-gegeben, wird angenommen, dass alle bei der GetFeature-Operation in den Capabilities angegebenen Ausgabe-formate unterstützt werden.
2.6.4.1.9 Räumliche Verfügbarkeit des Feature-Types*
Angabe der BoundingBox des Fea-tureTypes im CRS WGS84 mit geo-grafischen 2D-Koordinaten (EPSG:4326).
XML-Tag <ows:WGS84BoundingBox>
Zwei Koordinatenpaare: Links unten und rechts oben <LowerCorner>
Bsp. für ganz Bayern:
<ows:LowerCorner>8.9451 47.2484</ows:LowerCorner>
<ows:UpperCorner>13.9089 13.9089</ows:UpperCorner>
24 WFS-Leitfaden
und <UpperCorner>
2.6.4.1.10 Metadaten-URL*
Angabe einer URL zu einem Meta-datensatz, der den FeatureType be-schreibt.
XML-Tag: <MetadataURL>
xlink:href, i.d.R. gefolgt von GetRe-cordByID-Aufruf eines Metadatensat-zes, der über die CSW-Schnittstelle ei-nes Metadatenkatalogs angesprochen werden kann.
2.6.4.1.11 Erweiterte Beschreibung
Weitere Elemente können dem Cap-abilities-Dokument unter diesem Tag hinzugefügt werden ohne eine Schema-Änderung.
XML-Tag: <ExtendedDescripti-on>
2.6.5 Filter
Ob eine Filter-Konformitätsklasse unterstützt wird, ist im Capabilities-Dokument im Un-terabschnitt <fes:Conformance> der <fes:FilterCapabilities> in <fes:Constraint> Elementen durch die boolschen Operatoren „TRUE“ (Klasse wird unterstützt) oder „FALSE“ (Klasse wird nicht unterstützt) anzugeben. Die unterstützten Operatoren und Funktionen werden ebenfalls im <fes:FilterCapabilities> Abschnitt aufgelistet. Diese Angaben werden i. d. R. gemäß der Konfiguration des Servers automatisch befüllt.
2.6.6 Erweiterte Capabilities für INSPIRE Downloaddienste
Sofern der Dienst unter die INSPIRE-Richtlinie fällt, müssen die im Folgenden beschriebe-nen, spezifischen Anforderungen für INSPIRE-Downloaddienste erfüllt werden, die sich aus der INSPIRE-Verordnung für Netzdienste [INSPIRE VO ND] ergeben.
Für einen INSPIRE-Downloaddienst müssen im Capabilities-Dokument gegenüber einem herkömmlichen OGC-WFS einige zusätzliche Elemente bereitgestellt werden. Daher muss das Capabilities-Dokument durch so genannte ExtendedCapabilities erweitert werden, um zum einen die Integration von INSPIRE-Metadaten und zum anderen die Sprachparameter zu unterstützen [GDI-DE DLS 2013].
Integration von INSPIRE-Metadaten in die Capabilities
INSPIRE bietet zwei Möglichkeiten, Metadaten zu einem Dienst in den Capabilities abzubilden, entweder durch Verlinkung auf einen standardisierten INSPIRE-Dienst-Metadatensatz oder durch die komplette Integration aller geforderten Metadaten-Elemente in die Capabilities.
Empfohlen wird eine Verlinkung auf die Dienst-Metadaten. Voraussetzung für diese Integration ist das Vorliegen eines INSPIRE-Dienst-Metadatensatzes, der über eine URL (i.d.R. ein GetRecordByID-Aufruf eines Metadatensatzes, der über die CSW-Schnittstelle eines Metadatenkatalogs angesprochen werden kann) verfügbar ist. In diesem Fall ist die Angabe des Links innerhalb der <inspire_dls:ExtendedCapabilities> im Abschnitt <ows:ExtendedCapabilites> ausreichend.
WFS-Leitfaden 25
Nr.: Angaben zu den ExtendedCapabi-lities
Beschreibung Bemerkung
2.6.6.1 Verlinkung ei-nes Metadaten-satzes*
Link zu einem Dienst-Metadatensatz.
XML-Tag <inspire_common:URL> in <inspire_common: MetadataUrl>
Der Dienst-Metadatensatz muss gemäß ISO 19139 vorliegen.
Werden die Metadaten vollständig in die Capabilities übernommen, sind weitere Einträge in den ExtendedCapabilities erforderlich. Details hierzu können dem Technical Guidance Do-kument zu Downloaddiensten [INSPIRE TG DS] entnommen werden.
Angabe der unterstützten natürlichen Sprachen
Der Dienst muss den Parameter LANGUAGE bei GetCapabilities Anfragen unterstützen. Gefordert ist allerdings lediglich die Unterstützung mindestens einer europäischen Sprache durch den Dienst.
Innerhalb der <inspire_dls:ExtendedCapabilities> muss mindestens eine Standardsprache (engl. „Default Language“) und ggf. eine oder mehrere weitere unterstützte Sprachen (engl. „Supported Language“) angegeben. Werden mehrere Sprachen unterstützt, muss der Dienst auch in der Lage sein, ein Capabilities-Dokument zurückzuliefern, dass mindestens Titel (<title>) und Abstract (<abstract>) in diesen Sprachen enthält. Die Antwortsprache (engl. „Response Language“) - d.h. die Sprache des vom Dienst als Antwort zurückgelieferten Capabilities-Dokumentes - wird ebenfalls in den Capabilities angegeben. Dies erfolgt abhängig von der Abfrage. Wird in der Anfrage kein LANGUAGE Parameter verwendet, oder eine nicht unterstützte Sprache angegeben, so wird die Antwort in der Standardsprache zurückgeliefert. Wird eine unterstützte Sprache angegeben, so wird diese als Antwortsprache angegeben.
Die erweiterten Capabilities in der Übersicht (Angaben zu den fett geschriebenen Tags sind verpflichtend):
Nr.: Angaben zu den ExtendedCapabi-lities
Beschreibung Bemerkung
2.6.6.2
Standard-Sprache*
Sprache, in der der Dienst ant-wortet, wenn die Anfrage keinen LANGUAGE-Parameter enthält oder eine nicht unterstützte Spra-che angefordert wird.
XML-Tag: <inspire_common: Language> in <in-spire_common: DefaultLanguage>
Eintrag gemäß Codelist (ISO 639-2/B alpha 3 codes).
Code für Deutsch: „ger“
26 WFS-Leitfaden
2.6.6.3 Weitere unter-stützte Sprachen
XML-Tag: <inspire_common: Language> in <inspire_common: SupportedLanguage>
Eintrag gemäß Codelist (ISO 639-2/B alpha 3 codes).
2.6.6.4 Antwort-Sprache*
Die Sprache, in der der Dienst die entsprechende Antwort liefert (Sprache des Capabilities-Dokuments).
XML-Tag: <in-spire_common:ResponseLanguage>
Eintrag gemäß Codelist (ISO 639-2/B al-pha 3 codes), abhängig von der Anfrage.
Code für Deutsch: „ger“
2.7 Absicherung des WFS
Der WFS-Standard selbst sieht keine Möglichkeiten zur Zugriffseinschränkung vor. Falls ein Dienst zugriffsbeschränkt sein soll, so ist dies durch die konkrete Implementierung sicher zu stellen. Einige Software-Implementierungen für WFS-Server bieten diese Funktionalität be-reits an.
2.7.1 Beschränkung der Anzahl der abrufbaren Features
Es wird empfohlen, die Anzahl der maximalen Features, die bei einer GetFeature-Abfrage zurückgeliefert werden, bei der Konfiguration des WFS einzuschränken. Dies wird dann im <ows:Constraint name="CountDefault"> Element des Capabilities-Dokuments an-geführt.
2.7.2 Zugriffskontrolle auf den Dienst oder einzelne Operationen
Der Dienst kann rudimentär durch eine HTTP-Basic-Authentifizierung abgesichert werden. Hierbei ist der komplette Dienst, d. h. alle zur Verfügung gestellten Operationen passwort-geschützt.
Einige Serverprodukte bieten auch den Passwortschutz ausgewählter Operationen an (z. B. Transaction, CreateStoredQuery, DropStoredQuery).
Für detaillierte Absicherungsszenarien werden i. d. R. Proxy-Fassaden notwendig, die in der Softwarearchitektur vor die Serverkomponente geschaltet werden. Diese ermöglichen beispielsweise unterschiedliche Gebietseinschränkungen in Abhängigkeit der jeweiligen Kennung. Bei der Wahl der Proxy-Fassade ist darauf zu achten, dass die vom WFS-Server bereitgestellten Dienste-Versionen (insbesondere auch WFS 2.0) unterstützt werden. Des Weiteren sollte die Proxy-Fassade die bestehende Kennungsverwaltung (z. B. LDAP) un-terstützen.
WFS-Leitfaden 27
2.8 Anforderungen bzgl. Dienstqualität
Die INSPIRE-Verordnung zu Netzdiensten [INSPIRE VO ND] legt konkrete Kriterien bzgl. Leistung, Kapazität und Verfügbarkeit eines Downloaddienstes fest. Diese technischen An-forderungen können als Richtwert auch bei weiteren in der GDI-DE bzw. der GDI-BY be-reitgestellten WFS-Diensten, die nicht unter die INSPIRE-Richtlinie fallen, dienen. Empfeh-lungen, wie die Einhaltung dieser Anforderungen getestet werden kann, können Anhang E entnommen werden.
2.8.1 Leistung
Der Parameter „Leistung“ bezieht sich auf die Antwortzeit des Dienstes auf eine definierte Anfrage.
Für die Operation GetFeature bei einem Direktzugriffs-Downloaddienst („Get Spatial Ob-ject“ bei INSPIRE) bzw. für die Operation GetFeature mit Stored Query bei einem Dienst zum Download vordefinierter Datensätze („Get Spatial Dataset“ bei INSPIRE) beträgt die Zeit bis zur ersten Antwort in einer normalen Situation höchstens 30 Sekunden, dann - ebenfalls in einer normalen Situation - beträgt die ständige Übertragungsrate mehr als 0,5 Megabytes pro Sekunde oder mehr als 500 Geo-Objekte pro Sekunde.
Für die Operation DescribeFeatureType bei einem Direktzugriffs-Downloaddienst („Descri-be Spatial Object Type“ bei INSPIRE) bzw. die Operation GetCapabilities bei einem Dienst zum Download vordefinierter Datensätze („Describe Spatial Dataset“ bei INSPIRE) beträgt die Zeit bis zur ersten Antwort in einer normalen Situation höchstens 10 Sekunden, dann - ebenfalls in einer normalen Situation - beträgt die ständige Übertragungsrate mehr als 0,5 Megabytes pro Sekunde oder mehr als 500 Beschreibungen von Geo-Objekten pro Sekun-de.
Mit einer „normalen Situation“ ist hierbei ein Zeitraum ohne Spitzenbelastung gemeint. Eine normale Situation ist 90 % der Zeit gegeben.
2.8.2 Kapazität
Als „Kapazität“ wird die Höchstmenge gleichzeitiger Anfragen, die ein Dienst in einem defi-nierten Zeitraum unter Einhaltung der oben definierten Leistungsparameter bearbeiten kann, bezeichnet.
Pro Sekunde müssen mindestens 10 Anfragen an einen WFS gleichzeitig bearbeitet wer-den können. Die Zahl der gleichzeitig bearbeiteten Anfragen kann auf 50 beschränkt wer-den.
2.8.3 Verfügbarkeit
Die „Verfügbarkeit“ ist die Wahrscheinlichkeit, dass der WFS zur Verfügung steht.
Die Verfügbarkeit des Dienstes muss 99% betragen. Die Gesamtzeit bezieht sich auf den Zeitraum eines Kalenderjahres (365 Tage x 24 Stunden). D. h. der Dienst darf im Jahr ins-gesamt nur maximal 87,6 Stunden nicht verfügbar sein.
28 WFS-Leitfaden
2.9 Test
Es wird empfohlen, den WFS vor der Bereitstellung in der GDI-BY hinsichtlich der im vorlie-genden Dokument genannten Vorgaben bzw. im Falle einer zusätzlichen fachlichen Spezi-fikation hinsichtlich dieser Spezifikation zu testen. Anhang E beinhaltet einen Vorschlag zur Vorgehensweise beim Test.
WFS-Leitfaden 29
Quellenverzeichnis
Normen, Standards und Spezifikationen [INSPIRE TG DS] Technical Guidance for the implementation of INSPIRE Download Services, Version 3.1. URL:
http://inspire.jrc.ec.europa.eu/documents/Network_Services/Technical_Guidance_Download_Services_v3.1.pdf (abgerufen am 18.09.2013).
[INSPIRE VO ND] 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. URL: http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CONSLEG:2009R0976:20101228:DE:PDF (abge-rufen am 18.09.2013).
[OGC FE 1.0.0] Filter Encoding Implementation Specification. Version: 1.0.0 (OGC 02-059). URL: http://portal.opengeospatial.org/files/?artifact_id=1171 (abgerufen am 03.09.2013).
[OGC FE 1.1.0] OpenGIS Filter Encoding Implementation Specification. Version: 1.1.0 Corrigendum (OGC 04-095c1). URL: https://portal.opengeospatial.org/files/?artifact_id=51130 (abgerufen am 03.09.2013).
[OGC FE 2.0.0] OpenGIS Filter Encoding 2.0 Encoding Standard. Version: 2.0.0 (OGC 09-026r1). URL: http://portal.opengeospatial.org/files/?artifact_id=39968 (abgerufen am 03.09.2013).
[OGC GML 2.1.1] OpenGIS Geography Markup Language (GML) Implementation Specification. Version 2.1.1 (OGC 02-009). URL: http://portal.opengeospatial.org/files/?artifact_id=1108 (abgerufen am 03.09.2013).
[OGC GML 3.1.1] OpenGIS Geography Markup Language (GML) Implementation Specification. Version 3.1.1 (OGC 03-105r1). URL: http://portal.opengeospatial.org/files/?artifact_id=4700 (abgerufen am 03.09.2013).
[OGC GML 3.2.1] OpenGIS Geography Markup Language (GML) Encoding Standard. Version 3.2.1 (OGC 07-036). URL: http://portal.opengeospatial.org/files/?artifact_id=20509 (abgerufen am 03.09.2013).
[OGC OWS 0.3.0] OWS Common Implementation Specification. Version 0.3.0 (OGC 04-016r3).
[OGC OWS 1.1.0] OGC Web Service Common Implementation Specification. Version 1.1.0 (OGC 06-121-r3). URL: http://portal.opengeospatial.org/files/?artifact_id=20040 (abgerufen am 03.09.2013).
[OGC SF 2.0] Geography Markup Language (GML) simple features profile (with Corrigendum). Version 2.0 (OGC 10-100r3). URL: http://portal.opengeospatial.org/files/?artifact_id=42729 (abgerufen am 03.09.2013).
[OGC WFS 1.0.0] Web Feature Service Implementation Specification. Version 1.0.0 (OGC 02-058). URL: http://portal.opengeospatial.org/files/?artifact_id=7176 (abgerufen am 03.09.2013).
[OGC WFS 1.1.0] Web Feature Service Implementation Specification. Version 1.1.0 (OGC 04-094). URL: http://portal.opengeospatial.org/files/?artifact_id=8339 (abgerufen am 03.09.2013).
[OGC WFS 2.0.0] OpenGIS Web Feature Service 2.0 Interface Standard. Version 2.0.0 (OGC 09-025r1). URL: http://portal.opengeospatial.org/files/?artifact_id=39967 (abgerufen am 03.09.2013).
Literatur [GDI-DE DLS 2013] Arbeitskreis Geodienste der GDI-DE (Hrsg.): Handlungsempfehlungen für die Bereitstellung von
INSPIRE konformen Downloaddiensten. Version 1.1. Frankfurt, 2013. URL: http://www.geoportal.de/SharedDocs/Downloads/DE/GDI-DE/Handlungsempfehlungen_Inspire_Downloadservices1_1.pdf?__blob=publicationFile (abgerufen am 18.09.2013).
[Weichand 2013] Weichand, Jürgen: Entwicklung und Anwendung von Downloaddiensten im Kontext der europäi-schen Geodateninfrastruktur INSPIRE. Masterarbeit, Hochschule Anhalt, 2013. URL: http://www.weichand.de/masterarbeit-inspire-downloaddienste/ (abgerufen am 18.09.2013).
30 WFS-Leitfaden
Anhang
A Abkürzungsverzeichnis
Abkürzung Erklärung
AdV Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder der Bundesrepublik Deutschland
CRS Coordinate Reference System
CSW OpenGIS Catalogue Service
EPSG European Petroleum Survey Group
FES Filter Encoding Standard
GDI Geodateninfrastruktur
GML Geography Markup Language
HTML Hypertext Markup Language
INSPIRE Infrastructure for Spatial Information in Europe
ISO Internationale Organisation für Normung
OGC Open Geospatial Consortium
OWS OGC Web Service Common
SRS Spatial Reference System
UTM Universal Transverse Mercator
URL Uniform Resource Locator
WFS Web Feature Service
XML Extensible Markup Language
Anhang B 31
B Beispiel: Spezifikation WFS Hauskoordinaten Bayern
Das folgende Beispiel dient als Anhaltspunkt, welche technischen und fachlichen Aspekte mindestens in einer Spezifikation festgehalten werden sollten.
B.1 Angaben zum Dienst
Der WFS auf die Hauskoordinaten hat folgende Eigenschaften:
1. URL des Dienstes: https://www.geodaten.bayern.de/wfs/ogc_hauskoordinaten.cgi?
2. Bei dem WFS handelt es sich um einen Simple Feature WFS, d. h. das zugrunde liegende Da-tenmodell ist ein einfaches Datenmodell.
3. Der Dienst unterstützt die Konformitätsklasse Basic WFS
4. Der Dienst unterstützt die Versionen 2.0.0, 1.1.0 und 1.0.0
5. Es werden daher folgende Operationen unterstützt: a. GetCapabilities (alle Versionen), b. DescribeFeatureType (alle Versionen), c. GetFeature (alle Versionen), d. GetPropertyValue (Version 2.0.0), e. ListStoredQueries (Version 2.0.0) f. DescribeStoredQueries (Version 2.0.0)
6. Der Dienst soll die Anforderungen der INSPIRE Umsetzungsvariante Direct WFS der Technical Guidance 3.0 erfüllen, d. h. es müssen mindestens folgende Filter-Konformitätsklassen unter-stützt werden: a. Ad hoc Query b. Resource Identification c. Minimum Standard Filter d. Minimum Spatial Filter e. Minimum Spatial Filter f. Minimum Temporal Filter g. Minimum XPath
7. Folgende Koordinatensysteme werden durch den Dienst angeboten: a. urn:ogc:def:crs:EPSG::31468 (GK 4) (default) b. urn:ogc:def:crs:EPSG::31467 (GK 3) c. urn:ogc:def:crs:EPSG::25832 (ETRS89/UTM32) Deutschland-Profil d. urn:ogc:def:crs:EPSG::25833 (ETRS89/UTM33) Deutschland-Profil e. urn:ogc:def:crs:EPSG::4258 (ETRS89) erforderlich für INSPIRE
8. Ausgabeformate für die Operationen: Es werden alle Ausgabeformate, die vom WFS-Server bereitgestellt werden können, unterstützt.
9. Der Dienst steht flächendeckend für ganz Bayern zur Verfügung (Boundingbox für Bayern).
10. Der Namensraum wird folgendermaßen definiert: a. Präfix: bvv b. URL des Namensraumes: http://www.geodaten.bayern.de
Die Erstellung des Capabilities-Dokuments erfolgt aufgrund der definierten Konfiguration serverseitig. Ei-ne nachträgliche technische Anpassung ist nicht vorgesehen.
32 Anhang B
B.2 Konfiguration der FeatureTypes (Datenmodell)
B.2.1 FeatureTypes
Namensraum Name* <wfs:Name> Bezeichnung <wfs:Title>
bvv: Hauskoordinaten Hauskoordinaten Bayern (BY)
B.2.2 Datenmodell
FeatureType - Attribut
Datentyp Beschreibung Kardi-nalität
Beispiel
FeatureType: Hauskoordinaten
nba string Kennung des Datensatzes (bei Differenzdaten rele-vant)
1 N
oid string Objektidentifikator 1 DEBYv00087004546
qua string Qualität der georefenzier-ten Gebäudeadresse
1 A
lan string Schlüssel Bundesland 1 09
lanText string Name des Bundeslands 1 Bayern
rbz string Schlüssel Regierungsbezirk 1 1
rbzText string Name des Regierungsbe-zirks
1 Oberbayern
krs string Schlüssel Kreis/kreisfreie Stadt
1 75
krsText string Name des Landkreises/ der kreisfreien Stadt
1 Ebersberg
gmd string Schlüssel Gemeinde 1 128
gmdText string Name der Gemeinde 1 Moosach
ott string Schlüssel des Orts- bzw. Gemeindeteils
1 0001
ottText string Name des Orts- bzw. Ge-meindeteils
1 Moosach
sss string Schlüssel der Straße 1 00000
hnr string Hausnummer 1 9
adz string Adressierungszusatz 0..1 a
stn string Unverschlüsselter Straßen-name
1 Bahnhofstraße
plz string Postleitzahl 0..1 85665
onm string Postalischer Ortsname 0..1 Moosach
zon string Zusatz zum postalischen Ortsnamen
0..1 Grafing b München
Anhang B 33
pot string Postalischer Ortsteil 0..1 Moosach
geometry gml:PointPropertyType
Position der georefenzier-ten Gebäudeadresse
1
B.2.3 Konfiguration der Capabilities
B.2.3.1 Allgemeine Angaben (section ServiceIdentification)
Angaben zum Service
XML-Tag Bitte befüllen …
Titel des Dienstes <ows:Title> Hauskoordinaten Bayern
Beschreibung des Dienstes*
<ows:Abstract> Der WFS auf die Hauskoordinaten übermittelt die Komplettdatensätze der rund 3,3 Mio. georeferenzier-ten Gebäudeadressen in Bayern. Das durch den Dienst übermittelte Datenmodell orientiert sich an der deutschlandweiten Datenformatbeschreibung Hausko-ordinaten, Version 3.0 (siehe http://vermessung.bayern.de/file/pdf/5060/HNR_Formatbeschreibung_Deutschland.pdf) und beinhaltet die dort beschriebenen Attribute. Die Daten sind in den Koordinatenreferenzsystemen EPSG:31468 (GK4), EPSG:31467 (GK3), EPSG:25832 (ERTS89/UTM32), EPSG:25833 (ETRS89/UTM33) und EPSG:4258 (ETRS89) verfügbar.
Liste von Schlüs-selwörtern, die den Dienst beschreiben
<ows:Keyword> in <ows:Keywords>
• Adresse • Gebäudeadresse • georeferenziert • Hauskoordinate • Postalische Adresse • Hausnummer
Art des Dienstes <ows:ServiceType> WFS
Version des Diens-tes
<ows:ServiceTypeVersion>
2.0.0 1.1.0 1.0.0
Gebühren <ows:Fees> Es gilt die Gebührenordnung der Bayerischen Vermes-sungsverwaltung, siehe http://www.gesetze-bay-ern.de/jportal/portal/page/bsbayprod.psml?showdoccase=1&doc.id=jlr-VermGebOBY2006rahmen&doc.part=X
Nutzungsbe-schränkungen
<ows:AccessConstraints>
Es gelten die Nutzungsbedingungen der Bayerischen Vermessungsverwaltung, siehe https://geoportal.bayern.de/geodatenonline/pdf/Nutzungsbedingungen.pdf
34 Anhang B
B.2.3.2 Kontaktinformationen (section ServiceProvider)
Angaben zum Dienstan-bieter
XML-Tag Bitte befüllen …
Dienstanbieter <ows:ProviderName> Landesamt für Vermessung und Geoinformation
Website des Datenanbie-ters
<ows:ProviderSite xlink:href=…>
Kontaktinformationen zum Dienstanbieter
<ows:ServiceContact>
Ansprechpartner <ows:IndividualName>
Ansprechpartner
Abteilung / Position <ows:PositionName>
Kontaktinformationen <ows:ContactInfo>
Telefonnummer <ows:Voice> in <ows:Phone>
+49 89 2129 1111
Fax-Nummer <ows:Facsimile> in <ows:Phone>
+49 89 2129 1113
Straße <ows:DeliveryPoint> in <ows:Address>
Alexandrastraße 4
Stadt <ows:City> in <ows:Address>
München
Bundesland <ows:AdministrativeArea> in <ows:Address>
DE-BY
Postleitzahl <ows:PostalCode> in <ows:Address>
80538
Land <ows:Country> in <ows:Address>
DE
E-Mail <ows:ElectronicMailAddress> in <ows:Address>
URL zum Datenanbiter <ows:OnlineResource xlink:href=>
http://www.geodaten.bayern.de
Erreichbarkeit <ows:HoursOfService>
Mo. – Do. 8 – 16 Uhr und Fr. 8 – 14 Uhr
Hinweise <ows:ContactInstructions>
Bei Fragen zu den Geodaten und -diensten der Bayerischen Vermessungsverwaltung können Sie uns während der Sprechzeiten anrufen. Unsere Mitarbeiterinnen und Mitarbeiter beraten Sie gern.
Anhang B 35
Angaben zum Dienstan-bieter
XML-Tag Bitte befüllen …
Rolle <Role> PointOfContact
B.2.3.3 Informationen zu Operationen und Konformitätsklassen (section OperationsMetadata)
Die Parameter und Bedingungen der section OperationMetadata werden durch den WFS-Server eingetragen. Hierbei sollen die Mindestanforderungen von INSPIRE erfüllt werden.
B.2.3.4 Beschreibungen der FeatureTypes (section FeatureTypeList)
FeatureType: Hauskoordinaten
Angaben zum FeatureType XML-Tag Bitte befüllen …
Name des FeatureType <Name> bvv:Hauskoordinaten
Titel des FeatureType <Title> Hauskoordinaten Bayern (BY)
Beschreibung des Feature-Types*
<Abstract> Die Objektklasse beinhaltet alle georeferenzierten Gebäudeadressen in Bayern. Jedes Objekt enthält die Attribute gemäß der Datenformatbeschreibung Hauskoordinaten Deutschland Version 3.0 (siehe http://vermessung.bayern.de/file/pdf/5060/HNR_Formatbeschreibung_Deutschland.pdf). Die unter 1.2 ge-nannte Entschlüsselungsdatei, die zur Entschlüsse-lung des Gemeidekennzeichens (Attribute lan, rbz, krs, gmd, ott) benötigt wird, wird durch zusätzliche At-tribute im Datensatz in das Datenmodell integriert.
Liste von Schlüsselwörtern <ows:Keyword> in <ows:Keywords>
Hausnummer, Hauskoordinate, Straße, Postleitzahl, Gemeinde, Adresse
Anmerkung: Weitere Pflichteinträge in den Capabilities werden durch den WFS-Server erstellt.
36 Anhang B
B.2.3.5 Filter
Die Parameter und Bedingungen der section fes:Filter_Capabilities werden durch den WFS-Server eingetragen.
B.2.3.6 Erweiterte Capabilites für INSPIRE Downloaddienste
Für INSPIRE werden folgende erweiterte Capabilities beötigt: • Verlinkung eines Metadatensatzes • Standard-Sprache • Weitere unterstützte Sprachen • Antwort-Sprache
B.2.4 Konfiguration von Stored Queries
Beispiele hierfür können Anhang C entnommen werden.
Anhang C 37
C Beispiele für Stored Queries
Im Folgenden werden zwei Beispiele für Stored Queries anhand ihrer Spezifikation sowie den Antworten (XML-Dokumente), die beim Aufruf der Operationen DescribeStoredQueries zurückgeliefert werden, vorgestellt.
Beispiel 1: Stored Query, die den Abruf aller Hauskoordinaten zu einer bestimmten Postleitzahl und in einem bestimmten Koordinatensystem ermöglicht.
Für die Postleitzahl und das Koordinatensystem werden hierbei Variablen definiert, die der Nutzer dann beim Aufruf der Stored Query mit konkreten Werten befüllen kann.
Spezifikation:
Angaben zu StoredQueries
XML-Tag Bitte befüllen …
ListStoredQueriesResponse
ID der Stored Query <wfs:StoredQuery id=>
urn:bvv:def:query:OGC-WFS::HauskoordinatenAnhandPostleitzahlUndCrs
Titel der Stored Query <wfs:Title xml:lang="de">
HauskoordinatenAnhandPostleitzahlUndCrs
Auswahl der zurückzulie-fernden FeatureTypes
<wfs:returnFeatureType>
bvv:Hauskoordinaten
DescribeStoredQueriesResponse
ID der Stored Query <wfs:StoredQueryDescription id=>
urn:bvv:def:query:OGC-WFS::HauskoordinatenAnhandPostleitzahlUndCrs
Titel der Stored Query <wfs:Title xml:lang="de">
HauskoordinatenAnhandPostleitzahlUndCrs
Kurzbeschreibung <wfs:Abstract xml:lang="de">
Laden Sie alle Hauskoordinaten in einen be-stimmten Koordinatensystem (GK3, GK4, ETRS89/UTM32, ETRS89/UTM33, ETRS89) in einem bestimmten Postleitzahlenbereich.
Ausfüllbare Parameter <wfs:Parameter> <wfs:Parameter name=“Postleitzahl“ type=“string“>
<wfs:Parameter name=“CRS“ type=“string“> <wfs:Abstract>Mögliche Eingabewerte: EPSG:31468 (GK4), EPSG:31467 (GK3), EPSG:25832 (ETRS89/UTM32), EPSG:25833 (ETRS89/UTM33) und EPSG:4258 (ETRS89)</wfs:Abstract>
Angaben zur Abfrage <wfs:QueryExpression • Request:
38 Anhang C
Text> - srsName=Parameter „CRS“ - Parameter „Postleitzahl“ filtert nach At-tribut „plz“
• Response: Ergebnis der Abfrage sind alle Hauskoordinaten in einem bestimmten Postleitzahlenbereich im gewählten Koor-dinatensystem
DescribeStoredQueries Antwort (XML) <?xml version="1.0" encoding="UTF-8"?> <DescribeStoredQueriesResponse xmlns="http://www.opengis.net/wfs/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/wfs/2.0 http://schemas.opengis.net/wfs/2.0/wfs.xsd">
<StoredQueryDescription id="urn:bvv:def:query:OGC-WFS::HauskoordinatenAnhandPostleitzahlUndCrs">
<Title>HauskoordinatenAnhandPostleitzahlUndCrs</Title> <Abstract>Laden Sie alle Hauskoordinaten in einen bestimmten Koordinatensystem (GK3, GK4, ETRS89/UTM32, ETRS89/UTM33, ETRS89) in einem bestimmten Postleitzah-lenbereich.</Abstract> <Parameter xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="Postleitzahl" type="xsd:string"/> <Parameter xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="CRS" type="xsd:string"/> <QueryExpressionText xmlns:bvv="http://www.geodaten.bayern.de" returnFeature-Types="bvv:Hauskoordinaten" language="urn:ogc:def:queryLanguage:OGC-WFS::WFS_QueryExpression"/>
</StoredQueryDescription> </DescribeStoredQueriesResponse>
Anhang C 39
Beispiel 2: in Kapitel 2.5 angesprochene Stored Query für INSPIRE-Downloaddienste
Hierbei sind für die Parameter Koordinatenreferenzsystem („CRS“), Datensatz-ID (unter „DataSetIdCode“ und „DataSetIdNamespace“) und Sprache („Language“) Variablen defi-niert, die der Nutzer beim Aufruf der Stored Query mit konkreten Werten befüllen kann.
Spezifikation:
Angaben zu StoredQueries
XML-Tag Bitte befüllen …
ListStoredQueriesResponse
ID der Stored Query <wfs:StoredQuery id=>
http://inspire.ec.europa.eu/operation/download/GetSpatialDataset
Titel der Stored Query <wfs:Title xml:lang="de">
InspireGetSpatialDataset
Auswahl der zurückzulie-fernden FeatureTypes
<wfs:returnFeatureType>
Alle FeatureTypes
DescribeStoredQueriesResponse
ID der Stored Query <wfs:StoredQueryDescription id=>
http://inspire.ec.europa.eu/operation/download/GetSpatialDataset
Titel der Stored Query <wfs:Title xml:lang="de">
InspireGetSpatialDataset
Kurzbeschreibung <wfs:Abstract xml:lang="de">
Wählen Sie einen kompletten Datensatz an-hand der Datensatz-ID, des Koordinatensys-tems und der Sprache aus.
Angaben zu den wählbaren Parametern
<wfs:Parameter> <wfs:Parameter name=“DataSetIdCode“ type=“string“>
<wfs:Parameter name=“DataSetIdNamespace“ type=“string“>
<wfs:Parameter name=“CRS“ type=“string“>
<wfs:Parameter name=“Language“ type=“string“>
Angaben zur Abfrage <wfs:QueryExpressionText>
• Request: - UND-Verknüpfung der vier Eingabepara-meter „DataSetIdCode“, „DataSetIdName-space“, „CRS“ und „Language“
• Response: Ergebnis ist der Datensatz mit der gewählten Datensatz-ID, wobei die Ausgabe im gewählten Koordinatensystem und der gewählten Sprache erfolgt. Der WFS unterstützt keine Mehrsprachigkeit, daher ist die Ausgabe immer deutsch.
40 Anhang C
DescribeStoredQueries Antwort (XML) <?xml version="1.0" encoding="UTF-8"?> <DescribeStoredQueriesResponse xmlns="http://www.opengis.net/wfs/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/wfs/2.0 http://schemas.opengis.net/wfs/2.0/wfs.xsd">
<StoredQueryDescription id="http://inspire.ec.europa.eu/operation/download/GetSpatialDataset">
<Title>InspireGetSpatialDataset</Title> <Abstract>Wählen Sie einen kompletten Datensatz anhand der Datensatz-ID, des Ko-ordinatensystems und der Sprache aus.</Abstract> <Parameter xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="DataSetIdCode" type="xsd:string"/> <Parameter xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="DataSetIdNamespace" type="xsd:string"/> <Parameter xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="CRS" type="xsd:string"/> <Parameter xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="Language" type="xsd:string"/> <QueryExpressionText xmlns:bvv="http://www.geodaten.bayern.de" returnFeature-Types="bvv:Hauskoordinaten" language="urn:ogc:def:queryLanguage:OGC-WFS::WFS_QueryExpression"/>
</StoredQueryDescription> </DescribeStoredQueriesResponse>
Anhang C 41
D Beispiele für Capabilities-Dokumente
Capabilities-Dokumente des in Anhang B spezifizierten WFS Hauskoordinaten Bayern in den drei verschiedenen Versionen des WFS-Standards sind unter folgenden Links zugäng-lich:
WFS 2.0.0: http://www.geodaten.bayern.de/oadownload/Capabilities_Bsp_Hauskoordinaten_2.0.0.xml
WFS 1.1.0: http://www.geodaten.bayern.de/oadownload/Capabilities_Bsp_Hauskoordinaten_1.1.0.xml
WFS 1.0.0: http://www.geodaten.bayern.de/oadownload/Capabilities_Bsp_Hauskoordinaten_1.0.0.xml
Hinweis: der WFS Hauskoordinaten ist zugangsgeschützt.
42 Anhang E
E Testvorgehen
E.1 Testwerkzeuge
Zum Testen des Dienstes können folgende Testwerkzeuge eingesetzt werden:
Die Konformität zum WFS-Standard kann mit der vom OGC bereitgestellten „Test, Eva-luation, And Measurement (TEAM) Engine“ (http://cite.opengeospatial.org/teamengine/) überprüft werden. Hinweis: Bisher (Stand Oktober 2013) stehen hier Tests für die WFS-Versionen 1.0.0 und 1.1.1 zur Verfügung. Der Test für die Version 2.0.0 wird voraussichtlich Ende 2013 veröffentlicht.
Eine Erweiterung der von der GDI-DE bereitgestellten Testsuite (http://testsuite.gdi-de.org/gdi/) im Hinblick auf Downloaddienste ist derzeit in Planung. Damit kann zukünf-tig die INSPIRE-Konformität eines Dienstes getestet werden.
Verschiedene Clients (Desktop- und Web-GIS), in die die Dienste eingebunden werden können (eine Aufstellung kostenfreier Software ist unter http://www.gdi.bayern.de/Geoanwendungen.html abrufbar). Hinweis: von den dort aufgeführten Clients können WFS in der Version 2.0 bisher nur bei Quantum GIS eingebunden werden (Plugin „WFS 2.0 Client“).
Internet-Browser GET- und POST-Abfragen können mit der Firefox-Erweiterung
HttpRequester abgesetzt werden. Zur übersichtlichen Visualisierung der Capabilities steht der
Capabilities-Viewer zur Verfügung: http://www.geoportal.bayern.de/getcapabilities/
E.2 Testszenarien
Grundsätzlich ist zu testen:
Lässt sich der Dienst in verschiedene Clients einbinden, die die entsprechende Version des OGC-WFS-Standards unterstützen?
Führen an den Dienst gestellte Abfragen zu den erwarteten Ergebnissen? Sind die Daten vollständig und korrekt?
Hinweis: Sofern der Dienst in mehreren WFS-Versionen abrufbar ist, sollten die Tests für alle diese Versionen durchgeführt werden. Die folgenden Testszenarien basieren auf dem WFS in der Version 2.0.0.
INSPIRE-spezifische Anforderungen sind in den folgenden Testszenarien mit einem oran-gen Balken hervor gehoben.
Anhang E 43
E.2.1 Inhalte des Capabilities-Dokuments
Überprüfung des Inhalts des Capabilities-Dokuments, das als Antwort auf eine GetCapabi-lities-Anfrage vom Dienst zurückgeliefert wird.
Nr. Was ist zu testen Testszenario Testergebnis
1 • Allgemeine Angaben
• Kontaktinformationen
• FeatureTypes
• unterstützte Operationen
• INSPIRE-spezifische Anforderungen
Nutzung des Capabilities-Viewers
Vorgaben aus der Spezifikation müssen eingehalten werden
E.2.2 Funktionalitäten (Operationen und Funktionen)
Test der Operationen:
Nr. Was ist zu testen Testszenario Testergebnis
2 GetCapabilities Ist nicht separat zu testen - Test erfolgt unter Nr. 1 (Inhalte des Capabilities-Dokuments)
Siehe Nr.1
3 DescribeFeatureType 1. Aufruf im Browser
2. Aufruf des Datenmodells für ein/mehrere ausgewählte Fea-tureTypes mittels des Parame-ters „typeName“
1. Alle verfügbaren Feature-Types müssen beschrieben sein
2. Beschreibung wird nur für die ausgewählten Feature-Types zurückgeliefert
4 GetFeature Ist nicht separat zu testen - Test erfolgt unter „Test der Funktio-nen“
Siehe „Test der Funktionen“
5 GetPropertyValue Aufruf im Browser Zurückgeliefertes Attribut ist korrekt
6 ListStoredQueries
Aufruf im Browser Liste der verfügbaren Stored Queries und die Angaben zu den einzelnen Stored Queries müssen mit der Spezifikation übereinstimmen
7 DescribeStoredQueries Aufruf im Browser Angaben zu den einzelnen Stored Queries müssen mit der Spezifikation übereinstim-men
44 Anhang E Test der Funktionen:
Nr. Was ist zu testen Testszenario Testergebnis
8 FeatureTypes Einbindung in einen Client Alle in der Spezifikation ange-gebenen FeatureTypes sind verfügbar und werden korrekt angezeigt
9 FeatureType-Attribute Einbindung in einen Client und Prüfung der Attribute aller ver-fügbaren FeatureTypes
Attribute müssen mit der Spe-zifikation übereinstimmen
10 GetFeature-Operation: Ausgabe-formate
Aufruf im Browser Alle im Capabilities-Dokument angegebenen Formate müs-sen unterstützt werden
11 Referenzsysteme: Vollständig-keit
Aufruf im Browser Alle in der Spezifikation ange-gebenen Referenzsysteme müssen unterstützt werden
12 Referenzsysteme: Richtigkeit Einbindung in einen Client und Vergleich mit geeigneten Refe-renzdaten (Daten, WMS)
Datenbestände müssen in der Lage übereinstimmen (kein systematischer Datenversatz)
13 Metadaten-URL (zu den FeatureTypes)
Für jeden FeatureType Ent-nahme der URL aus dem Tag <wfs:MetadataURL> und Aufruf dieser im Browser
Für jeden FeatureType wird ein Daten-Metadatensatz zu-rückgeliefert, der den Feature-Type beschreibt
14 StoredQueries Einbindung in einen Client und Ausführung der Stored Queries
Alle Stored Queries müssen funktionieren
15 Fehlermeldungen Aufruf im Browser mit falschen Parametern
Fehlermeldungen sind ver-ständlich und beziehen sich auf den tatsächlichen Fehler
E.3 Test der Dienstqualität
Die folgenden Empfehlungen zum Test der Leistung, Verfügbarkeit und Kapazität eines Downloaddienstes basieren auf dem Technical Guidance Dokument zu INSPIRE-Downloaddiensten [INSPIRE TG DS].
E.3.1 Leistung und Verfügbarkeit
In der Verordnung für Netzdienste [INSPIRE VO ND] ist die Antwortzeit als Zeitdauer defi-niert, bis am Server des Downloaddienstes das erste Byte der Antwort auf eine Anfrage (z.B. GetFeature) ausgegeben wird, d.h. sie schließt die Übertragungszeit im Netzwerk (zwischen Client und Dienst) nicht mit ein.
Aus praktischen Gründen ist es gemäß [INSPIRE TG DS] trotzdem zulässig, die Antwort-
Anhang E 45
zeit an einem Client (Anwendung), d.h. von einem zentralen Netzwerkknoten innerhalb der GDI aus über das Netzwerk zu messen. In diesem Fall soll die Übertragungszeit im Netz-werk nach der folgenden Formel berücksichtigt werden: Antwortzeit über Netzwerk = Übertragungszeit + Antwortzeit am Dienst Für die Übertragungszeit ist in diesem Fall ein plausibler Wert anzunehmen, der durch ver-gleichende Messungen ermittelt werden soll. Im Zweifelsfall ist für eine Konformitätsaussa-ge jedoch immer die Messung am Dienst ausschlaggebend.
Zum Test der Antwortzeit und Verfügbarkeit eines WFS-Downloaddienstes soll kontinuier-lich alle 6 Minuten ein Anfragepaket an den Downloaddienst gesendet werden, das folgen-dermaßen zusammengesetzt sein soll:
bei einem „Direktzugriffs-Downloaddienst“ der Konformitätsklasse „Basic WFS“ (in Klammern sind die Bezeichnungen der jeweiligen Operation bei INSPIRE angegeben):
− 10% GetCababilities („Get Download Service Metadata“)
− 10% DescribeFeatureType („Describe Spatial Object Type”)
− ≥ 2% GetFeature mit StoredQuery („Get Spatial Dataset”)
− ≤ 78% GetFeature („Get Spatial Object”) mit Parameter BBOX und Beschränkung auf einen FeatureType, wobei empfohlen wird, das das Ergebnis der Abfrage min-destens eine Dateigröße von 1MB hat.
bei einem Dienst der Konformitätsklasse „Simple WFS” zum Download vordefinierter Datensätze:
− 10% GetCababilities („Get Download Service Metadata“)
− 10% GetCapabilities („Get Spatial Dataset“)
− 80% GetFeature mit StoredQuery („Get Spatial Dataset”) zum Download eines vor-definierten Datensatzes.
Bei länger andauernden Anfragen (z. B. „Get Spatial Data Set“) ist es zulässig, die Zeit-spanne zwischen dem Absenden aufeinanderfolgender Abfragen zu verlängern ,d.h. die nächste Anfrage kann bis zu 6 Minuten nach Beendigung der vorherigen gestartet werden.
Bei den Anfragepaketen sollen die Standard-Sprache sowie das Standard-Koordinatenreferenzsystem des Downloaddienstes als Parameter verwendet werden.
Bei einer GetFeature Anfrage darf die Zeit bis zum Senden des ersten Bytes der Antwort 30 Sekunden zzgl. Übertragungszeit nicht überschreiten. Die maximal zulässige Zeitdauer bis zum Senden des letzten Bytes der Antwort (vollständiges Ergebnis der Anfrage) kann unter Ansatz der geforderten Übertragungsrate von 0,5 MB/Sek. oder 500 Objekte/Sek. be-rechnet werden (bei angenommenen 5 Sek. Übertragungszeit beispielsweise 55 Sek. bei 100.000 abgerufenen Objekten).
Unter Berücksichtigung der Tatsache, dass die Antwortzeit von der Anzahl paralleler An-fragen beeinflusst wird, wird empfohlen, zur Ermittlung der Leistung nur die Ergebnisse von den oben beschriebenen Tests zu verwenden, die während Schwachlastzeiten (z.B. wäh-rend Wartungszeiten oder nachts) durchgeführt wurden.
46 Anhang E Geplante Wartungszeiten müssen bei der Messung der Verfügbarkeit nicht berücksichtigt werden. Diese Wartungszeiten müssen mindestens eine Woche im Voraus angekündigt sein (z.B. durch Benachrichtigungen an registrierte Nutzer oder auf Portalen) und sollten in Summe 10 Stunden pro Monat nicht überschreiten.
E.3.2 Kapazität
Die Messung der Kapazität sollte am Dienst selbst erfolgen. Sie soll mindestens einmal vor dem Start des Dienstes in einer Produktionsumgebung erfolgen und dann in regelmäßigen Abständen überwacht werden, um sicherzustellen, dass die Kapazitätsanforderungen ein-gehalten werden. Auch hier wird eine Durchführung der Messung während der Wartungs-zeit oder nachts empfohlen.
Zur Messung sollen eine Minute lang jeweils 10 der unter E.3.1 beschriebenen Anfragepa-kete pro Sekunde an einen definierten „service endpoint“ gestellt werden. Hierbei kann die die Zahl der gleichzeitig bearbeiteten Anfragen auf 50 beschränkt werden.
