[GRASS5] coordinate conversion library/datum support

[Andreas Lange]

Hi all,

i checked in the new cc library with rudimentary datum support.

Now that i have implemented this (at least partly) i know how it can be
done better. 

I'll first describe some general problems with datum support in GRASS
and then give some summary of how it should be implemented in future.


The general problem with datum support in GRASS is the flexibility of
GRASS. You can use GRASS for analyzing data from the microscopic to
global scale. But datum transformation makes only sense in the range
from 1:50.000 to 1:1000 (and the precisision of the calculations used
within GRASS (block shift, molodensky formula) is about 15 meters, so
that for ratios bigger than 1:25.000 the accuracy is not sufficient). 

As the programmer has no means to control or know the ratio, the user is
here on his own to check. I would be glad for any comments or ideas for
improvements. 


My ideas for a real implementation:
g.setproj asks if datum support is needed for the location. If yes, the
datum parameters are saved to the PROJ_INFO file, if not, the PROJ_INFO
file has no datum parameters (or an entry datum=none?).
All modules that import or reproject data must check a) if the location
supports a map datum, b) if the data require datum transformation and c)
if the source data support a map datum (if it is known). 
The datum transformation itself should be done transparently with the
new functions from PROJ4.4.2. I think it should be possible to use the
proj string for the datum, too. 

The main problem is the overhead for the calculation, as with projected
data, each and every point must be 1) inverse projected to latlong, 2)
converted to geocentric coordinates, 3) datum shift added (for 7
parameter shift a scale factor is applied additionally), 4) converted
back to geographic coordinates and 5) projected back to the projection
the dataset is in. Further complications and overhead come from that the
applicability of the formula must be checked. This procedure should be
shortcut if not needed, so that if both datums are identical or both
datasets do not support a map datum, the data must not be fed through
the above procedure. But what if the source data has no map datum and
the destination dataset has?

Additionally i think that the PROJ_INFO and data header system in GRASS
should be improved in a way that allows to save the metadata within the
actual dataset (e. g. projection and map datum within cell header for
raster files). 
The function G_get_projinfo should be changed in a way that for
locations with a missing PROJ_INFO file (GRASS 4.x) valid parameters are
returned, not an error. This was suggested by Frank Warmerdam, are there
any objections to such a change?


I have checked in a program s.datum.shift, which allows to do a datum
transformation on sites files within a mapset. This is not a supported
new module, i needed it to test the library and it can serve as an
example on how to do this. The functionality should be included in
s.proj later (and r.proj/v.proj).


If you have further suggestions please mail to the list. I would be
happy to get any feedback, 

cu,

Andreas 

-- 
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange at Rhein-Main.de - A.C.Lange at GMX.net



---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'