Les-ejk

I’m afraid that if you expect clear wording, you will be disappointed. I have the impression that standards are not always written in a way that is meant to be obvious for implementators ;-)

I also don’t believe this is written explicitely in the WFS 1.1 standard. The only mention I found was :

“””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:
• http://www.opengis.net/gml/srs/epsg.xml#
• urn:EPSG:geographicCRC:
In these format models, the values are placeholders for actual EPSG code values. Here is an example of the srsName where the assigned value follows one of the required format models: srsName=”urn:EPSG:geographicCRS:63266405″.”””

But if you look for other OGC standards (actually a “Best practice” docment), you can find “Definition identifier URNs in OGC namespace” , 1.3, 07-092r3 ( http://www.opengeospatial.org/standards/bp ) that has an interesting example at page 10 :
“””EXAMPLE The URN value urn:ogc:def:crs:EPSG:6.6:4326 shall mean the Coordinate Reference System (CRS) with code 4326 specified in version 6.6 of the EPSG database available at http://www.epsg.org/. That CRS specifies the axis order as Latitude followed by Longitude.”””

By Even Rouault on Feb 9, 2012

At GeoServer, while implementing WFS 1.1, we have had this painful discussion about the axis order with the WFS spec authors and they were adamant about the axis order as reported by the EPSG authority (which one would expect to be north/east for geographic, and east/north for projected, but actually has a lot of exceptions). I agree the wording is poor/lacking, this has actually created a ton of confusion… anyone setting up a WFS client should probably allow the user to specify the axis order manually since the same SRS definition is interpreted in different ways by different servers…

By Andrea Aime on Feb 11, 2012