[GRASS-dev] v.to.rast for polygons not overlapping center of raster cell

[Veronica Andreo]

Hi Markus, Nikos

Thanks for your answers

[...]

> > I have hundreds of vector maps corresponding to a time series of burned
> areas in the state of Victoria, Australia. To be able to extract the number
> of classes (diversity) and the most common LC/slope burned (mode), I need
> to transform each polygon vector map to raster, then use r.statistics, then
> use r.mapcalc "LC_mode = @bushfire_20000103_LC_mode" and then v.rast.stats
> (could use v.rast.stats directly if it had mode and diversity) to get the
> values.
> >
> > In any case, my problem arises when polygons do not overlap the center
> of the cell and therefore I get null rasters out of v.to.rast [1].
> Consequently I cannot get info of LC and slope classes for those polygons.
> >
> > Is there a way to avoid this behavior in v.to.rast and be able to get
> info for those polygons too? How can I get a list of all the polygons that
> do not overlap the center of the grid cells to then use a different
> approach for those ( if they are not too many :-/ )?
>
> This can happen when the polygons are very small or very thin. You could
> either discard these tiny polygons or increase the resolution of the
> current region. With smaller raster cells, chances are higher that a cell
> center will fall into these small polygons.
>

I did the latter indeed, i.e., increased the resolution of the region.
Overall, the workflow is not very efficient... to be able to get diversity
and mode from a raster map into polygons of a vector map, I use v.to.rast
first (which with higher res takes more time), then r.statistics, then
r.mapcalc, and then v.rast.stats (which internally uses v.to.rast again)...
Is it difficult to implement diversity and mode in r.univar so then
v.rast.stats can benefit of it? (then the workflow would be only
v.rast.stats) Maybe I can study this in the code sprint with some help of
yours of course...

Thanks again :)
Vero
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20180227/e5a315bb/attachment-0001.html>