[GRASS5] v.surf.rst - serious errors in DEM

Sun Sep 11 15:46:39 EDT 2005

Jaro, All,

1. My message was a general point about v.surf.rst having problems with
handling non homogenous elevation data, rather than a help-request in case
of interpolating faults with v.surf.rst. That's why I won't refer to Jaro's
suggestion about interpolatng two DEMs and patching them to obtain sharp
faults, as it is quite OT.

2. During my struggling with faults I simply noticed that v.surf.rst
introduces serious errors into DEM when interpolating non-homogenous
elevation data. This problem might apply to any elevation data of rapid
elevation gradient. This is a big concern, because as far as I can see there
is no mention about such a "feature" in the manual or the Grass mailing
lists archives.

2. I also noticed that v.surf.rst tends to create artificial pikes (sharp
peeks) on hilltops, intead od a reasonable smooth elavation gradient towards
the first elevation contour line below such a hilltop (see the screendumps).
And there is no way to manipulate tension and smoothing in order to
interpolate both: a decent hilltop and a decent remaining area, at the same
time. Low tension and high smoothing make the resulting hilltops smooth and
neat-looking but most of the DEM is seriously apart from input data then.
Especially when talking of places of rapid elevation gradient such as
faults.

3. Summarizing, I'm unable to interpolate a reliale DEM from input data
composed of elevation contour lines, hilltop elevation points and patches of
dense elavation points of rapid elevation gradient. Unless I use a
resolution coarse enough to *hide* problems described above.

Now, there are 3 possiblities:
a. I'm not clever enough to make v.surf.rst work with non-homogenous data;
please enlighten me (no irony here, I swear)
b. there is some related bug in v.surf.rst
c. this is a "feature" and users must be warned

Please verify this, anybody, for the sake of Grass usability, after 
carefully going through whole my message and screendumps. There is something 
weird going on with v.surf.rst IMHO.

I hope somebody can clear this issue out finally. There was no reply besides
from Jaro, so I suppose it might be that I'm missing something obvious. Am
I?

Maciek

----- Original Message -----
From: "Jaro Hofierka" <hofierka at geomodel.sk>
To: "Maciek Sieczka" <werchowyna at epf.pl>
Cc: "Helena Mitasova" <hmitaso at unity.ncsu.edu>; "grass devel"
<grass5 at grass.itc.it>; <grasslist at baylor.edu>; "Michele"
<michele.rocc at libero.it>
Sent: Wednesday, September 07, 2005 8:11 PM
Subject: Re: [GRASS5] v.surf.rst - serious errors in DEM

> Sorry, I did not follow this discussion, but I am curious why you have not
> interpolated this area with a sharp fault line using separated
> interpolations on 2 areas divided by fault line that can be later combined
> in 1 area. I remember that Simox Cox was doing similar tasks with faults
> quite successfully perhaps 10 years ago.
> I believe that Surfer is doing the same but "behind the curtain".
>
> I am sorry if I missed somethong in your previous discussions.
>
> Jaro
>
> Maciek Sieczka wrote:
>> Helena,
>> Thank you for your interest in my problem. Below I'm trying to answer and
>> explain more.
>>
>> All,
>> If you have any remarks regarding my problems with v.surf.rst, please
>> join
>> the discussion.
>>
>> Helena Mitasova wrote:
>>
>> (regarding
>> http://www.biol.uni.wroc.pl/sieczka/udostepnione/vsurfrst/vsurfrst.png
>> and
>> http://www.biol.uni.wroc.pl/sieczka/udostepnione/vsurfrst/vsurfrst_exag.png
>> - MS)
>>
>>> I have never seen anything like that - check the elevations on your
>>> faults - it behaves as if the elevation in the highest row of the fault
>>> was lower than the elevation in the second row
>>
>>
>> No, it isn't the case. The elevation of all points in the highest row of
>> the
>> fault is higher than in rows below. Otherwords, the elevation of each
>> point
>> in the fault decreases down the fault. It is hard to describe spatial
>> data
>> in words, do you mind if I send you a sample for testing with v.surf.rst?
>>
>>> and the tension was too low
>>
>>
>> So I tried higher tension. But even as much as tension=170 is v.surf.rst
>> still warns me about overshoots. And the "ditch" artifact visible on
>> http://www.biol.uni.wroc.pl/sieczka/udostepnione/vsurfrst/vsurfrst_exag.png
>> is *only reduced*, it still remains - see
>> http://www.biol.uni.wroc.pl/sieczka/udostepnione/vsurfrst/vsurfrst_exag_tension170.png.
>> I've tried even more tension, but the higher the tension, the more
>> distinct
>> the artificial "pikes" on the hilltops get...
>>
>> So I tried less tension and more smoothing to get rid of "pikes", but the
>> results is that the "ditch" betwen contour line and the fault remains, as
>> well as the "pike" on the hilltop:
>> http://www.biol.uni.wroc.pl/sieczka/udostepnione/vsurfrst/vsurfrst_exag_tension80_smooth1.png.
>> More smoothing along with tension 80 still doesn't get rid of "pike" or
>> the
>> "ditch", only an artificial wave along the contour line gets more
>> visible:
>> http://www.biol.uni.wroc.pl/sieczka/udostepnione/vsurfrst/vsurfrst_exag_tension80_smooth10.png
>>> Where is the fault line?
>>
>>
>> Here:
>> http://www.biol.uni.wroc.pl/sieczka/udostepnione/vsurfrst/fault_line.png
>>
>> On
>> http://www.biol.uni.wroc.pl/sieczka/udostepnione/vsurfrst/surfer8_mincurv_exag.png
>> you can see a 2m res DEM interpolated in Surfer8 using minimum curvature,
>> with a Surfer's "blanking file" indicating this fault line (that's why
>> the
>> fault is so sharp on this picture). The vector points you also see on
>> this
>> screendump are points which were sampled over this Surfer's DEM, so I
>> could
>> include elevation faults in v.surf.rst. The results you saw above...
>>
>>> And why are you interpolating 1m resolution DEM from data that are
>>> 10-20m
>>> appart?
>>
>>
>> Is it forbidden? And seriously - for visualization with a topo map, which
>> is
>> 1m, and for experiments with modelling drainage network, which is
>> consisted
>> mainly of land reclamation ditches or other narrow watercourses, 1-5 m.
>> Resolution 10-20 m  wouldn't cover such details.
>>
>> Besides, e.g. 5m doesn't improve anything:
>> http://www.biol.uni.wroc.pl/sieczka/udostepnione/vsurfrst/vsurfrst_exag_res5.png I
>> tried also 10m, but although the "ditch" artifact cannot be distinguished
>> anymore, I believe that a coarser resolution doesn't improve the
>> v.surf.rst
>> interpolation, it only hides it's deficiencies. And I can't be sure if
>> the
>> same error wouldn't pop up in the area where generalisation to 10m isn't
>> enough to "hide" the error. Coarser resolution is not a asolution.
>>
>>> Did you try different parameters? You may want to read a little more
>>> about
>>> rst - there is plenty on my web site
>>
>>
>> I read, tried different settings but to no avail. Why does v.surf.rst
>> produce pike on the hilltop, no matter what settings? I can't get rid of
>> pikes unless I go for very low tension and high smoothing, like:
>> http://www.biol.uni.wroc.pl/sieczka/udostepnione/vsurfrst/vsurfrst_exag_tension15_smooth10.png
>> but then the ditch between the contour line and fault remains - because
>> of
>> tension to low this time, dead end. And besides, with high smoothing and
>> low
>> tension the overall DEM accuracy when compared to input data seriously
>> suffers.
>>
>> See the Surfer's DEM for comparison: there is a smooth gradient from the
>> hilltop towards the contour line below, and then into the fault boundary.
>> This looks more reasonable than an outstanding "pike" on the hilltop and
>> a
>> "ditch" between the fault and contour line. I know this is a different
>> algorithm, but could v.surf.rst behave similarily? Or do I have to settle
>> for that v.surf.rst is completely no good for non-homogenic data - in
>> spite
>> of it is claimed to be?
>>
>> Maciek
>>
>> P.S.
>>
>> I could be told by you "If you are so happy with results from Surfer, go
>> use
>> it and give v.surf.rst and Grass a brake". To avoid it I'll say something
>> more first:
>>
>> 1. I want Grass to be usefull for interpolating DEM from contour lines
>> and elevation points. On both Grass lists and some publications users are
>> kept being said v.surf.rst is capable of doing it in a reliable way.
>> Altough I've been trying to, I can't see how though. I'm not that dumb
>> you know - if it would be possible for a regular inteligent human being,
>> I would be able to do it. I'm still ready to admit I'm wrong and that
>> v.surf.rst is indeed as good for interpolating elevation data from topo
>> maps as it is advertised. Please convince me. From my experience so far,
>> I can only admit that v.surf.rst is good for interpolating homogenous
>> data - say for resampling SRTM DEMs, and completely no good for
>> non-homogenous data.
>>
>> 2. I want to use free software as much as I can. Thus I wanted Surfer
>> only
>> to help me in obtaining additional data for faults, which I could then
>> feed
>> back to v.surf.rst together with contour lines and elevation points - to
>> produce a complete DEM having used as much free software as possible.
>>
>> 3. Minimum curvature algorithm implementation in Surfer8 is the only tool
>> available to me which is capable of processing my contour lines and
>> elevation points *together with fault lines* in a reasonable time and
>> fairly
>> convenient way. Yet it has several other deficiencies I don't want to
>> elaborate on here now not to go OT. Anyway, I'll say it once more,
>> Surfer's
>> minimum curvature DEM interpolator I want to use only for interpolating
>> decent faults across my DEM, sampling these faults next and patching them
>> into the input for v.surf.rst for final DEM generating. Or is v.surf.rst
>> not
>> able to handle such a combination, because as Michelle wrote:
>>
>>> I think the problem is that your data are clusterized, and the
>>> resolution
>>> for interpolation is to hight with respect to the distribution of your
>>> data. You can try to add more isolines.
>>
>>
>> (Quick answer to Michele here - I don't have any more isolines on my topo
>> map to input. And I expect DEM interpolator to be able to interpolate
>> something reasonable from those data I provide, as they are a reasonable
>> input and not ditches and pikes. Quality data in != garbage out.)
>>
>> Maciek