[Geoserver-devel] [JIRA] (GEOS-7660) WFS2.0 doesn't contain srsName attribute for the top-most gml:Envelope element

Sorin RUSU created an issue

GeoServer / BugGEOS-7660

WFS2.0 doesn’t contain srsName attribute for the top-most gml:Envelope element

Issue Type:

BugBug

Affects Versions:

2.8.4

Assignee:

Unassigned

Components:

Validation

Created:

27/Jul/16 12:02 PM

Environment:

Windows Server 2012 R2 VM, running on 4 cores with 8 Gbytes of RAM.
Apache Tomcat 7.0 running with Java 1.7

Version
2.8.3
Git Revision
1c8c9ba0f74a465c397d46cf19d3b34b95b2fb6e
Build Date
22-Mar-2016 21:12
GeoTools Version
14.3 (rev 2298d56000bef6f526b521a480316ea544c74571)
GeoWebCache Version
1.8.2 (rev 1.8.x/442d5127d1a01942f4c04c8140ade4c4538bb16d)

Labels:

wfs gml32 validation boundingBox srsName

Priority:

MediumMedium

Reporter:

Sorin RUSU

Original Estimate:

3 days

Remaining Estimate:

3 days

I have a geoserver endpoint serving INSPIRE compliant environmental data (EPSG:3035) as WFS 2.0 (GML 3.2) through AppSchema from a PostGIS (pg 9.4) database. There is a validation error for the WFS request if the “return bounding box with each feature” is checked.

For the wfs:boundedBy element there is no declaration of srsName, and while that bounding box is correct and valid, since the srsName isn’t specified, GML validators, like the one from opengeospatial, http://cite.opengeospatial.org/teamengine/viewSessions.jsp, will not validate my GML, saying that the bounding box for WFS doesn’t have a SRS associated.

This issue is with any WFS 2.0 generated GML3.2, none of the requests seem to generate the required attributes for the WFS’s Envelope (i tried both complex feature types as well as simple feature types: shapefile, direct postgis data connections etc).

I have confirmed this issue with Andrea Aime as well as with Ben Caradoc-Davies:
Andrea wrote:
_Double checked, indeed it seems the srsName is never encoded for envelopes of WFS 2.0 responses,
even if they are made of simple features.
E…g:
http://demo.geo-solutions.it/geoserver/tiger/ows?service=WFS&version=2.0.0&request=GetFeature&typeName=tiger:tiger_roads&count=1
vs:
http://demo.geo-solutions.it/geoserver/tiger/ows?service=WFS&version=1.1.0&request=GetFeature&typeName=tiger:tiger_roads&maxFeatures=1
So no, the issue was not known (possibly because many try to avoid computing/encoding the bounds, as it adds extra cost). Please report it at the bug tracker
_

In a WFS request, for example administrative units (request: http://inspire.biodiversity.ro/geoserver/ows?service=wfs&version=2.0.0&request=getfeature&typename=au:AdministrativeUnit&featureID=BC) I get the following response:
<wfs:boundedBy>
<gml:Envelope>
<gml:lowerCorner>2687567.4042999963 5533251.203599997</gml:lowerCorner>
<gml:upperCorner>2781594.9288999955 5660608.522499993</gml:upperCorner>
</gml:Envelope>
</wfs:boundedBy>
<wfs:member>
<au:AdministrativeUnit gml:id=“BC”>
<gml:boundedBy>
<gml:Envelope srsDimension=“2” srsName=“urn:ogc:def:crs:EPSG::3035”>
<gml:lowerCorner>2687567.4042999963 5533251.203599997</gml:lowerCorner>
<gml:upperCorner>2781594.9288999955 5660608.522499993</gml:upperCorner>
</gml:Envelope>
</gml:boundedBy>

Add Comment

Add Comment

This message was sent by Atlassian JIRA (v1000.184.1#100008-sha1:1fb1cc9)

Atlassian logo