[GRASS-user] Query: number of 'areas' reported in v.build output does not necessarily represent different geographical areas

[Markus Metz]

On Thu, May 9, 2013 at 3:06 PM, Nikos Alexandris
<nik at nikosalexandris.net> wrote:
> Vincent Bainwrote:
>
>> >> > Thank you Markus, good news !
>> >> > how long has it been implemented ?
>
> Markus Metz wrote:
>
>> >> The option to snap boundary vertices has been there ever since. The
>> >> suggestion of a reasonable (assuming floating point rounding errors)
>> >> threshold for snapping has been added 3 weeks ago, on April 19th.
>
>> >> BTW, if the input polygons are supposed to not overlap each other, the
>> >> number of centroids should be identical to the number of input
>> >> polygons (needs to be added to the manual).
>
> Nikos Alexandris:
>
>> > I tried to import USGS' (2011) Global Mangroves map:
>> >
>> > # stuff copied from the map's *latest* history
>> > v.in.ogr dsn="/geo/geodata/mangroves/usgs_mangroves/usgs_mangroves2.shp"
>> > output="global_mangroves_usgs_2011" min_area=0.0001 snap=0.000000000000001
>> >
>> > 2018421 input polygons
>> > Total area: 1.47005E+11 (2750605 areas)
>> > Overlapping area: 5.32085E+09 (41540 areas)
>> > Area without category: 9.25489E+09 (773734 areas)
>
>> > Twice the "error" message was like (even after I, by mistake, imported
>> > with snap=1e-15):
>
>> > Ended with an "error while impoting, try to import with snap 1e-14"
>> > This means that there are still errors in the map, right?
>
> Markus Metz wrote:
>
>> I assume the global mangroves map should not have overlapping
>> polygons, therefore as long as there are overlapping areas and/or the
>> number of centroids is not equal to the number of input polygons, more
>> cleaning is needed.
>
> Unfortunately it seems there are overlapping polygons.

Obviously so, and fairly large overlapping areas according to your
output even for snap=1e-6:

Overlapping area: 5.32085E+09 (41538 areas)

Therefore there are probably logical errors in the input data, for
example the same mangrove polygon might be present more than once.
This can not be cleaned automatically with v.in.ogr or v.clean. You
can investigate overlapping areas in the imported vector with d.vect
type=area layer=2 (only overlapping areas have a category in layer 2).

Markus M