Wed, Aug 17 2005
17:31:37
|
|
Request created by guest
|
|
Subject: distance calculation in s/v.surf.idw wrong in lat/lon projection
Platform: GNU/Linux/i386
grass obtained from: Trento Italy site
grass binary for platform: Downloaded precompiled Binaries
GRASS Version: All
My name is Tye Parzybok (tyep@metstat.com) and I've been a happy, loyal GRASS
software user for over 10 years. I recently discovered that when using the old
s.surf.idw (new v.surf.idw) function in a "geographic" projection (i.e. lat.lon)
and with points in lat/lon, the distances computed DO NOT account for convergence
of the meridians. What needs to be done, and I've done this with an old (4.2)
version of GRASS, is the same logic used in r.surf.idw -- which computes distances
from raster to raster along a geodesic -- needs to be added to the s/v.surf.idw
function. Since the distance units aren't important to IDW, it doesn't matter
what you use, but they need to represent a true distance (in say meters) instead
of a straight line (Euclidean) decimal degree distance.
Here is the distance calculation I used in my modified version of s.surf.idw.
The distance units are in km and I assume the earth is a perfect sphere (using
a better spherical representation would make this even better). This first part
of this is to convert the degrees into radians.
First calculation of “dist”:
northr = (north * 3.14159265) / 180.0;
eastr = (east * 3.14159265) / 180.0;
inorthr = (points[i].north * 3.14159265) / 180.0;
ieastr = (points[i].east * 3.14159265) / 180.0;
list[i].dist = 6378.7 * acos((sin(northr) * sin(inorthr)) + (cos(northr)
* cos(inorthr) * cos(ieastr- eastr)));
Second calculation of “dist”:
northr = (north * 3.14159265) / 180.0;
eastr = (east * 3.14159265) / 180.0;
inorthr = (points[i].north * 3.14159265) / 180.0;
ieastr = (points[i].east * 3.14159265) / 180.0;
dist = 6378.7 * acos((sin(northr) * sin(inorthr)) + (cos(northr)
* cos(inorthr) * cos(ieastr- eastr)));
Here is a web link that pertains to this issue:
http://grass.itc.it/pipermail/grass5/1992-February/000092.html |
|
Wed, Aug 17 2005
18:54:38
|
|
Mail sent by hmitaso@unity.ncsu.edu
|
|
Return-Path |
<hmitaso@unity.ncsu.edu>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Message-ID |
<43036BB7.4050606@unity.ncsu.edu>
|
Date |
Wed, 17 Aug 2005 12:54:15 -0400
|
From |
Helena Mitasova <hmitaso@unity.ncsu.edu>
|
User-Agent |
Mozilla Thunderbird 1.0.2 (X11/20050317)
|
X-Accept-Language |
en-us, en
|
MIME-Version |
1.0
|
To |
Request Tracker <grass-bugs@intevation.de>
|
Cc |
grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #3530] (grass) distance calculation in s/v.surf.idw wrong in lat/lon projection
|
References |
<20050817153137.2CDD0101FCE@lists.intevation.de>
|
In-Reply-To |
<20050817153137.2CDD0101FCE@lists.intevation.de>
|
Content-Type |
text/plain; charset=windows-1252; format=flowed
|
Content-Transfer-Encoding |
8bit
|
X-PMX-Version |
4.7.1.128075, Antispam-Engine: 2.0.3.2, Antispam-Data: 2005.8.17.17
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
this should actually be done also for v.surf.rst to support lat/long
correctly, however, it may slow down the computation significantly.
Do you have some estimate at what distances this actually matters and
what is the error associated with the wrong computation of distance -
e.g. for average distance between points 100m, 1000m, 10000m what are
the mean and max differences in the interpolated surfaces? This would
help to decide when this needs to be used, to minimize the impact on
performance,
Helena
P.S. I did not look into v.surf.idw but I assume that if G_distance is
used it will compute the distance correctly for lat,long so that may be
all that is needed.
Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=3530
> -------------------------------------------------------------------------
>
> Subject: distance calculation in s/v.surf.idw wrong in lat/lon projection
>
> Platform: GNU/Linux/i386
> grass obtained from: Trento Italy site
> grass binary for platform: Downloaded precompiled Binaries
> GRASS Version: All
>
> My name is Tye Parzybok (tyep@metstat.com) and I've been a happy, loyal GRASS
software user for over 10 years. I recently discovered that when using the old
s.surf.idw (new v.surf.idw) function in a "geographic" projection (i.e. lat.lon)
and with points in lat/lon, the distances computed DO NOT account for convergence
of the meridians. What needs to be done, and I've done this with an old (4.2)
version of GRASS, is the same logic used in r.surf.idw -- which computes distances
from raster to raster along a geodesic -- needs to be added to the s/v.surf.idw
function. Since the distance units aren't important to IDW, it doesn't matter
what you use, but they need to represent a true distance (in say meters) instead
of a straight line (Euclidean) decimal degree distance.
>
> Here is the distance calculation I used in my modified version of s.surf.idw.
The distance units are in km and I assume the earth is a perfect sphere (using
a better spherical representation would make this even better). This first part
of this is to convert the degrees into radians.
>
> First calculation of “dist”:
> northr = (north * 3.14159265) / 180.0;
> eastr = (east * 3.14159265) / 180.0;
> inorthr = (points[i].north * 3.14159265) / 180.0;
> ieastr = (points[i].east * 3.14159265) / 180.0;
> list[i].dist = 6378.7 * acos((sin(northr) * sin(inorthr)) +
(cos(northr) * cos(inorthr) * cos(ieastr- eastr)));
>
>
> Second calculation of “dist”:
> northr = (north * 3.14159265) / 180.0;
> eastr = (east * 3.14159265) / 180.0;
> inorthr = (points[i].north * 3.14159265) / 180.0;
> ieastr = (points[i].east * 3.14159265) / 180.0;
> dist = 6378.7 * acos((sin(northr) * sin(inorthr)) + (cos(northr)
* cos(inorthr) * cos(ieastr- eastr)));
>
>
> Here is a web link that pertains to this issue:
> http://grass.itc.it/pipermail/grass5/1992-February/000092.html
>
> -------------------------------------------- Managed by Request Tracker
>
> _______________________________________________
> grass5 mailing list
> grass5@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
|
|
Wed, Aug 17 2005
19:54:56
|
|
Mail sent by guest
|
|
Yes, you're correct...this WILL slow down the computation significantly, that
is one drawback. As far as error goes, I have made some comparisons and can
only make some general statements about them. Of course the error is going to
be influenced by...
- Latitude (high latitudes = more error)
- Distance between points (greater distance = greater error)
...therefore making it complicated to establish thresholds.
I can say however that for parts of the CONUS the error approached 20% in
places where points (weather stations) were 50-100 km apart. But you're
correct, the distance won't make a big difference with a high density of
points. When I say “error” I mean the difference in z between s.surf.idw
results when using true distances vs. uncorrected decimal degree distances.
What spheroid representation does G_distance assume…because perhaps the thing
to do is simply call this already-coded routine in the idw functions.
How long would it take to get this fix included in GRASS 6.0?
-Tye
|
|
Wed, Aug 17 2005
19:57:18
|
|
Mail sent by guest
|
|
Yes, you're correct...this WILL slow down the computation significantly, that
is one drawback. As far as error goes, I have made some comparisons and can
only make some general statements about them. Of course the error is going to
be influenced by...
- Latitude (high latitudes = more error)
- Distance between points (greater distance = greater error)
...therefore making it complicated to establish thresholds.
I can say however that for parts of the CONUS the error approached 20% in
places where points (weather stations) were 50-100 km apart. But you're
correct, the distance won't make a big difference with a high density of
points. When I say “error” I mean the difference in z between s.surf.idw
results when using true distances vs. uncorrected decimal degree distances.
What spheroid representation does G_distance assume…because perhaps the thing
to do is simply call this already-coded routine in the idw functions.
How long would it take to get this fix included in GRASS 6.0?
-Tye
|
|