#959: r.surf.contour. Resulting range of values has an incorrect 0 minimum.
-------------------------+--------------------------------------------------
Reporter: clerici | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: Raster | Version: unspecified
Keywords: | Platform: Linux
Cpu: Unspecified |
-------------------------+--------------------------------------------------
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).[[BR]]
v.to rast in=countours ou=contours use=cat[[BR]]
r.mask in=maskmap[[BR]]
r.surf.contour in=contours ou=dem[[BR]]
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)[[BR]]
With:[[BR]]
r.mapcalc demcalc=dem[[BR]]
r.info demcalc[[BR]]
the correct range min=310 and max=370 is reported and a more adequate
color table is adopted (fig.3).[[BR]]
This seems a very old feature as I had the same results with GRASS6.5,
6.4, 6.3 and 6.2.
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).
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.
----
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
#959: r.surf.contour. Resulting range of values has an incorrect 0 minimum.
----------------------------------+-----------------------------------------
Reporter: clerici | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.1
Component: Raster | Version: svn-releasebranch64
Keywords: r.surf.contour, NULL | Platform: All
Cpu: All |
----------------------------------+-----------------------------------------
Changes (by mmetz):
* platform: Linux => All
* cpu: Unspecified => All
Comment:
Replying to [comment:4 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.