Vishful thinking…

Reversed co-ordinate axis order for EPSG:4326 vs CRS:84 when requesting WMS 1.3.0 images

Posted in ArcGIS, ESRI, GIS by viswaug on March 15, 2009

I spent quite a bit of time last week over this and thought it might help others who might encounter the same thing as I did. I was requesting images from the WMS service version 1.3.0 in ArcGIS Server and everything was fine as long I was requesting images with the “CRS:84” value for the co-ordinate reference system. According to the GetCapabilities document returned from the WMS Server, both the “CRS:84” and the “EPSG:4326” values are suported by the WMS server.

But when I started requesting images with “EPSG:4326”, I was seeing some really weird behaviour. I spent quite a bit of time trying to figure out what was going on without luck. The OGC team at ESRI helped me out and pointed out that when using WMS 1.3.0, the co-ordinate axis order in reversed for CRS:84 and EPSG:4326. So, when requesting images in CRS:84 use the coordiate axis order of (long, lat) and when using EPSG:4326 use the (lat, long) order.,18.924782,-66.969271,71.406235&WIDTH=765&HEIGHT=360&LAYERS=0,1,2&STYLES=,,pointSymbolizer&EXCEPTIONS=application/vnd.ogc.se_xml&FORMAT=image/png&BGCOLOR=0xFFFFFF&TRANSPARENT=TRUE&SLD=,-178.217598,71.406235,-66.969271&WIDTH=765&HEIGHT=360&LAYERS=0,1,2&STYLES=,,pointSymbolizer&EXCEPTIONS=application/vnd.ogc.se_xml&FORMAT=image/png&BGCOLOR=0xFFFFFF&TRANSPARENT=TRUE&SLD=

But when requesting images from WMS Server version 1.1.1 with EPSG:4326, we should still use the coordinate axis order of (long, lat),18.924782,-66.969271,71.406235&WIDTH=765&HEIGHT=360&LAYERS=0,1,2&STYLES=,,pointSymbolizer&EXCEPTIONS=application/vnd.ogc.se_xml&FORMAT=image/png&BGCOLOR=0xFFFFFF&TRANSPARENT=TRUE&SLD=

Do these standards really help when the standards are not really STANDARD?

Then comes the issue of versioning of these standards, especially the OGC standards. The OGC standards are so reliant on one another that the different versions that exist in each standard actually adds a lot more complexity to systems that actually use them. For example, the SLD 1.1.0 standard (Styled Layer Descriptor) depends on the FE 1.1.0 standard (Filter Encoding), the SE 1.1.0 standard (Symbology Encoding) and the GML 3.1.1 standard (Geography Markup Language). As and when the standards evolve and higher versions are created, the versions of the standards they in-turn depend on change making a big mess for the systems that actually have to implement these standards.


10 Responses

Subscribe to comments with RSS.

  1. Duarte Carreira said, on March 16, 2009 at 10:30 am

    Hi there.

    Did you notice any trouble using WMS clients with AGS using WMS 1.3.0?


  2. viswaug said, on March 16, 2009 at 12:08 pm

    Hi Duarte,

    Not yet. I have used OpenLayers as a client earlier without issues.

    Thank You,

  3. Pål Herman Sund said, on March 16, 2009 at 1:11 pm

    Hi, seems like 1.3.0 standard actually is more clear on CRS stuff:..
    ..Coordinates shall be listed in the order defined by the CRS
    and shall be mapped appropriately to the Map CS i and j axes,
    swapping axis order as needed during the projection operation…

    The use of geographic CRSs with axis order of longitude before latitude
    differs from historical convention..

    So it is a change, but maybe to the better?

    Pål H

  4. Morten said, on March 17, 2009 at 11:42 pm

    Vish I’m completely on your side.
    This has always been one of my major complaints about OGC (and EPSG for that matter). They are much more concerned that the theoretical and academical parts are correct, than considering the complexities this adds to implementing their standards. The fact of the matter is that you cannot create an OGC compliant client without including the entire EPSG database, just so you can check what order your coordinates should be in. If they instead had went with a much simpler approach and let X be X and Y be Y, we wouldn’t have all these problems.

    Before you start telling me that a spherical coordinate system using latitude and longitude are not in any way equivalent to a flat X and Y coordinate system, I maintain that they can easily be conceptualized as the same (I think we can agree that north is up) and greatly simplifies implementation and understanding. And if you really want to go academic on me, then first tell me how come I can request a flat map in EPSG:4326 from a WMS server, if that coordinate system is spherical? Technically a WMS server shouldn’t support any spatial reference that is using a spherical coordinate system.

  5. Pål Herman said, on March 18, 2009 at 8:52 am

    Morten/Vish, I do not disagree that the OGC and EPSG domain is complex and maybe too academic on many matters. But from my understanding (which is modest.. )I think we have seen in the past many examples that simplifying sometimes adds complexity in the end. I mean there are so many SRS’s around, and if a standard should cover everyone (which it should I guess) there is no simple solution?? For example SRS’s with first axis (“X”) positive to north and second axis (“Y”) positive to west, couldnt that be a problem with a somplified solution?

  6. […] by viswaug on April 1, 2009 A couple of weeks ago I had written about how the different axis ordering that can be defined in EPSG coordinate system standards makes the […]

  7. Marcel said, on July 28, 2009 at 2:06 pm

    actually, I had problems, when I used Gaia for accessing the 1.3.0-WMS from Gaia uses CRS=CRS:84 in its GetMap requests. However, the order of coordinate values that specify the BBOX will be incorrect. I assume that the capabilities are correct.

  8. Long time developer said, on August 27, 2009 at 4:51 am

    I totally agree. The spec is for software developers not GIS people. GIS people should stick to giving opinions about their profession and developers can be the authority on how to develop robust, consistent software specifications. It’ the same reason we all drive on the same side of the road in each state in the US. That would be AWESOME if it changed from state to state because someone thought it was more theoretically correct in their state to drive on the left side instead.

    Roses are blue, Violets are red, this poem makes no sense because I didn’t use my head!

  9. L.G. Davies said, on October 15, 2009 at 2:13 pm

    For GetMap requests…

    Spec for 1.3.0:


    Spec for 1.1.1:


    So no difference in the order i.e. no problem here.

    When parsing the GetCapabilities responses each of the values is named in the XML, which is of course one of the reasons for using XML i.e. it’s self-describing. So there should be no confusion…depending on who wrote your parsing routines and whether they’ve made some rash assumptions on ordering etc.

  10. Kristof Vydt said, on February 2, 2010 at 1:27 pm

    WMS 1.3.0 states:
    – “CRS:84” refers to WGS 84 geographic longitude and latitude expressed in decimal degrees, with longitude ranging from −180 degrees to +180 degrees and latitude from −90 degrees to +90 degrees.
    – “EPSG:4326” refers to WGS 84 geographic latitude, then longitude. That is, in this CRS the x axis corresponds to latitude, and the y axis to longitude.

    Hence for GetMap requests…
    Spec for 1.3.0:
    Spec for 1.1.1:

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: