[GRASS-user] Problem with slope modeling .

[Dylan Beaudette]

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