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

Ksenia Konwicki kes at timberline.ca
Tue Aug 16 13:05:12 EDT 2005


Maciek,

I would like to throw my voice in for the request to increase the functionality
of v.surf.rst to include breaklines/faultlines/watercourses. We are currently
dealing with an elevation model that was designed to be used as a TIN with
breaklines and we have been unable to create a satisfactory DEM for terrain
analysis using GRASS 6. The surface generated from the ESRI tools is superior so
we are using this method for the time being. We are currently developing a
work-around to incorporate information from the arcs.

My input/interest would simply be as a user, but I would certainly be willing to
work with a developer to test any new methods.

Thanks,

Ksenia.
--
Ksenia E. Konwicki, RPF
Ecologist

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.









More information about the grass-user mailing list