<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Steve, there are more things I do not understand either. What is 'psData->scale'? Is it the grid cell size?<br>
So, if 'pafLocalMin' is on one of the 4 corners the distance is not cell size (let's call it DX) but instead sqrt(DX*DX + DX*DX).<br>
And what if data is in geogs? Than DX is clearly different from DY and changes with latitude. You need to take that into account to compute the slope.<br><font color="#888888">
<br></font></blockquote><div><br>:) I don't plan to refactor this for non-planar coordinate systems. That is beyond my skills. AFAIK, none of the gdaldem code would be appropriate to run on lat lon-- which is probably something which would be good to address, since many global datasets default to that, but I can barely read c++, let along do that level of refactoring. Of course, if I'm wrong in how I'm reading the source for the existing gdaldem code, and it does deal with non-planar cases, I'll adapt that code for this use case.<br>
<br>As to corners and sqrt(2), I'll take another look through tomorrow. In the likely case that you're right, I was sloppy in adapting the roughness index for this purpose and will have to take those distances into account. This will of course change the metric by which the lowest nearby point is determined, because of how distance will affect the factor of slope.<br>
<br>And so, my 10 minute solution takes much longer in the end... .<br><br>Best,<br>Steve<br></div></div>