[GRASS-user] srtm - r.fillnuls

Markus Neteler neteler at osgeo.org
Sun Dec 22 09:53:42 PST 2013


On Fri, Dec 20, 2013 at 12:40 PM, Martin Landa <landa.martin at gmail.com> wrote:
> Hi,
>
> 2013/12/19 Markus Neteler <neteler at osgeo.org>:
>
>>>> when playing with SRTM data I found out that `r.fill.nulls`'s RST
>>>> method usually fails [1] -- compared to `method=cubic` (cubic spline
>>>> interpolation) [2]. Is it expectable?
>>>>
>>>> Wouldn't be better to change default method to 'cubic' (v.surf.spline
>>>> is quite slow anyway)?
>>>
>>> sorry for noise, really no idea?
>>
>> Could you put the (reduced) location anywhere to try it out?
>
> sure, here it is [1]. Martin
>
> [1] http://geo.fsv.cvut.cz/~landa/tmp/location-srtm-test.tar.bz2

Trying out, I discovered a LU decomposition issue:

r.fillnulls input=SRTM_u01_n060w150 at PERMANENT output=rst method=rst
...
WARNING: Taking too long to find points for interpolation - please change
         the region to area where your points are. Continuing
         calculations...
G_ludcmp() failed! n=0  d=0.00
WARNING: Taking too long to find points for interpolation - please change
         the region to area where your points are. Continuing
         calculations...
G_ludcmp() failed! n=0  d=0.00
WARNING: Taking too long to find points for interpolation - please change
         the region to area where your points are. Continuing
         calculations...

The SRTM tile in question is a but "unfortunate" since approx. 50% of
the map are lacking, all of them in one part of the tile. This is hard
(impossible) to solve by means of RST. See also the difference of
nominal extent and trie dara extent:

GRASS 7.0.svn (srtm):~/grassdata > g.region rast=SRTM_u01_n060w150 -p
projection: 3 (Latitude-Longitude)
zone:       0
datum:      wgs84
ellipsoid:  wgs84
north:      61:00:00.5N
south:      59:59:59.5N
west:       150:00:00.5W
east:       148:59:59.5W
nsres:      0:00:01
ewres:      0:00:01
rows:       3601
cols:       3601
cells:      12967201

GRASS 7.0.svn (srtm):~/grassdata > g.region zoom=SRTM_u01_n060w150 -p
projection: 3 (Latitude-Longitude)
zone:       0
datum:      wgs84
ellipsoid:  wgs84
north:      60:24:14.5N
south:      59:59:59.5N
west:       150:00:00.5W
east:       148:59:59.5W
nsres:      0:00:01
ewres:      0:00:01
rows:       1455
cols:       3601
cells:      5239455

Indeed that's not really surprising, too: Please not that the north
"data" border is close to 60°N. Remember:

http://www2.jpl.nasa.gov/srtm/factsheet_tech.html
-> " Data that will be used to generate a digital topographic map of
80 percent of Earth's land surface (everything between 60 degrees
north and 56 degrees south latitude)"

Zooming manually to the region where the data really are, improves the
situation.

Hope this helps as a start,
Markus


More information about the grass-user mailing list