On Thu, 14 Jan 2010, Karl Ove Hufthammer wrote:
On Thu, 14 Jan 2010 12:27:04 +0100 (CET) Roger Bivand
<roger.biv...@nhh.no> wrote:
So in principle geod.dist() and spDistsN1(..., longlat=TRUE) should yield
equivalent results, because their assumptions are the same.
Several of the references suggest that the geographic pole should not be
input. It looks as though the oce implementation handles this more
gracefully than sp.
Hope this helps,
It does. Thanks.
BTW, is there a reason 'spDistsN1' handle longitude 360 different from
longitude 0? For example, the distance between 0,0 and 0,0 is 0, but the
distance between 0,0 and 360,0 is about 1e-12. This is of course not a
problem; I was just wondering on the reason (since 360,0 is for all
practical *correctly* handled -- it's just not handled equal to 0,0).
The C function now tests for equality in the longitude and latitude pairs,
but arguably should catch this. Equality is taken here as an absolute
difference of less than .Machine$double.eps, about 2.220446e-16. I've
committed a change to sourceforge, setting distance to 0.0 for
(|lat0 - lat1| < fuzz) && (|lon0 - lon1| < fuzz)
as before, but also:
(|lat0 - lat1| < fuzz) && (((|lon0| + |lon1|) - 360.0) < fuzz)
which seems to handle your case, and others - like -170, 190. Comments
welcome.
Roger
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: roger.biv...@nhh.no
_______________________________________________
R-sig-Geo mailing list
R-sig-Geo@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
