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

[Markus Metz]

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