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

[Maciek Sieczka]

From: "Dylan Beaudette" <dylan at iici.no-ip.org>

<snip>
> I think that it  would be great if the pooled efforts of the GRASS
> community could be  used to make GRASS the premier DEM creation /
> modification environment.
<snip>
> Currently v.surf.rst provides a very flexible means to produce  elevation
> surfaces from point and contour data.

I fully agree. Unfortunatelly, these are the only data it supports...

> 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".

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.

Summarrising, including watercourses and fault lines in ANUDEM (and ridges 
in CatchmenetSIM) is quick and easy. In v.surf.rst extremely time consuming, 
thus virtually impossible, i.e. a non-existant feature.

Example:

There is stream 10000 meters long.
How long would it take one to digitise it as a line and include in ANUDEM?
Answer: a minute :) ?

And how long is it to digitise points dense enough and label each for
elevation along the 10 km long watercourse for v.surf.rst? Ok, one could
digitise the line and convert into points then, half work less work. But
still, *each* point has to be labelled for elevation now. A real problem -
interpolate manually the elavation of all the points and label each - e.g.
1000 points in case of 10 m resolution, 10000 points if res=1 m.

Answer:  say, 5 sesonds a point. In case of 10 m resolution this gives us 83
minutes. If one wants the 1 m resolution, he'd have to settle for something
about 14 *hours*. Who dares?

Same in case of fault lines and ridges...

That would an great leap forward for DEM interpolation in GRASS if we could
utilise fault lines and watercourses as they are digitised from topo maps,
i.e. lines not labelled for elevation. As well as ridgelines and
waterbodies. I'm no programmer, so I don't know if that is hard to implement
and I can't offer any help. But I don't want to taken for a pain in the back
only. Might I be really the only one intersted indeed? So why does ANUDEM
even exist? Or CatchmentSIM, SURGE? And why does ANUDEM sell at such a high 
price and is included in ESRI software? Having an equal competitor for 
ANUDEM could be really a tremendous benefit for GRASS IMHO. Currently 
v.surf.rst is excellent for homogenous data, like LIDAR. But such datasets 
are rare, which makes v.surf.rst usefull for limited amount of users. Who 
could make v.surf.rst really usefull for data derived from topo maps - the 
most available kind of elevation data?

P.S.
I'm CCing to grass devel as advised by Markus so Helena could read this all.
Let's continue there.

Helena,
There's been some discussion on grass user list on this toppic. I don't want
to crowd your box or grass devel forwarding it all, so please take a look at
the archive if you can.

All hail GRASS!
Maciek