Lenien datum comparison fails because of different ivDefinitive values
----------------------------------------------------------------------
Key: GEOT-1411
URL: http://jira.codehaus.org/browse/GEOT-1411
Project: GeoTools
Issue Type: Bug
Components: core referencing
Affects Versions: 2.4-M4
Reporter: Andrea Aime
Assignee: Martin Desruisseaux
Fix For: 2.4.0
Comparing two datums in lenient mode may fail because of different ivDefinitive
value.
>From the mailing list:
I'm playing with some raster data and I'm having issues
with datum comparison. Basically, the file is the world
image type, with a .prj file that contains the exact
dump of the EPSG:26713 CRS.
The main problem here is that the CRS resulting from decode
is not the same as the one got from parsing the WKT, the
difference being in the "ivfDefinitive" parameter, which
is used for comparison (even the lenient verision of it).
The following program demonstrates the behaviour:
{code}
import org.geotools.referencing.CRS;
import org.opengis.referencing.crs.CoordinateReferenceSystem;
public class TestConversion {
public static void main(String[] args) throws Exception {
CoordinateReferenceSystem crs1 = CRS.decode("EPSG:26713");
CoordinateReferenceSystem crs2 = CRS.parseWKT(crs1.toWKT());
System.out.println("Equal: " + CRS.equalsIgnoreMetadata(crs1,
crs2));
System.out.println("Transform: " + CRS.findMathTransform(crs1,
crs2));
}
}
{code}
It's output being:
{code}
Equal: false
Transform: CONCAT_MT[INVERSE_MT[PARAM_MT["Transverse_Mercator",
PARAMETER["semi_major", 6378206.4],
PARAMETER["semi_minor", 6356583.8],
PARAMETER["central_meridian", -105.0],
PARAMETER["latitude_of_origin", 0.0],
PARAMETER["scale_factor", 0.9996],
PARAMETER["false_easting", 500000.0],
PARAMETER["false_northing", 0.0]]],
PARAM_MT["Molodenski",
PARAMETER["dim", 2],
PARAMETER["dx", 0.0],
PARAMETER["dy", 0.0],
PARAMETER["dz", 0.0],
PARAMETER["src_semi_major", 6378206.4],
PARAMETER["src_semi_minor", 6356583.8],
PARAMETER["tgt_semi_major", 6378206.4],
PARAMETER["tgt_semi_minor", 6356583.8]],
PARAM_MT["Molodenski",
PARAMETER["dim", 2],
PARAMETER["dx", 0.0],
PARAMETER["dy", 0.0],
PARAMETER["dz", 0.0],
PARAMETER["src_semi_major", 6378206.4],
PARAMETER["src_semi_minor", 6356583.8],
PARAMETER["tgt_semi_major", 6378206.4],
PARAMETER["tgt_semi_minor", 6356583.8]],
PARAM_MT["Molodenski",
PARAMETER["dim", 2],
PARAMETER["dx", 0.0],
PARAMETER["dy", 0.0],
PARAMETER["dz", 0.0],
PARAMETER["src_semi_major", 6378206.4],
PARAMETER["src_semi_minor", 6356583.8],
PARAMETER["tgt_semi_major", 6378206.4],
PARAMETER["tgt_semi_minor", 6356583.8]],
PARAM_MT["Transverse_Mercator",
PARAMETER["semi_major", 6378206.4],
PARAMETER["semi_minor", 6356583.8],
PARAMETER["central_meridian", -105.0],
PARAMETER["latitude_of_origin", 0.0],
PARAMETER["scale_factor", 0.9996],
PARAMETER["false_easting", 500000.0],
PARAMETER["false_northing", 0.0]]]
{code}
As you can see, that minor difference in the Ellipsoid definition
triggers the generation of a quite expensive transform (which would
probably end up being an identity, haven't checked thought).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
