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

[Maciek Sieczka]

Helena,

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

From: "Helena Mitasova" <hmitaso at 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