[GRASSLIST:10526] Re: topidx calculation

[Huidae Cho]

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
>