Hi Moritz Thanks for the heads-up! Yes, for overlapping buffers v.rast.bufferstats seems just perfect! IIUC, it does exactly what MM was explaining. Great!
Thanks again! And thanks Stefan for the add-on! Vero El mié., 22 may. 2019 19:30, Moritz Lennert <[email protected]> escribió: > Le Wed, 22 May 2019 19:25:19 +0200, > Veronica Andreo <[email protected]> a écrit : > > > 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. > > You can also have a look at the v.rast.bufferstats addon. > > Moritz > > > > > 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 > > > > > > > -- > Département Géosciences, Environnement et Société Université Libre de > Bruxelles Bureau: S.DB.6.138 > CP 130/03 > Av. F.D. Roosevelt 50 > 1050 Bruxelles > Belgique > > tél. + 32 2 650.68.12 / 68.11 (secr.) > fax + 32 2 650.68.30 >
_______________________________________________ grass-user mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/grass-user
