Hi,
I have some questions concerning the use of r.mapcalc. I have a DEM made by r.surf.contour using the approach in the wiki (multiplying by 100000)[1]. Now when calculating back the original values I wonder about the values given by r.info. Calculation is done like so within the wxpython map calculator: r.mapcalc dtm_surf = dtm_surf.100k / 100000.0
Now r.info tells me:
Data Type: DCELL
which seems OK, but
Range of data: min = 130 max = 555
-> shouldn't these be float values after calculation?
and the comments
dtm_surf.100k / 100000
I definitely typed 100000.0! Where're my .0s? A quick visual verification with r.slope.aspect shows some terracing effects. That lets me suspect that the conversion to a DEM float raster failed somehow - but why?
I'm using the osgeo4w build on windows 7 64. GRASS GIS version is 6.4.1 (2011).
Many thanks
Frank
[1] http://grass.osgeo.org/wiki/Contour_lines_to_DEM
--
Frank BRONIEWSKI
METRICO s.à r.l.
géomètres
technologies d'information géographique
rue des Romains 36
L-5433 NIEDERDONVEN
tél.: +352 26 74 94 - 28
fax.: +352 26 74 94 99
http://www.metrico.lu
Frank Broniewski wrote:
I have some questions concerning the use of r.mapcalc. I have a DEM made
by r.surf.contour using the approach in the wiki (multiplying by
100000)[1]. Now when calculating back the original values I wonder about
the values given by r.info. Calculation is done like so within the
wxpython map calculator: r.mapcalc dtm_surf = dtm_surf.100k / 100000.0
Now r.info tells me:
Data Type: DCELL
which seems OK, but
Range of data: min = 130 max = 555
-> shouldn't these be float values after calculation?
and the comments
dtm_surf.100k / 100000
I definitely typed 100000.0! Where're my .0s?
For DCELL, r.info uses %.15g for the range, while r.mapcalc uses %.8g
for floating-point constants in the history. The "%g" format specifier
omits trailing zeros, and omits the decimal point if nothing follows
it.
The alternatives are "%f", which uses a fixed number of decimal
places, "%e" which always uses scientific (exponential) notation, or
"%#g", which always includes the decimal point and trailing zeros. All
of these have their drawbacks.
Would would be nice would be like the existing behaviour but always
retaining the decimal point and at least one digit, but there isn't
any easy way to get that.
A quick visual
verification with r.slope.aspect shows some terracing effects. That lets
me suspect that the conversion to a DEM float raster failed somehow -
but why?
Note that r.surf.contour works in floating-point and generates DCELL
output, so the multiplication and subsequent division should be
unnecessary.
--
Glynn Clements <glynn@gclements.plus.com>
Hi Glynn,
thanks for your response. So it's only a matter of string/number formatting with r.info? That's good to hear. I feared already the worst - sort of 
r.surf.contour uses floating point only in the latest version of GRASS, doesn't it? I read it too late in the wiki and my calculation was already half through, so I stuck with the "old method", but for newer calculations it's good to know that the workaround isn't necessary anymore.
Frank
Am 09.06.2011 08:58, schrieb Glynn Clements:
Frank Broniewski wrote:
I have some questions concerning the use of r.mapcalc. I have a DEM made
by r.surf.contour using the approach in the wiki (multiplying by
100000)[1]. Now when calculating back the original values I wonder about
the values given by r.info. Calculation is done like so within the
wxpython map calculator: r.mapcalc dtm_surf = dtm_surf.100k / 100000.0
Now r.info tells me:
Data Type: DCELL
which seems OK, but
Range of data: min = 130 max = 555
-> shouldn't these be float values after calculation?
and the comments
dtm_surf.100k / 100000
I definitely typed 100000.0! Where're my .0s?
For DCELL, r.info uses %.15g for the range, while r.mapcalc uses %.8g
for floating-point constants in the history. The "%g" format specifier
omits trailing zeros, and omits the decimal point if nothing follows
it.
The alternatives are "%f", which uses a fixed number of decimal
places, "%e" which always uses scientific (exponential) notation, or
"%#g", which always includes the decimal point and trailing zeros. All
of these have their drawbacks.
Would would be nice would be like the existing behaviour but always
retaining the decimal point and at least one digit, but there isn't
any easy way to get that.
A quick visual
verification with r.slope.aspect shows some terracing effects. That lets
me suspect that the conversion to a DEM float raster failed somehow -
but why?
Note that r.surf.contour works in floating-point and generates DCELL
output, so the multiplication and subsequent division should be
unnecessary.
--
Frank BRONIEWSKI
METRICO s.à r.l.
géomètres
technologies d'information géographique
rue des Romains 36
L-5433 NIEDERDONVEN
tél.: +352 26 74 94 - 28
fax.: +352 26 74 94 99
http://www.metrico.lu
Frank Broniewski wrote:
thanks for your response. So it's only a matter of string/number
formatting with r.info?
Yes.
r.surf.contour uses floating point only in the latest version of GRASS,
doesn't it?
Yes. 6.4.0 uses CELL, 6.4.1 uses DCELL.
--
Glynn Clements <glynn@gclements.plus.com>