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

[Jonathan Blower]

Hi Martin,

Hm, do you have a feeling for how many differences there are between the wkt database and the official EPSG one?  (Thanks for correcting me about which version is correct, and for pointing me to the official EPSG registry.  I'm very surprised that the official version has n-e axis order as I haven't found a client yet that matches this!)

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

Cheers, Jon

-----Original Message-----
From: geotoolkit-bounces at lists.osgeo.org [mailto:geotoolkit-bounces at lists.osgeo.org] On Behalf Of Martin Desruisseaux
Sent: 22 April 2010 22:58
To: geotoolkit at lists.osgeo.org
Subject: Re: [geotk] Polar sterographic projection axes reversed in Geotk3.10 CRS database

Hello John

Le 22/04/10 23:24, Jonathan Blower a écrit :
> Here's the result of CRS.decode("EPSG.32661").toString() in Geotk 3.10 (referencing bundle):
>
> PROJCS["WGS 84 / UPS North",
>    (...snip...)
>    AXIS["Northing", "South along 180°"],
>    AXIS["Easting", "South along 90°E"],
>    AUTHORITY["EPSG","32661"]]
>
> And here's the result from Geotk 3.04 with the embedded epsg-wkt database:
>
> PROJCS["WGS 84 / UPS North",
>    (...snip...)
>    AXIS["x", EAST],
>    AXIS["y", NORTH],
>    AUTHORITY["EPSG","32661"]]
>
> As you can see, the axis definitions are different, and in reverse order.  I think the ordering from 3.04/epsg-wkt is correct.

 From an EPSG point of view, the authoritative source is the online registry:

   * http://www.epsg-registry.org/
   * Click on "Retrieve by code", enter 32661 in the code field.
   * Click on the "view" link on the right
   * Click on + on the left side of "Axes".

The Geotk 3.10 output is the correct one from an EPSG authority point of view. 
However the Geotk 3.04 output is widely used in practice.

Actually this is not a matter of using Geotk 3.04 or 3.10. I'm pretty sure that 
both of them produce the same result when using the same database or WKT files, 
since that part of the code got no significant change since a long time. It is 
rather a matter of using the EPSG database or the WKT property file.

Maybe one thing that changed is that Geotk 3.10 is compatible with the HSQL 
database (Geotk 3.04 was not). So if HSQL is found on your classpath, Geotk uses 
it automatically. You can check by looking in the Geotoolkit.org directory, 
which should exist in "Application Data" (Windows), "Library" (Mac) or as 
".geotoolkit.org" in your home directory (Linux). If this directory contains a 
EPSG/HSQL sub-directory, the HSQL database has been used. If it contains a 
EPSG/7.05 directory, the Derby or JavaDB database has been used.

> Is there a way to force it to use the epsg-wkt database until a fix is found?

Yes you can force epsg-wkt, but I suggest that you try the following first:

     CRS.decode("EPSG.32661", true)

The boolean 'true' argument means "force longitude axis first". If it doesn't 
fit your need, you can force a particular factory implementation with:

    Hints.putSystemDefault(Hints.CRS_AUTHORITY_FACTORY, YourFactory.class);

	Regards,

		Martin
_______________________________________________
Geotoolkit mailing list
Geotoolkit at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/geotoolkit