[GRASS-user] Problem with slope modeling .

Maciej Sieczka tutey at o2.pl
Mon Apr 30 13:31:01 EDT 2007


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




More information about the grass-user mailing list