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
