[GRASSLIST:7922] Re: [GRASS5] Re: Re: Hutchinson's Adaptive Alogrithm for sound DEMs?

[Graham Watt-Gremm]

Hi Maciek and list,
Just throwing in my support as a user who would value many of the  
developments talked about in this discussion. I work with archival  
survey photographs, analyzing subalpine forest dynamics in the  
Canadian Rockies. I frequently desire the ability to augment the .75  
arc second DEM I am using with the ridgelines, scarps and cliffs in  
my landscape, so I can decrease the spatial uncertainty in  
georeferencing the oblique photographs. I would definitely be  
interested in testing and documenting any programming efforts others  
can contribute!

Cheers,

Graham Watt-Gremm
Rocky Mountain Repeat Photography Project
School of Environmental Studies
University of Victoria

On 16-Aug-05, at 12:56 AM, Maciek Sieczka wrote:

> Jaro,
>
> I have merged your two recent messages here to compact the discussion.
>
> From: "Jaro Hofierka" <hofierka at geomodel.sk>
>
>
>>>> Dylan Beaudette <dylan at iici.no-ip.org>
>>>> The recent work by  Tomas Cebecauer and others (See "Processing  
>>>> digital
>>>> terrain models by  regularized spline with tension: tuning  
>>>> interpolation
>>>> parameters for  different input datasets" from the proceedings  
>>>> to the
>>>> 2002
>>>> GRASS  conference.) shows how v.surf.rst can be used in a method  
>>>> similar
>>>> to  ANUDEM to enforce proper drainage networks, by adding a  
>>>> "terrain
>>>> skeleton".
>>>>
>
>
>>> Maciek Sieczka <werchowyna at epf.pl>:
>>> I'm affraid the method described in Cebecauer's paper is  
>>> *completely*
>>> diffferent from the one used in ANUDEM. ANUDEM supports watercourse
>>> *lines*
>>> and elevation fault *lines*. While for v.surf.rst you have to  
>>> digitise
>>> them
>>> as *points*. What's really bad, each such point has to be  
>>> labelled for
>>> elevation before you feed it into v.surf.rst. So actually you  
>>> have to do
>>> the
>>> interpolation of fault lines, ridges and watercourses manually,  
>>> before
>>> you can make v.surf.rst use this crucial information. I find it  
>>> strange,
>>> because a DEM interpolation program should be able to do it  
>>> alone. At
>>> least that's the way I see it.
>>>
>
> <snip>
>
>
>> The method described in Cebecauer et al. 2002 has 2 parts. So called
>> "terrain skeleton" consists of mostly vector lines digitized from  
>> maps
>> (ridges, valley lines, etc.). The vertices for these lines are
>> automatically "densified" to a regular step, i.e. linearly  
>> interpolated
>> along the line, using a script (currently available only in  
>> ArcView GIS).
>>
>
> There is no mention about the script in the paper... There is the  
> skeleton
> mentioned several times and watercourse lines present on a figure,  
> but any
> direct notes on interpolation refer to elevation points and  
> contours. The
> processing of a skeleton into points is omitted.
>
>
>> If I remember correctly, the script takes elevation values from  
>> contours
>> and interpolates values for points automatically generated between  
>> the
>> contours.
>>
>
>
>> However, it still doesn't solve the problem completely, as flat areas
>> (like lowlands) usually have too complex microrelief to be solved  
>> using
>> a simple stream enforcement.
>>
>
> Right. Indeed ANUDEM's drainage enforcement works different. It  
> utilizes the
> watercourse direction data. Thus, it is able to enforce the  
> drainage even
> *upslope* (or rather *through* the slope) or on completely flat  
> area and can
> handle flow splits. And that's the drainage enforcement method I  
> wish for
> v.surf.rst... CatchmentSIM on the other hand, although not able to  
> model the
> flow splits, should have no problem to drain through the slope,  
> down the
> stream, provided that the elevation at the outlet of the stream  
> network is
> lower than the other end of this line segment.
>
> Also, the method you describe might be no good for some elevation  
> faults. I
> don't know how ANUDEM handles them. I *might* have acces to SURFER  
> soon and
> maybe I can see how elevation faults support works there (thanks to  
> Carlos
> Guâno Grohmann for the tip).
>
> But this simple method seems suitable for ridges indeed, does it?
>
>
>> Moreover, rivers sometimes do not follow exactly adjacent terrain  
>> as the
>> river flows in the channel, etc.
>>
>
> That could be overcome by "stream burning" I guess. Each cell which  
> falls
> into the watercouse is lowered for, say, 0.1 m. This usualy does  
> the trick.
>
>
>> So, there is no need for "massive" manual editing for these points.
>> At that time we were using just "site" version of the RST method,  
>> so we
>> needed points to enforce the shape of resulting surface.
>>
>
> As you might have read on the list Dylan and I (hopefully more  
> Folks will
> join us) are looking for somebody who could extend v.surf.rst to  
> handle
> watercources, faults and ridges (else ?). Spread the word please.  
> If enough
> people join us we can think of a financial reward for the  
> developer. Maybe
> you?
>
> Thank for your input Jaro.
>
> Best,
> Maciek
>
> P.S.
> Everobody who is interested in adding faults, watercouses  
> (including their
> flow direction - to be able to drain through the slope and to model  
> flow
> splits), ridges and stream burning functionality into v.surf.rst  
> (or other
> DEM interpolation program in GRASS) please report. Say whether you are
> interested as a:
>
> 1. user who needs this functionality (give us a sign, it doesn't  
> hurt :);
> the more of us the better chances!)
> 2. user any experienced in incorparating faults, watercouses,  
> ridges into
> DEM who could contribute information and advice
> 3. developer willing to coordinate the project from the programming  
> side
> 4. programmer willing to help
> 5. users willing to contribute in testing and writing the docs
>
> Also, please let us know if there is any other functionality you  
> would find
> beneficial for DEM interpolation. Maybe could be done by the way.
>
>