[MetaCRS] failed epsg wkt (geotools)

[Martin Desruisseaux]

Christopher Schmidt a écrit :
> Is geotidy in a branch, or if I use the 2.6 development jar, do I get
> the more correct/recent behavior? 

It is like a branch. GeoTools 2.6 does not contain the fixes yet. GeoTools will
hopefully contains the fixes after Geotidy is merged back to Geotools.

Actually geotidy is on its own source code repository (available as anonymous
user) at http://hg.geomatys.fr/geotidy/

In the future (when it will be ready) we will propose to replace the GeoTools
metadata, referencing and coverage modules by the geotidy ones. Geotidy is a
major cleanup of geotools code by the main author of the above-cited modules.
The scope is limited to those modules for now.

Nightly builts can be downloaded from the Maven repository
(http://geotidy.geomatys.fr/repository/org/geotools/). For convenience, we also
provide "everything in one JAR" file, so you don't have to worries about
dependencies: just one JAR to put in the classpath and everything is there.
Instructions and download link at http://geotidy.geomatys.fr/bundles.html

The factories that create CRS from EPSG code are not yet ported. This is my next
steps after I finished the cleanup of projection code (derived from Proj4 code).


>>   * The TOWGS84 string, while extracted from the EPSG database, are
>>     not always the most appropriate one when EPSG defines many datum
>>     shift for the same CRS. This is an issue I plan to fix soon.
> 
> How do you plan to fix this? As I understand it, these EPSG codes
> actually have multiple 'correct' forms. This is on the plate for sr.org
> to deal with as well, but not done yet. I believe that GDAL's approach
> to this thus far has been to not export any WKT when there are multiple
> correct ones (or something along those lines).

Yes, last time I talked with Frank, he told me that Proj4 do not export any
TOWGS84 in that case.

On the GeoTools side, this issue is discussed there:

    http://jira.codehaus.org/browse/GEOT-1179

The above link contains the SQL statement that we currently use as the
criterion. Basically we looks first in non-deprecated entries. If there is more
than one non-deprecated entries, we look for the most accurate one. If there is
more than one entry with the best accuracy, we look for the one having the
highest code on the assumption that they were typically introduced later.

The above works for many cases, but of course not always. The proposed
improvement is to take the area of validity in account. Most Projected CRS
defined in the EPSG database have an area of validity. We could search for a
TOWGS84 element having an area of validity that contains the ProjectedCRS area
of validity.

	Martin