WFS 1.1.0: support for srsName format models

Hello,

In the Netherlands we have a profile on WFS 1.1.0. It is still in use. For this profile we have test tooling. The tooling requests a server, using the srsName with the following notation: "EPSG:28992". This is based on page 36 of the WFS 1.1.0 spec.

-- start quote page 36 --

Any valid URI value can be assigned to the srsName attribute. However, in order to enhance interoperability, a web feature service must be able to process srsName attribute values with the following format models:

EPSG:<EPSG code>

http://www.opengis.net/gml/srs/epsg.xml#<EPSG code>

urn:EPSG:geographicCRC:<epsg code>

-- end quote --

 

Now we have a service implementation that fails this test, since it does not understand the above notation. The service advertizes the SRSes as:

-- start quote --

<wfs:DefaultSRS>urn:ogc:def:crs:EPSG:6.9:28992</wfs:DefaultSRS

<wfs:OtherSRS>urn:ogc:def:crs:EPSG:6.9:4326</wfs:OtherSRS>

-- end quote --

The above seems valid to me, but when requesting the service with the other notations, we get exceptions. The service-software has passed the CITE tests.

The question rises: must the service support the other notations as mentioned on page 36  as well, in order to be compliant to the WFS 1.1.0 spec? And thus, may a WFS client assume that the service supports the other notations, even if these notations are not advertized in the Capabilities?

 

Hope someone can clarify this.

I passed your questions/issues to the OGC WFS WG. They have already submitted change requests for WFS 1.1 that will resolve this problem. They are discussing how to deal with the backwards compatibility problem. The clarification and fix will be issues as a corrigendum.

Thanks for the question!

Carl Reed

Hi, as far as I understand,

Hi,

as far as I understand, the issue is, that you are trying to request the service with EPSG:28992 but it has only urn:ogc:def:crs:EPSG:6.9:28992 and urn:ogc:def:crs:EPSG:6.9:4326 as supported SRS, right?

I so, the answer is quite simple, as most implementations understand different notations as different SRS. From my point of view, an implementation has to generally support all the notations (to be able to process all types of notations) but is not required to actually support all notations for a supported SRS and map them against each other.

 

Best regards

Sebastian Goerke

---

Thanks for the reply

Thanks for the reply Sebastian (and sorry for my late reply, getting the people involved and discussing this issue took a long time).

The issue is indeed about the notations the server shall be able to understand, according to the spec. So indeed, does a server need to be able to process all notations / format models? And what do you mean by "process" and "map"? Should a server respond to a client request using EPSG:28992 with data in urn:ogc:def:crs:EPSG:6.9:28992 (if the codes mean the same of course)? From a functional and client perspective I'd say it should and my interpretation of the text from the spec is that a server shall understand those different notations and thus must be able to respond with features. Is this correct? Is this what the WFS spec is requiring (unambigously)? 

To me that is still not 100% clear.

Hope someone can help clarifying.

Thijs

---