[GRASS5] coorcnv library

[Andreas Lange]

Hi, 

as announced last week my work on the coorcnv library has reached a
stadium where i need some input from others.

I changed the library to support a central datum.table (in $GISBASE/etc)
like the ellipse.table for ellipsoid parameters. 

As the library until now used hard-coded values for the ellipsoid
parameters (a, e2), i had to write wrappers to call
G_get_ellipsoid_by_name from gislib. Are there any objections to this
setup?
This is not a clean design, but it keeps backward compatibility and
makes this maintainable, as hardcoded ellipsoid values can not be kept
in sync with the ellipse.table. 

I had to add a new function (G_get_spheroid_by_name) to gislib, because
the datum shift functions need an additional parameter (f, reciprocal
flattening) from the ellipsoid table. 

The introduction of full map datum support needs many changes (that i
have not the time and resources to make), but with the changes to the
library this is possible and can be done succesively / on a
as-needed-basis. 

The datum shift functions (Block Shift, Molodensky, Bursa-Wolf) are not
very well tested until now, but i verified that they give correct
results on examples i found on the web and the values are consistent
with the values my GPS receiver calculates. I optimized the code not for
speed, but for best readability and maintainability. I wrote a new
m.datum.shift with the new function calls. 

I verified that the above changes and all depended modules compile (i
recompiled the whole grass5.0beta7 source tree), i will test them on
IRIX later. 

Later i want to include all map datums that are used by common GPS
receivers (121 on garmin gps), but this requires adding some more
ellipsoids to ellips.table. Any objections to this?

I would be glad to get comments, if you want to get the source code,
please contact me. I hope that i will be able to commit the changes to
CVS in the near future, but i hesitate to make the changes to the
default/stable branch. When will the branching to the
development/unstable branch be done?


Andreas

-- 
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange at Rhein-Main.de, A.C.Lange at GMX.net
-------------- next part --------------
This are the neccessary steps to get 
full map datum support within GRASS:

- change coorcnv library calls to use $GISBASE/etc/datum.table
done.

- change coorcnv library to use ellipsoids in 
$GISBASE/etc/ellipse.table
done.

- add datum support functions to coorcnv library:
datum shift parameters:
+ CC_get_datum_by_name
+ CC_get_datum_by_nbr
x CC_datum_name
x CC_datum_description
+ CC_datum_ellipsoid
x CC_datum_shift -> CC_get_datum_parameters
+ CC_get_datum_parameters

spheroid/ellipsoid parameters:
(only wrappers for libgis calls!)
* CC_get_spheroid
* CC_spheroid_name
+ CC_get_spheroid_by_name
+ CC_get_spheroid_by_nbr
+ G_get_spheroid_by_name (for f parameter)

datum shift routines:
+ CC_datum_shift_Molodensky
+ CC_datum_to_datum_shift_M
+ CC_datum_shift_CC
+ CC_datum_to_datum_shift_CC
+ CC_datum_shift_BursaWolf
+ CC_datum_to_datum_shift_BW

others:
+ CC_geo2lld
+ CC_lld2geo

symbols:
? not known
x changable, because not used in any module
* existing, not changable
+ new
  not yet implemented
mostly done, needs testing. 

- change m.datum.shift to new library calls
done, needs testing. 

- add functions for low-level datum support to gislib 
(in analogy to the ellipsoid and projection functions):
add a MAPDATUM_FILE to every PERMAMENT mapset of locations
_or_ add datum parameters to PROJ_INFO file ?
proposed format: 
datum:  acronym
ellips: acronym -> not neccessarily needed, redundant
dx: -> dto.
dy: -> dto.
dz: -> dto.
a:  -> dto.
e2: -> dto.
f:  -> dto.

- add a function to read the datum parameters for the 
actual location (parallel to G_get_ellipsoid_parameters)
  G_get_datum_parameters(a, e2, f)

- add G_ask_datum_name for interactive use in modules
  G_ask_datum_name

- change all modules that create new locations to
ask the user for a map datum and to create MAPDATUM_FILE
or add to PROJ_INFO file.

- change all modules that do projection or data-import 
to use datum conversion:
v.proj
r.proj
s.proj
r.in.*
v.in.*
etc.

Please note that i am only involved with the first steps of 
changing the library to support map datums. The changes in 
the modules must be done by other GRASS developers or
the module maintainers.

Andreas Lange, 05/2000,
andreas.lange at rhein-main.de