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, 2019 at 17:08
  • No difference. I i tried both and in both situations the same slope results.
    – mazinga
    Jun 4, 2019 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, 2019 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, 2019 at 13:25

1 Answer 1


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


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, 2019 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, 2019 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, 2019 at 10:50
  • @mankoff done! and thanks again
    – mazinga
    Jun 11, 2019 at 13:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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