Farber, Saul (ENV) a écrit :
> So *why* are these two WKT's not equal? Well, I can see that the
> standard_parallel_1 and 2 are 'inverted' (switched?) between the two...is
> that the cause? When I stepped through the code with a debugger, I found
> that the 'equalsIgnoreMetadata' seemed to bail on the AXIS["Easting" vs
> AXIS["x" difference.
The difference in axis name may be the cause. In current Geotools
implementation, the name is ignored for every objects except Datum and Axis,
because names are the only way to distinguish between different Datum or Axis.
Example:
AXIS["Ellipsoidal height", UP]
AXIS["Geodial height", UP]
are really two different axis (conversions between them require a geoidal model)
and the name is the only way to distingish them.
Axis names are strictly defined by ISO 19111 (Table 18 at page 30 in 2004
edition). The "x" and "y" names do not follow the ISO 19111 standard (the axis
names should be "Easting" and "Northing"), but they are obviously in wide use. A
similar problem occured for "Lat" (wide use in WKT) and "Geodetic latitude"
(official ISO 19111 name). Geotools DefaultCoordinateSystemAxis treats them as
special case (synonymous); I will add "x" vs "Easting" as other special cases on
trunk (you will know it is commited when SVN will see a change in
DefaultCoordinateSystemAxis).
> So my question is: Should those two CRS's be equalsIgnoreMetadata()? And if
> they're not, is it the AXIS that's the culprit, or is it the
> standard_parallel1/2? And if they *are* different, which one is the correct
> one (for 26986)?
Axis name is a cause. The standard_parallel1/2 may be an other cause, I don't
know yet (we will see after the addition of "x" vs "Easting" special case).
Could you post the following please?
System.out.println(CRS.findMathTransform(crs1, crs2));
> Is it at all possible that the EPSG database has a bug in it that has
> inverted the _1 and _2 standard_parallels?
If you have the chance to navigate in an EPSG database in some way (do you have
MS-Access? I don't have it since I'm on Linux), it would be worth to check for
the parameters in the EPSG database, in order to make sure that
standard_parallel1/2 are really like that in the database.
I don't know if the parameter order is significant for standard_parallel1/2. We
will need to check the projection formulas. If the parameter order appears to
not be significant, we could make the referencing module more "intelligent" in
order to detect those cases, but we would need to open a JIRA task with a
description like this:
"Add a MapProjection.equivalent(MapProjection) method
A MapProjection.equivalent(MapProjection) method could performs a work similar
to MapProjection.equals(Object), but check only for field values relevant to
'transform' and 'inverseTransform' methods. The purpose is to detect
MapProjection that are equivalent even in the case were parameters where
specified in a different but equivalent way. It would allows
CRS.equalsIgnoreMetadata(...) to returns 'true' in some situations where it
currently returns 'false'."
Would you be okay for opening such a JIRA task? I don't know when I will be able
to work on it...
Martin
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
