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

[Markus Metz]

On Wed, May 8, 2013 at 9:49 PM, Nikos Alexandris
<nik at nikosalexandris.net> wrote:
> Hi!
>
> ..
>
> 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).
>
> 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?

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.

Markus M