OGC WFS
Ermöglicht den Zugriff auf OGC konforme WFS Dienste (Web Feature Services) in den Versionen 2.0, 1.1 und 1.0.
Abfragen mittels GeoSQL sind möglich.
Beim Laden einer solchen Ebene wird intern pro Feature ein eigener Layer zurückgegeben. Der Layername setzt sich dabei aus dem angegeben für diese Ebene und dem Feature Typename wie vom Dienst angegeben zusammen. Als Trennzeichen zwischen Layername und Featurename wird ein Punkt verwendet.
Bei unseren älteren Komponenten war der Zugriff eher lax gestaltet. Inzwischen haben sich die Standards aber doch mehr etabliert, so dass wir in der neuen Version auf jegliche Workarounds verzichten (wollen) und dringend empfehlen im Problemfall gegebenenfalls mit dem Dienstbetreiber Kontakt aufzunehmen um evtl. Ungereimtheiten an der Quelle zu beheben. Hierin sehen wir auch unseren Beitrag zu mehr Konformität bei den Standards beizutragen.
Der Parameter "loadErrorBehavior" wird ausgewertet. Bei "Lax" werden einige Probleme mit Namespaces ignoriert (bei Strict wird der Ladevorgang mit entsprechender Fehlermeldung abgebrochen).
Ein Filter, wie aus WFS Iwan6 Ebenen bekannt, kann nicht angegeben werden.
Für das Mapping der aus dem XSD Schema ermittelten Datentypen finden Sie hier eine Auflistung der unterstützten Elemente eine Auflistung der Typen.
Argumente
Typname: WFS
url: Die Endpunkt Url zu dem Dienst, alle OGC Parameter werden intern automatisch angefügt, unbekannte Parameter und Version werden beibehalten
layers (""): optionale Liste (kommagetrennt) der Features die aus dem WFS Dienst verwendet werden sollen. Es kann ein Namespace-Prefix pro Feature angegeben werden, werden keine Features angegeben, werden alle vom Dienst angebotenen eingebunden
serverUser (""): optionaler Benutzername für die Anmeldung am Dienst
serverPwd (""): wenn serverUser angegeben ist, dann muss ein Kennwort übergeben werden, leere Kennwörter sind nicht zulässig
proxyUri (""): optionale Url zu einem Http-Proxyserver z.B. http://proxy:8888
proxyUser(""): optionaler Benutzername für die Anmeldung am proxyUri
proxyPwd(""): wenn proxyUser angegeben ist, dann muss ein Kennwort übergeben werden, leere Kennwörter sind nicht zulässig
proxyBypassList (null): optionale Bypass-Liste, wenn ein Proxyserver eingestellt ist (bei WFS vor allem für Trennung der XSD Zugriffe relevant)
timeoutMilliseconds (30000): Http-Timeout für die Zugriffe auf den Dienst
useDefaultProxy (false): Standard-Proxy des Betriebssystems verwenden
allowServiceMetadataCaching (true): Zugriff auf GetCapabilities / Schemata cachen und wiederverwenden
axisOrder (): Legt die Interpretation der Achsen-Reihenfolge in der Antwort-GML Dateien fest, wenn nicht angegeben, dann je nach WFS das was der "Standard" vorgibt. Mgl. Werte sind:
- AxisOrderByEpsg: das ist das, was dem Standard entspricht
- AxisOrderByEpsgUrnOnly: wie AxisOrderByEpsg, aber nur dann, wenn die urn:... Schreibweise verwendet wird,
- AxisOrderXY : immer in der Reihenfolge X/Y interpretieren,
- AxisOrderYX: immer in der Reihenfolge Y/X interpretieren
requestAxisOrder (): wenn angegeben, dann die Achsen-Reihenfolge bei Geometrien die, bspw. in einem Filter, an den Server übergeben werden, wenn nicht definiert, dann wird der Wert aus axisOrder mit verwendet.
includeBaseElements(): weitere Spalten aus GML oder WFS-Namespace
chunkRecordCount() : Hiermit kann das featureCount Limit des Dienstes unterschritten werden, dies ist der Wert der pro Request abgeforderten Daten, 0 nimmt die Einstellungen, wie der Dienst dies definiert. Normalerweise sollte Sie diesen Wert nicht angegeben.
importSchemaOnce(true): wenn true, dann beim Auswerten der XSDs pro xsd:import nur der 1. dort importierten XSD weiter folgen, erneue Import für den gleichen Namespace ignorieren.
Sonderform:
Neben WFS gibt es noch die Quelle WFSOneFeatureType. Diese entspricht exakt dem WFS Typ, mit der Ausnahme, dass hier immer genau ein Featuretyp die Quelle bildet. Der Layername entspricht dem angeforderten, die Generierung von Sublayern etc. erfolgt dabei nicht.
Typname: WFSOneFeatureType
featureTypeName: der Feature-Typename (evtl. vorhandenes Prefix wird ignoriert) dieser Ebene
filter (): definiert einen Filter, der bei allen Anfragen an diesen WFS Dienst mit gesetzt wird. Der Filter kann in der Syntax analog der CSS Condition oder Zeichenfilter übergeben werden.
Bsp.:
OBJECT ID == 1 OR Name == "Test"
. Weitere Informationen...includeBaseElements(): weitere Spalten aus GML oder WFS-Namespace
Die Argumente serverPwd und proxyPwd können auch verschlüsselt angegeben werden.
includeBaseElements
Ermöglicht die Angabe einer kommagetrennte Liste von Feldern, die aus den vererbten Attributen eines GML Features mit verwendet werden.
Die Namespaces können dabei mit xmlns:prefx=uri
vorbelegt werden.
Vordefinierte Prefix:
- gml32 : http://www.opengis.net/gml/3.2
- wfs20 : http://www.opengis.net/wfs/2.0.
Bsp.:
"includeBaseElements":"xmlns:gml=http://www.opengis.net/gml/3.1,gml:name"
"includeBaseElements":"gml23:name,gml23:description"
oder hier, Redefinition als Text Datentyp mit Länge von 255 Zeichen (Beachte: da muss dann auch das XML Element direkt ein Text sein)
"includeBaseElements":"gml32:location as text(255),gml32:name as text",
Praktisch funktioniert dies allerdings so gut wie nicht, da einige Dienste die Attributate auf die Basis-Typen abbilden, aber die Struktur wir dabei ignoriert. Location bspw. wir dann als Text ausgeliefert, obwohl dies vom Typ her nicht passt. Die Folge ist dann ein Fehler beim Datenabruf.
Ladevorgang
Der Zugriff auf einen Dienst läuft immer in dieser Form ab:
- Abrufen des GetCapabilities-Dokumentes, Aushandeln der Version (2.0 wird bevorzugt)
- Ermitteln der verfügbaren Feature-Types, der Endpunktdefinitionen der Methoden und der ggf. vorhandenen Service und Operation Constraints. Bei den Endpunkten wird immer POST per XML bevorzugt.
- Abrufen der Datenschema via DescribeFeatureType inkl. aller referenzierten Schema. Der Schema-Abruf kann u.U. einen Moment dauern ...
- Aufbau der Datenstruktur gemäß der Schema-Definition. Die für Features geerbten Attribute werden dabei ignoriert (hier muss eindeutig Kritik am Standard geübt werden, siehe auch includeBaseElements)
- Die Datentypen werden gemäß der Schema übersetzt bereitgestellt
- Die gml:id (bzw. gml:fid) wird immer als Spalte mit dem Namen wfs_gml_Feature_Id bereitgestellt
Beispiel
{
"WfsDienst": {
"type": "WFS",
"url":"http://wfs.service/thema"
}
}
Bsp. mit Proxy, Abruf der "üblichen" Xsd ohne Proxy
{
"WfsDienst": {
"type": "WFS",
"url":"http://wfs.service/thema",
"proxyUri":"http://localhost:8888",
"proxyBypassList":".*/www.w3.org/.*;.*/schemas.opengis.net/.*"
}
}
Implementierungsdetails / Features und Einschränkungen
Per Default werden die GetCapabilities und vor allem die Schemas zwischengespeichert (derzeit für eine Dauer von maximal 20 Minuten), so dass bei Lade-Vorgängen auf die gleiche Quelle (Endpunkt-Url, Server-Login name und Proxy-Loginname) der Abruf der Schema entfallen kann.
Wird beim Laden für allowServiceMetadataCaching false übergeben, dann werden die Einträge zu der Ressource aus dem Cache entfernt und die Informationen werden neu abgerufen.
Seit Version 7.0.6.560 werden die beteiligten XSD Schemas (das sind ~40 Stück pro Dienst) mit einem neuen Verfahren abgerufen. Dabei werden auch die Proxy-Einstellungen beachtet und die Einzel-Xsd von den Quellen www.w3.org/ und schemas.opengis.net/ werden Prozess weit zwischengespeichert.
Wird keine Version in der Url mit übergeben (empfohlen), wird die höchste Versionsnummer des Dienstes verwendet. I.d.R. sollte das WFS Version 2 sein.
(Meine) Meinung zu den WFS Diensten
Leider müssen wir feststellen, dass es viele unklare Punkte im Standard, bzw. in den Implementierungen gibt.
das Elend mit der Axis-Order...
Es gibt u.E. nach keine eindeutige Definition, wie und unter welchen Umständen die XY oder YX Variante bei der Herausgabe der Geometriedaten implementiert wird. Wir haben pro Epsg die Achsen-Reihenfolge hinterlegt (ist in der epsg-registry definiert) und werten dies entsprechend aus. Nun gibt es einige Dienste, die mit der Schreibweise hantieren (mal urn::...., oder urn-x). Oder man wälzt das Problem auf den Nutzer ab, wo dann vorzugeben ist ob der Request oder der Response XY oder YX ist. Wobei ... dann bei allen CRS oder nur bei bestimmten?
Im Netz finden sich recht widersprüchliche Aussagen dazu, keine der Varianten funktioniert in jedem Fall. Die Einstellung dem Nutzer zu überlassen, der es auch nur durch probieren herausbekommt, sehen wir kritisch.
Update: Seit Dez. 2018 haben wir uns dem gefügt ...
das andere Elend mit dem ResultCount...
Manche Dienste definieren ein Limit was die maximale Anzahl der pro Request gelieferten Features definiert. Dumm nur, wenn dies in den GetCapabilities nicht (korrekt) ausgegeben wird. Erschwerend kommt hinzu, dass scheinbar viele Dienste das Paging nicht lt. WFS 2.0 Standard implementiert haben. So ist es fast ein Glücksspiel, ob man wirklich alle Daten bekommt. Auch dieser Punkt ist kritisch zu sehen, vor allem im Hinblick auf ggf. stattfindenden Auswertungen dieser Daten. Es ist nicht in jedem Fall klar, ob keine Daten vorhanden sind oder ob der Dienst die Anzahl still und heimlich reduziert hat.
Mit Http Streaming besteht eigentlich auch überhaupt kein Grund Limits zu verwenden (wenn da nun nicht wieder die Proxy-Server ins Spiel kämen...)
Bitte beachten Sie diese Ausführungen bei der Verwendung von WFS Diensten.
Die Meldung: Das XSD Schema "xyz" ist ungültig.
meist in Verbindung mit der Meldung ....
Error Code = 80004005
Source = msxml6.dll
Description = /schema/complexType[1][@name = 'CurveType']
Doppelt benanntes <complexType> : Name = '{http://www.opengis.net/gml/3.2}CurveType'.
Mit der neuen Standard-Option "importSchemaOnce" (ab Version 7.6.8.4) kann dieses Problem umgangen werden.
Allerdings kann es dabei neue Probleme geben, wenn der 1. Import des Namespaces auf ein Schema zeigt, welches nicht alle benötigten Typen inkludiert. Das ist bspw. bei einigen WFS Diensten von 'https://www.geodaten-mv.de/dienste/inspire_cp_alkis_download' der Fall.
Hier ist das Problem, dass der Dienstanbieter in den Schemas die in DescribeFeatureType geliefert wird durch ein Folge von xsd:import oder schemaLocation oder xsd:include Angaben gemischte Inhalte liefert.
Das dort etwas mit Error Code = 80004005 und Source = msxml6.dll steht, liegt nur an der verwendeten Komponente, nicht an "Windows", sollte der Dienstanbieter mit "Das ist ne Windows-Fehlermeldung - geht uns nichs an" antworte, dann verweisen Sie gerne auf diese Seite :)
Beim Laden eines XSD Schemas werden alle weiteren Schema die referenziert sind betrachtet. Iwan7 erstellt dazu eine Liste aller beteiligten Urls und lädt diese.
Für die Referenzierung gibt es dazu verschiedene Möglichkeiten, die der XML Standard vorsieht:
<xs:include schemaLocation="gml.xsd"/>
<xs:import namespace="foo" schemaLocation="gml.xsd"/>
<schemaName:el xsi:schemaLocation="schemaName gml.xsd">
Wenn nun ein Schema, nehmen wir als Beispiel einfach wahllos die Datei "measures.xsd", importiert wird und diese einmal von der Quelle "http://meinDienstanbieter/schemas/measures.xsd" und einmal von "http://schemas.opengis.net/gml/3.2.1/measures.xsd" referenziert wird, dann tritt ein Fehler wie oben genannt auf, da festgestellt wird das der Typ "LengthType" im Namespace "http://www.opengis.net/gml/3.2" sowohl in der Datei aus Quelle A und Quelle B definiert wird.
Diesen Konflikt kann das System nicht lösen, da es einfach keine Definition gibt, welche der beiden Typdefinitionen denn nun die richtige ist.
Im Ergebnis gibt es diese Fehlermeldung und der Ladevorgang wird abgebrochen.
Wir haben in Version 4.5.5.2 integriert, dass zusätzlich noch der Inhalt (MD5 des geparsten XML-Content) beachtet wird. Der Effekt zur Lösung dieses Fehler ist aber faktisch 0, da tatsächlich bei allen Stichprobentest Unterschiede in den gelieferten XSDs enthalten sind.
Dies unterstreicht die "Richtigkeit der Fehlermeldung", da verschiedene Versionen der Datei vorliegen.
Der Dienstanbieter muss sich des Problems annehmen und die Definition korrigieren.
TIPP: Es wird oft wahllos eine Kopie der XSD Schemas von opengis.net erstellt und auf dem lokalen Server abgelegt. Dabei wird nicht beachtet, dass die meisten der Schemas für Referenzen auf andere Schema absolute URL Angaben enthalten. Entweder auf die Kopie verzichten und gleich alle Quellen von opengis.net beziehen, oder, mit entsprechendem Sachverstand, die Inhalte der kopierten Schema anpassen.
Hier wieder ein wahllos herausgegriffenes Beispiel: Die Datei "htt\p://schemas.opengis.net/iso/19139/20070417/gco/basicTypes.xsd":
Diese importiert hier "gml.xsd" als absolute Url:
...
<xs:import namespace="http://www.opengis.net/gml/3.2" schemaLocation="http://schemas.opengis.net/gml/3.2.1/gml.xsd"/>
Bei einer Kopie der gesamten schemas.opengis.net müsste diese Angabe dann zu einer relativen Url angepasst werden:
...
<xs:import namespace="http://www.opengis.net/gml/3.2" schemaLocation="../../../../gml/3.2.1/gml.xsd"/>
Möglicher Workaround
Wir haben unter Fixes von Problemen der Dienstanbieter einen Workaround beschrieben, der evtl. zum Ergebnis führen kann.
Zuletzt geändert: 19.09.2024 15:39:22 (erstmals erstellt 16.03.2017) // Alias: "iwan7WFSOneFeatureType"