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 [0] http://courses.ncsu.edu/mea592/common/media/02/nc_climate_spm_2000_2012.zip El jue., 7 feb. 2019 a las 14:39, Margherita Di Leo (<direg...@gmail.com>) 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 < > stefan.blumentr...@nina.no> 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 <direg...@gmail.com> >> *Sent:* torsdag 7. februar 2019 10:37 >> *To:* Stefan Blumentrath <stefan.blumentr...@nina.no> >> *Cc:* Veronica Andreo <veroand...@gmail.com>; grass-user < >> grass-user@lists.osgeo.org> >> *Subject:* Re: [GRASS-user] sample a strds at specific locations (areas) >> >> >> >> Hi, >> >> >> >> thank you for your replies. To give a little more context: I selected my >> polygon areas to be > 0.5 ha each (this would be 50000 mq if I'm not >> mistaken) and I'm sampling NDVI maps at 10m resolution (the region being >> the same as NDVI maps). So I think I need an idea on how to debug the areas >> that were excluded to check them individually to see what could be the >> problem... >> >> Regarding the alignment problem, if I understand it correctly: if the >> polygon doesn't include the *center* of the raster beneath it, can't >> retrieve the value and the polygon is discarded? But a value exists, so it >> would be correct that it returned a value in any case. But I admit I don't >> have a full grasp of the problem. >> >> >> >> On Wed, Feb 6, 2019 at 10:52 PM Stefan Blumentrath < >> stefan.blumentr...@nina.no> wrote: >> >> Hi Vero, >> >> >> >> I think there is a little misunderstanding. >> >> v.rast.stats did not change it behaviour with regards to the >> computational region (at least not if only one raster map is used). The >> alignment to the input raster (resolution) has been around since the module >> got ported to Python (like 10 years ago): >> >> >> https://trac.osgeo.org/grass/browser/grass/trunk/scripts/v.rast.stats/v.rast.stats.py?rev=33522#L148 >> >> >> >> So, adding a flag for skipping the alignment was more an idea for an >> enhancement that allows the behaviour you seem to prefer (too). >> >> >> >> Cheers >> >> Stefan >> >> >> >> *From:* Veronica Andreo <veroand...@gmail.com> >> *Sent:* onsdag 6. februar 2019 21:38 >> *To:* Stefan Blumentrath <stefan.blumentr...@nina.no> >> *Cc:* Margherita Di Leo <direg...@gmail.com>; grass-user < >> grass-user@lists.osgeo.org> >> *Subject:* Re: [GRASS-user] sample a strds at specific locations (areas) >> >> >> >> I had a similar problem some time ago, just that it was not raster >> resolution, but region resolution that I changed to solve my problem (see >> this thread and MM's answer: >> http://osgeo-org.1560.x6.nabble.com/v-to-rast-for-polygons-not-overlapping-center-of-raster-cell-td5355686.html#a5355729 >> ) >> >> >> >> IIUC, MM's proposed solution to my case then does not work anymore >> because v.to.rast call inside v.rast.stats is affected by the region >> alignment to the raster to be queried. So, the solution is indeed now, to >> change raster resolution... ? Then the region would be aligned to it (them)? >> >> >> >> If one has large areas or long time series and has to resample all >> rasters to get smallish polygons rasterized, I do not see the advantage of >> this new behavior... but maybe I'm missing something >> >> >> >> Cheers, >> >> Vero >> >> >> >> El mié., 6 feb. 2019 16:54, Stefan Blumentrath < >> stefan.blumentr...@nina.no> escribió: >> >> Ciao Madi, Vero, >> >> >> >> Starting with GRASS 7.6, also centroids are used to get the raster >> representation of your area vector map. That increases the likelihood of >> smaller areas to be rasterized. >> >> Increasing the resolution of the current region alone does not help, >> because v.rast.stats temporarily changes the computational region to align >> with the input raster map(s) (see also: >> https://trac.osgeo.org/grass/ticket/3523 and >> https://trac.osgeo.org/grass/ticket/3598 for discussion) Even if the >> first ticket is closed, comments are welcome. >> >> It might make sense to add a flag to v.rast.stats like in r.slope.aspect >> to not align the computational region. >> >> >> >> Furthermore, with regards to efficiency, v.strds.stats could gain some >> speed if multi-raster support in v.rast.stats - added in G 7.6 - would be >> handed down to the addon. Might almost double the speed for larger STRDS… >> >> >> >> Cheers >> >> Stefan >> >> >> >> *From:* grass-user <grass-user-boun...@lists.osgeo.org> *On Behalf Of >> *Veronica >> Andreo >> *Sent:* onsdag 6. februar 2019 17:20 >> *To:* Margherita Di Leo <direg...@gmail.com> >> *Cc:* GRASS user list <grass-user@lists.osgeo.org> >> *Subject:* Re: [GRASS-user] sample a strds at specific locations (areas) >> >> >> >> Hi Madi >> >> >> >> El mié., 6 feb. 2019 a las 16:31, Margherita Di Leo (<direg...@gmail.com>) >> escribió: >> >> I have a question regarding v.strds.stats. I get the following warning >> message: >> >> >> >> WARNING: Not all vector categories converted to raster. Converted 120 of >> 265. >> >> >> >> What could be the reason for that? >> >> >> >> Some vector areas might not be converted because they are too small with >> respect to the pixel size that you try to query. Others will tell better >> but I think the polygon must overlap the center of the pixel in order to be >> converted into raster. One solution could be to resample your rasters to a >> higher resolution. >> >> HTH, >> >> Vero >> >> >> >> -- >> >> Margherita Di Leo >> > > > -- > Margherita Di Leo >
_______________________________________________ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user