[GRASS-dev] v.rast.stats: NULL values for very small areas

[Moritz Lennert]

On 06/10/15 17:51, Martin Landa wrote:
> Hi,
>
> 2015-10-06 17:29 GMT+02:00 Moritz Lennert <mlennert at club.worldonline.be>:
>> One can argue that setting them NULL is actually a valid choice as it might
>> not be legitimate to give them values of pixel so much larger. But maybe
>> this should be decided by a flag ?
>
> right, a flag could be an option.
>
> [...]
>
>> Get area and if area < pixel size then
>
>> - number = 1
>
> There can be more areas with same category.

Yes, but the 'number' statistic gives you the number of pixels in the 
area. This number is important to interpret the other statistics (a mean 
and stddev based on 2 pixels do not necessarily have the same 
statistical value as the same statistics based on several hundred 
pixels). Putting number = 1 is a bit of a 'lie', here as there is less 
than a pixel in the area, but the only way to get any numbers into the 
statistics is to use the value of a pixel, so number=1 means: we used 
one single pixel to determine these statistics.

>
>> - range = 0
>> - stddev,variance,coeff_var = 0 (or NULL)
>> - all other values = pixel value which you can get by replacing the areas by
>> their centroids, you could use v.what.rast to get the pixel value.
>>
>> But I wonder if this is not a bit of overkill...
>
> Why? I have request from the users, they are not happy about NULL
> values.

But, as already said, one could argue that NULL is the  scientifically 
most correct answer in this case...

v.rast.stats is not about getting pixel values, but about getting 
statistics of collections of pixel values. When you do not even have one 
single pixel entirely containted in the area, then it makes sense to say 
that you cannot calculate any statistics and set the value to NULL.

If you just want pixel values, you can always use v.what.rast based on 
the area centroids.

> I just wonder how to implement within Python script.

Get areas of all polygons (or lenghts of lines) with v.to.db and then 
divide the features into those with areas above pixel size and those 
with areas below. Treat each set differently (i.e. the former as before, 
the latter by using v.what.rast - with the -p flag - to get the pixel 
value). As the updating of the table is done feature by feature anyhow, 
all you lose in terms of performance is the additional step of 
calculating areas/lengths of features.

> Probably
> rewriting to C would make sense(?)

It might make it more efficient, but I think the python version would 
work well and the change in python version should not be too complicated.

Moritz