Categories
github activity- An error has occurred, which probably means the feed is down. Try again later.
Tags
Add new tag Code Sprint development ESRI foss4g geodatahackaton geojson GIS GIS Novinky github GPS GRASS HSLayers INSPIRE Kolo MapServer OGC opendata OpenLayers Open Source OpenStreetMap OSGeo OSM OWS Pes Proxy4OWS Python PyWPS QGIS rakovina varlete REST RUIAN Sport TopoJSON Ubuntu WFS wikipedia WMS WPS školeníArchives
- March 2018
- December 2015
- June 2014
- April 2014
- December 2013
- August 2013
- June 2013
- May 2013
- March 2013
- October 2012
- July 2012
- March 2012
- February 2012
- December 2011
- September 2011
- July 2011
- June 2011
- February 2011
- January 2011
- September 2010
- July 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- November 2009
- October 2009
- August 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- February 2008
- January 2008
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
- February 2006
- January 2006
- December 2005
- November 2005
- October 2005
- September 2005
- August 2005
- July 2005
- May 2005
- April 2005
- February 2005
- January 2005
Meta
- github activity
- An error has occurred, which probably means the feed is down. Try again later.
3 Responses to “WFS 1.1 and axis orientation: where is this written”
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
Even, this is nice. But how come, everybody is *so* sure about it base don one best practice example :-(
By Jachym Cepicky 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