[GRASS-user] Problem with slope modeling .

GRASS GRASS user
1

Hi all,
I'm preparing the slope and elevation map from digitised isolines.
I'm using v.surf.rst to do that with the following options:

v.surf.rst input="izolinie_punkty" layer=1 zcolumn="wysokosc_m_npm"
dmax=3.174812 dmin=0.634962 elev="mapa_wystaw" slope="mapa_spadk"
maskmap="maska" zmult=1.0 tension=40. segmax=40 npmin=300

The screenshot from small part of resulting map is here:
http://mort.no-ip.org/screen.png

On this screen you can see the valley in the center. I expect that the
slope between two isolines on the bottom of the valley will be similar.
But it is changing and gives an effect of "wave" between isolines. Those
"waves" cause the unexpected results in LS factor.

I was trying to manipulate with the tension and smoothness but without
visible results.

What should I change to calculate better slope model?? Any help with
understanding will be appreciated.

Best Regards,
Radomir

--
Radomir

----
The Future Is Now :wink:

2

I was looking at your image you linked too of your DEM with slope profile.

I am really confused by your Isolines…

The profile you drew on your DEM shows exactly what you would expect from your transect along the DEM colour sensitive elevations.

The Isolines however are completely contradictory… but… Maybe these isolines are for something entirely else besides elevation?

Sorry, can’t wrap my head around what those isolines are representing…

When you say:

I expect that the slope between two isolines on the bottom of the valley will be similar.

I presume the Isolines are representative of Elevation.

If the Isolines are representative of Elevation then what is the DEM representative of?

Your profile is of your Raster image, and your transect profile along that image shows a fairly constant elevation with the slight dips that are represented in your Profile graph.
Meanwhile the isolines are telling a completely different story…

Is there any chance that one of your fields inputted was mixed up between slope and elevation, that your DEM is perhaps incorrect?
I am used to seeing similar colours ALONG the length of the Isolines not Against them.

Maybe I’m way out in left field picking daisies… I don’t know…

Nice snapshot thought!

good luck!

Mars

On 24-Mar-07, at 1:03 PM, Radomir wrote:

Hi all,
I’m preparing the slope and elevation map from digitised isolines.
I’m using v.surf.rst to do that with the following options:

v.surf.rst input=“izolinie_punkty” layer=1 zcolumn=“wysokosc_m_npm”
dmax=3.174812 dmin=0.634962 elev=“mapa_wystaw” slope=“mapa_spadk”
maskmap=“maska” zmult=1.0 tension=40. segmax=40 npmin=300

The screenshot from small part of resulting map is here:
http://mort.no-ip.org/screen.png

On this screen you can see the valley in the center. I expect that the
slope between two isolines on the bottom of the valley will be similar.
But it is changing and gives an effect of “wave” between isolines. Those
“waves” cause the unexpected results in LS factor.

I was trying to manipulate with the tension and smoothness but without
visible results.

What should I change to calculate better slope model?? Any help with
understanding will be appreciated.

Best Regards,
Radomir

–
Radomir

The Future Is Now :wink:

grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser

Amaginary Studios
amagine@telus.net
Phone 250 845 7999

Mars Sjoden
3320 Mount Davis Way
Houston BC
V0J 1Z2

READ CAREFULLY.
By reading this email, you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (“BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

3

Radomir wrote:

Hi all,
I'm preparing the slope and elevation map from digitised isolines.
I'm using v.surf.rst to do that with the following options:

v.surf.rst input="izolinie_punkty" layer=1 zcolumn="wysokosc_m_npm"
dmax=3.174812 dmin=0.634962 elev="mapa_wystaw" slope="mapa_spadk"
maskmap="maska" zmult=1.0 tension=40. segmax=40 npmin=300

The screenshot from small part of resulting map is here:
http://mort.no-ip.org/screen.png

On this screen you can see the valley in the center. I expect that the
slope between two isolines on the bottom of the valley will be similar.
But it is changing and gives an effect of "wave" between isolines.

I had this problem too when interpolating DEM from contour lines with
RST. Try to interploate DEM with r.surf.nnbathy from GRASS WIKI add-ons
page and let us know if the artifact hollow between 2 adjacent contour
lines still remains. I'm not 100% sure it will help. It might.

Maciek

4

Dnia 25-03-2007, nie o godzinie 07:35 +0530, nishith datta napisał(a):

hi Radomir,
I found a nice write up on interpolation techniques GIS Ostrava
2006.htm. If you cant find let me know shall send you attachment.
May be it will help you solve the problem.
Keep us posted about the results and how you resolve the problem
thanks
nishith

On 3/25/07, Radomir <dod.mort@gmail.com> wrote:
        Hi all,
        I'm preparing the slope and elevation map from digitised
        isolines.
        I'm using v.surf.rst to do that with the following options:
        
        v.surf.rst input="izolinie_punkty" layer=1
        zcolumn="wysokosc_m_npm"
        dmax=3.174812 dmin=0.634962 elev="mapa_wystaw"
        slope="mapa_spadk"
        maskmap="maska" zmult=1.0 tension=40. segmax=40 npmin=300
        
        The screenshot from small part of resulting map is here:
        http://mort.no-ip.org/screen.png
        
        On this screen you can see the valley in the center. I expect
        that the
        slope between two isolines on the bottom of the valley will be
        similar.
        But it is changing and gives an effect of "wave" between
        isolines. Those
        "waves" cause the unexpected results in LS factor.
        
        I was trying to manipulate with the tension and smoothness but
        without
        visible results.
        
        What should I change to calculate better slope model?? Any
        help with
        understanding will be appreciated.
        
        Best Regards,
        Radomir
        
        --
        Radomir
        
        ----
        The Future Is Now :wink:
        
        _______________________________________________
        grassuser mailing list
        grassuser@grass.itc.it
        http://grass.itc.it/mailman/listinfo/grassuser

hi Nishit
Unfortunately I can't find the website from your link.
If you please send me again this link...
Best regards,
Radomir
--
Radomir

----
The Future Is Now :wink:

5

Radomir wrote:
> I'm preparing the slope and elevation map from digitised isolines.
> I'm using v.surf.rst to do that with the following options:
>
> v.surf.rst input="izolinie_punkty" layer=1 zcolumn="wysokosc_m_npm"
> dmax=3.174812 dmin=0.634962 elev="mapa_wystaw" slope="mapa_spadk"
> maskmap="maska" zmult=1.0 tension=40. segmax=40 npmin=300
>
> The screenshot from small part of resulting map is here:
> http://mort.no-ip.org/screen.png
>
>
> On this screen you can see the valley in the center. I expect that
> the slope between two isolines on the bottom of the valley will be
> similar. But it is changing and gives an effect of "wave" between
> isolines.

Mars wrote:

I presume the Isolines are representative of Elevation.

and the displayed raster, legend, and profile show the slope.
it might help to show a profile using the elevation map. (it is hard to
tell if the slope stays monotonically increasing in your profile as
slope will always be positive)

profiler notes:
- y-scale is ranged to max/min of map, not max/min of profile?
  ($elevrange from r.univar instead of r.profile in gis.m/profile.tcl)
  Not sure which is best. Both ways have some merit.

- in your screenshot the axes tick labels are not formatted cleanly.
  I've just prettified those in CVS, please test.

- BUG: if profile ends outside of the raster map off in NULL-land,
  the totaldistance calculation is calculated to the end of the arrows,
  but the end of real data in the plot is stretched to the far right end
  regardless. e.g.: Zoom out so your raster is a postage stamp sized box
  in the middle, then make some profiles from map canvas corner to
  corner. The start of the data is positioned ok. Also it should break
  the plot at NULL data, not draw a line beween the last known good data
  either side of the NULLs.

- it would be possible to add a title like "Profile for $mapname" at the
  top of the profile. Is there demand for this? Better to have it in the
  window title than on the plot itself?

Maciek wrote:

I had this problem too when interpolating DEM from contour lines with
RST. Try to interploate DEM with r.surf.nnbathy from GRASS WIKI
add-ons page and let us know if the artifact hollow between 2 adjacent
contour lines still remains. I'm not 100% sure it will help. It might.

v.surf.rst is designed for semi-evenly distributed series of data points
(at least locally, it is fine for data density to smoothly change), not
contour lines.

running v.to.points + v.surf.rst tends to bias the surface to the
isolines. Output the treefile= segmentation map and curvature maps to
see the effect in detail. Also in the GRASS book, if you have access to
it.

as Maciek wrote, you should get better results with r.surf.nnbathy, or
you can try r.surf.contour (see hints about that posted in the last day
or two to this list for r.surf.contour).

You might try r.contour with your output raster map at levels half way
between your original isolines to get a nice visual check of how the
interpolation went. (create new contour lines 1/2 way between the
original ones and overlay them)

Hamish

6

Hi Hamish,

I assume you copied me on this reply for the 'profiler notes'.

On 3/26/07 1:30 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:

profiler notes:
- y-scale is ranged to max/min of map, not max/min of profile?
  ($elevrange from r.univar instead of r.profile in gis.m/profile.tcl)
  Not sure which is best. Both ways have some merit.

Good thought. I don't know which is better. Currently, it tries to get max
and min from the displayed area of the map so that all profiles will be to
the same scale. eg., for cutting and pasting comparisons. However, I can
also see the merit of making the scale dependent on the max and min of the
profile itself. Which do you think is better?

- in your screenshot the axes tick labels are not formatted cleanly.
  I've just prettified those in CVS, please test.

- BUG: if profile ends outside of the raster map off in NULL-land,
  the totaldistance calculation is calculated to the end of the arrows,
  but the end of real data in the plot is stretched to the far right end
  regardless. e.g.: Zoom out so your raster is a postage stamp sized box
  in the middle, then make some profiles from map canvas corner to
  corner. The start of the data is positioned ok. Also it should break
  the plot at NULL data, not draw a line beween the last known good data
  either side of the NULLs.

This works better than it did, but it is still not the best, as you note.
It's hard to fix given how r.profile works. Still, there is not much use for
a profile that goes off a map on purpose.

- it would be possible to add a title like "Profile for $mapname" at the
  top of the profile. Is there demand for this? Better to have it in the
  window title than on the plot itself?

This could be done. But would it clutter up the profile display too much
(i.e., with breaklines)?

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

7

Dnia 26-03-2007, pon o godzinie 20:30 +1200, Hamish napisał(a):

> Radomir wrote:
> > I'm preparing the slope and elevation map from digitised isolines.
> > I'm using v.surf.rst to do that with the following options:
> >
> > v.surf.rst input="izolinie_punkty" layer=1 zcolumn="wysokosc_m_npm"
> > dmax=3.174812 dmin=0.634962 elev="mapa_wystaw" slope="mapa_spadk"
> > maskmap="maska" zmult=1.0 tension=40. segmax=40 npmin=300
> >
> > The screenshot from small part of resulting map is here:
> > http://mort.no-ip.org/screen.png
> >
> >
> > On this screen you can see the valley in the center. I expect that
> > the slope between two isolines on the bottom of the valley will be
> > similar. But it is changing and gives an effect of "wave" between
> > isolines.

Mars wrote:
> I presume the Isolines are representative of Elevation.

and the displayed raster, legend, and profile show the slope.
it might help to show a profile using the elevation map. (it is hard to
tell if the slope stays monotonically increasing in your profile as
slope will always be positive)

profiler notes:
- y-scale is ranged to max/min of map, not max/min of profile?
  ($elevrange from r.univar instead of r.profile in gis.m/profile.tcl)
  Not sure which is best. Both ways have some merit.

- in your screenshot the axes tick labels are not formatted cleanly.
  I've just prettified those in CVS, please test.

- BUG: if profile ends outside of the raster map off in NULL-land,
  the totaldistance calculation is calculated to the end of the arrows,
  but the end of real data in the plot is stretched to the far right end
  regardless. e.g.: Zoom out so your raster is a postage stamp sized box
  in the middle, then make some profiles from map canvas corner to
  corner. The start of the data is positioned ok. Also it should break
  the plot at NULL data, not draw a line beween the last known good data
  either side of the NULLs.

- it would be possible to add a title like "Profile for $mapname" at the
  top of the profile. Is there demand for this? Better to have it in the
  window title than on the plot itself?

Maciek wrote:
> I had this problem too when interpolating DEM from contour lines with
> RST. Try to interploate DEM with r.surf.nnbathy from GRASS WIKI
> add-ons page and let us know if the artifact hollow between 2 adjacent
> contour lines still remains. I'm not 100% sure it will help. It might.

v.surf.rst is designed for semi-evenly distributed series of data points
(at least locally, it is fine for data density to smoothly change), not
contour lines.

running v.to.points + v.surf.rst tends to bias the surface to the
isolines. Output the treefile= segmentation map and curvature maps to
see the effect in detail. Also in the GRASS book, if you have access to
it.

as Maciek wrote, you should get better results with r.surf.nnbathy, or
you can try r.surf.contour (see hints about that posted in the last day
or two to this list for r.surf.contour).

You might try r.contour with your output raster map at levels half way
between your original isolines to get a nice visual check of how the
interpolation went. (create new contour lines 1/2 way between the
original ones and overlay them)

Hamish

Maciek, Hamish, Mars,
Thank you for your comments.

I've interpolated isolines with use of r.surf.nnbathy:

r.surf.nnbathy alg=nn input=izolinie output=nn_elevation

unfortunately, the results are even worse that those which comes from
RST method. After "translating" it into the slope map (r.slope.aspect) I
have the following result:

http://mort.no-ip.org/grass/indexgrass.html

As You can see, I still have "waves" between isolines. On the graph you
will find those "waves" really large.

The r.surf.contour methods gives much worse results then RST (see the
Elevation graph).

I've run r.contour with my RST output map as Hamish suggested ( see the
last image on the http://mort.no-ip.org/grass/indexgrass.html )

It was really interesting to analyse the output vector map. It seems
that when the distance between two isolines is "large" GRASS "puts the
next isoline" very close to the previous and this is how the "waves"
comes from.

What sholud I do next?? Please for comments and suggestions.
Best Regards,
--
Radomir

----
The Future Is Now :wink:

8

On Monday 30 April 2007 06:01, Radomir wrote:

Dnia 26-03-2007, pon o godzinie 20:30 +1200, Hamish napisał(a):
> > Radomir wrote:
> > > I'm preparing the slope and elevation map from digitised isolines.
> > > I'm using v.surf.rst to do that with the following options:
> > >
> > > v.surf.rst input="izolinie_punkty" layer=1 zcolumn="wysokosc_m_npm"
> > > dmax=3.174812 dmin=0.634962 elev="mapa_wystaw" slope="mapa_spadk"
> > > maskmap="maska" zmult=1.0 tension=40. segmax=40 npmin=300
> > >
> > > The screenshot from small part of resulting map is here:
> > > http://mort.no-ip.org/screen.png
> > >
> > >
> > > On this screen you can see the valley in the center. I expect that
> > > the slope between two isolines on the bottom of the valley will be
> > > similar. But it is changing and gives an effect of "wave" between
> > > isolines.
>
> Mars wrote:
> > I presume the Isolines are representative of Elevation.
>
> and the displayed raster, legend, and profile show the slope.
> it might help to show a profile using the elevation map. (it is hard to
> tell if the slope stays monotonically increasing in your profile as
> slope will always be positive)
>
>
>
> profiler notes:
> - y-scale is ranged to max/min of map, not max/min of profile?
> ($elevrange from r.univar instead of r.profile in gis.m/profile.tcl)
> Not sure which is best. Both ways have some merit.
>
> - in your screenshot the axes tick labels are not formatted cleanly.
> I've just prettified those in CVS, please test.
>
> - BUG: if profile ends outside of the raster map off in NULL-land,
> the totaldistance calculation is calculated to the end of the arrows,
> but the end of real data in the plot is stretched to the far right end
> regardless. e.g.: Zoom out so your raster is a postage stamp sized box
> in the middle, then make some profiles from map canvas corner to
> corner. The start of the data is positioned ok. Also it should break
> the plot at NULL data, not draw a line beween the last known good data
> either side of the NULLs.
>
> - it would be possible to add a title like "Profile for $mapname" at the
> top of the profile. Is there demand for this? Better to have it in the
> window title than on the plot itself?
>
> Maciek wrote:
> > I had this problem too when interpolating DEM from contour lines with
> > RST. Try to interploate DEM with r.surf.nnbathy from GRASS WIKI
> > add-ons page and let us know if the artifact hollow between 2 adjacent
> > contour lines still remains. I'm not 100% sure it will help. It might.
>
> v.surf.rst is designed for semi-evenly distributed series of data points
> (at least locally, it is fine for data density to smoothly change), not
> contour lines.
>
> running v.to.points + v.surf.rst tends to bias the surface to the
> isolines. Output the treefile= segmentation map and curvature maps to
> see the effect in detail. Also in the GRASS book, if you have access to
> it.
>
> as Maciek wrote, you should get better results with r.surf.nnbathy, or
> you can try r.surf.contour (see hints about that posted in the last day
> or two to this list for r.surf.contour).
>
> You might try r.contour with your output raster map at levels half way
> between your original isolines to get a nice visual check of how the
> interpolation went. (create new contour lines 1/2 way between the
> original ones and overlay them)
>
>
>
> Hamish

Maciek, Hamish, Mars,
Thank you for your comments.

I've interpolated isolines with use of r.surf.nnbathy:

r.surf.nnbathy alg=nn input=izolinie output=nn_elevation

unfortunately, the results are even worse that those which comes from
RST method. After "translating" it into the slope map (r.slope.aspect) I
have the following result:

http://mort.no-ip.org/grass/indexgrass.html

As You can see, I still have "waves" between isolines. On the graph you
will find those "waves" really large.

The r.surf.contour methods gives much worse results then RST (see the
Elevation graph).

I've run r.contour with my RST output map as Hamish suggested ( see the
last image on the http://mort.no-ip.org/grass/indexgrass.html )

It was really interesting to analyse the output vector map. It seems
that when the distance between two isolines is "large" GRASS "puts the
next isoline" very close to the previous and this is how the "waves"
comes from.

What sholud I do next?? Please for comments and suggestions.
Best Regards,

I do not know what is causing this behaviour, but there is a well-documented
problem with USGS dem data that causes similar artifacts:

(see the image at the bottom of the page)
http://169.237.35.250/~dylan/gdalwarp/image_matrix.html

dylan

--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341

9

Dylan Beaudette wrote:

On Monday 30 April 2007 06:01, Radomir wrote:

Dnia 26-03-2007, pon o godzinie 20:30 +1200, Hamish napisa³(a):

Radomir wrote:

I'm preparing the slope and elevation map from digitised isolines.
I'm using v.surf.rst to do that with the following options:

v.surf.rst input="izolinie_punkty" layer=1 zcolumn="wysokosc_m_npm"
dmax=3.174812 dmin=0.634962 elev="mapa_wystaw" slope="mapa_spadk"
maskmap="maska" zmult=1.0 tension=40. segmax=40 npmin=300

The screenshot from small part of resulting map is here:
http://mort.no-ip.org/screen.png

On this screen you can see the valley in the center. I expect that
the slope between two isolines on the bottom of the valley will be
similar. But it is changing and gives an effect of "wave" between
isolines.

Mars wrote:

I presume the Isolines are representative of Elevation.

and the displayed raster, legend, and profile show the slope.
it might help to show a profile using the elevation map. (it is hard to
tell if the slope stays monotonically increasing in your profile as
slope will always be positive)

profiler notes:
- y-scale is ranged to max/min of map, not max/min of profile?
  ($elevrange from r.univar instead of r.profile in gis.m/profile.tcl)
  Not sure which is best. Both ways have some merit.

- in your screenshot the axes tick labels are not formatted cleanly.
  I've just prettified those in CVS, please test.

- BUG: if profile ends outside of the raster map off in NULL-land,
  the totaldistance calculation is calculated to the end of the arrows,
  but the end of real data in the plot is stretched to the far right end
  regardless. e.g.: Zoom out so your raster is a postage stamp sized box
  in the middle, then make some profiles from map canvas corner to
  corner. The start of the data is positioned ok. Also it should break
  the plot at NULL data, not draw a line beween the last known good data
  either side of the NULLs.

- it would be possible to add a title like "Profile for $mapname" at the
  top of the profile. Is there demand for this? Better to have it in the
  window title than on the plot itself?

Maciek wrote:

I had this problem too when interpolating DEM from contour lines with
RST. Try to interploate DEM with r.surf.nnbathy from GRASS WIKI
add-ons page and let us know if the artifact hollow between 2 adjacent
contour lines still remains. I'm not 100% sure it will help. It might.

v.surf.rst is designed for semi-evenly distributed series of data points
(at least locally, it is fine for data density to smoothly change), not
contour lines.

running v.to.points + v.surf.rst tends to bias the surface to the
isolines. Output the treefile= segmentation map and curvature maps to
see the effect in detail. Also in the GRASS book, if you have access to
it.

as Maciek wrote, you should get better results with r.surf.nnbathy, or
you can try r.surf.contour (see hints about that posted in the last day
or two to this list for r.surf.contour).

You might try r.contour with your output raster map at levels half way
between your original isolines to get a nice visual check of how the
interpolation went. (create new contour lines 1/2 way between the
original ones and overlay them)

Hamish

Maciek, Hamish, Mars,
Thank you for your comments.

I've interpolated isolines with use of r.surf.nnbathy:

r.surf.nnbathy alg=nn input=izolinie output=nn_elevation

unfortunately, the results are even worse that those which comes from
RST method. After "translating" it into the slope map (r.slope.aspect) I
have the following result:

http://mort.no-ip.org/grass/indexgrass.html

As You can see, I still have "waves" between isolines. On the graph you
will find those "waves" really large.

The r.surf.contour methods gives much worse results then RST (see the
Elevation graph).

I've run r.contour with my RST output map as Hamish suggested ( see the
last image on the http://mort.no-ip.org/grass/indexgrass.html )

It was really interesting to analyse the output vector map. It seems
that when the distance between two isolines is "large" GRASS "puts the
next isoline" very close to the previous and this is how the "waves"
comes from.

What sholud I do next?? Please for comments and suggestions.
Best Regards,

I do not know what is causing this behaviour, but there is a well-documented
problem with USGS dem data that causes similar artifacts:

(see the image at the bottom of the page)
http://169.237.35.250/~dylan/gdalwarp/image_matrix.html

Dylan,

Are you sure this is related? The material you mention refers to issues
connected with raster DEM re-projection. Radomir is concerned with a
comparison of different interpolation methods (with a specific input
such as contour lines), in regard to DEM's slope.

Maybe I'm missing something. Please excuse me and elaborate, if so.

Best,
Maciek

10

On Monday 30 April 2007 10:31, Maciej Sieczka wrote:

Dylan Beaudette wrote:
> On Monday 30 April 2007 06:01, Radomir wrote:
>> Dnia 26-03-2007, pon o godzinie 20:30 +1200, Hamish napisa³(a):
>>>> Radomir wrote:
>>>>> I'm preparing the slope and elevation map from digitised isolines.
>>>>> I'm using v.surf.rst to do that with the following options:
>>>>>
>>>>> v.surf.rst input="izolinie_punkty" layer=1 zcolumn="wysokosc_m_npm"
>>>>> dmax=3.174812 dmin=0.634962 elev="mapa_wystaw" slope="mapa_spadk"
>>>>> maskmap="maska" zmult=1.0 tension=40. segmax=40 npmin=300
>>>>>
>>>>> The screenshot from small part of resulting map is here:
>>>>> http://mort.no-ip.org/screen.png
>>>>>
>>>>>
>>>>> On this screen you can see the valley in the center. I expect that
>>>>> the slope between two isolines on the bottom of the valley will be
>>>>> similar. But it is changing and gives an effect of "wave" between
>>>>> isolines.
>>>
>>> Mars wrote:
>>>> I presume the Isolines are representative of Elevation.
>>>
>>> and the displayed raster, legend, and profile show the slope.
>>> it might help to show a profile using the elevation map. (it is hard to
>>> tell if the slope stays monotonically increasing in your profile as
>>> slope will always be positive)
>>>
>>>
>>>
>>> profiler notes:
>>> - y-scale is ranged to max/min of map, not max/min of profile?
>>> ($elevrange from r.univar instead of r.profile in gis.m/profile.tcl)
>>> Not sure which is best. Both ways have some merit.
>>>
>>> - in your screenshot the axes tick labels are not formatted cleanly.
>>> I've just prettified those in CVS, please test.
>>>
>>> - BUG: if profile ends outside of the raster map off in NULL-land,
>>> the totaldistance calculation is calculated to the end of the arrows,
>>> but the end of real data in the plot is stretched to the far right
>>> end regardless. e.g.: Zoom out so your raster is a postage stamp sized
>>> box in the middle, then make some profiles from map canvas corner to
>>> corner. The start of the data is positioned ok. Also it should break
>>> the plot at NULL data, not draw a line beween the last known good data
>>> either side of the NULLs.
>>>
>>> - it would be possible to add a title like "Profile for $mapname" at
>>> the top of the profile. Is there demand for this? Better to have it in
>>> the window title than on the plot itself?
>>>
>>> Maciek wrote:
>>>> I had this problem too when interpolating DEM from contour lines with
>>>> RST. Try to interploate DEM with r.surf.nnbathy from GRASS WIKI
>>>> add-ons page and let us know if the artifact hollow between 2 adjacent
>>>> contour lines still remains. I'm not 100% sure it will help. It might.
>>>
>>> v.surf.rst is designed for semi-evenly distributed series of data
>>> points (at least locally, it is fine for data density to smoothly
>>> change), not contour lines.
>>>
>>> running v.to.points + v.surf.rst tends to bias the surface to the
>>> isolines. Output the treefile= segmentation map and curvature maps to
>>> see the effect in detail. Also in the GRASS book, if you have access to
>>> it.
>>>
>>> as Maciek wrote, you should get better results with r.surf.nnbathy, or
>>> you can try r.surf.contour (see hints about that posted in the last day
>>> or two to this list for r.surf.contour).
>>>
>>> You might try r.contour with your output raster map at levels half way
>>> between your original isolines to get a nice visual check of how the
>>> interpolation went. (create new contour lines 1/2 way between the
>>> original ones and overlay them)
>>>
>>>
>>>
>>> Hamish
>>
>> Maciek, Hamish, Mars,
>> Thank you for your comments.
>>
>> I've interpolated isolines with use of r.surf.nnbathy:
>>
>> r.surf.nnbathy alg=nn input=izolinie output=nn_elevation
>>
>> unfortunately, the results are even worse that those which comes from
>> RST method. After "translating" it into the slope map (r.slope.aspect) I
>> have the following result:
>>
>> http://mort.no-ip.org/grass/indexgrass.html
>>
>> As You can see, I still have "waves" between isolines. On the graph you
>> will find those "waves" really large.
>>
>> The r.surf.contour methods gives much worse results then RST (see the
>> Elevation graph).
>>
>> I've run r.contour with my RST output map as Hamish suggested ( see the
>> last image on the http://mort.no-ip.org/grass/indexgrass.html )
>>
>> It was really interesting to analyse the output vector map. It seems
>> that when the distance between two isolines is "large" GRASS "puts the
>> next isoline" very close to the previous and this is how the "waves"
>> comes from.
>>
>> What sholud I do next?? Please for comments and suggestions.
>> Best Regards,
>
> I do not know what is causing this behaviour, but there is a
> well-documented problem with USGS dem data that causes similar artifacts:
>
> (see the image at the bottom of the page)
> http://169.237.35.250/~dylan/gdalwarp/image_matrix.html

Dylan,

Are you sure this is related? The material you mention refers to issues
connected with raster DEM re-projection. Radomir is concerned with a
comparison of different interpolation methods (with a specific input
such as contour lines), in regard to DEM's slope.

Maybe I'm missing something. Please excuse me and elaborate, if so.

Best,
Maciek

Maciek-

I was referring to the bottom-most figure, which depicts curvatures computed,
with original contours (derived from a topographic map) -and the relationship
between the two. Unfortunately the referenced page was *mostly* about
interpolation / projection of raster data..

Dylan

--
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341

11

Radomir wrote:

The r.surf.contour methods gives much worse results then RST (see the
Elevation graph).

r.surf.contour will only work with interger values (so far).
can you try something like:

r.mapcalc "map10000= int(map * 10000)"
r.surf.contour in=map10000 out=map10000_rsc
r.mapcalc "map_rsc = map10000_rsc / 10000.0"

then you can produce a smoother result in spite of r.surf.contour's
limitations.

It was really interesting to analyse the output vector map. It seems
that when the distance between two isolines is "large" GRASS "puts the
next isoline" very close to the previous and this is how the "waves"
comes from.

Could you specify the module name, not just "GRASS 'puts the next
isoline'"? GRASS is the whole, there are many different methods within
its modules, not just one, so it's hard to know which one you mean to
refer to.

Hamish

12

Dnia 01-05-2007, wto o godzinie 21:23 +1200, Hamish napisał(a):

Radomir wrote:
> The r.surf.contour methods gives much worse results then RST (see the
> Elevation graph).

r.surf.contour will only work with interger values (so far).
can you try something like:

r.mapcalc "map10000= int(map * 10000)"
r.surf.contour in=map10000 out=map10000_rsc
r.mapcalc "map_rsc = map10000_rsc / 10000.0"

then you can produce a smoother result in spite of r.surf.contour's
limitations.

I did as you suggested:
r.mapcalc "izolinie_rsc_izolinie_10k = int(izolinie_rsc_izolinie
*10000)"
r.surf.contour input=izolinie_rsc_izolinie_10k output=wysokosci_rsc_10k
r.mapcalc "wysokosci_rsc_male = wysokosci_rsc_10k / 10000.0"
then:
r.slope.aspect
and again I have those "waves" between each isoline....
See picture:
http://mort.no-ip.org/grass/indexgrass2.html

hmmm. Maybe there is something wrong with my whole project??
Basics about the project:
projection: 0 (x,y)
zone: 0
north: 444979.06151534
south: 438995.17651068
west: 597964.6049651
east: 604980.31251938
nsres: 1.26992466
ewres: 1.27004119
rows: 4712
cols: 5524
cells: 26029088
Elevation isolines are every 2.5m. Original map scale 1:10000.

> It was really interesting to analyse the output vector map. It seems
> that when the distance between two isolines is "large" GRASS "puts the
> next isoline" very close to the previous and this is how the "waves"
> comes from.

Could you specify the module name, not just "GRASS 'puts the next
isoline'"? GRASS is the whole, there are many different methods within
its modules, not just one, so it's hard to know which one you mean to
refer to.

Hamish

--
Radomir

----
The Future Is Now :wink: