Le jeudi 18 janvier 2007 à 17:13 +0100, Andrea Aime a écrit :
> Now, there are a couple of issues here. The first one
> is that CRS.parseWkt has create a lat/lon CRS, whilst
> the EPSG one one has swapped axis.
When the axis are not explicitly given in a WKT, (longitude, latitude)
is assumed. This is a OGC 01-009 specification if I'm remembering right.
> I hope that forcing lon/lat axis would get me a lon/lat
> one out of the epsg database
Yes, for example using CRS.decode(code, true). Or using
Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER.
> because even using AbstractIdentifiableObject.equals(xxx, false) to
> avoid metadata comparison, axis names and such are considered to be
> relevant, and this makes it impossible to compare them.
As a side note, you can also use CRS.equalsIgnoreMetadata(...). This
just a convenient way to invoke AbstractIdentifiedObject.equals(xxx,
false).
But you are right, the axis name are relevant. Those names are
constrained by ISO 19111 specification, table 16 at page 22. According
ISO 19111, those axis names must be "Geodetic longitude" and "Geodetic
latitude". The WKT is in violation with this standard, since WKT
specification in OGC 01-009 said that default axis name should be "Lon"
and "Lat".
So we have a conflict between two standards. Current Geotools code
doesn't try to solve this conflict. But we could add some code in
DefaultCoordinateSystemAxis.equals(...) saying that "Lon" is equivalent
to "Geodetic longitude".
> I would like a more lenient way to do the comparison, that uses
> only the spheroid parameters, the projection parameters, primem, and
> unit. Is there any way to get it?
Current code doesn't do that. We could try to generalize
AbstractIdentifiedObject.equals(..., boolean) method, for example trying
to replace the boolean argument by some Enum object, so we have room for
a variety of comparaison methods. However I'm not sure that we can
compare units if we don't check axis name (how can we know if we are
comparing the units of the same axis?). Futhermore, we may also need a
way to specify a tolerance level in floating point comparaisons.
We may try to first add the special check for "Lon" and "Lat" axis names
since they come from legacy OGC 01-009 specification and see if it
resolve a majority of cases. If it doesn't work well enough, then we
could consider the more complex AbstractIdentifiedObject.equals(...,
SomeEnum) approach. What do you think?
Martin
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
