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

[Jaro Hofierka]

Hi Macej,

Your data is pretty tough for any interpolation method, including RST. 
Points are extremely distributed and sharp fault means extreme change of 
elevation. The RST method has proved that it is an excelent method even 
in this situations, but limits do exist. If you are interested in 
spatial interpolation you should read more about its theory and practice 
in some papers - there plenty of them in the Grassbook references and on 
the Helena's web page.
The most important thing to understand is that RST and other 
interpolation methods are for continuous data. This is not the case in 
your example and therefore area must be divided into 2 areas separated 
by a fault line (this is a discontinuity line).

As I mentioned earlier I believe that the excelent result of Surfer in 
your example is not a result of interpolation per se, but data 
processing. I suggested a procedure that should help. Did you try it?
Also, you can try other available methods to see differences(idw,krig etc).
I hope this helps.

Jaro


Maciek Sieczka wrote:

> 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
> 
> 
>