While adding even more unit test coverage for srsNames in HTTP URI format, I added some for EPSG codes and HTTP URLs as well, and noticed what looks like a discrepancy between the axis order or a request and the axis order of a response.
For WFS 2.0.0 and WFS 1.1.0 GET requests with srsName=EPSG:4326 or srsName=http://www.opengis.net/gml/srs/epsg.xml#4326, the response is returned with srsName=http://www.opengis.net/gml/srs/epsg.xml#4326 and coordinates in longitude/latitude order. However, if the request includes a bbox, it is interpreted as latitude/longitude order, the opposite of the response.
Is this intended? (Or just what we are stuck with for backwards compatibility?) It looks like a discrepancy to me. It looks like the documented axis order hack is only applied to encoding, not parsing of a request:
http://docs.geoserver.org/latest/en/user/services/wfs/basics.html#axis-ordering
(The solution being for everyone to move on to URN and HTTP URI srsNames and try to forget the axis order of evil.)
Kind regards,
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
On Fri, Aug 10, 2012 at 6:20 AM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:
While adding even more unit test coverage for srsNames in HTTP URI
format, I added some for EPSG codes and HTTP URLs as well, and noticed
what looks like a discrepancy between the axis order or a request and
the axis order of a response.
For WFS 2.0.0 and WFS 1.1.0 GET requests with srsName=EPSG:4326 or
srsName=http://www.opengis.net/gml/srs/epsg.xml#4326, the response is
returned with srsName=http://www.opengis.net/gml/srs/epsg.xml#4326 and
coordinates in longitude/latitude order. However, if the request
includes a bbox, it is interpreted as latitude/longitude order, the
opposite of the response.
This is the expected behavior, WFS does not behave like WMS.
In particular, the BBOX is always interpreted in the data native SRS, which
WFS wise is the one declared in the capabilities document,
which is in your case the urn:ogc-x:… form that has lat/lon axis order.
The bbox also takes a fifth element for the crs, so if you want to express
your bbox in lon/lat you can do so by using
&bbox=lon1,lat1,lon2,lat2,EPSG:4326
Cheers
Andrea
–
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
On 10/08/12 15:04, Andrea Aime wrote:
This is the expected behavior, WFS does not behave like WMS.
In particular, the BBOX is always interpreted in the data native SRS, which
WFS wise is the one declared in the capabilities document,
which is in your case the urn:ogc-x:... form that has lat/lon axis order.
Ah, that explains everything.
The bbox also takes a fifth element for the crs, so if you want to express
your bbox in lon/lat you can do so by using
&bbox=lon1,lat1,lon2,lat2,EPSG:4326
Excellent idea! I'll add these to the test.
--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
On Fri, Aug 10, 2012 at 6:20 AM, Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com> wrote:
(The solution being for everyone to move on to URN and HTTP URI srsNames
and try to forget the axis order of evil.)
There is no such a solution anymore, since OGC decided to force an axis order that
is un-natural for the software industry the only sane way to go on is to allow the user
to specify what the heck of an axis order you get when connecting to a certain server.
Some smart clients already do so.
This plagues both WFS and WCS, and by extension WPS as well.
And let’s not get started with the correlation to output formats, some mandate a precise
axis order, shapefile often won’t be interpreted properly by clients in lat/lon, afaik
GeoJSON is mandated to be in lon/lat and so on.
It’s guessworks at best, I don’t see the situation improving any in the short term,
OGC generated too many standards in the years and the situation is very diluted,
the standard versions supported by clients and servers is a mixed bag and so is
the level of support for any given particular standard.
While the situation is certainly better than having to deal with proprietary standards
that change at any software release, it’s way far from being seamless and curses
and manual intervertion is very much needed (and sometimes you can only give up,
especially if one side of the equation is a closed source software).
Cheers
Andrea
–
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it