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

GRASS GIS GRASS GIS developer
1

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

2

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
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

3

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@geomodel.sk>
To: "Maciek Sieczka" <werchowyna@epf.pl>
Cc: "Helena Mitasova" <hmitaso@unity.ncsu.edu>; "grass devel"
<grass5@grass.itc.it>; <grasslist@baylor.edu>; "Michele"
<michele.rocc@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

4

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@geomodel.sk>
To: "Maciek Sieczka" <werchowyna@epf.pl>
Cc: "Helena Mitasova" <hmitaso@unity.ncsu.edu>; "grass devel"
<grass5@grass.itc.it>; <grasslist@baylor.edu>; "Michele"
<michele.rocc@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

5

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

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.

You are right. I tried all the interpolation methods available in Surfer,
with the same input data, and none (including min. curvature) produced an
acceptable result.

Minimum curvature performed well only when using "typical" elevation points (contour lines and hilltops) + fault lines. But when fault areas are represented by densely sampled elavation points, min. curv. fails same as any other method. Except triangulation
http://www.biol.uni.wroc.pl/sieczka/udostepnione/vsurfrst/surfer_triang_exag10.png
and natural neighbor
http://www.biol.uni.wroc.pl/sieczka/udostepnione/vsurfrst/surfer_natneigh_exag10.png
which gave excellent results, even with such a "tough data"!

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?

I'm afraid it is simply impossible to separately interpolate areas divided by faults and patch them subsequently, when input data looks like this http://www.biol.uni.wroc.pl/sieczka/udostepnione/vsurfrst/contours_faults.png (black - elvation data, red - fault lines). How do you think Jaro?

Summarising my amateur's remarks on DEM interpolation:
1. v.surf.rst could greatly benefit from supporting fault lines the way that Surfer or Surge does; then it could perform much better on areas with faults.
2. We are missing triangulation in Grass (wich was already rised by Helena I recall); I'm personally missing it badly - it showed to be perfect for heavily heterogenous data.

Maciek

--------------------
W polskim Internecie s? setki milionów stron. My przekazujemy Tobie tylko najlepsze z nich!
http://katalog.epf.pl/