[GRASS-user] importing and cleaning overlapping polygons that are supposed to overlap

Wed May 22 15:15:16 PDT 2019

Le Wed, 22 May 2019 19:25:19 +0200,
Veronica Andreo <veroandreo at gmail.com> 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 (<
> markus.metz.giswork at gmail.com>) escribió:  
> 
> >
> >
> > On Wed, May 22, 2019 at 3:11 PM Veronica Andreo
> > <veroandreo at gmail.com> 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 (<
> > mlennert at club.worldonline.be>) 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
> > > grass-user at lists.osgeo.org
> > > 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 