I agree both have their place. Sometimes we get a more consistent or more interesting answer from our analyses than from our field measurements.<br><br>As to the approach, I agree with your assessment, I was thinking backwards-- one caveat-- how best to handle local minima? Insert a null? I'm afraid I don't know how this is normally handled.<br>
<br>Steve<br><br><br><div class="gmail_quote">On Thu, Dec 15, 2011 at 1:45 PM, Matt Perry <span dir="ltr"><<a href="mailto:perrygeo@gmail.com">perrygeo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Stephen,<br>
<br>
<br>
It'd be great to see local hydrologic slope in gdaldem.<br>
<br>
I've seen a similar discrepancy between "field" slope and most<br>
GIS-derived slopes. The local max hydrologic slope seems to correspond<br>
much better to our perceived slope on the ground. The integrated slope<br>
used in most GIS, however, better matches the overall planar slope<br>
over a large extent. So they both have their place depending on scale;<br>
local hydrologic max slope for the micro, integrated planar slope for<br>
the macro.<br>
<br>
However, I don't think the algorithm that you describe below will<br>
work. It's currently looking for the *maximum* local elevation and<br>
computing slope to the center cell. Instead it should calculate the<br>
slope in the direction of hydrologic flow; i.e. the slope from the<br>
center cell to surrounding cell with the *minimum* elevation.<br>
<br>
<br>
- matt<br>
<br>
On Thu, Dec 15, 2011 at 10:29 AM, Stephen Mather<br>
<div><div></div><div class="h5"><<a href="mailto:mather.stephen@gmail.com">mather.stephen@gmail.com</a>> wrote:<br>
> I already see a flaw-- the function should be more like:<br>
><br>
><br>
> float GDALSlopeHydroAlg (float* afWin, float fDstNoDataValue, void* pData)<br>
> {<br>
> // Hydrologic Slope is the max<br>
> // local slope btw center cell and adjacent cells<br>
><br>
> const double radiansToDegrees = 180.0 / M_PI;<br>
> GDALSlopeAlgData* psData = (GDALSlopeAlgData*)pData;<br>
><br>
> float pafLocalMax = afWin[0];<br>
><br>
> for ( int k = 1; k < 9; k++)<br>
> {<br>
> if (afWin[k] > pafLocalMax)<br>
> {<br>
> pafLocalMax=afWin[k];<br>
> }<br>
> }<br>
> return atan(sqrt(pafLocalMax - afWin[4]) / (2*psData->scale)) *<br>
> radiansToDegrees;<br>
><br>
> }<br>
><br>
><br>
><br>
> On Thu, Dec 15, 2011 at 11:49 AM, Stephen Mather <<a href="mailto:mather.stephen@gmail.com">mather.stephen@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hi All,<br>
>> A colleague tipped me off to an article in Forestry Source entitled<br>
>> "When GIS Slope Isn't What You Think" showing differences between field<br>
>> measured slope values and GIS results. The differences can be substantial.<br>
>> The short and long of it is that local hydrologic slope is closer to what's<br>
>> used in the field by foresters than the integrated slope from either Horn or<br>
>> Zevenbergen-Thorne.<br>
>> And so, I have a feature request. I would like to add hydrologic<br>
>> slope to gdaldem. This is max local slope rather than integrated 9 cell<br>
>> slope like the existing code:<br>
>><br>
>> The existing code for Horn, e.g. is:<br>
>><br>
>> dx = ((afWin[0] + afWin[3] + afWin[3] + afWin[6]) -<br>
>> (afWin[2] + afWin[5] + afWin[5] + afWin[8]))/psData->ewres;<br>
>><br>
>> dy = ((afWin[6] + afWin[7] + afWin[7] + afWin[8]) -<br>
>> (afWin[0] + afWin[1] + afWin[1] + afWin[2]))/psData->nsres;<br>
>><br>
>> I'd like something more like this (adapted from roughness):<br>
>><br>
>> float GDALSlopeHydroAlg (float* afWin, float fDstNoDataValue, void* pData)<br>
>> {<br>
>> // Hydrologic Slope is the max<br>
>> // local slope btw center cell and adjacent cells<br>
>><br>
>> float pafLocalMax = afWin[0];<br>
>><br>
>> for ( int k = 1; k < 9; k++)<br>
>> {<br>
>> if (afWin[k] > pafLocalMax)<br>
>> {<br>
>> pafLocalMax=afWin[k];<br>
>> }<br>
>> }<br>
>> return pafLocalMax - afWin[4];<br>
>> }<br>
>><br>
>> Any critques? Reasons to not add?<br>
>><br>
>> Best,<br>
>> Steve<br>
>><br>
>> Stephen Mather<br>
>> GIS Manager<br>
>> Cleveland Metroparks<br>
>> 4101 Fulton Pkwy<br>
>> Cleveland, OH<br>
>> 44144<br>
><br>
><br>
><br>
</div></div>> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
<font color="#888888"><br>
<br>
<br>
--<br>
·´¯`·.¸. , . .·´¯`·.. ><((((º>`·.¸¸.·´¯`·.¸.·´¯`·...¸><((((º><br>
"The best way to predict the future is to invent it." -- Alan Kay<br>
Matthew T. Perry<br>
<a href="http://www.perrygeo.net" target="_blank">http://www.perrygeo.net</a><br>
<a href="http://viedevelo.wordpress.com" target="_blank">http://viedevelo.wordpress.com</a><br>
</font></blockquote></div><br>