Please ignore my last email, this is not the case, I had vectors with similar names in the current mapset. Sorry for confusion. Still struggling on this.
On Wed, Sep 4, 2019 at 12:01 PM Margherita Di Leo <direg...@gmail.com> wrote: > 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 <direg...@gmail.com> > 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 <direg...@gmail.com> >> 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 <veroand...@gmail.com> >>> 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 >>>> >>>> [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 >>>>> >>>> >>> >>> -- >>> Margherita Di Leo >>> >> >> >> -- >> Margherita Di Leo >> > > > -- > Margherita Di Leo > -- Margherita Di Leo
_______________________________________________ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user