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

GRASS GRASS developer
1

Hi devs,

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 :-/ )?

What would you recommend?

Thanks a lot in advance!

Vero

[1] https://lists.osgeo.org/pipermail/grass-dev/2015-October/076676.html

2

* Veronica Andreo <veroandreo@gmail.com> [2018-02-26 23:40:59 +0100]:

Hi devs,

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.

Burned areas are the base maps?
And "cover" maps are then LC/slope?

Did you consider to use

r.mask vector=BurnedAreas [where="SomeColumn='SomeValue'"]

and then `g.region zoom=MASK` and then, maybe, grow a bit the region with the
new(est) `g.region pixels=` option and, finally, redo the MASK,

so at least to get the computational region to include all of it?

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 :-/ )?

What would you recommend?

Thanks a lot in advance!
Vero

[1] https://lists.osgeo.org/pipermail/grass-dev/2015-October/076676.html

Vero, I recall some similar situation years ago (described somewhere in
a messy script in https://trac.osgeo.org/grass/ticket/804) with a
specific problem that lead to `g.region pixels=`, see:
the step-by-step process https://trac.osgeo.org/grass/ticket/789.

I hope this is not confusing more.

Nikos

3

On Mon, Feb 26, 2018 at 11:40 PM, Veronica Andreo <veroandreo@gmail.com> wrote:

Hi devs,

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.

Markus M

What would you recommend?

Thanks a lot in advance!
Vero

[1] https://lists.osgeo.org/pipermail/grass-dev/2015-October/076676.html

grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

4

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 :slight_smile:

Vero