[GRASS5] Fixing up projection related code...

[Paul Kelly]

On Mon, 26 Aug 2002, Eric G. Miller wrote:

> I've been looking at some of the projection related code, and I'm
> trying to come up with a course of action to clean it up in places.
> Eventually, this should result in:
>

...

> 4.  Have transparent handling for a variety of datum transformations
>     incorporated into the library wrappers for proj4.  Most of the
>     necessary work for the transformations has been done by Andreas
>     Lange, it's a matter of working in the strategies.  Perhaps the
>     programs can pass on a preferred stategy when specified by the
>     user (for instance, NADCON vs. Bursa Wolf).  Get rid of GRASS
>     copy of proj4 and make a dependency on proj4 >= whatever version.
>     It should be a fatal error if a datum transformation is impossible.

I have already done half of this. Now to separate the GRASS dependency on
a local copy of the PROJ.4 source, I need to extend the GRASS datum.table
format to allow more than the simple 3-parameter dx dy dz datum
transformation parameters it stores at present.

I intend to use the same keywords as PROJ.4, i.e. towgs84 for the
7-parameter transform (and optionally for the 3-parameter[1] ) and
nadgrids for the (NADCON?) American grid-shifting tables. I intend to
allow more than one set of transform parameters for each datum (it doesn't
seem right to delete anything from the table), but what I'm not sure about
is which should be used.

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?

Eric suggested above that programs could pass on a preferred type of
transform, but what if that's not available in the table? It would seem a
bit awkward to implement, making the system less transparent. Perhaps the
new improved g.setproj could allow the user to set which transformation
they wanted before running the re-projection command, and this could be
explained in the documentation for those commands?

That's what I'm leaning towards at the minute, but I haven't convinced
myself it's the best way. I was wondering does anyone know how it is
implemented in other GIS systems?

To summarise what I'll do if there are no better suggestions:
1. By default use the most accurate transformation available in the GRASS
datum.table
2. Explain this in the man pages / documentation for the re-projection
commands, and explain how the user can define his/her own datum
transformation parameters.


[1] In PROJ.4, 'towgs84=' should be followed by a comma-separated list of
numbers. If there are 3 numbers a 3-parameter transform is assumed; if 7
it is assumed a 7-parameter transform was intended.


Paul.