[GRASS5] Fixing up projection related code...

Frank Warmerdam warmerdam at pobox.com
Sun Feb 2 17:18:54 EST 2003


Paul Kelly wrote:
> Should the default logic be to use the most accurate transformation (tables)
> if it's available, then 7-parameter, falling back to 3-parameter if there
> is nothing else in the datum.table?

Paul,

First an observation.  It is hard in many cases to establish which is
the more accurate transformation. For instance if you have two three
parameter transformations, which is best?  The answer is that likely
either is best for a particular area. That is, it is common to generate
an assortment of datum shifts, each appropriate for some subarea where
the datum is used.   Even in cases like datum shift files where some
are high precision, but local to a region, it is hard to automatically
determine which is best.

This is not a problem I have dealt with well in PROJ, just punting and
leaving it up to the user to select an appropriate transformation.

In EPSG they list all the transformations, and the descriptions generally
contain information useful to the user in selecting the best for their
situation.

The most general solution then would likely be maintaining a list of
datum shift options for any given datum, each having some descriptive
text that can be offered to the user when setting up their location
(in g.setproj?).

A slightly easier approach would be to have a datum name for each
possible transformation.  This is what they do in MapInfo for instance.
So you might have nad27-conus, nad27-ntv1, nad27-HPGN, each represening
a different approximation for shifting to WGS84.  This is likely what
I would suggest in your case.  The downside is that if a user select nad27
it may be difficult to automatically determine a list of all the datum
names that could apply.

> Eric suggested above that programs could pass on a preferred type of
> transform, but what if that's not available in the table? 

I do think that import programs that report projection information, or
offer to setup new locations (like r.in.gdal) should offer the transformation
used if possible.

Best regards,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent





More information about the grass-dev mailing list