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

GRASS GIS GRASS GIS developer
1

From: "Dylan Beaudette" <dylan@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 :slight_smile: ?

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

2

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

We are looking into this right now. We have done some testing of watercourses and breaklines that are available for our test area to find out which to use to improve our DEMs - the student that
I work with tested 2 different types of USGS stream data, local government data (that would be very detailed cadastral maps) and stream data used for "improving" NC Flood mapping DEMs derived from lidar (these were supposed to be high quality). Surprisingly the average distance of these lines from the actual streams measured on ground with GPS was 30-70m which does not matter if you are working with 100m res. DEM but it is a lot if you are working with DEM that is 10m resolution or better. So using any of these data sets would actually introduce an unwanted error into the DEM. In some of our preliminary tests the streams derived from a DEM interpolated from lidar data without the streamlines were more accurate than those derived from the DEM interpolated with streamlines and even more accurate than the streamlines themselves, but more testing is needed to find out whether this is generally true. We are including Tpopogrid in our tests and I have already written to the list that we will try to implement whatever we will find that improves the DEM.

Anyway I will forward your suggestions to my colleagues at Duke to see whether they would like to implement any of the breakline/ridges to make the process more automated (you should keep in mind that although you see your watercourses drawn as lines they are actually stored as points so it is more the issue to hide some of the processing from the user and make it more automated, because you do have points and you adjust their elevation as you go through an iterative interpolation process)

I am totally swamped by work at this moment so I can hardly keep up with emails, but if somebody wants to work on this, I will be happy to assist
with the implementation - my projects focus on lidar data where the issues are quite different (e.g. ridges are very sharp directly from the data so you don't really want to mess it up with some other data that may be old or prone to errors), much much bigger priority for me is to get the vector modules support our large data sets,

Helena

3

Helena,

Thank you for you interest and support in spite of how busy you are.

From: "Helena Mitasova" <hmitaso@unity.ncsu.edu>

Maciek Sieczka wrote:

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

We are looking into this right now. We have done some testing of
watercourses and breaklines that are available for our test area to find
out which to use to improve our DEMs - the student that
I work with tested 2 different types of USGS stream data, local government
data (that would be very detailed cadastral maps) and stream data used for
"improving" NC Flood mapping DEMs derived from lidar (these were supposed
to be high quality).

<snip>

Absolutely, there is no need to polute LIDAR DEM with data from topo maps.
But when your main elevation data are contour lines digitised from a topo
map, then adding watercourses and elevation faults, present on the same map,
is a great addition to the DEM quality. I'm 100% sure that DEMs I produced
in TOPOGRID with watercouses included were much better suitable for water
flow modelling. Having the same functionality in GRASS is really important,
because LIDAR data users are and will be the minority when compared to cheap/free topo maps data users.

Anyway I will forward your suggestions to my colleagues at Duke to see
whether they would like to implement any of the breakline/ridges to make
the process more automated

That's great! thank you.

(you should keep in mind that although you see your watercourses drawn as
lines they are actually stored as points so it is more the issue to hide
some of the processing from the user and make it more automated, because
you do have points and you adjust their elevation as you go through an
iterative interpolation process)

I understand. But it's not "some processing". It is a *huge* amount of
processing. And because this is so much work to prepare watercourses and
fault lines as elevation points manually, this option is never used in real
applications, only possible in theory.

Some analogy: contour lines are also finally converted into elevation points
before interpolated in v.surf.rst. But it doesn't mean I have to digitise
contour lines as a set of elevation points and label each one's elevation
myself. I wish someday this was also true for watercourses, fault lines,
ridges and waterbodies. Let's hope somebody with appropriate skills and
enough spare will pick up this task.

I am totally swamped by work at this moment so I can hardly keep up with
emails, but if somebody wants to work on this, I will be happy to assist
with the implementation - my projects focus on lidar data where the issues
are quite different (e.g. ridges are very sharp directly from the data so
you don't really want to mess it up with some other data that may be old
or prone to errors), much much bigger priority for me is to get the vector
modules support our large data sets,

GRASS users will surely be gratefull for sorting out the large vector data
sets issue. Thank you.

Best
Maciek

4

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

<snip>

For us non programmers, lets put together a list of things that we can
accomplish to facilitate the developers. Possible tasks might include:
1. writing of good documentation with figures and references
2. testing for bugs with known datasets

Yes, I'm always happy to point out what others programmed wrong. I guess
that's how I cope with my complex of a non-programmer :).

3. literature search and review of methods -> passing on the information
to
the developers.

Points 1 and 3 are good ideas. Nice if we had a place to store all the
information. A section in GRASS wiki? How do we do it (I've never used WIKI before).

My first idea is to collect all the links to info on DEM interpolation
programs that support other data than contour lines and points only.

any others ideas?

Yes. Let me know if ridicolous. If we get enough people interested, and
agree on what is missing in v.surf.rst and what is realistic to be added,
could we collect enough money to, at least partly, reward the programmer who
would implement these features for the community?

Maciek

5

Maciek Sieczka wrote:

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 :slight_smile: ?

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?

Hi,

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).
If I remember correctly, the script takes elevation values from contours and interpolates values for points automatically generated between the contours.
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.

Another reason for this was that usually we interpolate such data with variable smoothing option, i.e. input dataset consists of several parts, each assigned with different smoothing parameters. So, for example, "skeleton lines" have different smoothing than contours.

Jaro

6

Maciek Sieczka wrote:

(you should keep in mind that although you see your watercourses drawn as
lines they are actually stored as points so it is more the issue to hide
some of the processing from the user and make it more automated, because
you do have points and you adjust their elevation as you go through an
iterative interpolation process)

I understand. But it's not "some processing". It is a *huge* amount of
processing. And because this is so much work to prepare watercourses and
fault lines as elevation points manually, this option is never used in real
applications, only possible in theory.

As I mentioned in my previous message to the list, there is no need for a "huge" amount of work. But of course, it always requires digitized lines that you want to include in the interpolation.
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.
Moreover, rivers sometimes do not follow exactly adjacent terrain as the river flows in the channel, etc.

It really makes me wonder if LIDAR can provide sufficiently precise data for such hydrological applications. I think the land cover (e.g. trees) can pose a problem as a precision in such areas can be decreased substantially in relation to areas with no cover.

Jaro

Some analogy: contour lines are also finally converted into elevation points
before interpolated in v.surf.rst. But it doesn't mean I have to digitise
contour lines as a set of elevation points and label each one's elevation
myself. I wish someday this was also true for watercourses, fault lines,
ridges and waterbodies. Let's hope somebody with appropriate skills and
enough spare will pick up this task.

I am totally swamped by work at this moment so I can hardly keep up with
emails, but if somebody wants to work on this, I will be happy to assist
with the implementation - my projects focus on lidar data where the issues
are quite different (e.g. ridges are very sharp directly from the data so
you don't really want to mess it up with some other data that may be old
or prone to errors), much much bigger priority for me is to get the vector
modules support our large data sets,

GRASS users will surely be gratefull for sorting out the large vector data
sets issue. Thank you.

Best
Maciek

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

7

Jaro,

I have merged your two recent messages here to compact the discussion.

From: "Jaro Hofierka" <hofierka@geomodel.sk>

Dylan Beaudette <dylan@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@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.

8

Maciek Sieczka wrote:

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.

Maciek,

The problem is a bit more complex than you are suggesting here. Rivers on lowlands flow usually within the walls (sediment deposits), so the river is actually above the terrain. I am not sure if "stream burning" helps in this case, at least it cannot be fully automated.
Anyway, there are plenty of algorithms that handle water courses/flows, DEM depresion filling, etc. The excellent module for this application in GRASS is r.terraflow, you even do not need a hydrologically-enforced DEM to get all water into the outlet.
Some of your suggestions for v.surf.rst are interesting, e.g. faults/breaklines, other problems can be solved outside v.surf.rst in a separate module. Perhaps Helena can help to select reasonable improvements for v.surf.rst that are worth of effort.

Jaro

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.

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

9

Dylan,

Could you please add this link to your www knowledge database?

www.ga.gov.au/servlet/BigObjFileManager?bigobjid=GA4783

It's a pretty big paper on creating Australia DEM with Anudem. The cliff
lines, watercourses and lake boundaries input data are briefly but
meaningfully characterised. Cool, I couldn't find this information elsewhere, even on the ANUDEM site itself.

Cheers,
Maciek

10

Ok, so far 5 us looking forward to incorparating additional data
(watercourses, faults, ridges, waterbodies) for Grass DEM interpolation, v.surf.rst preferably.

Dylan Beaudette <debeaudette@ucdavis.edu>
testing, documenting, hosting web site (temporarily?) for collecting
required
knowledge

Graham Watt-Gremm <sunyata@uvic.ca>
testing, documenting;
ridgelines, scarps, cliffs and elevation data of rocky mountains

Ksenia Konwicki <kes@timberline.ca>
testing;
breaklines dataset and TIN

Maciek Sieczka <werchowyna@epf.pl>
testing, documenting;
faults (gullies and antropogenic), watercourses, contour lines and elevation
points - all from a 1:10000 topo map of a lowland area

Michael Barton <michael.barton@asu.edu>
testing, documenting; (Michael ?)

No programmer though. But let's keep the faith.

Five of us could collect some decent funds I hope. I and Dylan we are
willing to contribute. Still only an idea but would be good to know if
realistic. So, would any of you be willing to contribute too?

Who else interested please?

Maciek

11

Dylan,

Another thing: http://freegis.org/cgi-bin/viewcvs.cgi/grass6/notyetuploaded/r.carve/Attic/

"r.carve - carve a vector stream into an elevation model"

Something like stream burning but a bit more according to the doc. Cool, let's have it linked.

Maciek

12

On Tue, Aug 16, 2005 at 11:45:33PM +0200, Maciek Sieczka wrote:

Dylan,

Another thing:
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/notyetuploaded/r.carve/Attic/

"r.carve - carve a vector stream into an elevation model"

Something like stream burning but a bit more according to the doc. Cool,
let's have it linked.

This module is now available from here:
http://grass.itc.it/outgoing/

See:
http://grass.itc.it/outgoing/r.carveREADME.txt
And the report:
http://skagit.meas.ncsu.edu/~helena/gmslab/reports/cerl99/rep99.html

Markus

13

Hello Brad,

From: "Brad Douglas" <rez@touchofmadness.com>

I may be of some use on the programming side, although my high level
math skills are not what they should be. As Helena has mentioned, I'm
doing some work on r.slope.aspect to incorporate other algorithms and I
have a fair understanding of the RST algorithm.

Together with you we are 8 people looking forward to extending v.surf.rst
for watercourses, faults, ridges and waterbodies support. Brent Wood said he
could be of some use in programming too, but he also doubts in his skills
:). Anyway, there are to of you who do know at least some programming,
great. Are you interested in being funded? Brent, are you?

We haven't talked of that for real yet, but it is time to. I'm looking
forward to hearing from anybody what would be a decent amount and who can
contribute. Forgive me I don't propose anything first but I have completely
no experience here and don't want to say anything stupid. I only suggest
that the money part we should keep off list, is that all right? If so, write
me with topic "DEM/GRASS improvements - Funding" CCing to all of us being
interested so far.

Folks list update:

Brad Douglas <rez@touchofmadness.com>
programming

Brent Wood <b.wood@niwa.co.nz>
programming

Dylan Beaudette <debeaudette@ucdavis.edu>
testing, documenting, hosting web site for collecting required knowledge

Carlos Guâno Grohmann <carlos.grohmann@gmail.com>
testing

Graham Watt-Gremm <sunyata@uvic.ca>
testing, documenting;
ridgelines, scarps, cliffs and elevation data of rocky mountains

Ksenia Konwicki <kes@timberline.ca>
testing;
breaklines dataset and TIN

Maciek Sieczka <werchowyna@epf.pl>
testing, documenting;
faults (gullies and antropogenic), watercourses, contour lines and elevation
points - all from a 1:10000 topo map of a lowland area

Michael Barton <michael.barton@asu.edu>
testing, documenting

14

On Aug 19, 2005, at 3:41 PM, Maciek Sieczka wrote:

Thanks Markus!

Markus wrote:

This module is now available from here:
http://grass.itc.it/outgoing/

See:
http://grass.itc.it/outgoing/r.carveREADME.txt

I guess r.carve could be a starting point for watercorse enforcement in
v.surf.rst.

Helena,

How does the r.enforce mentioned on
http://skagit.meas.ncsu.edu/~helena/gmslab/reports/cerl99/rep99.html compare
to r.carve?

it is the same thing. It did not get tested much so I am not sure how well it works.
I have found that for our applications a better solution was to include the information about stream channels
into the flowrouting program rather than change the DEM.

Helena

P.S.

Next week I'll post a summary of different approaches for modelling faults, watercourses, ridges and waterbodies I know of so we could discuss cons and pros of each. Please point to any other besides Surfer 8, CatchmentSIM, ANUDEM and Surge. Does anybody know of any more information available about approaches originating from Grass, besides the above mentioned and the famous Cebecauer et al. 2002?

Helena Mitasova
Dept. of Marine, Earth and Atm. Sciences
1125 Jordan Hall, NCSU Box 8208,
Raleigh NC 27695
http://skagit.meas.ncsu.edu/~helena/

15

From: "Helena Mitasova" <hmitaso@unity.ncsu.edu>

On Aug 19, 2005, at 3:41 PM, Maciek Sieczka wrote:

<snip>

Helena,

How does the r.enforce mentioned on
http://skagit.meas.ncsu.edu/~helena/gmslab/reports/cerl99/rep99.html compare
to r.carve?

it is the same thing. It did not get tested much so I am not sure how well it works.

What do I need to do to get it to Grass61 for testing?

I have found that for our applications a better solution was to include the information about stream channels

Raster or vector channels? Could you elaborate on what you mean by "better"?

into the flowrouting program

In Grass or other FOSS?

rather than change the DEM.

Hmm. Once one has a DEM with drainable channels, which follow their "real" path as seen on a map, it is pretty easy to utilize this channel information. The stream channel information is embedded in the DEM itself then. So any regular GRASS tools for hydrological modelling, r.mapcalc etc. are at disposal. But if we want the stream channels data to be external to DEM, then special tools to handle such a combination have to be developed as well. What do you think? Do we have such tools already in GRASS?

Maciek