GeoTools
  1. GeoTools
  2. GEOT-1388

EPSG codes in URN form do not respect global axis orientation setting

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.4-M4
    • Fix Version/s: 2.4.0, 2.5-M1
    • Component/s: referencing
    • Labels:
      None

      Description

      The following program shows the issue:

      import org.geotools.referencing.CRS;
      import org.opengis.referencing.crs.CoordinateReferenceSystem;
      
      
      public class TestDecodeURN {
          public static void main(String[] args) throws Exception {
              System.setProperty("org.geotools.referencing.forceXY", "true");
              CoordinateReferenceSystem urn = CRS.decode("urn:x-ogc:def:crs:EPSG:6.11.2:4326");
              System.out.println(urn);
              CoordinateReferenceSystem epsg = CRS.decode("EPSG:4326");
              System.out.println(epsg);
          }
      }
      

        Issue Links

          Activity

          Hide
          Andrea Aime added a comment -
          To make it clearer... the usual decode("epsg:4326") returns lon/lat axis orientation, whilst a decode against an URN form always returns lon/lat no matter what the global setting is.
          Show
          Andrea Aime added a comment - To make it clearer... the usual decode("epsg:4326") returns lon/lat axis orientation, whilst a decode against an URN form always returns lon/lat no matter what the global setting is.
          Hide
          Martin Desruisseaux added a comment -
          You mean that the URN form always return (lat,long)? If this is the case, this is on purpose. My understanding was that a lot of confusion exists around the axis order in the "EPSG" name space, and that the "urn:ogc:def:crs:EPSG" namespace has been created exactly in order to clear this confusion: axis order is as specified by the authority, no excuse. Was is a wrong interpretation?
          Show
          Martin Desruisseaux added a comment - You mean that the URN form always return (lat,long)? If this is the case, this is on purpose. My understanding was that a lot of confusion exists around the axis order in the "EPSG" name space, and that the "urn:ogc:def:crs:EPSG" namespace has been created exactly in order to clear this confusion: axis order is as specified by the authority, no excuse. Was is a wrong interpretation?
          Hide
          Andrea Aime added a comment -
          Well, somewhere there is a wrong interpretation for sure, since our WFS cite tests using that syntax are failing because of coordinate inversion issues. Can you point me to the standards document stating that we must use lat/lon axis ordering for URN definitions (boys that would be a disaster, all public data I downloaded so far in lon/lat).
          Show
          Andrea Aime added a comment - Well, somewhere there is a wrong interpretation for sure, since our WFS cite tests using that syntax are failing because of coordinate inversion issues. Can you point me to the standards document stating that we must use lat/lon axis ordering for URN definitions (boys that would be a disaster, all public data I downloaded so far in lon/lat).
          Hide
          Martin Desruisseaux added a comment -
          I had a quick look at the specification, especially the "Definition identifier URNs in OGC namespace" at http://www.opengeospatial.org/standards/bp, but I have been unable to find a clear statement. We probably need to contact the authors in the above-cited specification, or somebody else who may know.
          Show
          Martin Desruisseaux added a comment - I had a quick look at the specification, especially the "Definition identifier URNs in OGC namespace" at http://www.opengeospatial.org/standards/bp, but I have been unable to find a clear statement. We probably need to contact the authors in the above-cited specification, or somebody else who may know.
          Hide
          Andrea Aime added a comment -
          I looked at the standard. Found no definitive answer me neither, so they did not bother telling the world about a fixed axis ordering, yet at page 17, 8.2, CRS defintions, there is a table with a few well known CRS:

          urn:ogc:def:crs:OGC:1.3:CRS84: WGS 84 longitude-latitude
          urn:ogc:def:crs:OGC:1.3:CRS83: NAD27 longitude-latitude
          urn:ogc:def:crs:OGC:1.3:CRS27: NAD83 longitude-latitude

          They are all longitude-latitude. So for sure they are not enforcing a latitute-longitude approach. I don't believe they are requiring the opposite either thought.
          Show
          Andrea Aime added a comment - I looked at the standard. Found no definitive answer me neither, so they did not bother telling the world about a fixed axis ordering, yet at page 17, 8.2, CRS defintions, there is a table with a few well known CRS: urn:ogc:def:crs:OGC:1.3:CRS84: WGS 84 longitude-latitude urn:ogc:def:crs:OGC:1.3:CRS83: NAD27 longitude-latitude urn:ogc:def:crs:OGC:1.3:CRS27: NAD83 longitude-latitude They are all longitude-latitude. So for sure they are not enforcing a latitute-longitude approach. I don't believe they are requiring the opposite either thought.
          Hide
          Martin Desruisseaux added a comment -
          Note: those CRS84, CRS83 and CRS27 codes are already implemented in Geotools for a few months.

          OGC is not enforcing a latitude-longitude approach. OGC is enforcing a "as the authority said" approach, which may or may not be latitude-longitude depending on the authority.

          EPSG code prior to WMS 1.3.0 are ambiguous relative to axis order. In order to avoid ambiguity, it is recommanded to use CRS:84 instead of EPSG:4326 when we want to be sure to have a (longitude,latitude) axis order, since CRS:84 definition is very clear.

          Since WMS 1.3.0, EPSG:4326 is clearly defined as (latitude, longitude). See "Web Map Service" (OGC document 03-109r1) at http://www.opengeospatial.org/standards/wms. Quotes:

              "EPSG geographic coordinate reference systems follow ISO 6709 and always list latitude before longitude." (page 9)

              "EXAMPLE: 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." (page 10)

          I admit that it doesn't tell us what to do with URN in WMS 1.1. My understanding was "as the authority said" and it was implemented like that in Geotools, but I may be wrong. I will try to send an email to Arliss for asking him if I have a chance.


              Martin
          Show
          Martin Desruisseaux added a comment - Note: those CRS84, CRS83 and CRS27 codes are already implemented in Geotools for a few months. OGC is not enforcing a latitude-longitude approach. OGC is enforcing a "as the authority said" approach, which may or may not be latitude-longitude depending on the authority. EPSG code prior to WMS 1.3.0 are ambiguous relative to axis order. In order to avoid ambiguity, it is recommanded to use CRS:84 instead of EPSG:4326 when we want to be sure to have a (longitude,latitude) axis order, since CRS:84 definition is very clear. Since WMS 1.3.0, EPSG:4326 is clearly defined as (latitude, longitude). See "Web Map Service" (OGC document 03-109r1) at http://www.opengeospatial.org/standards/wms . Quotes:     "EPSG geographic coordinate reference systems follow ISO 6709 and always list latitude before longitude." (page 9)     "EXAMPLE: 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." (page 10) I admit that it doesn't tell us what to do with URN in WMS 1.1. My understanding was "as the authority said" and it was implemented like that in Geotools, but I may be wrong. I will try to send an email to Arliss for asking him if I have a chance.     Martin
          Hide
          Andrea Aime added a comment -
          Martin, would it be possible to have an alternate URN authority working in longitude/latitude mode? I frankly don't get much out of a standard if it does not play correctly with the data we have.
          For the moment, treat this just as a question (aka, don't waste your time on implementations), I'll have to check with the WFS cite test and see if there is any wrong assumption in Geoserver that's making them fail.
          But every time I see someone trying to impose a latitude/longitude approach I am suspicious, since I really still have to stumble on any significant free dataset using that axis ordering.
          Show
          Andrea Aime added a comment - Martin, would it be possible to have an alternate URN authority working in longitude/latitude mode? I frankly don't get much out of a standard if it does not play correctly with the data we have. For the moment, treat this just as a question (aka, don't waste your time on implementations), I'll have to check with the WFS cite test and see if there is any wrong assumption in Geoserver that's making them fail. But every time I see someone trying to impose a latitude/longitude approach I am suspicious, since I really still have to stumble on any significant free dataset using that axis ordering.
          Hide
          Martin Desruisseaux added a comment -
          Added a FORCE_AXIS_ORDER_HONORING hint on 2.4 branch as of revision 27544. Set this hint to "http" in order to get (longitude,latitude) axis order for "http://www.opengis.net/" namespace as well as EPSG. Set this hint to "http, urn" in order to force that axis order for URN too.
          Show
          Martin Desruisseaux added a comment - Added a FORCE_AXIS_ORDER_HONORING hint on 2.4 branch as of revision 27544. Set this hint to "http" in order to get (longitude,latitude) axis order for " http://www.opengis.net/ " namespace as well as EPSG. Set this hint to "http, urn" in order to force that axis order for URN too.
          Hide
          Martin Desruisseaux added a comment -
          Closing since it has been reported that it seems to work in GeoServer.
          Show
          Martin Desruisseaux added a comment - Closing since it has been reported that it seems to work in GeoServer.

            People

            • Assignee:
              Martin Desruisseaux
              Reporter:
              Andrea Aime
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: