Hi all,
i need some input on implementing datum support into GRASS. Please give
me some advice on the questions below.
1. A datum shifting function is now integrated into proj4, so that this
library could be used instead of my changes to the coorcnv library. But
there are difficulities with interfacing this function with GRASS, so
that i plan to check in my version first. Maybe i'll later integrate the
new proj library.
2. There are several different methods for the datum
shifting/transformation with differing accuracy.
Block Shift method: 10-25 m accuracy,
Molodensky Transformation: 10 - 5 m accuracy,
Bursa-Wolf Transformation/7-Parameter-Tr.: 5-1 m accuracy.
As processing power is no limitation today it is theoretically possible
to use always the best available method, but the problem is that the
molodensky and the bursa-wolf transformation use different parameters
and i don't know of a source for a complete list of the 7 parameters for
the bursa-wolf transformation.
So there are mainly two things that could be implemented:
- only use Molodensky transformation with a complete list of datums
(120) and an accuracy around 10 m (this is done with e. g. garmins gps
receivers);
_or_
- implement a system where with every location the method used is saved
and the appropretiate formula is applied, with accuracy from 10 m
(Molodensky) down to 1 m (Bursa-WOlf). Two datum lists, one for 3
parameter Molodensky, one for 7-parameter Bursa-wolf (this is done with
many commercial GIS packages).
I don't know which accuracy is needed with GRASS, as this depends on the
resolution and the sort of data to be processed. Could please tell me
someone if there are GRASS applications that use resolutions with
sub-meter or meter range and interface with programs that use datum
shifting?
3. I want to implement the lists for the datum shifting parameters in
parallel to the ellipsoid table. There will be an additional datum.table
(and a datum7.table?), the short name of the datum and the shifting
parameters are saved to the PROJ_INFO file of the PERMANENT mapset. New
functions will provide reading of these values. g.setproj will be
changed to support this.
4. The map datum defines an ellipsoid. On creation of the location the
user will be asked to provide a datum, there will be no need to provide
an ellipsoid. Is this ok or will this confuse users?
5. One should always bear in mind that the datum shifting provides only
approximated solutions and that the accuracy depends on the formula used
and on the spatially applicability of the parameters (you can calculate
regional shifting parameters that give accuracy in the 1 m range). This
is different from the projection/inverse projection, which can be
reversed and provides exact results.
One additional problem within 2D and 2.5D GIS is that the height
component of the datum transformation is always lost/discarded, so that
if you shift several times (e. g. from local datum to wgs84 and back)
errors will creep in. I don't know if this is a problem in praxi,
perhaps someone could comment on this.
Thank you very much for you patience,
cu,
Andreas
--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange@Rhein-Main.de - A.C.Lange@GMX.net
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'
Clarke
Clarke