axis order must be in order lat long for 4326 for 1.1.0

[tomkralidis]

From  http://lists.osgeo.org/pipermail/mapserver-dev/2009-February/008318.html

We recently stood up 5.2.1 to offer up corporate WMS, WFS, WCS and SOS
interfaces.

We have MAP.PROJECTION set to init=epsg:4326.

We don't have MAP.WEB.METADATA.wfs_srs set.

We have MAP.LAYER.METADATA.PROJECTION set (to each layer's native
projection)

WFS 1.1.0 shows EPSG:4326 as the DefaultSRS for the FeatureType in
question (probably fetching from MAP.PROJECTION?).

A colleague has noticed that connecting to our endpoint using WFS 1.1.0,
through ESRI ArcMap.  ArcMap renders the features flipped.

Searching a bit more, we found:

http://n2.nabble.com/WFS-lat-lon-coordinates-switched-in-ArcGIS-td205507
9.html 

When I try in QGIS, the WFS renders fine.

Anyone have suggestions?  Can WFS offer up > 1 SRS?  This would be a _non-trivial_ change to the codebase.

I checked out GeoServer and their 1.1.0 impl returns lat long (they use DefaultSRS = urn:x-ogc:def:crs:EPSG:4326)

 http://sigma.openplans.org/geoserver/ows?service=WFS&version=1.1.0&request=GetCapabilities

[tomkralidis]

At the code sprint, we discussed this in more detail. Notes:

- in mapgml.c, we will pass projection info. The code will check the axis order

- in mapwfs11.c, for GetFeature

• if srsName is passed in request
  • if srsName > 4000 and srsName < 5000
    • coordinates become lat long, following EPSG axis order
  • else
    • works as normal
• if srsName is null
  • take map level PROJECTION object, pass it through mapfile.c:msLoadProjectionStringEPSG()

Other:

• GetCapabilities
  • output has to swap axis for WGS84BoundingBox
  • output DefaultSRS as URN

[tomkralidis]

I've added support for handling SRSNAME in GetFeature requests in r8652.

[assefa]

Another element that is affected is the BBOX element which can have an option srs passed with it x1,y1,x2,y2.srs. We would need also need to check for axis order.

[assefa]

do we need to do the axis order for WGS84BoundingBox element in the layer (Get Capabilities request): we keep it the same right now.

[tomkralidis]

Replying to assefa:

do we need to do the axis order for WGS84BoundingBox element in the layer (Get Capabilities request): we keep it the same right now.

Daniel and I just checked this. In both  http://schemas.opengis.net/ows/1.1.0/owsCommon.xsd and  http://schemas.opengis.net/ows/1.0.0/owsCommon.xsd, ows:WGS84BoundingBoxType, which defines ows:UpperCorner and ows:LowerCorner, both of which are of type ows:PositionType2D, which defines the order as:

The longitude value shall be listed first, followed by the latitude value, both in decimal degrees

[assefa]

r8672 set the map projection using the srsname passed as argument. At this point the map projection object had the axis order set appropriately. We should be able to use it in the GML output codes.

Just as a note, wfs 1.1 allows to advertise more than 1 srs. We are missing at this point this capability.

[tomkralidis]

Assefa: any update on this since the code sprint?

Here's some more useful info:  http://geoserver.org/display/GEOSDOC/2.+WFS+-+Web+Feature+Service#2.WFS-WebFeatureService-Theaxisorderissue

[assefa]

At this point, I think the piece missing would be for the gml output to check for the inverse projection flag and do the output appropriately. I think Steve was going to do that from what I understood at the code sprint.

[assefa]

looking into this

[assefa]

Tom, is there a way for you to check what is the SRS sent by ARC in this case: something like urn:xxx or just epsg:xxx

[sdlime]

I found a note I made from the sprint that talked about using msAxisNormalizePoints() from mapproject.c. You pass a projObj and a couple of doubles and the function swaps if necessary. I believe the thought was to call that in the functions that encode GML3. I'd think that would be kinda expensive to do for each point. Plus isn't it the case that only WFS 1.1 requires swapping the coords or is all GML3 supposed to be swapped.

I wonder then if a msAxisNormalizeShape() couldn't be written and called in msGMLWriteWFSQuery() only.

This could still happen for 5.6 in my opinion...

Steve

[assefa]

Only wfs 1.1 need the axis order for some epsg codes. Yes it make sense to have the swapping function called only from msGMLWriteWFSQuery. I an downloading qgis 1.3 to see how it handles axis and will update this bug again.

[sdlime]

To make sure, we need to flip the bbox and the shape points, right? So it will be <gml:pos>x y</gml:pos> most of the time and <gml:pos>lat lon</gml:pos> for the appopriate EPSG codes and WFS 1.1.

Whomever thought this requirement up was nuts...

Steve

[tomkralidis]

I'll check this with ARC report back.

[assefa]

Verified that QGIS only request wfs 1.0. I also think that OpenLayer? does the same from the tests I have done.

Attached is a patch that swap the coordinates for the epsg codes between >=4000 and <5000.

Tom, is it possible to test this.

What other clients should we test against before committing this?

[warmerdam]

The patch looks promising, but I'd like to strongly encourage use of the name msAxisSwapShape() in place of msAxisNormalizeShape(). I think of normalizing as either swapping or not depending on the context while this function always swaps and is only called if needed.

[assefa]

changed locally to msAxisSwapShape

I also added the support to read urn:EPSG:geographicCRC:<epsg code>. Note that we still advertise srs using the ESPG:<epsg code>

Any objection for this patch to be committed?

[tomkralidis]

Replying to assefa:

Tom, is there a way for you to check what is the SRS sent by ARC in this case: something like urn:xxx or just epsg:xxx

Assefa: using ArcMap 9.3 SP1, testing against svn trunk, here is what ArcMap sends as a GetFeature request to MapServer.

199.212.19.130 - - [24/Sep/2009:10:59:33 -0400] "GET /cgi-bin/mapserv/foo?SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&TYPENAME=bar HTTP/1.1" 200 2005514 

[assefa]

Thx Tom for checking: if the map is configured par example for epsg:4326, It should now spit out "inverse" coordinates.

committed in r9342.

[tomkralidis]

Thx. Results:

• !ArcGIS: Works. !ArcGIS is making WFS 1.1.0 requests
• QGIS 1.0.2-Kore: Works. QGIS is making WFS 1.0.0 requests

We should add msautotest's here as well. We should also document this and / or (MIGRATION_GUIDE.txt?), and clearly specify when the coordinates will be swapped on output (i.e. WFS 1.1.0 when MAP.PROJECTION = epsg:4326?)

Too bad this won't make 5.6.

[dmorissette]

Current trunk *is* 5.6...

[warmerdam]

I have prepared a version of the patch for 5.2 for my client -- attaching here in case there is broader interest.

[warmerdam]

A version of the patch against MapServer 5.2 branch.

[assefa]

added a not in the docs (trunk) and migration guide. Closing this.