[GRASS-user] r.mapcalc questions

[Frank Broniewski]

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