r.surf.contour. Resulting range of values has an incorrect 0 minimum.

[clerici]

I have a vector with contour lines from min=300 and max=380 and I want to construct a DEM for a (nearly) rectangular area defined in the raster maskmap(fig.1).
v.to rast in=countours ou=contours use=cat
r.mask in=maskmap
r.surf.contour in=contours ou=dem
with: r.info dem, the output range of data is min=0 and max=370, but there isn't any value lesser than 310 in the map, at least inside the masked area, so it seems that also the values outside the mask are considered in defining the values' range. Unfortunately the range 0-370 affects the color table (fig.2)
With:
r.mapcalc demcalc=dem
r.info demcalc
the correct range min=310 and max=370 is reported and a more adequate color table is adopted (fig.3).

This seems a very old feature as I had the same results with GRASS6.5, 6.4, 6.3 and 6.2.

[hamish]

try "r.null dem setnull=0"

r.surf.contour is known to treat 0 as NULL; perhaps that also works the other way too with NULL being treated as 0??

a couple of subtle things to note:

• MASK maps are only applied when reading raster map cells from the disk. It has no effect on writing raster maps to the disk. So a MASK map will have no effect on r.surf.contour which only reads vector maps.

• r.info doesn't read raster cells, it just summarizes the raster map's metadata files. So MASK (or region settings) has no effect on it either.

• r.univar and d.histogram do on the other hand read cells so do respect the MASK.

• r.mapcalc works because the MASK is applied while reading the dem map from the disk.

This seems a very old feature as I had the same results with GRASS6.5, 6.4, 6.3 and 6.2.

The bug is even older than that.. see this bug report which I filed back in late 2002 (yes, it's still open!)

​http://intevation.de/rt/webrt?serial_num=1402

and the BUGS section of the r.surf.contour help page. The module does a really really nice job, but it has never fully been ported from GRASS 4.x (pre-NULL and floating point map support).

Hamish

[mmetz]

Hopefully fixed in trunk and devbr6 as of r43597. The help page still needs updating when the fix is confirmed, as does the wiki page.

Markus M

[mmetz]

Also fixed for 6.4.1 in 43605. I regard it as a change that should have happened several years ago.

Markus M

[hamish]

Also fixed for 6.4.1 in 43605. I regard it as a change that should have happened several years ago.

sure; all backports need thorough testing, so:

tested r.surf.contour in 6.5svn using NC dataset commands from ​http://grass.osgeo.org/wiki/Contour_lines_to_DEM#r.surf.contour

searching for artifacts in the derivative layers,

r.slope.aspect elev=elev.1mcont.surf slope=elev.1mcont.surf.slope \
  aspect=elev.1mcont.surf.aspect pcurv=elev.1mcont.surf.pcurv \
  tcurv=elev.1mcont.surf.tcurv

the profile curvature map highlights the "thatched roof" effect at contour lines as before. but all in all it's pretty good and nothing that a 5x5 r.neighbors smoothing can't clean up.

integer 0 contour levels tested ok too:

r.mapcalc "elev.1mcont.sealevel = int(elev.1mcont - 115)

---

remaining in CELL-only is r.surf.idw; r.surf.idw is much faster than r.surf.idw2 but does not create floating-point maps directly. Otherwise the module output is practically identical. see ​http://grass.osgeo.org/wiki/Contour_lines_to_DEM#r.surf.idw

thanks, Hamish

[mmetz]

Replying to hamish:

the profile curvature map highlights the "thatched roof" effect at contour lines as before.

The "thatched roof" effect is caused by the the interpolation method (inverse distance weighing) used by r.surf.contour.

IMHO, interpolating surfaces from contour lines should nowadays be a last resort to generate a surface when no other data (grids or point clouds) are available.

Thanks for additional testing,

Markus M

[mmetz]

Can we close this ticket now as fixed?

[clerici]

I agree in closing it as fixed.

1. Clerici