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