Opened 13 years ago

Closed 13 years ago

#2899 closed defect (fixed)

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

Reported by: tomkralidis Owned by: assefa
Priority: high Milestone: 5.6 release
Component: WFS Server Version: svn-trunk (development)
Severity: major Keywords: axis
Cc: warmerdam, assefa, sdlime, bartvde, dmorissette, nsavard

Description

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

Attachments (2)

mapserver-bug2899.zip (2.4 KB ) - added by assefa 13 years ago.
2899_wfs_axis_order.patch (9.2 KB ) - added by warmerdam 13 years ago.
A version of the patch against MapServer 5.2 branch.

Download all attachments as: .zip

Change History (27)

comment:1 by tomkralidis, 13 years ago

Component: MapServer C LibraryWFS Server
Owner: changed from sdlime to mapserverbugs

comment:2 by tomkralidis, 13 years ago

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

comment:3 by dmorissette, 13 years ago

Milestone: 6.0 release
Owner: changed from mapserverbugs to assefa

comment:4 by tomkralidis, 13 years ago

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

comment:5 by assefa, 13 years ago

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.

comment:6 by assefa, 13 years ago

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

in reply to:  6 comment:7 by tomkralidis, 13 years ago

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

comment:8 by assefa, 13 years ago

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.

comment:9 by tomkralidis, 13 years ago

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

comment:10 by assefa, 13 years ago

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.

comment:11 by assefa, 13 years ago

Cc: nsavard added

looking into this

comment:12 by assefa, 13 years ago

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

comment:13 by sdlime, 13 years ago

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

comment:14 by assefa, 13 years ago

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.

comment:15 by sdlime, 13 years ago

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

comment:16 by tomkralidis, 13 years ago

I'll check this with ARC report back.

comment:17 by assefa, 13 years ago

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?

by assefa, 13 years ago

Attachment: mapserver-bug2899.zip added

comment:18 by warmerdam, 13 years ago

Keywords: axis added

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.

comment:19 by assefa, 13 years ago

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?

in reply to:  12 comment:20 by tomkralidis, 13 years ago

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 

comment:21 by assefa, 13 years ago

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

committed in r9342.

comment:22 by tomkralidis, 13 years ago

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.

comment:23 by dmorissette, 13 years ago

Milestone: 6.0 release5.6 release

Current trunk *is* 5.6...

comment:24 by warmerdam, 13 years ago

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

by warmerdam, 13 years ago

Attachment: 2899_wfs_axis_order.patch added

A version of the patch against MapServer 5.2 branch.

comment:25 by assefa, 13 years ago

Resolution: fixed
Status: newclosed

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

Note: See TracTickets for help on using tickets.