In this group issues regarding the use of the GML application schemas are discussed.

| Share
Group discussion > Annex I Schemas - GML 3.2.1 with WFS ?

Annex I Schemas - GML 3.2.1 with WFS ?

Just
2766 days ago

Hi All,

On behalf of the Dutch Kadaster and in the context of EURADIN/ESDIN we are working on an INSPIRE WFS using PostGIS/Deegree (later on also GeoServer2). One of the standards-issues is that the Annex I v3.0 theme app schemas are defined using GML 3.2.1. AFAIK this requires WFS 2.0 which is still in draft within ISO (
ISO/DIS 19142). WFS 1.1 only supports up to GML 3.1.1 I think. Also I do not know of any FOSS GML 3.2.1/WFS 2.0 implementation.  I am wondering if other implementors/products have run into this issue and how they are solving this. We currently use XSLT filters with Deegree to transform from GML 3.1.1 to 3.2.1 and v.v.

best,

Just van den Broecke

Permalink

Clemens Portele
2764 days ago

Hi Just,

WFS 1.1 does support GML 3.2, it just requires that the service also supports GML 3.1, too. The only part where GML 3.1 is mandatory are the queries, i.e. the spatial predicates in the GetFeature requests are always in GML 3.1 for a WFS of version 1.1. But the data may be encoded in any format as long as the WFS is able to return GML 3.1 (the default encoding), too.

The client selects the version (GML 3.1 or GML 3.2) using the MIME type in the request. (It may also request other encodings like KML, GeoJSON, GML 2.1, CSV, etc, if they are supported by the WFS.)

This approach is fully conformant with the standards and what we have done whenever we have set up WFS instances requiring support for GML 3.2 with our XtraServer product.

Best regards,

Clemens Portele

Permalink

Just
2764 days ago

Hi Clemens,

Thanks! Good to hear this from the GML guru Smile

best regards,

Just van den Broecke

Permalink

Simon Cox
2717 days ago

What do you use for the container element? wfs2:FeatureCollection?

Permalink

Just
2717 days ago

Hi Simon,

This is a very good question. We use WFS 1.1.0 with a GML 3.2.1 response as a wfs:featureCollection which is an extension of gml:AbstractFeatureCollectionType. I was already wondering if this is not in conflict with WFS 1.1.0 standard. Maybe Clemens can again shed some light on this... Here is an example GetFeature response of our current response for Addresses (AD): WFS GetFeature Response for INSPIRE Addresses (AD) Theme

best,

Just van den Broecke

Permalink

Clemens Portele
2717 days ago

 

WFS 1.1 only mandates the root element (<FeatureCollection> from the WFS 1.1 schema) for cases where the outputFormat requested is GML 3.1.1 (although the wording could be clearer!). 

I.e. for other outputFormat values, incuding GML 3.2.1, this is unspecified and can be anything, e.g.

- a <SpatialDataSet> from the INSPIRE Base Types schema

- a <FeatureCollection> from GML 3.2 (deprecated)

- a <FeatureCollection> from WFS 2.0

- etc

Permalink

Ben Caradoc-Davies
2716 days ago

Thanks, Clemens, that makes sense. I am starting to get the feeling that a WFS 2.0 FeatureCollection might be the most interoperable container to use for a GML 3.2 response.

Just, I was surprised to read that you are using a WFS 1.1 FeatureCollection to contain your GML 3.2 response, as GML 3.2 feature types will not be in the correct substitution group to be contained in a WFS 1.1 FeatureCollection (the substitution groups are in different GML namespaces).

Looking at your sample response I see that you are using a modified copy of WFS 1.1 that has been translated/ported from GML 3.1 to GML 3.2:

http://schemas.kademo.nl/ogc/wfs/1.1.0-gml3.2.1/wfs.xsd

This differs from WFS 1.1, and explains why your response is schema-valid. This is an interesting approach, but I wonder if it is interoperable?

  1. Would you expect WFS 1.1 clients unaware of your custom WFS 1.1 / GML 3.2 to be able to consume these responses?
  2. Is the WFS 1.1 / GML 3.2 port an OGC standard/best-practice/suggestion?

Clemens, I would also like your opinion on whether the WFS 1.1 / GML 3.2 port is a viable interim solution or whether you would recommend WFS 2.0 (is it still a draft?).

Kind regards,

Ben Caradoc-Davies.

Permalink

Just
2716 days ago

Ben, Good to see you here too ! I am trying to figure out what the most practical approach is to comply with INSPIRE Annex I data themes using FOSS WFS products. GML 3.2.1 is required (v3.0 of INSPIRE themes). For WFS we appearantly have some freedom to use WFS 1.1.0 or WFS 2.0. Given that the FOSS WFS products I am considering, GeoServer2 and Deegree2 only support up to WFS 1.1.0, my focus is a compliant way to support WFS 1.1.0 + GML 3.2.1. From what I understand from Clemens last post, this would be a "a <SpatialDataSet> from the INSPIRE Base Types schema" (yes?).  The context of our project is within ESDIN best practice. Here we share a modified WFS XSD which is indeed non-compliant with the rest of the world so we may have to alter this. IMHO WFS 2.0 is only defined within ISO and (FOSS) WFS 2.0 products are not yet available. Also GML 3.2.1 is not yet supported in GeoServer2 and Deegree2 (I think in upcoming Deegree3). Here we apply an I/O transformation filter.

More details of our project can be found at: http://kademo.nl/inspire

best,

Just van den Broecke

Permalink

Clemens Portele
2716 days ago

WFS 2.0 is still a draft, but it is largely through the process; only some final edits and then the final vote in ISO/TC 211 will occur (no further changes to the document are allowed then). 

Until the WFS 2.0 process is complete, implementations are available and the technical guidance for the download service has been approved, I would consider WFS 1.1 the best interim solution.

By the way, I have checked which feature collection container we have typically used in our WFS 1.1 instances that return GML 3.2 and it is <FeatureCollection> from GML 3.2. One advantage of this root element over the other options is that there is a XML Schema document directly accessible on the OGC website to support validation. For the other options that I have listed below no such XML Schema document is currently directly accessible on the authoritative websites of INSPIRE/OGC/ISO (only in zip archives and/or not publicly available).

 

Permalink

Eddie Curtis
2715 days ago

Hi Just,

At Snowflake we have implemented quite alot of WFS serving INSPIRE annex 1 schemas (GML 3.2.1). We used WFS 1.1 and used the SpatialDataSet element defined in the INSPIRE schemas as the returned document element. This has the advantage that the returned data is wholly defined within the INSPIRE schemas and so is purely GML 3.2.1. It seems to avoid problems with version confusion since the WFS request parameters are pure GML 3.1 and the response is pure GML 3.2.

Eddie Curtis

 

 

Permalink

Just
2715 days ago

Hi Eddie,

Thanks for sharing. It looks like there are multiple compliant solutions, at least two:

1) WFS 1.1 with INSPIRE  SpatialDataSet (defined in INSPIRE v3 BaseTypes.xsd, substitutionGroup for gml:AbstractFeature) response body looks to me the most acceptable. Ok, the schemas are not directly online AFAIK (the current v3.0 version even has double annotations) but that goes for all of the INSPIRE data theme XSDs.

2) WFS 1.1 with GML 3.2.1 FeatureCollection, part of GML 3.2.1 deprecatedTypes.xsd . But why start with a deprecated type that may cause confusion with wfs:/gml:FeatureCollection from WFS 1.1/GML 3.1..1 ?

At the end of the day all these systems need to interwork. The more options, the more confusion. Is there any recommendation on this from INSPIRE or any of the best practice groups like ESDIN and EURADIN ?  (Or are we here to suggest such a recommendation?). I would suggest #1 but will be happy to comply with whatever a majority decides.

best,

Just van den Broecke - www.justobjects.nl

Permalink

Eddie Curtis
2715 days ago

Hi Just,

I had seen the presence of the SpatialDataSet element as implicit guidance to use that element. If they had wanted us to use wfs:FeatureCollection why model an INSPIRE collection?

Eddie

 

Permalink

Clemens Portele
2715 days ago

Hi Eddie,

the SpatialDataSet has been introduced not for the WFS (Direct Access Download Service) but mainly as the response type for the Download Service for pre-defined data sets (or parts of them). However, looking at the current draft technical guidance of the download service I see that it is silent on this.

Regarding the Direct Access Download Service my assumption always was that in the WFS context the respective FeatureCollection element would be used. Again the draft technical guidance is silent on this, but WFS 1.1 mandates the use of the element for GML 3.1. Similarily ISO/DIS 19142 mandates the use of its FeatureCollection element for GML 3.2 responses.

Clemens

 

Permalink

Clemens Portele
2715 days ago

Hi Just,

while the initial scope of the IOC Task Force is View/Discovery Services only, this type of decision would seem to fit with their scope and remit in general. While ESDIN, EURADIN, etc may make such decisions (and maybe will do) these will always be "local" decisions within a project/community.

For WFS 1.1 with GML 3.2 in INSPIRE I would be fine with any of the three options I have mentioned before (switching a WFS to a different feature collection container is simple). For WFS 2.0 it will be {http://www.opengis.net/wfs/2.0}FeatureCollection.

Clemens

Permalink

Markus Schneider
2518 days ago

I wonder what happens for the following request types in case a gml:FeatureCollection or an INSPIRE SpatialDataSet is used for WFS 1.1.0/GML 3.2 responses:

- GetFeature with resultType=HITS: Such requests shall return an empty collection element with the numberOfFeatures attribute set to the number of matching features. AFAIK, this attribute is only available in the wfs:FeatureCollection.

- GetFeatureWithLock: Responses to this request indicate the assigned lock identifier in the lockId attribute. I realize that this GetFeatureWithLock is only relevant for WFS-T, but some WFS implementations may actually support WFS-T with INSPIRE data sets, e.g. [1].

IMHO, only the "wfs:FeatureCollection" allows to support the above request types properly. Or am I missing something?

Best regards,
Markus

[1] http://inspire.kademo.nl/deegree-inspire-demo

Permalink