WFS 1.1.0 support

[assefa]

General bug to trac/discuss support of WFS 1.1.0

[tomkralidis]

Initial notes:

• WFS 1.1.0 implements Filter 1.1.0 (trac'd in #2111). Filter 1.1.0 will be a big part of supporting WFS 1.1.0, IMHO
• WFS 1.1.0 implements OWS Common 1.0.0 (which we support, so we can leverage here)
• We'll have to revisit approaches to optimizing output of GetFeature requests if we use the libxml2 approach instead of msIO_printf. I believe an approach has been discussed but not implemented
• parsing XML POST; use CPL or libxml2? I've used libxml2 for SOS and it works pretty well

[assefa]

I saw the part of wcs 1.1 implementation is done in wcs11.c. I like the idea of separating part of this development in two separate files (specifically those parts dealing with ows and libxml). I would like to use the same approach and create a mapwfs11.c. I am not sure though that using 11 is the best idea.

[tomkralidis]

Sounds good. What's the issue with '11'?

[assefa]

I though maybe that we may end up using the same file for 1.2 if there is no major change.

[tomkralidis]

Depends. What's our strategy here? Do we push each version to a new file (that could get hefty). Which level in version numbering do we declare a new file is needed (i.e. mapwcs11.c has both 1.1.0 and 1.1.1 support). Frank's mapwcs11.c uses some of mapwcs.c code for some of the operations.

Or do we have one big mapwfs.c?

I've cc'd Frank and Steve, as I think we're beginning to see a "next generation" of OGC standards which uses OWS Common, and the underlying supporting standards (SLD, FES), which has resulted in, for MapServer, 1./ new functionality 2./ new "common" approaches. In other words, this issue will hit most, if not all, of the OGC stuff in our codebase.

Oh, and just wait until you see the joint ISO/OGC WFS Committee Draft (WFS 2.0, I believe), which won't be on the street for quite awhile -- lotsa fun!

[warmerdam]

I would note, I setup a wcs11 file because the 1.1 implementation was almost completely distinct from the 1.0 implementation because of dramatic changes in the protocol, and the move to using the libxml for WCS 1.1 (due mainly to the OWS common sharing).

So I think a new file makes sense when it is allmost all new impelmentation, but that we should aim to keep versions together when the changes are less dramatic.

I would hope that WCS 1.2 will be implemented in mapwcs11.c.

[assefa]

Tom,

My comments about the "11" naming was only to indicate that we will probably use the same mapwfs11.c for next upgrades such as wfs 1.2 if there are no major changes. I don't think we would have a new file per ogc release unless there is a compelling reason.

[assefa]

added wfs11.c : support for getcapabilities and describefeature

[sdlime]

You mean mapwfs11.c I assume. Is you work on WFS 1.1 preserving the various GML metadata configuration I put in place for WFS 1.0? That affects the GML output but also the metadata production.

Steve

[tomkralidis]

Replying to assefa:

added wfs11.c : support for getcapabilities and describefeature

Assefa: I checked the GetCapabilities output and fixed wfs:Keywords to be ows:Keywords. The output now validates (see r7479).

As well, I added wfs:MetadataURL support (as we already support this for 1.0.0)

[assefa]

Replying to sdlime:

You mean mapwfs11.c I assume. Is you work on WFS 1.1 preserving the various GML metadata configuration I put in place for WFS 1.0? That affects the GML output but also the metadata production.

Steve

I have not looked yet at specifics regarding the GetFeature support but the intention is to preserve what we have now. I will update this bug regarding any issues that I see.

[assefa]

Assefa: I checked the GetCapabilities output and fixed wfs:Keywords to be ows:Keywords. The output now validates (see r7479).

As well, I added wfs:MetadataURL support (as we already support this for 1.0.0)

Thanks Tom.

[sdlime]

Assefa: For completeness, those changes also affect describeFeature (e.g. if you rename some field then the schema should also reflect that change).

Steve

[assefa]

Steve,

Looking into the wfs getfeature/decribefeaturetype, we do not generate a wfs:featurecollection container but rather ms:msFeatureCollection (by default). Is there a reason why we should not generate a wfs collection for wfs1.1 support?

[sdlime]

I don't recall the reason, perhaps Tom can refresh my memory as he helped with validation issues during that period. I believe it had to do with some circuitous XML schema imports that caused a problem returning GML 3 with WFS 1.0. There is some discussion in section 5.1.3 in this document:

​http://maps.dnr.state.mn.us/mapserver_docs/wfs_tutorial/index.html

Perhaps WFS has removed this limitation and a different default makes sense. I think it still makes sense to retain the existing level of configurability though.

Steve

[assefa]

The support was added. Will open new bugs for any specific issues.