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

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

Error Code = 80004005
Source = msxml6.dll
Description = /schema/complexType[1][@name = 'CurveType']
Doppelt benanntes <complexType> : Name = '{http://www.opengis.net/gml/3.2}CurveType'. 

<xs:include schemaLocation="gml.xsd"/>
<xs:import namespace="foo" schemaLocation="gml.xsd"/>
<schemaName:el xsi:schemaLocation="schemaName gml.xsd">

...
<xs:import namespace="http://www.opengis.net/gml/3.2" schemaLocation="http://schemas.opengis.net/gml/3.2.1/gml.xsd"/>

...
<xs:import namespace="http://www.opengis.net/gml/3.2" schemaLocation="../../../../gml/3.2.1/gml.xsd"/>

Wir haben unter Fixes von Problemen der Dienstanbieter einen Workaround beschrieben, der evtl. zum Ergebnis führen kann.