4

I'm creating a Topographic Wetness Index using a python script (http://arcscripts.esri.com/details.asp?dbid=16750)

As I don't want this just to be a blackbox, I'm trying to understand the different rasters this script produces. One of them is outdrop-raster, which is a by-product of flow direction raster. According to ESRI:

"The output drop raster is calculated as the difference in z-value divided by the path length between the cell centers, expressed in percentages. For adjacent cells, this is analogous to the percent slope between cells. Across a flat area, the distance becomes the distance to the nearest cell of lower elevation. The result is a map of percent rise in the path of steepest descent from each cell."

..which seems reasonable. The problem is, that there are several numbers which pop out. For example 16,666.. % and 25 % are by far the most common numbers, why? I'm sure there is an explanation for this, but I just can't figure it out. It doesn't seem logical to have continuous elevation (thus slope) data and results that are not (that) continuous. Original data is low-density LiDAR DEM (2 m pix), values are 32 bit float (197.132, 198.013 m etc.).

example

5 by 5 example, darker gray equals flow direcetion to lower left and percentage 16,666 % drop while lighter gray here has 25 % drop and flow direction to the left

  • Is your projection in the same units as your Z values? – Scro Oct 25 '13 at 8:09
  • If the numbers calculated by the software algorithm do not convince you, why not manually calculating a few values between cells and then comparing them with those given by the algorithm? – multigoodverse Oct 25 '13 at 9:32
  • I Already calculated some flow direction values, and they seem fine. It's more difficult (or time consuming) to calculate paths and path lenghts. I was just hoping if somebody had an idea why these values tend to stack up. – reima Oct 25 '13 at 9:53
  • All units are in metres. – reima Oct 25 '13 at 9:53
  • @reima I don't think Ardit Sulce was suggesting that you calculate path lengths, rather to verify slope between cells. Subtract the Z value from any cell from the Z value its neighbor with the greatest elevation difference. Then divide that by 2 if the cells are adjacent, or by 2.828 if they are diagonal. You won't get the exact value of the drop raster, but most problems with units will result in errors that differ in order of magnitude. Let us know what you find. – Scro Oct 25 '13 at 13:10
1

It seems that all the values in slopes are rounded to the nearest 0,5. So 0,401 m / 2.8284 m = 0,14177, would instead be 0,5/3 = 16,6667. Or if distance is 2 metres, then 0,5/2 = 25 %. In the manual it says the values are rounded in FLAT areas, which seems to be a little off considering it does that where slope is 25 %. Another remark is that in flat areas (lakes) the drop percentages are indeed continuous!

  • There are other strange things going on in that script, such as hard-coding a cellsize of 5 and using block statistics where apparently focal stats are needed. Consider creating your own script rather than relying on this one. – whuber Dec 31 '13 at 16:18
  • 1
    Whuber, I did modify that script to a cell size of 2 m and modified block stats to focal stats too, in addition I was able to reproduce the same results only using flow direction tool straight from toolbox, so the bug is in the tool itself. I send this issue to ESRI and they were also able to reproduce it with my sample data, but not with their own data. So apparently the bug is data related. Weird still. – reima Feb 4 '14 at 7:30
  • Update: It appears that ESRI tested with 10 m resolution data. I tested this issue again with 2 m data and got this issue again. – reima Feb 13 '14 at 10:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.