[GRASSLIST:10526] Re: topidx calculation
Huidae Cho
grass4u at gmail.com
Wed Feb 22 15:56:15 EST 2006
Hi,
Since r.topidx tries to calculate topidx values based on the resolution of a
dem, the dem has to have the right resolution. If the resolution is less than
the actual grid size, r.topidx cannot know whether cells within a grid are
sinks or not.
When your elevation data is (assume its resolution is 1):
123
456
789
If the above data has a resolution greater than 1 (let's say 3 here), the
imported raster will look like the following:
111222333
111222333
111222333
444555666
444555666
444555666
777888999
777888999
777888999
Now, GRASS cannot say those duplicated (because of greater resolution) 9 cells
per each grid are really one grid or 9 grids. Similarly, r.topidx treats those values as sinks.
To find the correct resolution of your dem data, run the following script
(find_res.sh my_dem):
---
#!/bin/sh
r.stats -1n "$1" | awk '{
v = $0
if(NR > 1 && v != v0){
if(min_n == 0 || n < min_n)
min_n = n
n = 1
v0 = v
next
}
v0 = v
n++
}
END{
print min_n
}'
---
The above script counts the minimum number of duplicated cell values. Now you
want to multiply the current resolution by the printed number.
> g.region -p | grep nsres | awk '{print $2}'
1
> find_res.sh my_dem
3
> g.region res=3 # 1 * 3
> d.erase
> r.topidx in=my_dem ou=topidx
Huidae Cho
On Wed, Feb 22, 2006 at 11:39:36AM +0000, Wouter Buytaert wrote:
>
> Hi list,
>
> I've got some problems with r.topidx.
>
> I've used both normal elevation maps and preprocessed (with r.fill.dir)
> depressionless elevation maps, but the resulting topidx map is full of
> artifacts
>
> - a lot of -10 values in the resulting topidx map
> - with some elevation maps, a kind of gridlike raster pattern is produced, with
> a background of NULL values and a grid consisting of both -10 and positive
> values.
>
> Any ideas?
>
> cheers
> wouter
>
More information about the grass-user
mailing list