On Mon, 15 Sep 2003, Deuchler, Christoph wrote:
Hi,
while playing around with different locations I encountered the following
problem (it is possible that this is already fixed in a new version (I
tested this with 5.0.0)):
When creating a lat/lon location on a sphere with a *different* than the
default radius, it seems that the entered user radius is ignored.
It is not really supported to have custom ellipsoids; you can have a
custom datum but for a custom ellipsoid you have to edit the system
ellipse.table file (e.g. as installed in
/usr/local/grass5/etc/ellipse.table) You do not have to recompile or
re-install so you can do this even with a binary distribution and it is
nice and easy to do.
I tried there now with 5.0.0pre5 and had the same problem; I can't
remember changing it but the latest g.setproj doesn't ask for a radius and
perhaps I just deleted it because it didn't work. It might be a nice idea
to put it back in and write the PROJ_INFO properly though, especially as
sphere still seems to be being handled as a special case in the code.
I tested
it using the module r.profile for measuring the distance between two points
(0,0 and 0,45). The results show that the default radius (6370997m) is used
for calculation, not the user radius.
The file PROJ_INFO also just states ellps: sphere, not the user radius.
If you delete the
ellps: sphere
line and add
a: 6370997
b: 6370997
or whatever radius you want, that should work.
When
using a projected location everything works fine (tested with merc), the
PROJ_INFO file also contains the radius in this case.
Yes the sphere case seems to be handled separately in the g.setproj code,
can't see why it should be like that but I'm sure there is a reason....
This problem seems irrelevant when approximating the earth as a sphere, but
in the case of planet Mars for example the distances are 100% off.
Thanks for the bug report, good to have it documented anyway
Paul