[GRASSLIST:7904] Re: Hutchinson's Adaptive Alogrithm for sound DEMs?
werchowyna at epf.pl
Mon Aug 15 09:58:23 EDT 2005
From: "Dylan Beaudette" <dylan at iici.no-ip.org>
> 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.
> 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
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.
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?
I'm CCing to grass devel as advised by Markus so Helena could read this all.
Let's continue there.
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!
More information about the grass-user