WFS 1.1

[Kralidis,Tom [Burlington]]

> is anybody planning on adding WFS 1.1 to Mapserver WFS? GML3 
> is in place, I've verified it can be read by ArcGIS 9.2 as a 
> GML file, so we are missing a large potential market because 
> we don't support WFS 1.1 (ArcGIS only supports WFS 1.1 and not 1.0).
> 
> I am thinking of only adding a 1.1 GetCapabilities interface, 
> not any of the new operations of WFS 1.1. GetFeature for 1.1 
> can default to OUTPUTFORMAT=GML3.
> 

So, based on above, the differences in a MapServer OGC:WFS 1.1.0 impl
would be

GetCapabilities

- response: an OGC:WFS 1.1.0 style Capabilities document.  The big
difference is the OGC OWS Common adherence.  Note that, now that we have
mapowscommon.c, we can leverage this on output, as it supports most of
the constructs already
- do we support the (optional) AcceptFormats, AcceptVersions and
Sections Keywords of this request, which are not covered by WFS 1.0.0?
Note that, if we do, we will want to abstract them to mapowscommon.c, as
this is the MO of forthcoming OGC interface specs
- where possible, MIME types: now have to be communicated as mime_type;
subtype (i.e. <Value>text/xml; subtype=gml/3.1.1</Value>

DescribeFeatureType

- REQUIRES a GML3 output (which we already support)
- output format MIME type: text/xml; subtype=gml/3.1.1 MUST be
supported.  Other additional formats are allowed

GetFeature
- optional SRSNAME parameter now allowed, which allows for one to ask
for data in a given SRS (hence reprojection).  Would be helpful
- optional allow the WFS client to set MAXFEATURES value (which
could/would override the MAP/WEB/METADATA/wfs_maxfeatures, if the value
is LOWER)
- optional allow the WFS client to send SORTBY parameter would be useful
for sorting results on response

Note: this analysis omits OPTIONAL features which I think are not worth
implementing, etc.

Other comments here w.r.t implementation?


> I would be willing to help out with it.
> 
> Anybody interested in helping out?