sample a strds at specific locations (areas)

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

sample a strds at specific locations (areas)

margherita
Hi,

I need to sample a strds at specific locations, but rather than point locations I need to pass a vector with areas. I need to know the average value within each area at each given time. How could I do this?

Thanks in advance

--
Margherita Di Leo

_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: sample a strds at specific locations (areas)

Veronica Andreo
Hi Madi,

check the add-on v.strds.stats (https://grass.osgeo.org/grass74/manuals/addons/v.strds.stats.html) that does exactly that :)

cheers,
Vero

El mar., 5 feb. 2019 a las 15:21, Margherita Di Leo (<[hidden email]>) escribió:
Hi,

I need to sample a strds at specific locations, but rather than point locations I need to pass a vector with areas. I need to know the average value within each area at each given time. How could I do this?

Thanks in advance

--
Margherita Di Leo
_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user

_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: sample a strds at specific locations (areas)

margherita
Grazie Vero!! Kudos to Luca (author) :-)

On Tue, Feb 5, 2019 at 3:27 PM Veronica Andreo <[hidden email]> wrote:
Hi Madi,

check the add-on v.strds.stats (https://grass.osgeo.org/grass74/manuals/addons/v.strds.stats.html) that does exactly that :)

cheers,
Vero

El mar., 5 feb. 2019 a las 15:21, Margherita Di Leo (<[hidden email]>) escribió:
Hi,

I need to sample a strds at specific locations, but rather than point locations I need to pass a vector with areas. I need to know the average value within each area at each given time. How could I do this?

Thanks in advance

--
Margherita Di Leo
_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user


--
Margherita Di Leo

_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: sample a strds at specific locations (areas)

margherita
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?

Thanks,

On Tue, Feb 5, 2019 at 3:30 PM Margherita Di Leo <[hidden email]> wrote:
Grazie Vero!! Kudos to Luca (author) :-)

On Tue, Feb 5, 2019 at 3:27 PM Veronica Andreo <[hidden email]> wrote:
Hi Madi,

check the add-on v.strds.stats (https://grass.osgeo.org/grass74/manuals/addons/v.strds.stats.html) that does exactly that :)

cheers,
Vero

El mar., 5 feb. 2019 a las 15:21, Margherita Di Leo (<[hidden email]>) escribió:
Hi,

I need to sample a strds at specific locations, but rather than point locations I need to pass a vector with areas. I need to know the average value within each area at each given time. How could I do this?

Thanks in advance

--
Margherita Di Leo
_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user


--
Margherita Di Leo


--
Margherita Di Leo

_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: sample a strds at specific locations (areas)

Veronica Andreo
Hi Madi

El mié., 6 feb. 2019 a las 16:31, Margherita Di Leo (<[hidden email]>) 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

_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
SBL
Reply | Threaded
Open this post in threaded view
|

Re: sample a strds at specific locations (areas)

SBL

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 <[hidden email]> On Behalf Of Veronica Andreo
Sent: onsdag 6. februar 2019 17:20
To: Margherita Di Leo <[hidden email]>
Cc: GRASS user list <[hidden email]>
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 (<[hidden email]>) 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


_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: sample a strds at specific locations (areas)

Veronica Andreo
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 <[hidden email]> 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 <[hidden email]> On Behalf Of Veronica Andreo
Sent: onsdag 6. februar 2019 17:20
To: Margherita Di Leo <[hidden email]>
Cc: GRASS user list <[hidden email]>
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 (<[hidden email]>) 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


_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
SBL
Reply | Threaded
Open this post in threaded view
|

Re: sample a strds at specific locations (areas)

SBL

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 <[hidden email]>
Sent: onsdag 6. februar 2019 21:38
To: Stefan Blumentrath <[hidden email]>
Cc: Margherita Di Leo <[hidden email]>; grass-user <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> On Behalf Of Veronica Andreo
Sent: onsdag 6. februar 2019 17:20
To: Margherita Di Leo <[hidden email]>
Cc: GRASS user list <[hidden email]>
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 (<[hidden email]>) 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


_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: sample a strds at specific locations (areas)

margherita
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 <[hidden email]> 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 <[hidden email]>
Sent: onsdag 6. februar 2019 21:38
To: Stefan Blumentrath <[hidden email]>
Cc: Margherita Di Leo <[hidden email]>; grass-user <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> On Behalf Of Veronica Andreo
Sent: onsdag 6. februar 2019 17:20
To: Margherita Di Leo <[hidden email]>
Cc: GRASS user list <[hidden email]>
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 (<[hidden email]>) 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

_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
SBL
Reply | Threaded
Open this post in threaded view
|

Re: sample a strds at specific locations (areas)

SBL

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 <[hidden email]>
Sent: torsdag 7. februar 2019 10:37
To: Stefan Blumentrath <[hidden email]>
Cc: Veronica Andreo <[hidden email]>; grass-user <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
Sent: onsdag 6. februar 2019 21:38
To: Stefan Blumentrath <[hidden email]>
Cc: Margherita Di Leo <[hidden email]>; grass-user <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> On Behalf Of Veronica Andreo
Sent: onsdag 6. februar 2019 17:20
To: Margherita Di Leo <[hidden email]>
Cc: GRASS user list <[hidden email]>
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 (<[hidden email]>) 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


_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: sample a strds at specific locations (areas)

margherita
Thank you Stefan for your help! I figured what happens. v.strds.stats with default method produces in my case a corrupted output, topology is there but there's no table associated to it. If I specify method=average, I do obtain the table, and the mystery is solved: some of the polygons fall into a nodata (due to cloud mask). If anyone else can reproduce the corrupted table issue, I can file a ticket for that.

Thanks for help!
Regards,

On Thu, Feb 7, 2019 at 12:33 PM Stefan Blumentrath <[hidden email]> wrote:

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 <[hidden email]>
Sent: torsdag 7. februar 2019 10:37
To: Stefan Blumentrath <[hidden email]>
Cc: Veronica Andreo <[hidden email]>; grass-user <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
Sent: onsdag 6. februar 2019 21:38
To: Stefan Blumentrath <[hidden email]>
Cc: Margherita Di Leo <[hidden email]>; grass-user <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> On Behalf Of Veronica Andreo
Sent: onsdag 6. februar 2019 17:20
To: Margherita Di Leo <[hidden email]>
Cc: GRASS user list <[hidden email]>
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 (<[hidden email]>) 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



--
Margherita Di Leo

_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: sample a strds at specific locations (areas)

Veronica Andreo
Hi Stefan and Madi,

Thanks Stefan for the explanations :) Indeed I agree that a flag to avoid the alignment to input rasters (and just use region settings) sounds good.
I tested what Madi said, but cannot reproduce in the climate NC location [0]. This is the command I used:

v.strds.stats in=boundary_county where="cat == '261'" strds=tempmean t_where="start_time >= '2012-01-01'" out=test

to make it faster (it feels indeed kinda slow for the whole vector and full time series), I selected only one polygon and a range of dates. I get the table as expected while leaving methods by default.

best,
Vero





El jue., 7 feb. 2019 a las 14:39, Margherita Di Leo (<[hidden email]>) escribió:
Thank you Stefan for your help! I figured what happens. v.strds.stats with default method produces in my case a corrupted output, topology is there but there's no table associated to it. If I specify method=average, I do obtain the table, and the mystery is solved: some of the polygons fall into a nodata (due to cloud mask). If anyone else can reproduce the corrupted table issue, I can file a ticket for that.

Thanks for help!
Regards,

On Thu, Feb 7, 2019 at 12:33 PM Stefan Blumentrath <[hidden email]> wrote:

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 <[hidden email]>
Sent: torsdag 7. februar 2019 10:37
To: Stefan Blumentrath <[hidden email]>
Cc: Veronica Andreo <[hidden email]>; grass-user <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
Sent: onsdag 6. februar 2019 21:38
To: Stefan Blumentrath <[hidden email]>
Cc: Margherita Di Leo <[hidden email]>; grass-user <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> On Behalf Of Veronica Andreo
Sent: onsdag 6. februar 2019 17:20
To: Margherita Di Leo <[hidden email]>
Cc: GRASS user list <[hidden email]>
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 (<[hidden email]>) 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



--
Margherita Di Leo

_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: sample a strds at specific locations (areas)

margherita
Thanks for testing, Vero. I assume it's due to a local problem then.

Cheers,

On Thu, Feb 7, 2019 at 3:29 PM Veronica Andreo <[hidden email]> wrote:
Hi Stefan and Madi,

Thanks Stefan for the explanations :) Indeed I agree that a flag to avoid the alignment to input rasters (and just use region settings) sounds good.
I tested what Madi said, but cannot reproduce in the climate NC location [0]. This is the command I used:

v.strds.stats in=boundary_county where="cat == '261'" strds=tempmean t_where="start_time >= '2012-01-01'" out=test

to make it faster (it feels indeed kinda slow for the whole vector and full time series), I selected only one polygon and a range of dates. I get the table as expected while leaving methods by default.

best,
Vero





El jue., 7 feb. 2019 a las 14:39, Margherita Di Leo (<[hidden email]>) escribió:
Thank you Stefan for your help! I figured what happens. v.strds.stats with default method produces in my case a corrupted output, topology is there but there's no table associated to it. If I specify method=average, I do obtain the table, and the mystery is solved: some of the polygons fall into a nodata (due to cloud mask). If anyone else can reproduce the corrupted table issue, I can file a ticket for that.

Thanks for help!
Regards,

On Thu, Feb 7, 2019 at 12:33 PM Stefan Blumentrath <[hidden email]> wrote:

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 <[hidden email]>
Sent: torsdag 7. februar 2019 10:37
To: Stefan Blumentrath <[hidden email]>
Cc: Veronica Andreo <[hidden email]>; grass-user <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
Sent: onsdag 6. februar 2019 21:38
To: Stefan Blumentrath <[hidden email]>
Cc: Margherita Di Leo <[hidden email]>; grass-user <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> On Behalf Of Veronica Andreo
Sent: onsdag 6. februar 2019 17:20
To: Margherita Di Leo <[hidden email]>
Cc: GRASS user list <[hidden email]>
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 (<[hidden email]>) 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



--
Margherita Di Leo


--
Margherita Di Leo

_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: sample a strds at specific locations (areas)

margherita
Hi,

excuse me if I return on this. I have again the same problem, of v.strds.stats skipping lots of polygons. Now I'm using a brand new dataset - strds of Sentinel 1 and a brand now vector of polygons - and the skipped polygons are not narrow, I'm sure that there are cells centroids in it. See for example screenshot attached, depicting a polygon that was skipped. I also tried to run v.strds.stats on that polygon alone, like:

v.strds.stats in=big_areas2@PERMANENT where="cat == '1'"  strds=db_cross_pol@scaled out=test method=average 

v.info test
 +----------------------------------------------------------------------------+
 | Name:            test                                                      |
 | Mapset:          stats                                                     |
 | Location:        S1                                                        |
 | Database:        /media/madi/TOSHIBA EXT/S1/grassdata                      |
 | Title:           Output from v.patch                                       |
 | Map scale:       1:1                                                       |
 | Name of creator: madi                                                      |
 | Organization:                                                              |
 | Source date:     Fri Aug  9 12:12:49 2019                                  |
 | Timestamp (first layer): none                                              |
 |----------------------------------------------------------------------------|
 | Map format:      native                                                    |
 |----------------------------------------------------------------------------|
 |   Type of map: vector (level: 2)                                           |
 |                                                                            |
 |   Number of points:       0               Number of centroids:  0          |
 |   Number of lines:        0               Number of boundaries: 0          |
 |   Number of areas:        0               Number of islands:    0          |
 |                                                                            |
 |   Map is 3D:              No                                               |
 |   Number of dblinks:      0                                                |
 |                                                                            |
 |   Projection: UTM (zone 34)                                                |
 |                                                                            |
 |               N:                 0    S:                 0                 |
 |               E:                 0    W:                 0                 |
 |                                                                            |
 |   Digitization threshold: 0                                                |
 |   Comment:                                                                 |
 |                                                                            |
 +----------------------------------------------------------------------------+

I confess I hadn't look much further into it because I thought it was a problem with nodata, but this is not the case and I think it's  worth of further investigation. Thanks for any pointers.

Regards,


On Thu, Feb 7, 2019 at 4:10 PM Margherita Di Leo <[hidden email]> wrote:
Thanks for testing, Vero. I assume it's due to a local problem then.

Cheers,

On Thu, Feb 7, 2019 at 3:29 PM Veronica Andreo <[hidden email]> wrote:
Hi Stefan and Madi,

Thanks Stefan for the explanations :) Indeed I agree that a flag to avoid the alignment to input rasters (and just use region settings) sounds good.
I tested what Madi said, but cannot reproduce in the climate NC location [0]. This is the command I used:

v.strds.stats in=boundary_county where="cat == '261'" strds=tempmean t_where="start_time >= '2012-01-01'" out=test

to make it faster (it feels indeed kinda slow for the whole vector and full time series), I selected only one polygon and a range of dates. I get the table as expected while leaving methods by default.

best,
Vero





El jue., 7 feb. 2019 a las 14:39, Margherita Di Leo (<[hidden email]>) escribió:
Thank you Stefan for your help! I figured what happens. v.strds.stats with default method produces in my case a corrupted output, topology is there but there's no table associated to it. If I specify method=average, I do obtain the table, and the mystery is solved: some of the polygons fall into a nodata (due to cloud mask). If anyone else can reproduce the corrupted table issue, I can file a ticket for that.

Thanks for help!
Regards,

On Thu, Feb 7, 2019 at 12:33 PM Stefan Blumentrath <[hidden email]> wrote:

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 <[hidden email]>
Sent: torsdag 7. februar 2019 10:37
To: Stefan Blumentrath <[hidden email]>
Cc: Veronica Andreo <[hidden email]>; grass-user <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
Sent: onsdag 6. februar 2019 21:38
To: Stefan Blumentrath <[hidden email]>
Cc: Margherita Di Leo <[hidden email]>; grass-user <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> On Behalf Of Veronica Andreo
Sent: onsdag 6. februar 2019 17:20
To: Margherita Di Leo <[hidden email]>
Cc: GRASS user list <[hidden email]>
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 (<[hidden email]>) 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



--
Margherita Di Leo


--
Margherita Di Leo


--
Margherita Di Leo

_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user

a104.png (31K) Download Attachment
SBL
Reply | Threaded
Open this post in threaded view
|

Re: sample a strds at specific locations (areas)

SBL

Ciao Margherita,

 

This is strange. The area (I assume it is an area though your image just shows the boundary) should definitely get rasterized and thus analysed in v.strds.stats.

 

Can you post the output of:

v.category input=big_areas2@PERMANENT option=report

and

v.info test -t ?

 

I double-checked, and the possibility to rasterize also centroids is unfortunately not handed down to v.rast.stats (and moduls build ontop of that, like v.strds.stats). This should be done for GRASS version >= 7.6 (e.g. by adding centroids to the default selection of types to rasterize in v.to.rast) and is probably worth a ticket.

 

Cheers

Stefan

 

From: Margherita Di Leo <[hidden email]>
Sent: fredag 9. august 2019 16:51
To: Veronica Andreo <[hidden email]>
Cc: Stefan Blumentrath <[hidden email]>; grass-user <[hidden email]>
Subject: Re: [GRASS-user] sample a strds at specific locations (areas)

 

Hi,

 

excuse me if I return on this. I have again the same problem, of v.strds.stats skipping lots of polygons. Now I'm using a brand new dataset - strds of Sentinel 1 and a brand now vector of polygons - and the skipped polygons are not narrow, I'm sure that there are cells centroids in it. See for example screenshot attached, depicting a polygon that was skipped. I also tried to run v.strds.stats on that polygon alone, like:

 

v.strds.stats in=big_areas2@PERMANENT where="cat == '1'"  strds=db_cross_pol@scaled out=test method=average 

 

v.info test
 +----------------------------------------------------------------------------+
 | Name:            test                                                      |
 | Mapset:          stats                                                     |
 | Location:        S1                                                        |
 | Database:        /media/madi/TOSHIBA EXT/S1/grassdata                      |
 | Title:           Output from v.patch                                       |
 | Map scale:       1:1                                                       |
 | Name of creator: madi                                                      |
 | Organization:                                                              |
 | Source date:     Fri Aug  9 12:12:49 2019                                  |
 | Timestamp (first layer): none                                              |
 |----------------------------------------------------------------------------|
 | Map format:      native                                                    |
 |----------------------------------------------------------------------------|
 |   Type of map: vector (level: 2)                                           |
 |                                                                            |
 |   Number of points:       0               Number of centroids:  0          |
 |   Number of lines:        0               Number of boundaries: 0          |
 |   Number of areas:        0               Number of islands:    0          |
 |                                                                            |
 |   Map is 3D:              No                                               |
 |   Number of dblinks:      0                                                |
 |                                                                            |
 |   Projection: UTM (zone 34)                                                |
 |                                                                            |
 |               N:                 0    S:                 0                 |
 |               E:                 0    W:                 0                 |
 |                                                                            |
 |   Digitization threshold: 0                                                |
 |   Comment:                                                                 |
 |                                                                            |
 +----------------------------------------------------------------------------+

I confess I hadn't look much further into it because I thought it was a problem with nodata, but this is not the case and I think it's  worth of further investigation. Thanks for any pointers.

 

Regards,

 

 

On Thu, Feb 7, 2019 at 4:10 PM Margherita Di Leo <[hidden email]> wrote:

Thanks for testing, Vero. I assume it's due to a local problem then.

 

Cheers,

 

On Thu, Feb 7, 2019 at 3:29 PM Veronica Andreo <[hidden email]> wrote:

Hi Stefan and Madi,

 

Thanks Stefan for the explanations :) Indeed I agree that a flag to avoid the alignment to input rasters (and just use region settings) sounds good.

I tested what Madi said, but cannot reproduce in the climate NC location [0]. This is the command I used:

 

v.strds.stats in=boundary_county where="cat == '261'" strds=tempmean t_where="start_time >= '2012-01-01'" out=test

 

to make it faster (it feels indeed kinda slow for the whole vector and full time series), I selected only one polygon and a range of dates. I get the table as expected while leaving methods by default.

 

best,

Vero

 

 

 

 

 

El jue., 7 feb. 2019 a las 14:39, Margherita Di Leo (<[hidden email]>) escribió:

Thank you Stefan for your help! I figured what happens. v.strds.stats with default method produces in my case a corrupted output, topology is there but there's no table associated to it. If I specify method=average, I do obtain the table, and the mystery is solved: some of the polygons fall into a nodata (due to cloud mask). If anyone else can reproduce the corrupted table issue, I can file a ticket for that.

 

Thanks for help!

Regards,

 

On Thu, Feb 7, 2019 at 12:33 PM Stefan Blumentrath <[hidden email]> wrote:

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 <[hidden email]>
Sent: torsdag 7. februar 2019 10:37
To: Stefan Blumentrath <[hidden email]>
Cc: Veronica Andreo <[hidden email]>; grass-user <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
Sent: onsdag 6. februar 2019 21:38
To: Stefan Blumentrath <[hidden email]>
Cc: Margherita Di Leo <[hidden email]>; grass-user <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> On Behalf Of Veronica Andreo
Sent: onsdag 6. februar 2019 17:20
To: Margherita Di Leo <[hidden email]>
Cc: GRASS user list <[hidden email]>
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 (<[hidden email]>) 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



--

Margherita Di Leo



--

Margherita Di Leo


 

--

Margherita Di Leo


_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: sample a strds at specific locations (areas)

Veronica Andreo
Ciao Madi,

is the region properly set?

@Stefan in this case, if the centroid only is rasterized, then stats will also belong to that pixel only? AFAIU, we don't want that, but stats for the area. Or rasterization of centroid would have a different effect?

best,
Vero

El vie., 9 ago. 2019 a las 21:29, Stefan Blumentrath (<[hidden email]>) escribió:

Ciao Margherita,

 

This is strange. The area (I assume it is an area though your image just shows the boundary) should definitely get rasterized and thus analysed in v.strds.stats.

 

Can you post the output of:

v.category input=big_areas2@PERMANENT option=report

and

v.info test -t ?

 

I double-checked, and the possibility to rasterize also centroids is unfortunately not handed down to v.rast.stats (and moduls build ontop of that, like v.strds.stats). This should be done for GRASS version >= 7.6 (e.g. by adding centroids to the default selection of types to rasterize in v.to.rast) and is probably worth a ticket.

 

Cheers

Stefan

 

From: Margherita Di Leo <[hidden email]>
Sent: fredag 9. august 2019 16:51
To: Veronica Andreo <[hidden email]>
Cc: Stefan Blumentrath <[hidden email]>; grass-user <[hidden email]>
Subject: Re: [GRASS-user] sample a strds at specific locations (areas)

 

Hi,

 

excuse me if I return on this. I have again the same problem, of v.strds.stats skipping lots of polygons. Now I'm using a brand new dataset - strds of Sentinel 1 and a brand now vector of polygons - and the skipped polygons are not narrow, I'm sure that there are cells centroids in it. See for example screenshot attached, depicting a polygon that was skipped. I also tried to run v.strds.stats on that polygon alone, like:

 

v.strds.stats in=big_areas2@PERMANENT where="cat == '1'"  strds=db_cross_pol@scaled out=test method=average 

 

v.info test
 +----------------------------------------------------------------------------+
 | Name:            test                                                      |
 | Mapset:          stats                                                     |
 | Location:        S1                                                        |
 | Database:        /media/madi/TOSHIBA EXT/S1/grassdata                      |
 | Title:           Output from v.patch                                       |
 | Map scale:       1:1                                                       |
 | Name of creator: madi                                                      |
 | Organization:                                                              |
 | Source date:     Fri Aug  9 12:12:49 2019                                  |
 | Timestamp (first layer): none                                              |
 |----------------------------------------------------------------------------|
 | Map format:      native                                                    |
 |----------------------------------------------------------------------------|
 |   Type of map: vector (level: 2)                                           |
 |                                                                            |
 |   Number of points:       0               Number of centroids:  0          |
 |   Number of lines:        0               Number of boundaries: 0          |
 |   Number of areas:        0               Number of islands:    0          |
 |                                                                            |
 |   Map is 3D:              No                                               |
 |   Number of dblinks:      0                                                |
 |                                                                            |
 |   Projection: UTM (zone 34)                                                |
 |                                                                            |
 |               N:                 0    S:                 0                 |
 |               E:                 0    W:                 0                 |
 |                                                                            |
 |   Digitization threshold: 0                                                |
 |   Comment:                                                                 |
 |                                                                            |
 +----------------------------------------------------------------------------+

I confess I hadn't look much further into it because I thought it was a problem with nodata, but this is not the case and I think it's  worth of further investigation. Thanks for any pointers.

 

Regards,

 

 

On Thu, Feb 7, 2019 at 4:10 PM Margherita Di Leo <[hidden email]> wrote:

Thanks for testing, Vero. I assume it's due to a local problem then.

 

Cheers,

 

On Thu, Feb 7, 2019 at 3:29 PM Veronica Andreo <[hidden email]> wrote:

Hi Stefan and Madi,

 

Thanks Stefan for the explanations :) Indeed I agree that a flag to avoid the alignment to input rasters (and just use region settings) sounds good.

I tested what Madi said, but cannot reproduce in the climate NC location [0]. This is the command I used:

 

v.strds.stats in=boundary_county where="cat == '261'" strds=tempmean t_where="start_time >= '2012-01-01'" out=test

 

to make it faster (it feels indeed kinda slow for the whole vector and full time series), I selected only one polygon and a range of dates. I get the table as expected while leaving methods by default.

 

best,

Vero

 

 

 

 

 

El jue., 7 feb. 2019 a las 14:39, Margherita Di Leo (<[hidden email]>) escribió:

Thank you Stefan for your help! I figured what happens. v.strds.stats with default method produces in my case a corrupted output, topology is there but there's no table associated to it. If I specify method=average, I do obtain the table, and the mystery is solved: some of the polygons fall into a nodata (due to cloud mask). If anyone else can reproduce the corrupted table issue, I can file a ticket for that.

 

Thanks for help!

Regards,

 

On Thu, Feb 7, 2019 at 12:33 PM Stefan Blumentrath <[hidden email]> wrote:

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 <[hidden email]>
Sent: torsdag 7. februar 2019 10:37
To: Stefan Blumentrath <[hidden email]>
Cc: Veronica Andreo <[hidden email]>; grass-user <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
Sent: onsdag 6. februar 2019 21:38
To: Stefan Blumentrath <[hidden email]>
Cc: Margherita Di Leo <[hidden email]>; grass-user <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> On Behalf Of Veronica Andreo
Sent: onsdag 6. februar 2019 17:20
To: Margherita Di Leo <[hidden email]>
Cc: GRASS user list <[hidden email]>
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 (<[hidden email]>) 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



--

Margherita Di Leo



--

Margherita Di Leo


 

--

Margherita Di Leo


_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
SBL
Reply | Threaded
Open this post in threaded view
|

Re: sample a strds at specific locations (areas)

SBL

Ciao Vero,

 

Currently, areas, lines and points are rasterized by default.

Centroids would come in addition.

 

That means, small polygons that only cover parts of a pixel would get rasterized never the less. This can of course be useful in some cases but cause issues in others. However, given that GRASS centroids are located inside areas it should be mostly OK.

 

Cheers

Stefan

 

From: Veronica Andreo <[hidden email]>
Sent: mandag 12. august 2019 16:24
To: Stefan Blumentrath <[hidden email]>
Cc: Margherita Di Leo <[hidden email]>; grass-user <[hidden email]>
Subject: Re: [GRASS-user] sample a strds at specific locations (areas)

 

Ciao Madi,

 

is the region properly set?

 

@Stefan in this case, if the centroid only is rasterized, then stats will also belong to that pixel only? AFAIU, we don't want that, but stats for the area. Or rasterization of centroid would have a different effect?

 

best,

Vero

 

El vie., 9 ago. 2019 a las 21:29, Stefan Blumentrath (<[hidden email]>) escribió:

Ciao Margherita,

 

This is strange. The area (I assume it is an area though your image just shows the boundary) should definitely get rasterized and thus analysed in v.strds.stats.

 

Can you post the output of:

v.category input=big_areas2@PERMANENT option=report

and

v.info test -t ?

 

I double-checked, and the possibility to rasterize also centroids is unfortunately not handed down to v.rast.stats (and moduls build ontop of that, like v.strds.stats). This should be done for GRASS version >= 7.6 (e.g. by adding centroids to the default selection of types to rasterize in v.to.rast) and is probably worth a ticket.

 

Cheers

Stefan

 

From: Margherita Di Leo <[hidden email]>
Sent: fredag 9. august 2019 16:51
To: Veronica Andreo <
[hidden email]>
Cc: Stefan Blumentrath <
[hidden email]>; grass-user <[hidden email]>
Subject: Re: [GRASS-user] sample a strds at specific locations (areas)

 

Hi,

 

excuse me if I return on this. I have again the same problem, of v.strds.stats skipping lots of polygons. Now I'm using a brand new dataset - strds of Sentinel 1 and a brand now vector of polygons - and the skipped polygons are not narrow, I'm sure that there are cells centroids in it. See for example screenshot attached, depicting a polygon that was skipped. I also tried to run v.strds.stats on that polygon alone, like:

 

v.strds.stats in=big_areas2@PERMANENT where="cat == '1'"  strds=db_cross_pol@scaled out=test method=average 

 

v.info test
 +----------------------------------------------------------------------------+
 | Name:            test                                                      |
 | Mapset:          stats                                                     |
 | Location:        S1                                                        |
 | Database:        /media/madi/TOSHIBA EXT/S1/grassdata                      |
 | Title:           Output from v.patch                                       |
 | Map scale:       1:1                                                       |
 | Name of creator: madi                                                      |
 | Organization:                                                              |
 | Source date:     Fri Aug  9 12:12:49 2019                                  |
 | Timestamp (first layer): none                                              |
 |----------------------------------------------------------------------------|
 | Map format:      native                                                    |
 |----------------------------------------------------------------------------|
 |   Type of map: vector (level: 2)                                           |
 |                                                                            |
 |   Number of points:       0               Number of centroids:  0          |
 |   Number of lines:        0               Number of boundaries: 0          |
 |   Number of areas:        0               Number of islands:    0          |
 |                                                                            |
 |   Map is 3D:              No                                               |
 |   Number of dblinks:      0                                                |
 |                                                                            |
 |   Projection: UTM (zone 34)                                                |
 |                                                                            |
 |               N:                 0    S:                 0                 |
 |               E:                 0    W:                 0                 |
 |                                                                            |
 |   Digitization threshold: 0                                                |
 |   Comment:                                                                 |
 |                                                                            |
 +----------------------------------------------------------------------------+

I confess I hadn't look much further into it because I thought it was a problem with nodata, but this is not the case and I think it's  worth of further investigation. Thanks for any pointers.

 

Regards,

 

 

On Thu, Feb 7, 2019 at 4:10 PM Margherita Di Leo <[hidden email]> wrote:

Thanks for testing, Vero. I assume it's due to a local problem then.

 

Cheers,

 

On Thu, Feb 7, 2019 at 3:29 PM Veronica Andreo <[hidden email]> wrote:

Hi Stefan and Madi,

 

Thanks Stefan for the explanations :) Indeed I agree that a flag to avoid the alignment to input rasters (and just use region settings) sounds good.

I tested what Madi said, but cannot reproduce in the climate NC location [0]. This is the command I used:

 

v.strds.stats in=boundary_county where="cat == '261'" strds=tempmean t_where="start_time >= '2012-01-01'" out=test

 

to make it faster (it feels indeed kinda slow for the whole vector and full time series), I selected only one polygon and a range of dates. I get the table as expected while leaving methods by default.

 

best,

Vero

 

 

 

 

 

El jue., 7 feb. 2019 a las 14:39, Margherita Di Leo (<[hidden email]>) escribió:

Thank you Stefan for your help! I figured what happens. v.strds.stats with default method produces in my case a corrupted output, topology is there but there's no table associated to it. If I specify method=average, I do obtain the table, and the mystery is solved: some of the polygons fall into a nodata (due to cloud mask). If anyone else can reproduce the corrupted table issue, I can file a ticket for that.

 

Thanks for help!

Regards,

 

On Thu, Feb 7, 2019 at 12:33 PM Stefan Blumentrath <[hidden email]> wrote:

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 <[hidden email]>
Sent: torsdag 7. februar 2019 10:37
To: Stefan Blumentrath <
[hidden email]>
Cc: Veronica Andreo <
[hidden email]>; grass-user <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
Sent: onsdag 6. februar 2019 21:38
To: Stefan Blumentrath <
[hidden email]>
Cc: Margherita Di Leo <
[hidden email]>; grass-user <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> On Behalf Of Veronica Andreo
Sent: onsdag 6. februar 2019 17:20
To: Margherita Di Leo <
[hidden email]>
Cc: GRASS user list <
[hidden email]>
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 (<[hidden email]>) 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



--

Margherita Di Leo



--

Margherita Di Leo


 

--

Margherita Di Leo


_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: sample a strds at specific locations (areas)

margherita
In reply to this post by Veronica Andreo
Ciao Vero,
indeed that was my first guess about the cause, I double checked but the region is properly set.
Sorry for late answer, I'm travelling these days with bad to none internet connection.

Thanks

On Mon, Aug 12, 2019 at 4:23 PM Veronica Andreo <[hidden email]> wrote:
Ciao Madi,

is the region properly set?

@Stefan in this case, if the centroid only is rasterized, then stats will also belong to that pixel only? AFAIU, we don't want that, but stats for the area. Or rasterization of centroid would have a different effect?

best,
Vero

El vie., 9 ago. 2019 a las 21:29, Stefan Blumentrath (<[hidden email]>) escribió:

Ciao Margherita,

 

This is strange. The area (I assume it is an area though your image just shows the boundary) should definitely get rasterized and thus analysed in v.strds.stats.

 

Can you post the output of:

v.category input=big_areas2@PERMANENT option=report

and

v.info test -t ?

 

I double-checked, and the possibility to rasterize also centroids is unfortunately not handed down to v.rast.stats (and moduls build ontop of that, like v.strds.stats). This should be done for GRASS version >= 7.6 (e.g. by adding centroids to the default selection of types to rasterize in v.to.rast) and is probably worth a ticket.

 

Cheers

Stefan

 

From: Margherita Di Leo <[hidden email]>
Sent: fredag 9. august 2019 16:51
To: Veronica Andreo <[hidden email]>
Cc: Stefan Blumentrath <[hidden email]>; grass-user <[hidden email]>
Subject: Re: [GRASS-user] sample a strds at specific locations (areas)

 

Hi,

 

excuse me if I return on this. I have again the same problem, of v.strds.stats skipping lots of polygons. Now I'm using a brand new dataset - strds of Sentinel 1 and a brand now vector of polygons - and the skipped polygons are not narrow, I'm sure that there are cells centroids in it. See for example screenshot attached, depicting a polygon that was skipped. I also tried to run v.strds.stats on that polygon alone, like:

 

v.strds.stats in=big_areas2@PERMANENT where="cat == '1'"  strds=db_cross_pol@scaled out=test method=average 

 

v.info test
 +----------------------------------------------------------------------------+
 | Name:            test                                                      |
 | Mapset:          stats                                                     |
 | Location:        S1                                                        |
 | Database:        /media/madi/TOSHIBA EXT/S1/grassdata                      |
 | Title:           Output from v.patch                                       |
 | Map scale:       1:1                                                       |
 | Name of creator: madi                                                      |
 | Organization:                                                              |
 | Source date:     Fri Aug  9 12:12:49 2019                                  |
 | Timestamp (first layer): none                                              |
 |----------------------------------------------------------------------------|
 | Map format:      native                                                    |
 |----------------------------------------------------------------------------|
 |   Type of map: vector (level: 2)                                           |
 |                                                                            |
 |   Number of points:       0               Number of centroids:  0          |
 |   Number of lines:        0               Number of boundaries: 0          |
 |   Number of areas:        0               Number of islands:    0          |
 |                                                                            |
 |   Map is 3D:              No                                               |
 |   Number of dblinks:      0                                                |
 |                                                                            |
 |   Projection: UTM (zone 34)                                                |
 |                                                                            |
 |               N:                 0    S:                 0                 |
 |               E:                 0    W:                 0                 |
 |                                                                            |
 |   Digitization threshold: 0                                                |
 |   Comment:                                                                 |
 |                                                                            |
 +----------------------------------------------------------------------------+

I confess I hadn't look much further into it because I thought it was a problem with nodata, but this is not the case and I think it's  worth of further investigation. Thanks for any pointers.

 

Regards,

 

 

On Thu, Feb 7, 2019 at 4:10 PM Margherita Di Leo <[hidden email]> wrote:

Thanks for testing, Vero. I assume it's due to a local problem then.

 

Cheers,

 

On Thu, Feb 7, 2019 at 3:29 PM Veronica Andreo <[hidden email]> wrote:

Hi Stefan and Madi,

 

Thanks Stefan for the explanations :) Indeed I agree that a flag to avoid the alignment to input rasters (and just use region settings) sounds good.

I tested what Madi said, but cannot reproduce in the climate NC location [0]. This is the command I used:

 

v.strds.stats in=boundary_county where="cat == '261'" strds=tempmean t_where="start_time >= '2012-01-01'" out=test

 

to make it faster (it feels indeed kinda slow for the whole vector and full time series), I selected only one polygon and a range of dates. I get the table as expected while leaving methods by default.

 

best,

Vero

 

 

 

 

 

El jue., 7 feb. 2019 a las 14:39, Margherita Di Leo (<[hidden email]>) escribió:

Thank you Stefan for your help! I figured what happens. v.strds.stats with default method produces in my case a corrupted output, topology is there but there's no table associated to it. If I specify method=average, I do obtain the table, and the mystery is solved: some of the polygons fall into a nodata (due to cloud mask). If anyone else can reproduce the corrupted table issue, I can file a ticket for that.

 

Thanks for help!

Regards,

 

On Thu, Feb 7, 2019 at 12:33 PM Stefan Blumentrath <[hidden email]> wrote:

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 <[hidden email]>
Sent: torsdag 7. februar 2019 10:37
To: Stefan Blumentrath <[hidden email]>
Cc: Veronica Andreo <[hidden email]>; grass-user <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
Sent: onsdag 6. februar 2019 21:38
To: Stefan Blumentrath <[hidden email]>
Cc: Margherita Di Leo <[hidden email]>; grass-user <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> On Behalf Of Veronica Andreo
Sent: onsdag 6. februar 2019 17:20
To: Margherita Di Leo <[hidden email]>
Cc: GRASS user list <[hidden email]>
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 (<[hidden email]>) 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



--

Margherita Di Leo



--

Margherita Di Leo


 

--

Margherita Di Leo



--
Margherita Di Leo

_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: sample a strds at specific locations (areas)

margherita
In reply to this post by SBL
Ciao Stefan,

v.category input=big_areas2@PERMANENT option=report
Layer/table: 1/big_areas2
type       count        min        max
point          0          0          0
line           0          0          0
boundary       0          0          0
centroid     280          2        265
area           0          0          0
face           0          0          0
kernel         0          0          0
all          280          2        265

v.info test -t
nodes=0
points=0
lines=0
boundaries=0
centroids=0
areas=0
islands=0
primitives=0
map3d=0

thanks

On Fri, Aug 9, 2019 at 9:29 PM Stefan Blumentrath <[hidden email]> wrote:

Ciao Margherita,

 

This is strange. The area (I assume it is an area though your image just shows the boundary) should definitely get rasterized and thus analysed in v.strds.stats.

 

Can you post the output of:

v.category input=big_areas2@PERMANENT option=report

and

v.info test -t ?

 

I double-checked, and the possibility to rasterize also centroids is unfortunately not handed down to v.rast.stats (and moduls build ontop of that, like v.strds.stats). This should be done for GRASS version >= 7.6 (e.g. by adding centroids to the default selection of types to rasterize in v.to.rast) and is probably worth a ticket.

 

Cheers

Stefan

 

From: Margherita Di Leo <[hidden email]>
Sent: fredag 9. august 2019 16:51
To: Veronica Andreo <[hidden email]>
Cc: Stefan Blumentrath <[hidden email]>; grass-user <[hidden email]>
Subject: Re: [GRASS-user] sample a strds at specific locations (areas)

 

Hi,

 

excuse me if I return on this. I have again the same problem, of v.strds.stats skipping lots of polygons. Now I'm using a brand new dataset - strds of Sentinel 1 and a brand now vector of polygons - and the skipped polygons are not narrow, I'm sure that there are cells centroids in it. See for example screenshot attached, depicting a polygon that was skipped. I also tried to run v.strds.stats on that polygon alone, like:

 

v.strds.stats in=big_areas2@PERMANENT where="cat == '1'"  strds=db_cross_pol@scaled out=test method=average 

 

v.info test
 +----------------------------------------------------------------------------+
 | Name:            test                                                      |
 | Mapset:          stats                                                     |
 | Location:        S1                                                        |
 | Database:        /media/madi/TOSHIBA EXT/S1/grassdata                      |
 | Title:           Output from v.patch                                       |
 | Map scale:       1:1                                                       |
 | Name of creator: madi                                                      |
 | Organization:                                                              |
 | Source date:     Fri Aug  9 12:12:49 2019                                  |
 | Timestamp (first layer): none                                              |
 |----------------------------------------------------------------------------|
 | Map format:      native                                                    |
 |----------------------------------------------------------------------------|
 |   Type of map: vector (level: 2)                                           |
 |                                                                            |
 |   Number of points:       0               Number of centroids:  0          |
 |   Number of lines:        0               Number of boundaries: 0          |
 |   Number of areas:        0               Number of islands:    0          |
 |                                                                            |
 |   Map is 3D:              No                                               |
 |   Number of dblinks:      0                                                |
 |                                                                            |
 |   Projection: UTM (zone 34)                                                |
 |                                                                            |
 |               N:                 0    S:                 0                 |
 |               E:                 0    W:                 0                 |
 |                                                                            |
 |   Digitization threshold: 0                                                |
 |   Comment:                                                                 |
 |                                                                            |
 +----------------------------------------------------------------------------+

I confess I hadn't look much further into it because I thought it was a problem with nodata, but this is not the case and I think it's  worth of further investigation. Thanks for any pointers.

 

Regards,

 

 

On Thu, Feb 7, 2019 at 4:10 PM Margherita Di Leo <[hidden email]> wrote:

Thanks for testing, Vero. I assume it's due to a local problem then.

 

Cheers,

 

On Thu, Feb 7, 2019 at 3:29 PM Veronica Andreo <[hidden email]> wrote:

Hi Stefan and Madi,

 

Thanks Stefan for the explanations :) Indeed I agree that a flag to avoid the alignment to input rasters (and just use region settings) sounds good.

I tested what Madi said, but cannot reproduce in the climate NC location [0]. This is the command I used:

 

v.strds.stats in=boundary_county where="cat == '261'" strds=tempmean t_where="start_time >= '2012-01-01'" out=test

 

to make it faster (it feels indeed kinda slow for the whole vector and full time series), I selected only one polygon and a range of dates. I get the table as expected while leaving methods by default.

 

best,

Vero

 

 

 

 

 

El jue., 7 feb. 2019 a las 14:39, Margherita Di Leo (<[hidden email]>) escribió:

Thank you Stefan for your help! I figured what happens. v.strds.stats with default method produces in my case a corrupted output, topology is there but there's no table associated to it. If I specify method=average, I do obtain the table, and the mystery is solved: some of the polygons fall into a nodata (due to cloud mask). If anyone else can reproduce the corrupted table issue, I can file a ticket for that.

 

Thanks for help!

Regards,

 

On Thu, Feb 7, 2019 at 12:33 PM Stefan Blumentrath <[hidden email]> wrote:

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 <[hidden email]>
Sent: torsdag 7. februar 2019 10:37
To: Stefan Blumentrath <[hidden email]>
Cc: Veronica Andreo <[hidden email]>; grass-user <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
Sent: onsdag 6. februar 2019 21:38
To: Stefan Blumentrath <[hidden email]>
Cc: Margherita Di Leo <[hidden email]>; grass-user <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> On Behalf Of Veronica Andreo
Sent: onsdag 6. februar 2019 17:20
To: Margherita Di Leo <[hidden email]>
Cc: GRASS user list <[hidden email]>
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 (<[hidden email]>) 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



--

Margherita Di Leo



--

Margherita Di Leo


 

--

Margherita Di Leo



--
Margherita Di Leo

_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
Reply | Threaded
Open this post in threaded view
|

Re: sample a strds at specific locations (areas)

margherita
In reply to this post by margherita
Hi,

I have an update on this. It seems to work if the vector file resides in the same mapset! I g.copied big_areas2@PERMANENT to current mapset and the excluded polygons are much less. It surely needs further investigation...

Kind regards,

On Fri, Aug 9, 2019 at 4:50 PM Margherita Di Leo <[hidden email]> wrote:
Hi,

excuse me if I return on this. I have again the same problem, of v.strds.stats skipping lots of polygons. Now I'm using a brand new dataset - strds of Sentinel 1 and a brand now vector of polygons - and the skipped polygons are not narrow, I'm sure that there are cells centroids in it. See for example screenshot attached, depicting a polygon that was skipped. I also tried to run v.strds.stats on that polygon alone, like:

v.strds.stats in=big_areas2@PERMANENT where="cat == '1'"  strds=db_cross_pol@scaled out=test method=average 

v.info test
 +----------------------------------------------------------------------------+
 | Name:            test                                                      |
 | Mapset:          stats                                                     |
 | Location:        S1                                                        |
 | Database:        /media/madi/TOSHIBA EXT/S1/grassdata                      |
 | Title:           Output from v.patch                                       |
 | Map scale:       1:1                                                       |
 | Name of creator: madi                                                      |
 | Organization:                                                              |
 | Source date:     Fri Aug  9 12:12:49 2019                                  |
 | Timestamp (first layer): none                                              |
 |----------------------------------------------------------------------------|
 | Map format:      native                                                    |
 |----------------------------------------------------------------------------|
 |   Type of map: vector (level: 2)                                           |
 |                                                                            |
 |   Number of points:       0               Number of centroids:  0          |
 |   Number of lines:        0               Number of boundaries: 0          |
 |   Number of areas:        0               Number of islands:    0          |
 |                                                                            |
 |   Map is 3D:              No                                               |
 |   Number of dblinks:      0                                                |
 |                                                                            |
 |   Projection: UTM (zone 34)                                                |
 |                                                                            |
 |               N:                 0    S:                 0                 |
 |               E:                 0    W:                 0                 |
 |                                                                            |
 |   Digitization threshold: 0                                                |
 |   Comment:                                                                 |
 |                                                                            |
 +----------------------------------------------------------------------------+

I confess I hadn't look much further into it because I thought it was a problem with nodata, but this is not the case and I think it's  worth of further investigation. Thanks for any pointers.

Regards,


On Thu, Feb 7, 2019 at 4:10 PM Margherita Di Leo <[hidden email]> wrote:
Thanks for testing, Vero. I assume it's due to a local problem then.

Cheers,

On Thu, Feb 7, 2019 at 3:29 PM Veronica Andreo <[hidden email]> wrote:
Hi Stefan and Madi,

Thanks Stefan for the explanations :) Indeed I agree that a flag to avoid the alignment to input rasters (and just use region settings) sounds good.
I tested what Madi said, but cannot reproduce in the climate NC location [0]. This is the command I used:

v.strds.stats in=boundary_county where="cat == '261'" strds=tempmean t_where="start_time >= '2012-01-01'" out=test

to make it faster (it feels indeed kinda slow for the whole vector and full time series), I selected only one polygon and a range of dates. I get the table as expected while leaving methods by default.

best,
Vero





El jue., 7 feb. 2019 a las 14:39, Margherita Di Leo (<[hidden email]>) escribió:
Thank you Stefan for your help! I figured what happens. v.strds.stats with default method produces in my case a corrupted output, topology is there but there's no table associated to it. If I specify method=average, I do obtain the table, and the mystery is solved: some of the polygons fall into a nodata (due to cloud mask). If anyone else can reproduce the corrupted table issue, I can file a ticket for that.

Thanks for help!
Regards,

On Thu, Feb 7, 2019 at 12:33 PM Stefan Blumentrath <[hidden email]> wrote:

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 <[hidden email]>
Sent: torsdag 7. februar 2019 10:37
To: Stefan Blumentrath <[hidden email]>
Cc: Veronica Andreo <[hidden email]>; grass-user <[hidden email]>
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 <[hidden email]> 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 <[hidden email]>
Sent: onsdag 6. februar 2019 21:38
To: Stefan Blumentrath <[hidden email]>
Cc: Margherita Di Leo <[hidden email]>; grass-user <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> On Behalf Of Veronica Andreo
Sent: onsdag 6. februar 2019 17:20
To: Margherita Di Leo <[hidden email]>
Cc: GRASS user list <[hidden email]>
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 (<[hidden email]>) 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



--
Margherita Di Leo


--
Margherita Di Leo


--
Margherita Di Leo


--
Margherita Di Leo

_______________________________________________
grass-user mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/grass-user
12