Standards Compliance

Implemented Standards

This project implements WFS 2.0 Simple, Basic and POST conformance classes.

  • All operations for the WFS Basic conformance class are implemented.

  • The CITE Test Suite passes.

  • You should be able to view the WFS server QGis.

  • The unit tests validate the output against WFS 2.0 XSD schema.

Unimplemented Classes

The following additional conformance classes are not implemented:

  • WFS-Transactional support (<wfs:Transaction>).

  • Locking on updates: LockFeature, GetFeatureWithLock.

  • Managing stored queries (<wfs:CreateStoredQuery> / DropStoredQuery).

  • Temporal filtering (<fes:After>, <fes:Before>, <fes:During>, etc..).

  • JOIN queries, which involves queries with multiple feature types for standard, spatial or temporal joins.

  • Feature/resource versioning.

  • SOAP requests.

  • Transactional-safe pagination.

Any missing request types can be implemented on top of the existing POST parsing code (see Overriding Server Logic).

Finally, these optional bits are not implemented, nor really needed:

  • The GetCapabilities parameters acceptFormats and sections.

  • Remote resolving using resolveDepth and resolveTimeout.

Hopefully

While WMS and WMTS are not on the roadmap, they could be implemented based on Mapnik. Other Python tiling logic such as TileCache and TileStache could serve as inspiration too.

Low-Prio Items

Anything outside WFS-T could be implemented, but is very low on the todo-list:

  • The methods for the WFS locking and inheritance conformance classes.

  • SOAP requests.

  • Other OGS protocols such as WCS

  • Other output formats (shapefile, KML, GML 3.1) - but easy to add.

Some parts (such as output formats or missing WFS methods) can even be implemented within your own project, by overriding the existing class attributes.

Compatibility with older WFS-clients

Some popular WFS-clients still use aspects of the WFS 1.0 filter syntax in their queries. To support these clients, the following logic is also implemented:

Filter Logic

  • The <PropertyName> tag instead of <fes:ValueReference>

  • The <fes:Add>, <fes:Sub>, <fes:Mul> and <fes:Div> arithmetic operators, used by QGis.

  • The FILTER=<Filter>...</Filter> parameter without an XML namespace declaration, typically seen in web-browser libraries.

  • The MAXFEATURES parameter instead of COUNT.

  • The TYPENAME parameter instead of TYPENAMES (used by the CITE test suite!).

  • Using A and D as sort direction in SORTBY / <fes:SortBy> instead of ASC and DESC.

Coordinate Transformations

When an old syntax for coordinate transformation is used, the output will be rendered in legacy longitude/latitude ordering. It’s mostly old JavaScript-based clients that use this.

This can be disabled with the GISSERVER_FORCE_XY_… settings.

When enabled, this applies to the SRSNAME=EPSG:4326 parameter for projected output, and the BBOX=... parameter / <fes:BBOX> filter for coordinate input.

The modern recommended notations urn:ogc:def:crs:EPSG::4326 and http://www.opengis.net/def/crs/epsg/0/4326, used by modern GIS-software, will always render in the proper latitude/longitude ordering. GeoJSON however, will always render in CRS84 longitude/latitude as the standard dictates.

Content Types

The FME (Feature Manipulation Engine) software sent OUTPUTFORMAT=application/gml+xml; version=3.2 to all methods, including GetCapabilities and DescribeFeatureType. These are also silently accepted.

CITE Testing

For CITE test suite compliance, urn:ogc:def:query:OGC-WFS::GetFeatureById query returns an HTTP 404 for an invalid resource ID format, even though the WFS 2 specification states it should return an InvalidParameterValue. Likewise, the <ResourceId> query returns an empty list instead of InvalidParameterValue for invalid resource ID formats. This behavior can be disabled with the GISSERVER_WFS_STRICT_STANDARD setting.