[GRASS5] Re: [GRASSLIST:7895] Re: Hutchinson's Adaptive Alogrithm
for sound DEMs?
hofierka at geomodel.sk
Mon Aug 15 16:47:30 EDT 2005
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.
> Some analogy: contour lines are also finally converted into elevation
> 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
>> 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
>> modules support our large data sets,
> GRASS users will surely be gratefull for sorting out the large vector data
> sets issue. Thank you.
> grass5 mailing list
> grass5 at grass.itc.it
More information about the grass-dev