Details Ticket 3530


Comment | Reply | Take | Resolve


Serial Number 3530
Subject distance calculation in s/v.surf.idw wrong in lat/lon projection
Area grass5.4
Queue grass
Requestors tyep@metstat.com
Owner none
Status open
Last User Contact Wed Aug 17 19:57:18 2005 (3 yr ago)
Current Priority 70
Final Priority 70
Due No date assigned
Last Action Wed Aug 17 19:57:18 2005 (3 yr ago)
Created Wed Aug 17 17:31:37 2005 (3 yr ago)

Transaction History Ticket 3530


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
Comment | Reply | Take | Resolve

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request