<div dir="auto">Hi Moritz<div dir="auto"><br></div><div dir="auto">Thanks for the heads-up! Yes, for overlapping buffers v.rast.bufferstats seems just perfect! IIUC, it does exactly what MM was explaining. Great!</div><div dir="auto"><br></div><div dir="auto">Thanks again! And thanks Stefan for the add-on!</div><div dir="auto"><br></div><div dir="auto">Vero</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mié., 22 may. 2019 19:30, Moritz Lennert <<a href="mailto:mlennert@club.worldonline.be">mlennert@club.worldonline.be</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Le Wed, 22 May 2019 19:25:19 +0200,<br>
Veronica Andreo <<a href="mailto:veroandreo@gmail.com" target="_blank" rel="noreferrer">veroandreo@gmail.com</a>> a écrit :<br>
<br>
> Hi Markus,<br>
> <br>
> Thanks for the explanation. It is possible to import topologically<br>
> incorrect vectors, but not create them within GRASS. So, as a<br>
> solution to my problem, I rather create (potentially overlapping)<br>
> buffers outside GRASS and import them with -c in v.in.ogr to use<br>
> v.rast.stats with no loss of areas, or follow the procedure that you<br>
> described earlier in the thread.<br>
<br>
You can also have a look at the v.rast.bufferstats addon.<br>
<br>
Moritz<br>
<br>
> <br>
> Cheers,<br>
> Vero<br>
> <br>
> El mié., 22 may. 2019 a las 18:48, Markus Metz (<<br>
> <a href="mailto:markus.metz.giswork@gmail.com" target="_blank" rel="noreferrer">markus.metz.giswork@gmail.com</a>>) escribió: <br>
> <br>
> ><br>
> ><br>
> > On Wed, May 22, 2019 at 3:11 PM Veronica Andreo<br>
> > <<a href="mailto:veroandreo@gmail.com" target="_blank" rel="noreferrer">veroandreo@gmail.com</a>> wrote: <br>
> > ><br>
> > > Dear all,<br>
> > ><br>
> > > thanks again for your answers. I found an easier way, use -c flag<br>
> > > in <br>
> > v.in.ogr seems to not build topology of overlapping areas and then<br>
> > v.rast.stats does not complain. <br>
> > ><br>
> > > However, if one builds buffer areas for points within GRASS,<br>
> > > i.e., using <br>
> > v.buffer, the problem appears again when buffer areas overlap,<br>
> > which it's pretty common when creating buffers around neighbouring<br>
> > points. Then, to get zonal stats for those areas the approach<br>
> > suggested by Markus Metz should be followed. I believe it is a bit<br>
> > of an overkill for such a common task in GIS. Couldn't v.buffer<br>
> > have a -c flag as v.in.ogr so when overlapping of buffer areas is<br>
> > fine the topology is not built and one would get just one area per<br>
> > input point? Would that be possible?<br>
> ><br>
> > In short, no.<br>
> ><br>
> > The reason is that with a topological vector model, areas are<br>
> > constructed from boundaries and centroids. If you use the -c flag<br>
> > of v.in.ogr and there are polygons that overlap to a large degree<br>
> > or completely, it is not possible to find a centroid for each<br>
> > topological area, i.e. the overlapping input polygons can not be<br>
> > properly represented with a topological model when using the -c<br>
> > flag. As soon as you get incorrect boundaries and/or duplicate<br>
> > centroids when building topology, results are wrong.<br>
> ><br>
> > Markus M<br>
> > <br>
> > ><br>
> > > cheers,<br>
> > > Vero<br>
> > ><br>
> > ><br>
> > ><br>
> > > El jue., 16 may. 2019 a las 11:27, Moritz Lennert (<<br>
> > <a href="mailto:mlennert@club.worldonline.be" target="_blank" rel="noreferrer">mlennert@club.worldonline.be</a>>) escribió: <br>
> > >><br>
> > >> On 16/05/19 03:11, Veronica Andreo wrote: <br>
> > >> > Dear all,<br>
> > >> ><br>
> > >> > thanks for the answers...<br>
> > >> ><br>
> > >> > @Madi, I know, but that's how I got the data from a colleague<br>
> > >> > using SaTScan to get cluster sizes.<br>
> > >> ><br>
> > >> > So, these "clusters" are 3, they are represented by circular<br>
> > >> > areas <br>
> > and 2 <br>
> > >> > of them overlap, and it is just fine that they overlap. I just<br>
> > >> > want <br>
> > one <br>
> > >> > centroid per area to be able to get one value per original<br>
> > >> > area.<br>
> > >> ><br>
> > >> > I tested your solution, @Micha (thanks much for your time!),<br>
> > >> > but it gives me 4 values, and I need 3. Moreover, I can no<br>
> > >> > longer recognize which polygon is which since v.db.select for<br>
> > >> > layer 3 reports cats <br>
> > from 1 <br>
> > >> > to 4, but d.vect shows something different (I'd assume 2/3 has<br>
> > >> > become 4?). See screenshot below. <br>
> > >><br>
> > >> To see the cat values of layer 3 you have to indicate that layer<br>
> > >> in the label_layer parameter (Labels tab).<br>
> > >><br>
> > >> You can also see the correspondance between the two layers with<br>
> > >><br>
> > >> v.category polys_3layers op=print layer=1,3<br>
> > >> <br>
> > >> ><br>
> > >> > So, is it possible somehow to keep my 3 original polygons? And<br>
> > >> > how <br>
> > can I <br>
> > >> > get raster values for my original 3 polygons in GRASS? Or is<br>
> > >> > it that this is not allowed by topology? <br>
> > >><br>
> > >> This depends on how you want to get raster values. If<br>
> > >> v.what.rast at the location of the centroid is all you need than<br>
> > >> Micha's solution should <br>
> > work. <br>
> > >><br>
> > >> If you need v.rast.stats then you either have to use Markus'<br>
> > >> suggestion, or you use Micha's approach running v.rast.stats on<br>
> > >> layer three and then use some magic to transform the output of<br>
> > >> the above v.category call to a correspondance table between<br>
> > >> layer. Something like this<br>
> > >><br>
> > >> import grass.script as g<br>
> > >> for feature in g.read_command('v.category',<br>
> > >> input_='polys_3layers',<br>
> > >> op='print',<br>
> > >> layer=[3,1]).splitlines():<br>
> > >> cat1 = feature.split('|')[0]<br>
> > >> cats2 = feature.split('|')[1].split('/')<br>
> > >> for cat2 in cats2:<br>
> > >> print cat1, cat2<br>
> > >><br>
> > >> This correspondance table could then be used to aggregate the<br>
> > >> raster stats per (original) polygon in SQL. This could be the<br>
> > >> easily put into an addon module.<br>
> > >><br>
> > >> Moritz<br>
> > >> <br>
> > > _______________________________________________<br>
> > > grass-user mailing list<br>
> > > <a href="mailto:grass-user@lists.osgeo.org" target="_blank" rel="noreferrer">grass-user@lists.osgeo.org</a><br>
> > > <a href="https://lists.osgeo.org/mailman/listinfo/grass-user" rel="noreferrer noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/grass-user</a> <br>
> > <br>
<br>
<br>
<br>
-- <br>
Département Géosciences, Environnement et Société Université Libre de<br>
Bruxelles Bureau: S.DB.6.138<br>
CP 130/03<br>
Av. F.D. Roosevelt 50<br>
1050 Bruxelles<br>
Belgique<br>
<br>
tél. + 32 2 650.68.12 / 68.11 (secr.)<br>
fax + 32 2 650.68.30 <br>
</blockquote></div>