Hi Markus, Thanks for the explanation. It is possible to import topologically incorrect vectors, but not create them within GRASS. So, as a solution to my problem, I rather create (potentially overlapping) buffers outside GRASS and import them with -c in v.in.ogr to use v.rast.stats with no loss of areas, or follow the procedure that you described earlier in the thread.
Cheers, Vero El mié., 22 may. 2019 a las 18:48, Markus Metz (< [email protected]>) escribió: > > > On Wed, May 22, 2019 at 3:11 PM Veronica Andreo <[email protected]> > wrote: > > > > Dear all, > > > > thanks again for your answers. I found an easier way, use -c flag in > v.in.ogr seems to not build topology of overlapping areas and then > v.rast.stats does not complain. > > > > However, if one builds buffer areas for points within GRASS, i.e., using > v.buffer, the problem appears again when buffer areas overlap, which it's > pretty common when creating buffers around neighbouring points. Then, to > get zonal stats for those areas the approach suggested by Markus Metz > should be followed. I believe it is a bit of an overkill for such a common > task in GIS. Couldn't v.buffer have a -c flag as v.in.ogr so when > overlapping of buffer areas is fine the topology is not built and one would > get just one area per input point? Would that be possible? > > In short, no. > > The reason is that with a topological vector model, areas are constructed > from boundaries and centroids. If you use the -c flag of v.in.ogr and there > are polygons that overlap to a large degree or completely, it is not > possible to find a centroid for each topological area, i.e. the overlapping > input polygons can not be properly represented with a topological model > when using the -c flag. As soon as you get incorrect boundaries and/or > duplicate centroids when building topology, results are wrong. > > Markus M > > > > > cheers, > > Vero > > > > > > > > El jue., 16 may. 2019 a las 11:27, Moritz Lennert (< > [email protected]>) escribió: > >> > >> On 16/05/19 03:11, Veronica Andreo wrote: > >> > Dear all, > >> > > >> > thanks for the answers... > >> > > >> > @Madi, I know, but that's how I got the data from a colleague using > >> > SaTScan to get cluster sizes. > >> > > >> > So, these "clusters" are 3, they are represented by circular areas > and 2 > >> > of them overlap, and it is just fine that they overlap. I just want > one > >> > centroid per area to be able to get one value per original area. > >> > > >> > I tested your solution, @Micha (thanks much for your time!), but it > >> > gives me 4 values, and I need 3. Moreover, I can no longer recognize > >> > which polygon is which since v.db.select for layer 3 reports cats > from 1 > >> > to 4, but d.vect shows something different (I'd assume 2/3 has become > >> > 4?). See screenshot below. > >> > >> To see the cat values of layer 3 you have to indicate that layer in the > >> label_layer parameter (Labels tab). > >> > >> You can also see the correspondance between the two layers with > >> > >> v.category polys_3layers op=print layer=1,3 > >> > >> > > >> > So, is it possible somehow to keep my 3 original polygons? And how > can I > >> > get raster values for my original 3 polygons in GRASS? Or is it that > >> > this is not allowed by topology? > >> > >> This depends on how you want to get raster values. If v.what.rast at the > >> location of the centroid is all you need than Micha's solution should > work. > >> > >> If you need v.rast.stats then you either have to use Markus' suggestion, > >> or you use Micha's approach running v.rast.stats on layer three and then > >> use some magic to transform the output of the above v.category call to a > >> correspondance table between layer. Something like this > >> > >> import grass.script as g > >> for feature in g.read_command('v.category', > >> input_='polys_3layers', > >> op='print', > >> layer=[3,1]).splitlines(): > >> cat1 = feature.split('|')[0] > >> cats2 = feature.split('|')[1].split('/') > >> for cat2 in cats2: > >> print cat1, cat2 > >> > >> This correspondance table could then be used to aggregate the raster > >> stats per (original) polygon in SQL. This could be the easily put into > >> an addon module. > >> > >> Moritz > >> > > _______________________________________________ > > grass-user mailing list > > [email protected] > > https://lists.osgeo.org/mailman/listinfo/grass-user >
_______________________________________________ grass-user mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/grass-user
