[geotk] Some questions about Geotoolkit CRS objects

[Martin Desruisseaux]

Hello Jon

Le 26/01/10 23:54, Jonathan Blower a écrit :
> 1) Are the hashCode() and equals() methods always defined properly on
> these objects?  In other words, can I safely use them as keys in a
> HashMap?

Yes :) They are already used in HashMap in other parts of the library.


> 2) If I have a CRS object that I got from CRS.decode(), then I find a
> MathTransform to WGS84 using CRS.findMathTransform(crs,
> DefaultGeographicCRS.WGS84, true);  (i.e. being lenient about datum
> changes), can I always expect this to succeed?  In other words, how
> likely is it that I'll get a FactoryException from findMathTransform?

For 2D horizontal CRS created from the EPSG database, I have no example in mind 
of case that could fail.

Generally speaking, it could fail for 3D CRS having a geoidal height, or for a 
2D CRS of type EngineeringCRS.

Note however that even if the Math.findMathTransform(...) succeed, the call to 
MathTransform.transform(...) could fail or produce NaN or infinity values if the 
coordinate to transform is far from the area of validity of the map projection.


> 3) How reliable is CRS.lookupEpsgCode()?  Can I "usually" expect this to
> work correctly as the inverse of CRS.decode()?

I suggest a two step process:

1) Use CRS.getDeclaredIdentifier(...). This is cheap and always work when
    the CRS contains an authority element (this is always the case for CRS
    created from the EPSG database, or parsed from a WKT that contains a
    AUTHORITY element).

2) If the abore returns null, try to more extensive CRS.lookupEpsgCode(...).
    This is sensitive to rounding error. In current version, all parameters
    (ellipsoid axes length, etc.) must be identical to the ones declared in
    the EPSG database.

Note that it is possible to not do 1 and do 2 directly. The "advantage" of 1 is 
that it does not check if the parameters are identical to the ones declared in 
the database, so you are not hurt by rounding error. The advantage of 2 is that 
it always check if the authority code really matches the declaration in the 
database, so it is robust to erroneous authority code.

	Regards,

		Martin