[Geoserver-users] Bug GET request WFS 1.1.0 with GEOS 1.6.0?

GeoServer GeoServer User
1

Hi,
The problem which has been found is the following:
a GET request with WFS 1.1.0 standard causes XML with reference to WFS 1.0.0 schema.
The same POST request has the right schema reference.

example:
request:
http://localhost:8080/geoserver/wfs?request=GetFeature&version=1.1.0&typeName=topp:states&outputFormat=GML2&srsName=urn:x-ogc:def:crs:EPSG:4326

result:
<wfs:FeatureCollection xsi:schemaLocation=“http://www.sitename.it http://localhost:8080/geoserver/wfs?service=WFS&version=1.0.0&request=DescribeFeatureType&typeName=topp:states http://www.opengis.net/wfs http://localhost:8080/geoserver/schemas/wfs/1.0.0/WFS-basic.xsd”>
…

regards,
Giambattista

2

Hi Giambattista,

I have the confirmed the problem. At first glance it seemed trivial to fix but after thinking a bit more about it I think there is an issue here.

If a client makes a wfs 1.1 request specifying GML2, then the schema location for the wfs schema has to be the 1.0 version of the schema (WFS-basic.xsd). The reason being that if the 1.1 version of the schema is used (wfs.xsd), i dont believe the document would validate, because the wfs 1.1 schema references gml3, not gml2. And gml3 is not backwards compatable with gml2.

The same applies to the describe feature type request. If a 1.1 feature type request get sent back to the server, it will return the wfs 1.1 schema which against references gml3.. and I believe there will be a conflict.

You have stumbled onto a tricky issue here. I would like to hear other developers thoughts... and maybe ask wfs-dev, as this seems to be an inconsistency with the spec?

-Justin

Giambattista Mameli wrote:

Hi,
The problem which has been found is the following:
a GET request with WFS 1.1.0 standard causes XML with reference to WFS 1.0.0 schema.
The same POST request has the right schema reference.

*example:*
request:
http://localhost:8080/geoserver/wfs?request=GetFeature&version=1.1.0&typeName=topp:states&outputFormat=GML2&srsName=urn:x-ogc:def:crs:EPSG:4326 <http://localhost:8080/geoserver/wfs?request=GetFeature&version=1.1.0&typeName=topp:states&outputFormat=GML2&srsName=urn:x-ogc:def:crs:EPSG:432&gt;

result:
<wfs:FeatureCollection xsi:schemaLocation="http://www.sitename.it http://localhost:8080/geoserver/wfs?service=WFS&version=1.0.0&request=DescribeFeatureType&typeName=topp:states http://www.opengis.net/wfs http://localhost:8080/geoserver/schemas/wfs/1.0.0/WFS-basic.xsd&quot;&gt;
....
</wfs>

regards,
Giambattista

!DSPAM:4007,47c3cecb91881012714783!

------------------------------------------------------------------------

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

!DSPAM:4007,47c3cecb91881012714783!

------------------------------------------------------------------------

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

!DSPAM:4007,47c3cecb91881012714783!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com

3

Justin Deoliveira ha scritto:

Hi Giambattista,

I have the confirmed the problem. At first glance it seemed trivial to fix but after thinking a bit more about it I think there is an issue here.

If a client makes a wfs 1.1 request specifying GML2, then the schema location for the wfs schema has to be the 1.0 version of the schema (WFS-basic.xsd). The reason being that if the 1.1 version of the schema is used (wfs.xsd), i dont believe the document would validate, because the wfs 1.1 schema references gml3, not gml2. And gml3 is not backwards compatable with gml2.

The same applies to the describe feature type request. If a 1.1 feature type request get sent back to the server, it will return the wfs 1.1 schema which against references gml3.. and I believe there will be a conflict.

You have stumbled onto a tricky issue here. I would like to hear other developers thoughts... and maybe ask wfs-dev, as this seems to be an inconsistency with the spec?

Hum, the spec does not support GML2 output in any way, it's just our
custom addition. The way you describe it, it seems that we either
accept this weird output, or we remove GML2 output from WFS 1.1
right away, since as you say any attempt to output GML2 with the
WFS 1.1 schemas in the mix will result in an inconsistent document.

Giambattista, out of curiosity, is there any specific reason you're
using WFS 1.1? If it's reprojection, we have a custom extension
for WFS 1.0 that allows reprojection to be used in 1.0 as well,
at least in GetFeature GET requests (not sure about XML POST ones,
I would have to check).

Also, beware that by using WFS 1.1 you'll receive back geographic
coordinates in lat/lon order instead of the usual lon/lat used
by most GIS systems (that's by spec, see
http://geoserver.org/display/GEOSDOC/2.+WFS for more details)

Cheers
Andrea

4

Hmm.. I could have sworn that the spec said that gml2 be handled with the mime type text/xml; subtype=gml/3.1.1, but looking through it appears not. My mind must be playing tricks on me again. So... i think that the way it works now is probably the best behavior, unless we want to start producing xml documents that are invalid.

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Hi Giambattista,

I have the confirmed the problem. At first glance it seemed trivial to fix but after thinking a bit more about it I think there is an issue here.

If a client makes a wfs 1.1 request specifying GML2, then the schema location for the wfs schema has to be the 1.0 version of the schema (WFS-basic.xsd). The reason being that if the 1.1 version of the schema is used (wfs.xsd), i dont believe the document would validate, because the wfs 1.1 schema references gml3, not gml2. And gml3 is not backwards compatable with gml2.

The same applies to the describe feature type request. If a 1.1 feature type request get sent back to the server, it will return the wfs 1.1 schema which against references gml3.. and I believe there will be a conflict.

You have stumbled onto a tricky issue here. I would like to hear other developers thoughts... and maybe ask wfs-dev, as this seems to be an inconsistency with the spec?

Hum, the spec does not support GML2 output in any way, it's just our
custom addition. The way you describe it, it seems that we either
accept this weird output, or we remove GML2 output from WFS 1.1
right away, since as you say any attempt to output GML2 with the
WFS 1.1 schemas in the mix will result in an inconsistent document.

Giambattista, out of curiosity, is there any specific reason you're
using WFS 1.1? If it's reprojection, we have a custom extension
for WFS 1.0 that allows reprojection to be used in 1.0 as well,
at least in GetFeature GET requests (not sure about XML POST ones,
I would have to check).

Also, beware that by using WFS 1.1 you'll receive back geographic
coordinates in lat/lon order instead of the usual lon/lat used
by most GIS systems (that's by spec, see
http://geoserver.org/display/GEOSDOC/2.+WFS for more details)

Cheers
Andrea

!DSPAM:4007,47c52f09313311637810514!

--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com