WebFeatureService/de: Unterschied zwischen den Versionen
Tschug (Diskussion | Beiträge) K |
Tschug (Diskussion | Beiträge) K |
||
| Zeile 258: | Zeile 258: | ||
<ul> |
<ul> |
||
| − | <li> |
+ | <li> [//{{SERVERNAME}}/app-article/geobasisdatenuebersicht/ Übersicht über die opendata Geobasisdienste des LVGL]</li> |
| − | <li> OGC WFS Beschreibung und Downloadlink des Standards |
+ | <li> [https://www.ogc.org/standards/wfs/ OGC WFS Beschreibung und Downloadlink des Standards]</li> |
| − | <li> |
+ | <li> [https://www.ogc.org/standards/filter/ OGC Filter Encoding Standard]</li> |
| − | <li> |
+ | <li> [http://www.qgis.org/de/site/ QGIS Website]</li> |
| − | <li> |
+ | <li> [https://www.qgis.org/resources/hub/ QGIS Dokumentationen]</li> |
| − | <li> |
+ | <li> [http://www.qgistutorials.com/de/ QGIS Anleitungen]</li> |
| + | <li> [https://wiki.gdi-de.org/spaces/insp/pages/1165492229/Kurzanleitungen+QGIS+f%C3%BCr+INSPIRE Kurzanleitung: QGIS für INSPIRE]</li> |
||
</ul> |
</ul> |
||
Aktuelle Version vom 6. Mai 2025, 09:11 Uhr
Einführung
Funktionsweise eines Geodatendienstes
Abbildung 1: Funktionsweise eines Geodatendienstes
Geodatendienste sind Webservices, die den Austausch von Geodaten über standardisierte Schnittstellen ermöglichen. Sie sind dadurch interoperabel in unterschiedlichen Softwareanwendungen nutzbar. Erreichbar ist ein Geodatendienst über eine Internetadresse (URL), die den Dienst eindeutig identifiziert. Geodaten lassen sich abrufen, in dem der Nutzer eine Anfrage (Request) an den Diensteserver stellt. Dieser greift wiederum auf die Datengrundlage zu und liefert die Daten (Response) in dem angefragten Datenformat zurück an den Nutzer (Abb. 1). Der Request muss verschiedene (Pflicht-) Parameter enthalten, die dem Diensteserver beispielsweise mitteilen, welcher Layer, Kartenausschnitt oder welches Datenformat ausgegeben werden soll. Für den Zugriff auf Geodatendienste können Geoportale oder geographische Informationssysteme (GIS) genutzt werden.
Die Nutzung von Diensten bietet eine Reihe von Vorteilen, wie die Möglichkeit, auf den jeweils aktuellen Datenbestand zuzugreifen. Der Nutzer kann Geodaten, die an verschiedenen Orten und in unterschiedlichen Datenformaten gehalten werden, abrufen. Die Kombination verschiedener Datenquellen ist ebenfalls möglich.
Es lassen sich verschiedene Typen von Geodatendiensten unterscheiden. Es gibt u. a. Download- und Darstellungsdienste. Zu den Darstellungsdiensten gehören beispielsweise der Web Map Service (WMS) oder der Web Map Tile Service (WMTS), die Geodaten visualisieren. Der Web Feature Service (WFS) und der Web Coverage Service (WCS) zählen hingegen zu den Downloaddiensten, die das direkte Herunterladen der Geodaten unterstützen. Dabei handelt es sich um Raster- oder Vektordaten, die für die lokale Weiterverarbeitung auf dem Rechner gespeichert werden können. Dabei bleibt die volle Semantik der Daten erhalten.
Was ist ein Web Feature Service (WFS)?
Ein Web Feature Service (WFS) definiert eine durch das Open Geospatial Consortium (OGC) standardisierte Schnittstelle, die den Zugriff auf Geoobjekte, sogenannte „Features“ ermöglicht. Dabei handelt es sich in der Regel um räumliche Vektordaten (z. B. Punkt-, Linien- und Flächengeometrien) mit Sachinformationen. Ein WFS liefert diese Features im Allgemeinen in der Geography Markup Language (GML), einer XML-basierten Sprache zum Austausch von Geoobjekten, zurück. Diese kann von geographischen Informationssystemen verarbeitet werden und dient als Austauschformat für Geodaten über das Internet.
Der WFS bietet dem Nutzer verschiedene Operationen an, um die gewünschten Daten zurückzuliefern (Abb. 2):
Abbildung 2: Grundlagen Web Feature Service
Per HTTP (Hypertext Transfer Protocol) kann über GET- und POST-Anfragen mit dem Diensteserver kommuniziert werden. Werden Kartendienste in einem GIS oder einem Onlineportal/Onlineviewer genutzt, so übernehmen diese Komponenten die Kommunikation mit dem Server. Steht kein GIS oder Viewer zur Verfügung, so kann der WFS auch über einen üblichen Browser angesprochen werden.
Diese verschiedenen Möglichkeiten werden im nächsten Kapitel beschrieben.
Wie kann ich einen WFS nutzen?
Dem Nutzer stehen verschiedene Möglichkeiten zur Verfügung, um einen WFS anzufragen:
- Web-Browser (z.B. Mozilla Firefox, Edge oder Chrome)
- Desktop-Geoinformationssystem (GIS)
Während die erste Möglichkeit ein Vorwissen über Geodatendienste erfordert, gestaltet sich die Einsichtnahme über ein GIS bzw. eine Internet-Anwendung zur Verarbeitung von Geodaten meist einfacher.
In Kapitel 2 werden die Abfrageoptionen eines WFS beschrieben. Mit Hilfe der dort erläuterten Parameter kann der Nutzer selbstständig einen WFS über einen Web-Browser anfragen. Diese Art der Anfrage ist komplex, allerdings sind keine weiteren technischen Hilfsmittel erforderlich.
Die Nutzung eines WFS über ein Desktop-Geoinformationssystem, wie zum Beispiel QGIS und die damit einhergehenden Vor- und Nachteile, werden in Kapitel 3 beschrieben.
Bisher ist der GDI-SL keine Web-Applikation bekannt, die WFS darstellen oder verarbeiten kann.
Abfrageoperationen eines WFS
Dieses Kapitel beschreibt die verschiedenen Abfrageoptionen eines WFS sowie die entsprechenden Requests, die an den Server gestellt werden müssen. Dieses Wissen ist erforderlich, um die Funktionsweise eines WFS zu verstehen und erfolgreiche Anfragen an einen WFS über einen Web-Browser zu stellen.
GetCapabilities
Mit Hilfe der GetCapabilities-Operation, welche von allen OGC-Web Services unterstützt wird, können die Fähigkeiten und Metadaten des Dienstes abgefragt werden.
Der Aufruf setzt sich aus folgenden Parametern zusammen:
| Erforderlich/Optional | Beschreibung | |
|---|---|---|
| VERSION / ACCEPTVERSIONS |
Optional | WFS-Version der Anfrage. (Aktuell: 2.0.0) VERSION wird ab der Version 2.0.0 genutzt. Ältere WFS-Versionen verwenden ACCEPTVERSIONS. |
| SERVICE | Erforderlich | Service-Typ. Hier: WFS. |
| REQUEST | Erforderlich | Name der Operation. Hier: GetCapabilities |
Beispiel:
Der WFS der vereinfachten ALKIS Daten im Saarland hat folgende Adresse:
https://geoportal.saarland.de/arcgis/services/Internet/Schutzgebiete_INS/MapServer/WFSServer
Diese Adresse muss um die entsprechenden Parameter ergänzt werden. Sie wird durch ein „?“ vom restlichen Request getrennt. Die einzelnen Parameter werden durch ein „&“ verbunden.
Ein gültiger GetCapabilties-Aufruf sieht dann wie folgt aus:
Die Capabilities werden in Form eines XML-Dokumentes zurückgeliefert. Dieses kann entweder im Browser oder in einem Text-Editor angezeigt werden. Die Capabilities enthalten alle relevanten Informationen, um einen Dienst anzufragen. Neben allgemeinen Angaben zum Dienst, wie Kurzbeschreibung, Ansprechpartner und Nutzungsbedingungen, finden sich hier auch technische Details des Dienstes. Sie geben u. a. einen Überblick über die verfügbaren Abfrageformate, die Bezeichnung der einzelnen Feature Types oder unterstützte Koordinatenreferenzsysteme. Diese Informationen sind erforderlich, um eine gültige DescribeFeatureType- oder GetFeature-Anfrage zu stellen.
DescribeFeatureType
Mit der Operation „DescribeFeatureType“ lässt sich die Struktur eines konkreten Feature Types abfragen. Ähnlich wie bei der Capabilities-Abfrage wird die Adresse des Dienstes um einige Parameter erweitert:
| Erforderlich/Optional | Beschreibung | |
|---|---|---|
| VERSION / ACCEPTVERSIONS |
Erforderlich | WFS-Version der Anfrage. (Aktuell: 2.0.0) VERSION wird ab der Version 2.0.0 genutzt. Ältere WFS-Versionen verwenden ACCEPTVERSIONS. |
| SERVICE | Erforderlich | Service-Typ. Hier: WFS. |
| REQUEST | Erforderlich | Name der Operation. Hier: DescribeFeatureType. |
| TYPENAMES | Optional | Name keines, eines oder mehrerer Feature Types, für das eine Beschreibung abgefragt werden soll. |
| OUTPUTFORMAT | Optional | Ausgabeformat der Beschreibung. (Standard: application/gml+xml version=3.2) |
Ein gültiger DescribeFeatureType-Aufruf sieht wie folgt aus:
Die Antwort der DescribeFeatureType-Anfrage wird, wie die Capabilities, als XML-Dokument zurückgeliefert. Sie enthält unter anderem Angaben zu dem XML-Schema des angefragten Feature Types sowie zu den Attributen und deren Datentyp. Mit diesen Informationen ist es möglich, die GetFeature-Anfrage um einen Filterausdruck zu erweitern und somit eine ausgewählte Teilmenge aller verfügbaren Objekte abzufragen.
GetFeature
Die Operation „GetFeature“ ermöglicht den Zugriff auf die Daten. Eine Auswahl gängiger Parameter ist in nachfolgender Tabelle aufgeführt.
| Erforderlich/Optional | Beschreibung | |
|---|---|---|
| VERSION / ACCEPTVERSIONS |
Erforderlich | WFS-Version der Anfrage. (Aktuell: 2.0.0) VERSION wird ab der Version 2.0.0 genutzt. Ältere WFS-Versionen verwenden ACCEPTVERSIONS. |
| SERVICE | Erforderlich | Service-Typ. Hier: WFS. |
| REQUEST | Erforderlich | Name der Operation. Hier: GetFeature. |
| TYPENAMES | Erforderlich | Name eines oder mehrerer Feature Types, von dem Objekte abgefragt werden. |
| OUTPUTFORMAT | Optional | Ausgabeformat der Ergebnisliste. (Standard: application/gml+xml version=3.2) |
| COUNT | Optional | Anzahl der Features in der Ergebnisliste. |
| BBOX | Optional | Begrenzendes Rechteck, um Features innerhalb einer BoundingBox abzufragen. |
| RESULTTYPE | Optional | Art der Rückgabe. Auflistung der Features oder Anzahl der Features (results/hits). |
| FILTER | Optional | Filterausdruck, um die Feature- Ausgabe nach bestimmten Kriterien einzuschränken. (Gemäß Filter Encoding Standard 2.0) |
| NAMESPACES | Optional | Eindeutige Zuordnung eines Feature Types zu einem Namespace. In der Form: xmlns(prefix,escaped_url).
Bsp.: NAMESPACES=xmlns(adv,http://www.adv-online.de/namespaces/adv/gid/6.0). |
Ein gültiger GetFeature-Aufruf sieht wie folgt aus:
Mit dieser Anfrage werden alle Objekte des Feature Types Naturschutzgebiet (alle Naturschutzgebiete des Saarlandes) als GML-Datei ausgegeben. Hierbei wird der gesamte Datenbestand angefordert, was je nach übertragener Datenmenge zu langen Antwortzeiten führen kann. Das Ergebnis der Anfrage entspricht einem Vektordatensatz, der z. B. als GML-Datei abgespeichert und in Geographischen Informationssystemen verarbeitet werden kann.
Durch die Verwendung von Filterausdrücken bzw. Filterparametern lässt sich das Ergebnis einer GetFeature-Anfrage gezielt einschränken.
Der WFS 2.0 Standard unterscheidet dabei zwei Arten von Abfragen, sogenannte „Queries“.
Die Abfragemethode „Adhoc Query“, die auch ältere WFS-Versionen unterstützen und die seit der WFS-Version 2.0 definierte Abfrage „Stored Query“. Bei der Adhoc Query werden die Filterausdrücke gemäß Filter Encoding Standard vom Nutzer formuliert und als Request an den Diensteserver übertragen. Stored Queries bieten dem Datenanbieter die Möglichkeit, aufwendige Abfragen zu definieren und diese serverseitig abzuspeichern. In diesem Fall kann der Nutzer auf ausgewählte Features zugreifen und muss dafür keine eigenen, zum Teil komplexen Filterdefinitionen erstellen.
Beispiele Adhoc Query:
In dem folgenden Beispiel wird der GetFeature-Request über den Parameter „BBOX“ eingeschränkt. Es werden 17 Naturschutzgebiete im Saarland abgerufen, die innerhalb der angegebenen BoundingBox liegen oder diese schneiden:
Die zurückgelieferten Features im GML-Format können in ein geographisches Informationssystem eingeladen werden (Abb.3).
Abbildung 3: Eingeladener Datensatz in QGIS (die BoundingBox gehört nicht zum eingeladenen Datensatz und dient zur Veranschaulichung)
Mit bestimmten Filterausdrücken gemäß „Filter Encoding Standard 2.0“ kann die Ausgabe der Objekte entsprechend einer Bedingung eingeschränkt werden. In dem folgenden Beispiel wird das Naturschutzgebiet abgerufen, dessen Name („NAME“) dem Wert „Ellbachtal“ entspricht.
https://geoportal.saarland.de/arcgis/services/Internet/Schutzgebiete_INS/MapServer/WFSServer?VERSION=2.0.0&SERVICE=WFS&REQUEST=GetFeature&TYPENAMES=Naturschutzgebiet&FILTER=<Filter><PropertyIsEqualTo><ValueReference>NAME</ValueReference><Literal>Ellbachtal</Literal></PropertyIsEqualTo></Filter>
bekomme den Link nur auf diese beide Weisen hin! Falls jemand eine andere Möglichkeit hat, kann er sie gerne sagen.
Bei einer GetFeature-Anfrage sind gemäß WFS-Standard Namespaces anzugeben. Die WFS-Namespace-Eigenschaft wird zur Unterscheidung von XML-Element-Namen verwendet. Diese werden von einigen Diensteservern automatisch ausgefüllt, so dass wie im Beispiel des WFS Schutzgebiete_INS auf die Angabe der Namespaces im Request verzichtet werden kann. Ein gültiger GetFeature-Request mit Angabe der Namespaces sieht wie folgt aus:
hier bräuchte ich evtl. ein anderes Beispiel. Anfrage geht auch ohne Namespace!
In diesem Beispiel werden alle Flurstücke des WFS SL ALKIS Vereinfacht (vereinfachtes Schema) abgerufen. Über den Parameter „COUNT“ ist die Ausgabe auf 10 Features begrenzt.
Neben dem Parameter „COUNT“ lässt sich die Ausgabe der Flurstücke auch wieder durch einen Filterausdruck einschränken. In diesem Beispiel sind auch die Namensräume des Filters mit angegeben:
hier bräuchte ich ein Beispiel!
Es werden nur die Flurstücke abgerufen, die komplett innerhalb des angegebenen Bereichs liegen. Dieser Bereich wird durch ein Polygon definiert.
Beispiele Stored Query:
Stored Queries sind vordefinierte Abfragen, um ausgewählte Features abzurufen. In dem folgenden Beispiel wird ein Flurstück mit der ID „DESLALKI4R000Dvb“ angefragt und dafür die Stored Query „GetFeatureById“ genutzt.
hier bräuchte ich ein funktionierendes Beispiel!
WFS können auch mehrere Stored Queries unterstützen. Dabei kann eine Stored Query selbst definierte Parameter („Platzhalter“) enthalten, die bei jeder Anfrage mit einem individuellen Wert belegt werden. Folgendes Beispiel fragt einen WFS über eine Stored Query mit dem Titel „???“ an. Diese Stored Query enthält die zwei Parameter „AreaOfInterest“ und „CRS“. Diese müssen für einen gültigen Request bei der Anfrage mit übergeben werden. In folgendem Beispiel wird das gesuchte Gebiet (AreaOfInterest) über ein Polygon in GML definiert und für das Koordinatenreferenzsystem (CRS), in dem die Koordinaten des Polygons vorliegen, der entsprechende EPSG-Code übergeben.
hier bräuchte ich ein Beispiel!
Der Request erfragt alle Flächen, Linien und alle Objektarten des ATKIS-Basis-DLM, die zum Thema Verkehr gehören und die sich räumlich mit gegebener Geometrie überschneiden. Die Operationen ListStoredQueries und DescribeStoredQueries listen alle vordefinierten Anfragen auf und geben Informationen über den Aufbau der Stored Queries sowie über die Platzhalter und deren Datentypen. Auf diese Optionen wird hier nicht näher eingegangen.
Beispiel „Paging“:
Anfragen an den WFS lassen sich auch indexiert ohne Bounding Box stellen. Diese Anfragen sind immer dann sinnvoll, wenn alle Features der gesamten Landesfläche abgefragt werden sollen, um diese herunterzuladen. Viele WFS lassen nur eine bestimmte Anzahl an Features zu, die mit einem Aufruf heruntergeladen werden können. Selbst wenn dies nicht der Fall sein sollte, ist es sinnvoll bei einem Paging-Aufruf die Anzahl der Features zu begrenzen, um mögliche Timeouts aufgrund von zu vielen Features, die mit einem Request abgefragt werden müssen, zu verhindern. Beim Paging wird der Parameter „BBOX“, der die Bounding Box definiert, weggelassen. Hinzu kommen dafür die Parameter „STARTINDEX“ und „COUNT“. Der Startindex definiert die ID des Features, bei dem die Abfrage begonnen werden soll. Das erste Feature besitzt immer die ID 0. COUNT definiert die maximale Anzahl an Features, die mit einem Aufruf abgefragt werden sollen. Ein valider, indexierter Aufruf von Flurstücken des ALKIS würde demnach folgendermaßen aussehen:
https://geoportal.saarland.de/registry/wfs/414?VERSION=2.0.0&SERVICE=WFS&REQUEST=GetFeature&TYPENAMES=ALKIS_ALKIS_WFS_ohne_Eig:Flurstueck&STARTINDEX=0&COUNT=1000&SRSNAME=urn:ogc:def:crs:EPSG::25832&OUTPUTFORMAT=application/gml+xml version=3.2&NAMESPACES=xmlns(ave,http://repository.gdi-de.org/schemas/adv/produkt/alkis-vereinfacht/2.0)
hier bräuchte ich ein funktionierendes Beispiel!
Um die nächsten 1000 Features herunterzuladen, muss der Startindex auf „1000“ geändert werden. Auf diese Weise sind Abfragen ohne Doppelungen möglich.
Verwendung eines WFS in QGIS
Eine Hilfe zu diesem Thema finden Sie hier.
