With repect to what program is a zero eccentricity or 1/f in error??
I encountered the problem using m.datum.shift (in GRASS 4.1);
however, after tracing it to some routines in the GRASS gis
library I suspect it may affect other modules that use these
functions as well.
Upon investigating further, I have discovered that the routine
G_get_ellipsoid_parameters(a,e2) in that library has code
which traps the name 'sphere' and hard-codes its values of
a (radius) and e2 (eccentricity squared, which is set to zero in this
case). This bypasses the call to G_get_ellipsoid_by_name which
reads spheroid parameters from a table, rejecting any for
which e is less than or equal to zero. I don't know why this
one ellipsoid was hard-coded and why the table entries are
rejected if e = 0. Since some modules (m.datum.shift, for one)
call G_get_ellipsoid_by_name directly, the hard-coding of
'sphere' in G_get_ellipsoid_parameters does not get around
this limitation. Entering 'sphere' for one of the spheroid
arguments of m.datum.shift causes a "value out of range" error
since the parser uses the entries in the ellipse.table file,
but creating a 'sphere' entry in that file causes another
error if e=0. Catch-22, n'est-ce pas?
Perhaps I will report it as a bug, but I thought I'd try to
get a handle on what's going on and why first.
-- jim A.