Martin,
Thank you *very very much* for your great detailed explanation of exactly what
the hang-ups might be.
I'm going after the (hopefully easier) AXIS alias problem first, hoping that
after that these two CRS definitions will wind up being equivalent.
To do this, I added a few keys to the ALIASES map, something like the following:
ALIASES.put("x", EASTING);
ALIASES.put("y", NORTHING);
ALIASES.put("easting", EASTING);
ALIASES.put("northing", NORTHING);
I had hoped that this would allow the axis comparison logic to 'find' the
relationship between "x" and "easting"
However, after adding this code, I have unveiled another problem. When
initializing the sde-returned CRS (see first email) I get the following
exception:
...
Caused by: java.lang.IllegalArgumentException: Direction "DISPLAY_RIGHT" is
inconsistent with axis "x".
at org.geotools.referencing.cs.AbstractCS.<init>(AbstractCS.java:209)
at
org.geotools.referencing.cs.DefaultAffineCS.<init>(DefaultAffineCS.java:113)
at
org.geotools.referencing.cs.DefaultCartesianCS.<init>(DefaultCartesianCS.java:209)
at
org.geotools.referencing.cs.DefaultCartesianCS.<clinit>(DefaultCartesianCS.java:138)
I thought about this for a bit, and eventually decided that this is weird.
DISPLAY_RIGHT (as in, the x-axis is the right-left axis) seems to make good
sense to me.
I'm going deeper into this code right now, but I was just curious if you had
any pointers as to what's going on, or whether I've started down the right path.
thanks much!
--saul
________________________________
From: [EMAIL PROTECTED] on behalf of Martin Desruisseaux
Sent: Fri 5/11/2007 10:02 AM
To: Farber, Saul (ENV)
Cc: [email protected]
Subject: Re: [Geotools-devel] ArcSDE, EPSG and projections
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
-------------------------------------------------------------------------
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
