[MetaCRS] failed epsg wkt (geotools)
Christopher Schmidt
crschmidt at metacarta.com
Tue Dec 16 09:08:13 EST 2008
On Tue, Dec 16, 2008 at 02:41:30PM +0100, Martin Desruisseaux wrote:
> 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).
Ah, okay. So the org.geotools.referencing.CRS.decode() function is not
yet in that code? THat's the only function I'm using so far :)
>
> >> * 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.
Gotcha. Do you have a feeling as to whether there are cases where even
that will fail? I'm curious as to whether, in the end, we're really
going to be able to have "one true" WKT for a given projection, or if
there are multiple "Best answers"... and people will want all of them.
For me, the EPSG database is a bit of a bear to trawl through, so
perhaps this is an easy answer I just don't know. (I suppose if I had MS
Access, it might not be as terrible; perhaps someone has built UIs into
the access DB to make moving through it less painful.)
The reason I ask is that it helps direct whether we need to extent
SR.org to support multiple versions of the same SRS, or simply keep
improving our loading tools to pick the "right" one.
Hm, it seems that GDAL actually gives the 'correct' parameter set for
the code in GEOT-1179 (EPSG:4312). Now I'm just confused, since I
thought that GDAL didn't include these... ahh, I see, this one is in
gcs.override.csv, presumably that is a manually maintained file which
offers these parameters. I suppose I should really go read and
understand the code that is doing this before I get myself in a tarpit
by thinking I have any clue what I'm talking about :)
Regards,
--
Christopher Schmidt
MetaCarta
More information about the MetaCRS
mailing list