This discussion is archived
8 Replies Latest reply: Nov 9, 2012 8:37 AM by 973154 RSS

NAD83 lat/long order confusion

973154 Newbie
Currently Being Moderated
I am newbie to the geospatial world. I am working with data which is in NAD83, and have selected SRID 4269 as the coordinate reference system. Looking in the MDSYS.SDO_COORD_REF_SYSTEM view, this has a COORD_SYS_ID of 6422. In the MDSYS.SDO_COORD_AXES table, the North/Lat axis for 6422 has order 1 and the East/Long axis has order 2. In addition, in the MDSYS.SDO_COORD_SYS table the COORD_SYS_NAME is given as "Ellipsoidal 2D CS. Axes: latitude, longitude. Orientations: north, east. UoM: deg". All this leads me to believe that coordinates should be in lat/long order when using this CRS.

However, if I do:

SELECT SDO_GEOM.SDO_DISTANCE(
SDO_GEOMETRY(2001,4269,SDO_POINT_TYPE(39.721096,-103.776314,NULL),NULL,NULL),
SDO_GEOMETRY(2001,4269,SDO_POINT_TYPE(40.5,-103.85,NULL),NULL,NULL),
0.0001,'unit=km') AS DISTANCE_BETWEEN_POINTS
FROM DUAL

I get 22.3370028351841 which is wrong. Whereas, if I present the coordinates in long/lat order:

SELECT SDO_GEOM.SDO_DISTANCE(
SDO_GEOMETRY(2001,4269,SDO_POINT_TYPE(-103.776314,39.721096,NULL),NULL,NULL),
SDO_GEOMETRY(2001,4269,SDO_POINT_TYPE(-103.85,40.5,NULL),NULL,NULL),
0.0001,'unit=km') AS DISTANCE_BETWEEN_POINTS
FROM DUAL

I get 86.7148255311137, which is correct (thanks to whomever asked a similar question on here and left the answer that they figured out they needed to reverse the coordinates).

Clearly, I need to use long/lat ordering for coordinates when using this system, but what did I miss that indicates that that is the order to use? Is there an alternative SRID to use? I am working with the JTS, GeoTools, and Hibernate Spatial libraries in Java and working with polygons as well as points, so I am looking for a consistent and efficient way of working with these coordinates.

Thanks,

Marc
  • 1. Re: NAD83 lat/long order confusion
    Simon Greener Journeyer
    Currently Being Moderated
    Marc,
    Clearly, I need to use long/lat ordering for coordinates when using this system, but what did I miss that indicates that that is the order to use? Is there an alternative SRID to use? I am working with the JTS, GeoTools, and Hibernate Spatial libraries in Java and working with polygons as well as points, so I am looking for a consistent and efficient way of working with these coordinates.
    There have been lots of debates about this over the past, across different database systems (eg SQL Server). The reality is that the approach is always that:

    X -> Longitude
    Y -> Latitude

    As some would say: "Get over it"!

    That is the way it is.

    regards
    Simon
  • 2. Re: NAD83 lat/long order confusion
    973154 Newbie
    Currently Being Moderated
    Thanks Peter - clearly I will need to find a way to work around GeoTools using a NAD83 definition that expects lat/long and Oracle viewing persisted coordinates as long/lat.

    My confusion arises from not having seen anything in the Spatial Developer's documentation that indicates that geodetic coordinate systems always have their coordinates in long/lat order. Instead it seems to indicate that they should be in the order specified by the coordinate system metadata, which for NAD83 (4269) appears to specify lat/long. Is there something I missed?

    Thanks,

    Marc
  • 3. Re: NAD83 lat/long order confusion
    Stefan Jager Journeyer
    Currently Being Moderated
    Hi Marc,

    Yes you missed something, although being a newbie this could be excused I guess:
    http://docs.oracle.com/cd/E11882_01/appdev.112/e11830/sdo_objrelschema.htm#i1004087 section 2.2.5 clearly states
    "For example, a polygon whose boundary has four two-dimensional points is stored as {X1, Y1, X2, Y2, X3, Y3, X4, Y4, X1, Y1}".

    That as an aside (I always have to think for a moment too when I deal with lat/lon :-) ): You say you are using NAD83, but that is only a datum. Are you using America-wide data or State-wide data? Most States have their own coordinate system based on NAD83 (I'm not sure how many of those are defined in Oracle, but that's easy to check). If you have such data, you should use the appropriate SRID as well.

    Lastly: where is your data coming from? GML or some other XML-based format? Sometimes in GML you'd have to reverse the lat/lon to lon/lat or the other way around with GML, depending a bit on the version of GML and the application creating it. That may also be the cause of your problem.

    HTH,
    Stefan
  • 4. Re: NAD83 lat/long order confusion
    973154 Newbie
    Currently Being Moderated
    Thanks Stefan, I guess that section could be more clear in that the order is always X/Y or Long/Lat when geodetic. Instead, it makes reference to Section 2.8 where the dimensions are defined. Section 2.8.3 DIMINFO states:

    "Spatial assumes that the varying length array is ordered by dimension. The DIMINFO varying length array must be ordered by dimension in the same way the ordinates for the points in SDO_ORDINATES varying length array are ordered. For example, *+if+ the SDO_ORDINATES varying length array contains {X1, Y1, ..., Xn, Yn}, then the first DIMINFO entry must define the X dimension and the second DIMINFO entry must define the Y dimension*."

    The "if" in the second sentence, and the fact that the X/Y ordering is presented only as an example, is what led me to believe that the ordinate ordering was conditional, and to presume that the ordering should be the same as of the specified SRID.

    For this project we are working with geographic data at a national level with distances on the order of 100's of kilometers. We are generating the data internally and using Hibernate Spatial in Java to persist objects of JTS Geometry type (points and polygons).

    Thanks again,

    Marc
  • 5. Re: NAD83 lat/long order confusion
    973154 Newbie
    Currently Being Moderated
    Thanks Stefan, I guess that section could be more clear in that the order is always X/Y or Long/Lat when geodetic. Instead, it makes reference to Section 2.8 where the dimensions are defined. Section 2.8.3 DIMINFO states:

    "Spatial assumes that the varying length array is ordered by dimension. The DIMINFO varying length array must be ordered by dimension in the same way the ordinates for the points in SDO_ORDINATES varying length array are ordered. For example, *+if+ the SDO_ORDINATES varying length array contains {X1, Y1, ..., Xn, Yn}, then the first DIMINFO entry must define the X dimension and the second DIMINFO entry must define the Y dimension*."

    The "if" in the second sentence, and the fact that the X/Y ordering is presented only as an example, is what led me to believe that the ordinate ordering was conditional, and to presume that the ordering should be the same as of the specified SRID.

    For this project we are working with geographic data at a national level with distances on the order of 100's of kilometers. We are generating the data internally and using Hibernate Spatial in Java to persist objects of JTS Geometry type (points and polygons).

    Thanks again,

    Marc
  • 6. Re: NAD83 lat/long order confusion
    973154 Newbie
    Currently Being Moderated
    Thanks Stefan, I guess that section could be more clear in that the order is always X/Y or Long/Lat when geodetic. Instead, it makes reference to Section 2.8 where the dimensions are defined. Section 2.8.3 DIMINFO states:

    "Spatial assumes that the varying length array is ordered by dimension. The DIMINFO varying length array must be ordered by dimension in the same way the ordinates for the points in SDO_ORDINATES varying length array are ordered. For example, *+if+ the SDO_ORDINATES varying length array contains {X1, Y1, ..., Xn, Yn}, then the first DIMINFO entry must define the X dimension and the second DIMINFO entry must define the Y dimension*."

    The "if" in the second sentence, and the fact that the X/Y ordering is presented only as an example, is what led me to believe that the ordinate ordering was conditional, and to presume that the ordering should be the same as of the specified SRID.

    For this project we are working with geographic data at a national level with distances on the order of 100's of kilometers. We are generating the data internally and using Hibernate Spatial in Java to persist objects of JTS Geometry type (points and polygons).

    Thanks again,

    Marc
  • 7. Re: NAD83 lat/long order confusion
    Simon Greener Journeyer
    Currently Being Moderated
    Marc,

    I was surprised at what you said about GeoTools and NAD83.

    Doing some searching all I could find is that GeoTools notes this about the GEOGCS keyword for a Coordinate System WKT:
    "A coordinate system based on latitude and longitude. Some geographic coordinate systems are Lat/Lon, and some are Lon/Lat. You can find out which this is by examining the axes. You should also check the angular units, since not all geographic coordinate systems use degrees."
    So, here, we are talking about the definition of a coordinate system and not the storage of the actual data. The Coordinate System WKT does not mandate actual physical storage of Lat/Long.

    Then you say:
    "Spatial assumes that the varying length array is ordered by dimension. The DIMINFO varying length array must be ordered by dimension in the same way the ordinates for the points in SDO_ORDINATES varying length array are ordered. For example, *if* the SDO_ORDINATES varying length array contains {X1, Y1, ..., Xn, Yn}, then the first DIMINFO entry must define the X dimension and the second DIMINFO entry must define the Y dimension."
    The "if" in the second sentence, and the fact that the X/Y ordering is presented only as an example, is what led me to believe that the ordinate ordering was conditional, and to presume that the ordering should be the same as of the specified SRID.
    The if in the second sentence is not about conditional ordering at all of the actual XY ordinates, it is about ordering of entries that is conditional on the dimensionality of the SDO_ORDINATE array. It is saying that if the data is 2D (X,Y) then the DIMINFO structure must be organised accordingly. It could, just as easily gone on to say:
    For example, if the SDO_ORDINATES varying length array contains {X1, Y1, ..., Xn, Yn}, then the first DIMINFO entry must define the X dimension and the second DIMINFO entry must define the Y dimension.*[Or *if* the SDO_ORDINATES contained {X1, Y1, Z1, ..., Xn, Yn, Zn}, then the first DIMINFO entry must define the X dimension, the second the Y dimension, and the last the Z dimension.]*
    Note that this discussion is about the relationship of metadata to physical storage (ie ordering of the DIMINFO and SDO_ORDINATE data): it says nothing about the relationship of the metadata entries to the actual SRID (ie as defined by its Coordinate System WKT).

    Oracle, like SQL Server Spatial, PostGIS, MySQL etc all store their data in Long (easting), Latitude (Northing) (or X,Y) order. This is so common that when SQL Server back in the 2008 beta put to the testers the question about ordinate ordering for its GEOGRAPHY (not GEOMETRY) data type and WKT/WKB, they ended up being convinced by argument to stick with what everyone else is doing.

    As I implied in the last paragraph, the same ordering issue has been discussed many times about the WKT/WKB that describes the interchange format for spatial data. The common consensus on this is Long/X/E, Lat/Y/N. I have programmed with GeoTools and its XY storage order inside a Geometry object is as per this consensus.

    A coordinate system definition is only that: a definition. Software that processes coordinate systems reads the definition to extract the stored parameters. How that coordinate system is applied to persisted/interchange spatial data formats is more open that one thinks. When being applied, a "mapping" between the two systems is required.

    regards
    Simon
  • 8. Re: NAD83 lat/long order confusion
    973154 Newbie
    Currently Being Moderated
    Thanks Simon for taking the time to explain that - seems that I was inferring something that isn't! It reminds me a bit of the big-endian/little-endian byte-ordering issue where there are two ways to order things and different groups standardize on different ways of doing it.

    I found this page on the GeoTools site which seems to address the issue and provide a means of forcing long/lat ordering: [http://docs.geotools.org/latest/userguide/library/referencing/order.html] .

    Marc

    Edited by: dc_maf on Nov 9, 2012 8:35 AM

    Edited by: dc_maf on Nov 9, 2012 8:35 AM

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points