[GRASS-dev] Re: gui startup bug (new locn by epsg code)

[Paul Kelly]

On Tue, 30 Jan 2007, Michael Barton wrote:

> Finally, if the EPSG file contains incomplete projection information for
> some entries, shouldn't that be fixed with whoever supplies this file? If
> this becomes a useful way to create locations in GRASS, it needs to be an
> accurate and complete list of projection parameters.

The problem with that is that the choice of datum parameters is a 
subjective decision. It depends on the area covered by the user's data and 
the accuracy they require. There are many choices of datum transformation 
parameters for a particular datum - sometimes there is an indication that 
one is a good default, but often there isn't, and there isn't a universal 
way of determining this anyway (e.g. AFAIK some countries have laws passed 
that say a datum is actually defined by its relationship to WGS84 through 
a particular transformation). But a lot of datums are defined in other 
ways and the relationships to WGS84 are only an approximation.

We are also somewhat constrained by the historical structure of the datum 
tables in GRASS and the need for backward compatibility with existing 
locations. The original structure (dating from the late 90s or so) was 
based on the erroneous premise that there *was* only one correct set of 
parameters for each data, hence there are now two datum tables - 
datum.table and datumtransform.table. It is annoyingly complicated.

Paul