GeoTools

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

is depended upon by

Bug - A problem which impairs or prevents the functions of the product. GEOS-1212 EPSG codes in URN form are turned into lon/lat CRS

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. GEOS-1433 Make sure "http://www.opengis.net/gml/srs/epsg.xml#xxx" is interpreted as lon/lat by default

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is related to

Bug - A problem which impairs or prevents the functions of the product. GEOT-1659 urn:ogc:def:crs:EPSG:4326 parsing won't work if forcexy is activated

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

New Feature - A new feature of the product, which has yet to be developed. GEOT-859 Add a CRS authority factory for the "urn:ogc:def:...:EPSG" name space

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: