[GRASS-user] sample a strds at specific locations (areas)

Stefan Blumentrath Stefan.Blumentrath at nina.no
Thu Feb 7 03:33:09 PST 2019


Hi Madi,

With this combination (polygon size vs. raster resolution), the shape of the polygons can be an issue (narrow areas that do not cover the center of any pixel).

Debugging should be simple with v.db.select or v.extract.

Areas that did not get rasterized should be NULL in the column with statistics computed with v.rast.stats.

In verbose mode v.rast.stats (or probably even v.to.rast) should probably give a more informative Warning message (e.g. listing categories not rasterized). It also would help if you can rasterize the areas yourself and provide a raster with categories as (optional) input to v.rast.stats…

For high resolution data like yours, the speed improvement of multiple raster input might help quite a bit esp. with many maps in the time series. Will see if I can come up with a patch rather soon…

Cheers
Stefan

From: Margherita Di Leo <diregola at gmail.com>
Sent: torsdag 7. februar 2019 10:37
To: Stefan Blumentrath <Stefan.Blumentrath at nina.no>
Cc: Veronica Andreo <veroandreo at gmail.com>; grass-user <grass-user at lists.osgeo.org>
Subject: Re: [GRASS-user] sample a strds at specific locations (areas)

Hi,

thank you for your replies. To give a little more context: I selected my polygon areas to be > 0.5 ha each (this would be 50000 mq if I'm not mistaken) and I'm sampling NDVI maps at 10m resolution (the region being the same as NDVI maps). So I think I need an idea on how to debug the areas that were excluded to check them individually to see what could be the problem...
Regarding the alignment problem, if I understand it correctly: if the polygon doesn't include the *center* of the raster beneath it, can't retrieve the value and the polygon is discarded? But a value exists, so it would be correct that it returned a value in any case. But I admit I don't have a full grasp of the problem.

On Wed, Feb 6, 2019 at 10:52 PM Stefan Blumentrath <Stefan.Blumentrath at nina.no<mailto:Stefan.Blumentrath at nina.no>> wrote:
Hi Vero,

I think there is a little misunderstanding.
v.rast.stats did not change it behaviour with regards to the computational region (at least not if only one raster map is used). The alignment to the input raster (resolution) has been around since the module got ported to Python (like 10 years ago):
https://trac.osgeo.org/grass/browser/grass/trunk/scripts/v.rast.stats/v.rast.stats.py?rev=33522#L148

So, adding a flag for skipping the alignment was more an idea for an enhancement that allows the behaviour you seem to prefer (too).

Cheers
Stefan

From: Veronica Andreo <veroandreo at gmail.com<mailto:veroandreo at gmail.com>>
Sent: onsdag 6. februar 2019 21:38
To: Stefan Blumentrath <Stefan.Blumentrath at nina.no<mailto:Stefan.Blumentrath at nina.no>>
Cc: Margherita Di Leo <diregola at gmail.com<mailto:diregola at gmail.com>>; grass-user <grass-user at lists.osgeo.org<mailto:grass-user at lists.osgeo.org>>
Subject: Re: [GRASS-user] sample a strds at specific locations (areas)

I had a similar problem some time ago, just that it was not raster resolution, but region resolution that I changed to solve my problem (see this thread and MM's answer: http://osgeo-org.1560.x6.nabble.com/v-to-rast-for-polygons-not-overlapping-center-of-raster-cell-td5355686.html#a5355729)

IIUC, MM's proposed solution to my case then does not work anymore because v.to.rast call inside v.rast.stats is affected by the region alignment to the raster to be queried. So, the solution is indeed now, to change raster resolution... ? Then the region would be aligned to it (them)?

If one has large areas or long time series and has to resample all rasters to get smallish polygons rasterized, I do not see the advantage of this new behavior... but maybe I'm missing something

Cheers,
Vero

El mié., 6 feb. 2019 16:54, Stefan Blumentrath <Stefan.Blumentrath at nina.no<mailto:Stefan.Blumentrath at nina.no>> escribió:
Ciao Madi, Vero,

Starting with GRASS 7.6, also centroids are used to get the raster representation of your area vector map. That increases the likelihood of smaller areas to be rasterized.
Increasing the resolution of the current region alone does not help, because v.rast.stats temporarily changes the computational region to align with the input raster map(s) (see also: https://trac.osgeo.org/grass/ticket/3523 and https://trac.osgeo.org/grass/ticket/3598 for discussion) Even if the first ticket is closed, comments are welcome.
It might make sense to add a flag to v.rast.stats like in r.slope.aspect to not align the computational region.

Furthermore, with regards to efficiency, v.strds.stats could gain some speed if multi-raster support in v.rast.stats - added in G 7.6 - would be handed down to the addon. Might almost double the speed for larger STRDS…

Cheers
Stefan

From: grass-user <grass-user-bounces at lists.osgeo.org<mailto:grass-user-bounces at lists.osgeo.org>> On Behalf Of Veronica Andreo
Sent: onsdag 6. februar 2019 17:20
To: Margherita Di Leo <diregola at gmail.com<mailto:diregola at gmail.com>>
Cc: GRASS user list <grass-user at lists.osgeo.org<mailto:grass-user at lists.osgeo.org>>
Subject: Re: [GRASS-user] sample a strds at specific locations (areas)

Hi Madi

El mié., 6 feb. 2019 a las 16:31, Margherita Di Leo (<diregola at gmail.com<mailto:diregola at gmail.com>>) escribió:
I have a question regarding v.strds.stats. I get the following warning message:

WARNING: Not all vector categories converted to raster. Converted 120 of 265.

What could be the reason for that?

Some vector areas might not be converted because they are too small with respect to the pixel size that you try to query. Others will tell better but I think the polygon must overlap the center of the pixel in order to be converted into raster. One solution could be to resample your rasters to a higher resolution.
HTH,
Vero


--
Margherita Di Leo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20190207/9d2685a4/attachment-0001.html>


More information about the grass-user mailing list