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

Wed May 22 16:06:22 PDT 2019

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 <mlennert at club.worldonline.be>
escribió:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20190522/6f32132a/attachment-0001.html>