[GRASSLIST:7922] Re: [GRASS5] Re: Re: Hutchinson's Adaptive Alogrithm for sound DEMs?
sunyata at uvic.ca
Tue Aug 16 09:25:50 EDT 2005
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
Rocky Mountain Repeat Photography Project
School of Environmental Studies
University of Victoria
On 16-Aug-05, at 12:56 AM, Maciek Sieczka wrote:
> 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
>>>> terrain models by regularized spline with tension: tuning
>>>> parameters for different input datasets" from the proceedings
>>>> to the
>>>> GRASS conference.) shows how v.surf.rst can be used in a method
>>>> to ANUDEM to enforce proper drainage networks, by adding a
>>> Maciek Sieczka <werchowyna at epf.pl>:
>>> I'm affraid the method described in Cebecauer's paper is
>>> diffferent from the one used in ANUDEM. ANUDEM supports watercourse
>>> and elevation fault *lines*. While for v.surf.rst you have to
>>> 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
>>> interpolation of fault lines, ridges and watercourses manually,
>>> you can make v.surf.rst use this crucial information. I find it
>>> because a DEM interpolation program should be able to do it
>>> alone. At
>>> least that's the way I see it.
>> The method described in Cebecauer et al. 2002 has 2 parts. So called
>> "terrain skeleton" consists of mostly vector lines digitized from
>> (ridges, valley lines, etc.). The vertices for these lines are
>> automatically "densified" to a regular step, i.e. linearly
>> 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
> 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
>> and interpolates values for points automatically generated between
>> However, it still doesn't solve the problem completely, as flat areas
>> (like lowlands) usually have too complex microrelief to be solved
>> 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
> 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
> 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
> 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
> Thank for your input Jaro.
> Everobody who is interested in adding faults, watercouses
> (including their
> flow direction - to be able to drain through the slope and to model
> 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
> 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.
More information about the grass-user