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

RichTC · May 8, 2013, 8:33am

Hi,

Would my understanding be correct in that a given 'geographical area'
displayed in the Map Display could be counted as multiple 'areas' in the
v.build console output due to multiple centroids being associated with the
given area.

For instance, I imported a vector shapefile with the following topology:

Number of nodes: 1001
Number of primitives: 1322
Number of points: 0
Number of lines: 0
Number of boundaries: 1088
Number of centroids: 234
Number of areas: 323
Number of isles: 2
Number of duplicate centroids: 13
Number of areas without centroid: 102

With closer inspection of the displayed file, there are clearly 10
delineated areas, certainly not 323. The majority of centroids seem to sit
on boundary lines.

It appears that each 'area' counted in the v.build output represents a
single centroid AND a closed ring of boundaries* where an actual
geographical area can be counted multiple times due to multiple centroids
sitting on its boundaries. In other words, the number of 'areas' in v.build
output does not necessarily represent different geographical areas?

Thanks for your feedback.

Richard

*According to the GRASS vector introduction, an area is described as 'the
topological composition of a closed ring of boundaries and optionally a
centroid'.
http://grass.osgeo.org/grass64/manuals/vectorintro.html

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Query-number-of-areas-reported-in-v-build-output-does-not-necessarily-represent-different-geographics-tp5052007.html
Sent from the Grass - Users mailing list archive at Nabble.com.

Hamish · May 8, 2013, 9:22am

Richard wrote:

With closer inspection of the displayed file, there are
clearly 10 delineated areas, certainly not 323. The majority
of centroids seem to sit on boundary lines.

it is probably tiny sliver areas along doubled boundaries which
need cleaning up.

typically grass maintains just one boundary between two adjoining
areas, while some other GIS maintain two full area polygons with
a doubling up where they touch. for various reasons those two
overlapping boundaries may deviate slightly during processing,
and the result is fractional overlap which shows itself when
GRASS builds the topology.

the help page for v.overlay talks about it, and has some
screenshot examples of what you're describing.
see also http://trac.osgeo.org/qgis/ticket/3126

no doubt others here will have the magic v.clean or otherwise
recipe to clean it up.

Hamish

Vincent_Bain · May 8, 2013, 9:42am

Le mercredi 08 mai 2013 à 02:22 -0700, Hamish a écrit :

Richard wrote:no doubt others here will have the magic v.clean or otherwise
recipe to clean it up.

Yes,

I frequently have to work with damaged shapefiles (since my customers
moved from arcinfo workstation to arcgis, they provide me damaged data
layers, can't explain why). The main problem is the one Hamish describes
above.

You can tweak your imported file with various v.clean operations.
Attached is a little script I use to import problematic shapefiles. Fien
tuning the threshold value to your data can give good results. It's a
quick&durty script for my internal use, but the code may help you.

Yours,

Vincent.

(attachments)

v.in.shp (3.21 KB)

RichTC · May 8, 2013, 9:56am

Thanks for your fast replies. I'll certainly take a look at the script.

Snapping with v.clean seems to work quite nicely on this occasion:

    snap lines/boundaries 0.000001
    break lines/boundaries 0.00
    remove duplicates 0.00
    remove small angles at nodes 0.00
    break lines/boundaries 0.00
    break polygons 0.00
    remove duplicates 0.00
    remove lines/boundaries of zero length 0.00
    remove duplicate area centroids 0.00

Output:
Number of nodes: 774
Number of primitives: 786
Number of points: 0
Number of lines: 0
Number of boundaries: 776
Number of centroids: 10
Number of areas: 14
Number of isles: 2
Number of areas without centroid: 4

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Query-number-of-areas-reported-in-v-build-output-does-not-necessarily-represent-different-geographics-tp5052007p5052033.html
Sent from the Grass - Users mailing list archive at Nabble.com.

Markus_Metz · May 8, 2013, 2:27pm

On Wed, May 8, 2013 at 11:56 AM, RichardC <richtcooper@hotmail.com> wrote:

Thanks for your fast replies. I'll certainly take a look at the script.

Snapping with v.clean seems to work quite nicely on this occasion:

Easier (and maybe safer) would be to snap already during import with
v.in.ogr snap=

BTW, in the latest versions of GRASS, v.in.ogr suggest a snapping
threshold if errors are encountered.

Markus M

                snap lines/boundaries 0.000001
                break lines/boundaries 0.00
                remove duplicates 0.00
                remove small angles at nodes 0.00
                break lines/boundaries 0.00
                break polygons 0.00
                remove duplicates 0.00
                remove lines/boundaries of zero length 0.00
                remove duplicate area centroids 0.00

Output:
Number of nodes: 774
Number of primitives: 786
Number of points: 0
Number of lines: 0
Number of boundaries: 776
Number of centroids: 10
Number of areas: 14
Number of isles: 2
Number of areas without centroid: 4

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Query-number-of-areas-reported-in-v-build-output-does-not-necessarily-represent-different-geographics-tp5052007p5052033.html
Sent from the Grass - Users mailing list archive at Nabble.com.
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Vincent_Bain · May 8, 2013, 3:17pm

Thank you Markus,
good news !
how long has it been implemented ?

Vincent

Le mercredi 08 mai 2013 à 16:27 +0200, Markus Metz a écrit :

On Wed, May 8, 2013 at 11:56 AM, RichardC <richtcooper@hotmail.com> wrote:
> Thanks for your fast replies. I'll certainly take a look at the script.
>
> Snapping with v.clean seems to work quite nicely on this occasion:

Easier (and maybe safer) would be to snap already during import with
v.in.ogr snap=

BTW, in the latest versions of GRASS, v.in.ogr suggest a snapping
threshold if errors are encountered.

Markus M

>
> snap lines/boundaries 0.000001
> break lines/boundaries 0.00
> remove duplicates 0.00
> remove small angles at nodes 0.00
> break lines/boundaries 0.00
> break polygons 0.00
> remove duplicates 0.00
> remove lines/boundaries of zero length 0.00
> remove duplicate area centroids 0.00
>
> Output:
> Number of nodes: 774
> Number of primitives: 786
> Number of points: 0
> Number of lines: 0
> Number of boundaries: 776
> Number of centroids: 10
> Number of areas: 14
> Number of isles: 2
> Number of areas without centroid: 4
>
>
>
>
>
> --
> View this message in context: http://osgeo-org.1560.x6.nabble.com/Query-number-of-areas-reported-in-v-build-output-does-not-necessarily-represent-different-geographics-tp5052007p5052033.html
> Sent from the Grass - Users mailing list archive at Nabble.com.
> _______________________________________________
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

Markus_Metz · May 8, 2013, 7:08pm

On Wed, May 8, 2013 at 5:17 PM, Vincent Bain <bain@toraval.fr> wrote:

Thank you Markus,
good news !
how long has it been implemented ?

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).

Markus M

Vincent

Le mercredi 08 mai 2013 à 16:27 +0200, Markus Metz a écrit :

On Wed, May 8, 2013 at 11:56 AM, RichardC <richtcooper@hotmail.com> wrote:
> Thanks for your fast replies. I'll certainly take a look at the script.
>
> Snapping with v.clean seems to work quite nicely on this occasion:

Easier (and maybe safer) would be to snap already during import with
v.in.ogr snap=

BTW, in the latest versions of GRASS, v.in.ogr suggest a snapping
threshold if errors are encountered.

Markus M

>
> snap lines/boundaries 0.000001
> break lines/boundaries 0.00
> remove duplicates 0.00
> remove small angles at nodes 0.00
> break lines/boundaries 0.00
> break polygons 0.00
> remove duplicates 0.00
> remove lines/boundaries of zero length 0.00
> remove duplicate area centroids 0.00
>
> Output:
> Number of nodes: 774
> Number of primitives: 786
> Number of points: 0
> Number of lines: 0
> Number of boundaries: 776
> Number of centroids: 10
> Number of areas: 14
> Number of isles: 2
> Number of areas without centroid: 4
>
>
>
>
>
> --
> View this message in context: http://osgeo-org.1560.x6.nabble.com/Query-number-of-areas-reported-in-v-build-output-does-not-necessarily-represent-different-geographics-tp5052007p5052033.html
> Sent from the Grass - Users mailing list archive at Nabble.com.
> _______________________________________________
> grass-user mailing list
> grass-user@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

NikosAlexandris · May 8, 2013, 7:49pm

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?

Thanks, N

RichTC · May 9, 2013, 4:36am

Hi,

Snapping gives the maximum distance to another vertex in map units, degrees
for latlon.

I don't know the coordinate ref system for the world mangrove shapefile, but
if degrees lat/long, a snapping distance of 0.000001 would equate to ~0.1 m
at the equator, which should be sufficiently small?

Does using smaller values improve topology?

Cheers,
Richard

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Query-number-of-areas-reported-in-v-build-output-does-not-necessarily-represent-different-geographics-tp5052007p5052228.html
Sent from the Grass - Users mailing list archive at Nabble.com.

RichTC · May 9, 2013, 4:51am

Does using smaller values improve topology?

The approach I'd take would be to gradually reduce the snapping distanceby a
factor of 10 (e.g., starting at 0.000001) until no changes in topology are
apparent. Then I'd address the minimum size area to be imported to see how
that affects topology.

Unless there is an easier/quicker way?

Richard
GRASS 6.4.3

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Query-number-of-areas-reported-in-v-build-output-does-not-necessarily-represent-different-geographics-tp5052007p5052229.html
Sent from the Grass - Users mailing list archive at Nabble.com.

NikosAlexandris · May 9, 2013, 6:05am

RichardC wrote:

Hi,

Snapping gives the maximum distance to another vertex in map units, degrees
for latlon.

I don't know the coordinate ref system for the world mangrove shapefile,

Here a link to it: <http://data.unep-wcmc.org/datasets/21>\. For the records,
ogrinfo reports:

INFO: Open of `usgs_mangroves2.shp'
using driver `ESRI Shapefile' successful.

Layer name: usgs_mangroves2
Geometry: Polygon
Feature Count: 1432891
Extent: (-179.950672, -38.762073) - (179.987788, 32.350173)
Layer SRS WKT:
GEOGCS["GCS_WGS_1984",
    DATUM["WGS_1984",
        SPHEROID["WGS_84",6378137.0,298.257223563]],
    PRIMEM["Greenwich",0.0],
    UNIT["Degree",0.0174532925199433]]
[cut]

but if degrees lat/long, a snapping distance of 0.000001 would equate to
~0.1 m at the equator, which should be sufficiently small?

My post's target was the (as Markus Metz wrote:) "suggestion of a reasonable
(assuming floating point rounding errors) threshold for snapping".

I'd like to have a confirmation that, given that an error message/suggestion
appears still after using a snapping distance of 1e-14, it means that the
imported vector map couldn't automatically be topologically cleaned and needs
some manual handling.

Does using smaller values improve topology?

Is this a generic question or about the Global Mangroves vector map? If
generic, I don't think that topology is improved by using smaller values. If I
am not wrong, from things learned here and off-list as well, large(er)
snapping values might cause unwanted damage to the shape of the original data.

Thanks, Nikos

NikosAlexandris · May 9, 2013, 6:13am

Nikos Alexandris wrote:
..

My post's target was the (as Markus Metz wrote:) "suggestion of a reasonable
(assuming floating point rounding errors) threshold for snapping".

I'd like to have a confirmation that, given that an error message/suggestion
appears still after using a snapping distance of 1e-14, it means that the
imported vector map couldn't automatically be topologically cleaned and
needs some manual handling.

I should also add that, in the beginning, I tried to import the "mangroves"
map with the snap option set to 1e-8 (as elsewhere suggested by Markus Metz).
Only after getting the "error/suggestion" message in question, I increased to
the maximum (possible?) of 1e-14 (and, as I already wrote, actually I
mistakenly defined 1e-15 which I guess does not hurt).

Nikos

Markus_Metz · May 9, 2013, 12:23pm

On Thu, May 9, 2013 at 6:51 AM, RichardC <richtcooper@hotmail.com> wrote:

Does using smaller values improve topology?

Smaller values for the snapping threshold cause less modifications.
The idea is to modify the original data as little as possible and as
much as necessary. Thus...

The approach I'd take would be to gradually reduce the snapping distanceby a
factor of 10 (e.g., starting at 0.000001) until no changes in topology are
apparent.

... I would start with a very low threshold and gradually increase the
threshold by a factor of 10 until no more errors occur.

Then I'd address the minimum size area to be imported to see how

that affects topology.

That might have no effect because the minimum size applies to original
polygons, not to small overlapping areas.

Unless there is an easier/quicker way?

Richard
GRASS 6.4.3

Faster with GRASS 7, otherwise not really, unless you know exactly how
the dataset to be imported was created (the equivalent of v.info -h).

Markus M

Markus_Metz · May 9, 2013, 12:25pm

On Wed, May 8, 2013 at 9:49 PM, Nikos Alexandris
<nik@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

Markus_Metz · May 9, 2013, 12:32pm

On Thu, May 9, 2013 at 8:05 AM, Nikos Alexandris
<nik@nikosalexandris.net> wrote:

RichardC wrote:

Hi,

Snapping gives the maximum distance to another vertex in map units, degrees
for latlon.

I don't know the coordinate ref system for the world mangrove shapefile,

Here a link to it: <http://data.unep-wcmc.org/datasets/21>\. For the records,
ogrinfo reports:

INFO: Open of `usgs_mangroves2.shp'
      using driver `ESRI Shapefile' successful.

Layer name: usgs_mangroves2
Geometry: Polygon
Feature Count: 1432891
Extent: (-179.950672, -38.762073) - (179.987788, 32.350173)
Layer SRS WKT:
GEOGCS["GCS_WGS_1984",
    DATUM["WGS_1984",
        SPHEROID["WGS_84",6378137.0,298.257223563]],
    PRIMEM["Greenwich",0.0],
    UNIT["Degree",0.0174532925199433]]
[cut]

but if degrees lat/long, a snapping distance of 0.000001 would equate to
~0.1 m at the equator, which should be sufficiently small?

My post's target was the (as Markus Metz wrote:) "suggestion of a reasonable
(assuming floating point rounding errors) threshold for snapping".

I'd like to have a confirmation that, given that an error message/suggestion
appears still after using a snapping distance of 1e-14, it means that the
imported vector map couldn't automatically be topologically cleaned and needs
some manual handling.

Try to import with snap=1e-13
then try to import with snap=1e-12
then try to import with snap=1e-11
then try to import with snap=1e-10
etc.

stop when there are no more errors

Markus M

Does using smaller values improve topology?

Is this a generic question or about the Global Mangroves vector map? If
generic, I don't think that topology is improved by using smaller values. If I
am not wrong, from things learned here and off-list as well, large(er)
snapping values might cause unwanted damage to the shape of the original data.

Thanks, Nikos
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

NikosAlexandris · May 9, 2013, 1:06pm

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. All import attempts so
far report many overlapping polygons, e.g.:

- snap 1e-15 (number of overlapping areas shown above)
centroids=1976871
areas=2750605

- snap 1e-8: "WARNING: 41540 areas represent more (overlapping) features..."
Number of centroids: 1976871
Number of areas: 2750605

- snap 1e-7: "WARNING: 41539 areas represent more (overlapping) features..."
Number of centroids: 1976845
Number of areas: 2750579

- snap 1e-6: "WARNING: 41538 areas represent more (overlapping) features..."
Number of centroids: 1976634
Number of areas: 2750368

Complete v.in.ogr's outputs copy-pasted below. The number of imported areas
drops with snap=1e-7 and after. And it takes quite some time in my machine to
import this data set. If it is the case of so many overlapping polygons,
maybe USGS folks should be notified?

I will search the respective documentation tonight to find stuff related to
minimum area extent -- maybe this can help (?).

Thanks, Nikos
---

# snap=1e-8
v.in.ogr
dsn="/geo/geodata/mangroves/global_mangroves_usgs_2011/usgs_mangroves2.shp"
output="global_mangroves_usgs_2011_08" min_area=0.0001 snap=0.00000001
Counting polygons for 1432891 features (OGR layer <usgs_mangroves2>)...
100%
Importing 1432891 features (OGR layer <usgs_mangroves2>)...
100%
-----------------------------------------------------
Building topology for vector map
<global_mangroves_usgs_2011_08_tmp@PERMANENT>...
Registering primitives...
2505416 primitives registered
41179836 vertices registered
Number of nodes: 2384470
Number of primitives: 2505416
Number of points: 0
Number of lines: 0
Number of boundaries: 2505416
Number of centroids: 0
Number of areas: -
Number of isles: -
-----------------------------------------------------
Cleaning polygons
-----------------------------------------------------
Snapping boundaries (threshold = 1.000e-08)...
Reading features...
Snap vertices Pass 1: select points
100%
Snap vertices Pass 2: assign anchor vertices
100%
Snap vertices Pass 3: snap to assigned points
100%
-----------------------------------------------------
Breaking polygons...
Breaking polygons (pass 1: select break points)...
100%
Breaking polygons (pass 2: break at selected points)...
100%
-----------------------------------------------------
Removing duplicates...
100%
-----------------------------------------------------
Breaking boundaries...
100%
-----------------------------------------------------
Removing duplicates...
100%
-----------------------------------------------------
Cleaning boundaries at nodes...
100%
-----------------------------------------------------
Merging boundaries...
100%
-----------------------------------------------------
Removing dangles...
100%
-----------------------------------------------------
Building topology for vector map
<global_mangroves_usgs_2011_08_tmp@PERMANENT>...
Building areas...
100%
2750605 areas built
1278400 isles built
Number of nodes: 3463039
Number of primitives: 10456763
Number of points: 0
Number of lines: 0
Number of boundaries: 10456763
Number of centroids: 0
Number of areas: 2750605
Number of isles: 1278400
-----------------------------------------------------
Removing bridges...
100%
-----------------------------------------------------
Building topology for vector map
<global_mangroves_usgs_2011_08_tmp@PERMANENT>...
Registering primitives...
4133856 primitives registered
39140701 vertices registered
Building areas...
100%
2750605 areas built
1278400 isles built
Attaching islands...
100%
Number of nodes: 2661651
Number of primitives: 4133856
Number of points: 0
Number of lines: 0
Number of boundaries: 4133856
Number of centroids: 0
Number of areas: 2750605
Number of isles: 1278400
-----------------------------------------------------
Finding centroids for OGR layer <usgs_mangroves2>...
100%
-----------------------------------------------------
Writing centroids...
100%
WARNING: 41540 areas represent more (overlapping) features, because
         polygons overlap in input layer(s). Such areas are linked to more
         than 1 row in attribute table. The number of features for those
         areas is stored as category in layer 2
-----------------------------------------------------
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)
-----------------------------------------------------
Copying features...
100%
Building topology for vector map
<global_mangroves_usgs_2011_08@PERMANENT>...
Registering primitives...
6110727 primitives registered
41117572 vertices registered
Building areas...
100%
2750605 areas built
1278400 isles built
Attaching islands...
100%
Attaching centroids...
100%
Number of nodes: 2661651
Number of primitives: 6110727
Number of points: 0
Number of lines: 0
Number of boundaries: 4133856
Number of centroids: 1976871
Number of areas: 2750605
Number of isles: 1278400
-----------------------------------------------------
WARNING: Errors were encountered during the import
Try to import again, snapping with 1e-07: 'snap=1e-07'

# snap=1e-7
v.in.ogr
dsn="/geo/geodata/mangroves/global_mangroves_usgs_2011/usgs_mangroves2.shp"
output="global_mangroves_usgs_2011_07" min_area=0.0001 snap=0.0000001
Counting polygons for 1432891 features (OGR layer <usgs_mangroves2>)...
100%
Importing 1432891 features (OGR layer <usgs_mangroves2>)...
100%
-----------------------------------------------------
Building topology for vector map
<global_mangroves_usgs_2011_07_tmp@PERMANENT>...
Registering primitives...
2505416 primitives registered
41179836 vertices registered
Number of nodes: 2384470
Number of primitives: 2505416
Number of points: 0
Number of lines: 0
Number of boundaries: 2505416
Number of centroids: 0
Number of areas: -
Number of isles: -
-----------------------------------------------------
Cleaning polygons
-----------------------------------------------------
Snapping boundaries (threshold = 1.000e-07)...
Reading features...
Snap vertices Pass 1: select points
100%
Snap vertices Pass 2: assign anchor vertices
100%
Snap vertices Pass 3: snap to assigned points
100%
-----------------------------------------------------
Breaking polygons...
Breaking polygons (pass 1: select break points)...
100%
Breaking polygons (pass 2: break at selected points)...
100%
-----------------------------------------------------
Removing duplicates...
100%
-----------------------------------------------------
Breaking boundaries...
100%
-----------------------------------------------------
Removing duplicates...
100%
-----------------------------------------------------
Cleaning boundaries at nodes...
100%
-----------------------------------------------------
Merging boundaries...
100%
-----------------------------------------------------
Removing dangles...
100%
-----------------------------------------------------
Building topology for vector map
<global_mangroves_usgs_2011_07_tmp@PERMANENT>...
Building areas...
100%
2750579 areas built
1278397 isles built
Number of nodes: 3463450
Number of primitives: 10457376
Number of points: 0
Number of lines: 0
Number of boundaries: 10457376
Number of centroids: 0
Number of areas: 2750579
Number of isles: 1278397
-----------------------------------------------------
Removing bridges...
100%
-----------------------------------------------------
Building topology for vector map
<global_mangroves_usgs_2011_07_tmp@PERMANENT>...
Registering primitives...
4133745 primitives registered
39140346 vertices registered
Building areas...
100%
2750579 areas built
1278397 isles built
Attaching islands...
100%
Number of nodes: 2661563
Number of primitives: 4133745
Number of points: 0
Number of lines: 0
Number of boundaries: 4133745
Number of centroids: 0
Number of areas: 2750579
Number of isles: 1278397
-----------------------------------------------------
Finding centroids for OGR layer <usgs_mangroves2>...
100%
-----------------------------------------------------
Writing centroids...
100%
WARNING: 41539 areas represent more (overlapping) features, because
         polygons overlap in input layer(s). Such areas are linked to more
         than 1 row in attribute table. The number of features for those
         areas is stored as category in layer 2
-----------------------------------------------------
2018421 input polygons
Total area: 1.47005E+11 (2750579 areas)
Overlapping area: 5.32085E+09 (41539 areas)
Area without category: 9.25489E+09 (773734 areas)
-----------------------------------------------------
Copying features...
100%
Building topology for vector map
<global_mangroves_usgs_2011_07@PERMANENT>...
Registering primitives...
6110590 primitives registered
41117191 vertices registered
Building areas...
100%
2750579 areas built
1278397 isles built
Attaching islands...
100%
Attaching centroids...
100%
Number of nodes: 2661563
Number of primitives: 6110590
Number of points: 0
Number of lines: 0
Number of boundaries: 4133745
Number of centroids: 1976845
Number of areas: 2750579
Number of isles: 1278397
-----------------------------------------------------
WARNING: Errors were encountered during the import
Try to import again, snapping with 1e-06: 'snap=1e-06'

# snap=1e-6
v.in.ogr
dsn="/geo/geodata/mangroves/global_mangroves_usgs_2011/usgs_mangroves2.shp"
output="global_mangroves_usgs_2011_06" min_area=0.0001 snap=0.000001
Counting polygons for 1432891 features (OGR layer <usgs_mangroves2>)...
100%
Importing 1432891 features (OGR layer <usgs_mangroves2>)...
100%%
-----------------------------------------------------
Building topology for vector map
<global_mangroves_usgs_2011_06_tmp@PERMANENT>...
Registering primitives...
2505416 primitives registered
41179836 vertices registered
Number of nodes: 2384470
Number of primitives: 2505416
Number of points: 0
Number of lines: 0
Number of boundaries: 2505416
Number of centroids: 0
Number of areas: -
Number of isles: -
-----------------------------------------------------
Cleaning polygons
-----------------------------------------------------
Snapping boundaries (threshold = 1.000e-06)...
Reading features...
Snap vertices Pass 1: select points
100%
Snap vertices Pass 2: assign anchor vertices
100%
Snap vertices Pass 3: snap to assigned points
100%
-----------------------------------------------------
Breaking polygons...
Breaking polygons (pass 1: select break points)...
100%
Breaking polygons (pass 2: break at selected points)...
100%
-----------------------------------------------------
Removing duplicates...
100%
-----------------------------------------------------
Breaking boundaries...
100%
-----------------------------------------------------
Removing duplicates...
100%
-----------------------------------------------------
Cleaning boundaries at nodes...
100%
-----------------------------------------------------
Merging boundaries...
100%
-----------------------------------------------------
Removing dangles...
100%
-----------------------------------------------------
Building topology for vector map
<global_mangroves_usgs_2011_06_tmp@PERMANENT>...
Building areas...
100%
2750368 areas built
1278375 isles built
Number of nodes: 3466918
Number of primitives: 10463204
Number of points: 0
Number of lines: 0
Number of boundaries: 10463204
Number of centroids: 0
Number of areas: 2750368
Number of isles: 1278375
WARNING: Number of incorrect boundaries: 11
-----------------------------------------------------
Removing bridges...
100%
-----------------------------------------------------
Building topology for vector map
<global_mangroves_usgs_2011_06_tmp@PERMANENT>...
Registering primitives...
4132751 primitives registered
39137038 vertices registered
Building areas...
100%
2750368 areas built
1278377 isles built
Attaching islands...
100%
Number of nodes: 2660760
Number of primitives: 4132751
Number of points: 0
Number of lines: 0
Number of boundaries: 4132751
Number of centroids: 0
Number of areas: 2750368
Number of isles: 1278377
-----------------------------------------------------
Finding centroids for OGR layer <usgs_mangroves2>...
100%
-----------------------------------------------------
Writing centroids...
100%
WARNING: 41538 areas represent more (overlapping) features, because
         polygons overlap in input layer(s). Such areas are linked to more
         than 1 row in attribute table. The number of features for those
         areas is stored as category in layer 2
-----------------------------------------------------
2018421 input polygons
Total area: 1.47005E+11 (2750368 areas)
Overlapping area: 5.32085E+09 (41538 areas)
Area without category: 9.25489E+09 (773734 areas)
-----------------------------------------------------
Copying features...
100%
Building topology for vector map
<global_mangroves_usgs_2011_06@PERMANENT>...
Registering primitives...
6109385 primitives registered
41113672 vertices registered
Building areas...
100%
2750368 areas built
1278377 isles built
Attaching islands...
100%
Attaching centroids...
100%
Number of nodes: 2660760
Number of primitives: 6109385
Number of points: 0
Number of lines: 0
Number of boundaries: 4132751
Number of centroids: 1976634
Number of areas: 2750368
Number of isles: 1278377
-----------------------------------------------------
WARNING: Errors were encountered during the import
Try to import again, snapping with 1e-05: 'snap=1e-05'

Markus_Metz · May 9, 2013, 2:21pm

On Thu, May 9, 2013 at 3:06 PM, Nikos Alexandris
<nik@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

RichTC · May 10, 2013, 6:03am

Is there any automated way of removing the overlaps, as they appear quite
extensive?

I imported a portion of the large shapefile (I get memory errors when
attempting the entire file) covering SEAsia (I'm interested in wetlands of
this region where I'm based) and overlapping appears quite extensive for
some areas - see attached images.

I get the following errors on importing using snapping of 1e-16:
*379547 input polygons*
Total area: 1.64146E+10 (423219 areas)
Overlapping area: 1.61761E+09 (11784 areas)
Area without category: 6.61882E+08 (55476 areas)

Number of boundaries: 653327
Number of centroids: 367743
Number of areas: 423219
Number of isles: 165688
Number of incorrect boundaries: 19
Number of areas without centroid: 55476

Richard
<http://osgeo-org.1560.x6.nabble.com/file/n5052461/overlap_seasia.jpg>
<http://osgeo-org.1560.x6.nabble.com/file/n5052461/seaasia_layer1.jpg>
<http://osgeo-org.1560.x6.nabble.com/file/n5052461/overlap_areas.jpg>

Note about showing layer2 - when I change the colour of the feature (via
properties) it then displays all polygons and I have to re-run d.vect to
re-display just the overlapped areas: d.vect map=filename type=area layer=2

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Query-number-of-areas-reported-in-v-build-output-does-not-necessarily-represent-different-geographics-tp5052007p5052461.html
Sent from the Grass - Users mailing list archive at Nabble.com.

RichTC · May 10, 2013, 6:14am

I should rephrase my question, as Markus indicated that GRASS doesn't have
tools to resolve:

Is there any automated way outside GRASS (if not within) of removing the
overlaps, as they appear quite extensive?

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Query-number-of-areas-reported-in-v-build-output-does-not-necessarily-represent-different-geographics-tp5052007p5052463.html
Sent from the Grass - Users mailing list archive at Nabble.com.

Markus_Metz · May 10, 2013, 7:11am

On Fri, May 10, 2013 at 8:14 AM, RichardC <richtcooper@hotmail.com> wrote:

I should rephrase my question, as Markus indicated that GRASS doesn't have
tools to resolve:

You could try a dissolve:

v.category op=add cat=1 step=0 type=centroid layer=3
v.extract -d layer=3 type=area

optionally add new categories as unique ids to layer 1:
v.category op=del cat=-1 step=0 type=centroid layer=1
v.category op=add cat=1 step=1 type=centroid layer=1

HTH,

Markus M

Is there any automated way outside GRASS (if not within) of removing the
overlaps, as they appear quite extensive?

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Query-number-of-areas-reported-in-v-build-output-does-not-necessarily-represent-different-geographics-tp5052007p5052463.html
Sent from the Grass - Users mailing list archive at Nabble.com.
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user