[geotk] Polar sterographic projection axes reversed in Geotk3.10 CRS database

[Martin Desruisseaux]

Hello John

Le 23/04/10 16:19, Jonathan Blower a écrit :
> Hm, do you have a feeling for how many differences there are between the wkt database and the official EPSG one?

Actually the WKT properties file is derived from the PostGIS "spatial_ref_sys" 
table, and every CRS (including EPSG:4326) in that table assume (long,lat) axis 
order. That table does not handle axis order at all.

You can check by doing a search for the "AXIS" keyword in the "epsg.properties" 
file (or any other WKT file). If the "AXIS" keyword does not appear in the file, 
then that file does not specify axis order at all. In such case, Geotk complies 
with the WKT specification, which mandate that the default axis order shall be 
(long,lat) for every CRS without explicit "AXIS" declaration.

So the question is how many CRS in the EPSG database use anything different than 
the default (long,lat) axis order. The answer is:

   * Almost every CRS of kind GeographicCRS.

   * Some ProjectedCRS used in the South hemisphere
     (South Africa, Australia...)

   * Many polar projections.


> I'm very surprised that the official version has n-e axis order as I haven't found a client yet that matches this!

Many clients violate the specification, which is one raison why the "axis order" 
debate has been so animated at OGC. It was a debate between the "realists" 
claiming that most clients use (long,lat), against the "purists" claiming that 
the EPSG order is used for centuries by geographers, pilots, etc. (actually the 
EPSG job is to declare the axis order in use by the geographers / pilots / 
scientific communities, not the axis order that computer programmers are used to).

The Geotk library (and its GeoTools ancestor) is one of the few referencing 
libraries which try to be very strict about EPSG definitions. Many widely-used 
libraries (even in the C/C++ world) ignore this issue, which is why so many 
client applications has trouble with axis order. PostGIS for example supports 
only (long,lat) in its default installation (I don't know if a user can override 
that).

> Forcing longitude-first axis order didn't make any difference, by the way.

Thanks for reporting that. It sound like a bug then. At the North pole, 
"Northing" and "Easthing" has no meaning since every directions are going toward 
South, so the job is a little bit harder. The "Force longitude first axis order" 
parameter is supposed to be actually "Force a right handed coordinate system", 
which work everywhere (including poles). But is sound like that it didn't worked 
for EPSG:32661 since

     AXIS["Northing", "South along 180°"],
     AXIS["Easting", "South along 90°E"]

is left-handed. I will investigate that when I will have a bit of time...

	Regards,

		Martin