[geotk] Finding a CRS code/URN from a CoordinateReferenceSystem object

[Calum.Byrom at tessella.com]

Tessella Ref: NPD/6091/PR/TN/2009JUN19/12:11:41

Thanks Martin - I've tried your suggestions.  Results as follows:

Setting:

Hints.putSystemDefault(Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER, 
Boolean.TRUE);

doesn't appear to have any effect on produced results.

Using:

String code = ((AbstractAuthorityFactory) 
CRS.getAuthorityFactory(true)).getIdentifiedObjectFinder(CoordinateReferenceSystem.class).findIdentifier(crs);

reliably produces the same result as CRS.lookupIdentifier(crs, true); - I 
still can't get back any valid results when specifying the Citations 
object.

I've noticed for other CRS objects (e.g. 
DefaultVerticalCRS.GEOIDAL_HEIGHT), as well as the test object, I also get 
back null values - is this as you'd expect?

NB, I've tried the various different combinations of using the above with 
the different inputs to lookupIdentifier, and get the same results as per 
my last email.

Regards,

Calum.




Martin Desruisseaux <martin.desruisseaux at geomatys.fr> 
19/06/2009 11:24

To
Calum.Byrom at tessella.com
cc
Jon Blower <j.d.blower at reading.ac.uk>, Geotoolkit at lists.osgeo.org
Subject
Re: [geotk] Finding a CRS code/URN from a CoordinateReferenceSystem object






Hello Calum

Calum.Byrom at tessella.com a écrit :
> Thanks for the quick response.  As requested, crs.toString() gives:
> 
> GEOGCS["ED50",
>   DATUM["European Datum 1950",
>     SPHEROID["International 1924", 6378388.0, 297.0]],
>   PRIMEM["Greenwich", 0.0],
>   UNIT["degree", 0.017453292519943295],
>   AXIS["Longitude", EAST],
>   AXIS["Latitude", NORTH]]
> 
> (...snip...)
> 
> the test data returns 'null' for CRS.lookupIdentifier(Citations.EPSG, 
> crs, true) - and for any combinations of the input parameters;

In the EPSG database, the axis order for geographic CRS is (latitude, 
longitude). The CRS posted above has the opposite axis order (as we can 
see from 
the AXIS[...] elements). Consequently by default the lookupIdentifier 
methods 
consider that the given CRS doesn't match the definition in the EPSG 
database.

It is possible to force the library to treat axis order as if it was 
(longitude, 
latitude) despite what EPSG define. There is two way of doing that: you 
can set 
the (longitude, latitude) axis order on a system-wide basis (convenient if 
you 
are sure that all your data are that way, but not recommanded if you need 
to 
deal with latest OGC standards like WMS 1.3.0 and above):

   Hints.putSystemDefault(Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER, 
Boolean.TRUE);

or you can force the (longitude, latitude) axis order on a case-by-case 
basis:

   String code = ((AbstractAuthorityFactory) 
CRS.getAuthorityFactory(true)).getIdentifiedObjectFinder(CoordinateReferenceSystem.class).findIdentifier(crs);


> the 'real' data returns 'CRS:84' (what I'm actually looking for!) for 
> CRS.lookupIdentifier(crs, true) but 'null' for any other combination of 
> inputs.

CRS:84 is defined by the WMS specification as (longitude, latitude) - at 
the 
opposite of what EPSG define - so this matches your CRS. Other combinaison 
of 
parameters will consider that there is no match if the specified authority 
is 
Citations.EPSG, unless axis order has been forced as described above.


                 Martin

P.S.: I may be away of internet for the next week, since I'm traveling to 
the 
OGC meeting. So I may be slow in answering the next emails.







-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/geotoolkit/attachments/20090619/e161a88a/attachment-0001.html