[GRASS-dev] r.statistics limitation to CELL

Sören Gebbert soerengebbert at gmx.de
Sun Jun 3 20:08:20 EDT 2007


Hi,

Markus Neteler schrieb:
> On Sun, Jun 03, 2007 at 03:58:40AM +0100, Glynn Clements wrote:
>> Markus Neteler wrote:
>>> Glynn Clements wrote:
>>>> 2. r.statistics uses r.stats to calculate the statistics, and r.stats
>>>> reads its inputs as CELL.
>>> In this case, r.statistics could also accept an FCELL map
>>> without complaining? Currently I need extra steps to round
>>> elevation to a CELL map before running r.statistics.
>> You should be able to simply remove the check at
>> raster/r.statistics/main.c:83:
>>
>>     if( G_raster_map_is_fp(covermap->answer, mapset) != 0 )
>>         G_fatal_error (_("This module currently only works for integer (CELL) maps"));
>>
>> Or you might want to replace the error with a warning that the result
>> is inaccurate.
> 
> If so, the latter. Currently I have to round() the elevation map
> before running r.statistics - so results are inaccurate anyway
> but the procedure requires more extra work.
> 
> The master question is: is it possible to conditionalize calls in
> r3.stats to make it working for 2D maps. The new implementation from
> Soeren sounds promising and along the lines of your suggestion to
> rewrite r.stats from scratch.

The range and equal value group algorithm in r3.stats is generic, so
it is not complicated to extend r3.stats with raster support.
It is possible to call the statistic creation and computation functions
in r3.stats for every double/float array of which volume/area statistics should be
computed with very tiny modifications (eg: area instead of volume computation).
It is mostly independently from raster, volume or what ever maps.
But to implement all the nice features of r.stats in r3.stats is not that easy.

I have currently no time to implement this. :(
Currently more important for me is to finish the core design of the gpde library
and to implement a faster preconditioned conjugate gradient solver (pcg) for better
numerical stability in v.surf.rst.
And to check the stability of the gpde lib to work with multiple threads (which is not easy).

Best regards
Soeren

> 
> Markus
> 
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
> 




More information about the grass-dev mailing list