WFS Axis Order WFS 1.0.0 Axis order clearly defined in standard (East, North) <wfs:LatLongBoundingBox> causes confusion sometimes WFS 1.1.0 As widely accepted, axis order should follow the definition of the particular CRS However, not a strict requirement in the standard Implementations of standards differ, heaps of confusion Axis order depends not only on the CRS, but also on the notation used19.05.2012 HSRS & CCSS 9 GI2012
WFS Axis Order WFS 1.1.0 Axis order depends on the SRS used Check http://www.epsg-registry.org/ for definitions BBOX url parameter Sometimes you need to negotiate with the service providers to follow the definition, as otherwise no data may be returned Data themselves MapServer did not understand, that the axis order depends on the SRS used, data was rotated by 90° MapServer patch provided19.05.2012 HSRS & CCSS 10 GI2012
WFS Axis Order WFS 1.1.0 Axis order depends on the notation of the SRS as well: EPSG:EPSG_code → WFS 1.0.0 style – fixed East, North urn:EPSG:geographicCRC:epsg_code → Follow-up the definition http://www.opengis.net/gml/srs/epsg.xml#EPSG_code → We dont know19.05.2012 HSRS & CCSS 11 GI2012
WFS Axis Order MapServer as WFS 1.1.0 Client More details here: http://les-ejk.cz/2012/03/mapserver-as-wfs-1-1-0-client-not-suitable/19.05.2012 HSRS & CCSS 12 GI2012
Patches available OpenLayers – <Filter_Capabilities> not parsed http://trac.osgeo.org/openlayers/ticket/3652 (Patch proposed) MapServer – Filter produced as invalid XML http://trac.osgeo.org/mapserver/ticket/4171 (Expected in 6.2) MapServer – WFS Axis order http://trac.osgeo.org/mapserver/ticket/4228 (Expected in 6.2) OwsLib patches already deployed19.05.2012 HSRS & CCSS 13 GI2012
Thank you! Hope to see you in Prague:19.05.2012 HSRS & CCSS 14 GI2012
A particular slide catching your eye?
Clipping is a handy way to collect important slides you want to go back to later.