3

When producing a slope in GRASS GIS 7.4 the results are different than with QGIS (GDAL) and ArcMap for the same input data and same parameter (Z ratio is 1.0 and degrees). QGIS and ArcMap generate almost the same output. In GRASS, I tried both for DCELL and FCELL and the results are same. The original layer has a resolution on 1 m and the GRASS region resolution is set to 0.5 m.

Code GRASS: r.slope.aspect elevation=DMR@PERMANENT slope=slope

Code GDAL: gdaldem slope .../DMR.tif .../slope.tif -of GTiff -b 1 -s 1.0

Do I do something wrong? I am attaching the screenshots of the situation.

Left - GRASS calculated slope and right - GDAL calculated one Left - GRASS calculated slope and right - GDAL calculated one

  • What is the difference if you set the grass region to the raster resolution? g.region raster=DMR@PERMANENT? (with and without the -a option) – mankoff Jun 3 at 17:08
  • No difference. I i tried both and in both situations the same slope results. – mazinga Jun 4 at 10:27
  • Right - nor should it. I read the r.slope.aspect docs and it says it adjusts the region to the raster. Can you share the file? – mankoff Jun 5 at 12:16
  • 1
    Hi @mankoff I uploaded you a TIF [LZW] on wetrasnfer. Thank you very much. we.tl/t-YO1VNmDgAW – mazinga Jun 5 at 13:25
2

Here are the replies by mankoff and mmetz from trac.osgeo:

I think the issue is related to the region.

There is a work-around for the bug: g.region raster=<raster> -a

The r.slope.aspect documentation in the NOTES section implies that the region is adjusted to the raster. I do not find that to be the case. Specifically in the NC test data, I've created the following slope rasters, and then looked at their univariate statistics:

g.region raster=elevation r.slope.aspect elevation=elevation slope=slope_0 r.slope.aspect -a elevation=elevation slope=slope_1 g.region res=30 -pa r.slope.aspect elevation=elevation slope=slope_2 r.slope.aspect -a elevation=elevation slope=slope_3

for i in $(seq 0 3); do (echo -n "slope_${i} "; r.univar slope_${i} | grep range) | tr '\n' ' ' done

Results are:

slope_0 range: 36.3347 slope_1 range: 36.3347 slope_2 range: 13.7754 slope_3 range: 25.3968

ticket

Comment (by mmetz):

Replying to [comment:15 mankoff]:

Running r.univar at the region resolution (as above) or at the raster resolution:

{{{ for r in $(g.list mapset=. type=raster); do g.region raster=${r} -a (echo -n "${r} "; r.univar ${r} | grep range) done | sort | tac }}}

Does not change anything.

Right, this was a bug in r.slope.aspect, alignment to the input raster did not work (difference between G_get_window() and Rast_get_window()). Fixed in master, relbr76, and relbr74

  • Glad you spotted this! – markusN Jun 11 at 8:09
  • 1
    The bug has been fixed as of today and will be published in GRASS GIS 7.4.5, 7.6.2 and 7.8.0 (find here their respective release dates: trac.osgeo.org/grass/roadmap) – markusN Jun 11 at 8:15
  • 1
    Suggested edit, to be placed at top and/or highlighted: There is a work-around for the bug: g.region raster=<raster> -a. – mankoff Jun 11 at 10:50
  • @mankoff done! and thanks again – mazinga Jun 11 at 13:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.