[GRASS-user] ... getting rid of duplicate polygons ...

gisfisch · February 10, 2017, 4:44pm

Hello list,

I have a question about dealing with duplicate polygons (dp) coming into GRASS from a polygon shapefile. The polygons are not overlapping or having gaps, but there are a number of real duplicate ones (polygons show parcels with owners, and if one parcel has two or more owners, e. g. wife and husband, this situation in the shapefile is represented by two identical polys with two database rows that only differ in the owners name).

My goal is to get rid of duplicates, having a result with only one polygon/centroid at a given location with only one owner name. The name does not matter, it can be chosen arbitrary by the system. This works fine when using ESRI “clean”-command. The structure of the database table is maintained while one (or many) of the dp is/are lost, leaving only one valid polygon.

Now, I found an older thread called “unable to get rid of duplicate polygons”. Obviously, the problem/question is the same but I could not find a solution for GRASS there. So I tried:

v.clean -c input=input@mapset output=output_clean tool=snap,rmdac,bpol threshold=0.01,0,0

and

v.clean -c input=input@mapset output=output_clean tool=break,snap,rmdupl,rmdac,bpol

Nothing did work. I get a map with tree layers, one showing the islands only (layer 0), one showing the complete polygon set with duplicates (1), and one showing only the duplicates (2). I also tried to delete layer 2, assuming that this might remove the dp, but it only messed up the dataset.

What am I doing wrong?

Regards, Uwe

hcho · February 12, 2017, 7:25am

Uwe,

It wouldn’t be easy to tell what your problem is without seeing your dataset. If you don’t want to share your dataset, maybe create a small subset of it so others can try it.

Regards,

Huidae

···

On Fri, Feb 10, 2017 at 11:44 AM, Uwe Fischer <gisfisch@t-online.de> wrote:

Hello list,

I have a question about dealing with duplicate polygons (dp) coming into GRASS from a polygon shapefile. The polygons are not overlapping or having gaps, but there are a number of real duplicate ones (polygons show parcels with owners, and if one parcel has two or more owners, e. g. wife and husband, this situation in the shapefile is represented by two identical polys with two database rows that only differ in the owners name).

My goal is to get rid of duplicates, having a result with only one polygon/centroid at a given location with only one owner name. The name does not matter, it can be chosen arbitrary by the system. This works fine when using ESRI “clean”-command. The structure of the database table is maintained while one (or many) of the dp is/are lost, leaving only one valid polygon.

Now, I found an older thread called “unable to get rid of duplicate polygons”. Obviously, the problem/question is the same but I could not find a solution for GRASS there. So I tried:

v.clean -c input=input@mapset output=output_clean tool=snap,rmdac,bpol threshold=0.01,0,0

and

v.clean -c input=input@mapset output=output_clean tool=break,snap,rmdupl,rmdac,bpol

Nothing did work. I get a map with tree layers, one showing the islands only (layer 0), one showing the complete polygon set with duplicates (1), and one showing only the duplicates (2). I also tried to delete layer 2, assuming that this might remove the dp, but it only messed up the dataset.

What am I doing wrong?

Regards, Uwe

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

Stu1 · February 12, 2017, 3:36pm

Hi -

I have imported a kml file that contains contours of a feature of interest. Functionally an x,y,z data set. It displays correctly in GRASS. When queried to determine the value of z, the attached error is given that indicates a lack of conformance with JSON formatting. The values of z are given for the feature in the error message but additional processing such as v.to.rast does not work. GRASS is able to label the contours correctly. Using the attribute table manager is not much help - it produces an error that indicates ‘Inconsistent number of columns in table’.

I see that there is a bug report (3133) that reflects the same problem but has been fixed in 7.0.5 - I’m getting the ‘same’ error in 7.3.svn. (on OS X 10.10.5)

The error message is too long to fit on the monitor - and is not scrollable, so the full content is not visible.

Any assistance or advice much appreciated.

Stu

annakrat · February 12, 2017, 8:44pm

Hi,

(attachments)

Screen Shot 2017-02-12 at 10.29.33 AM.png

···

On Sun, Feb 12, 2017 at 10:36 AM, Stuart Edwards <sedwards2@cinci.rr.com> wrote:

Hi -

I have imported a kml file that contains contours of a feature of interest. Functionally an x,y,z data set. It displays correctly in GRASS. When queried to determine the value of z, the attached error is given that indicates a lack of conformance with JSON formatting. The values of z are given for the feature in the error message but additional processing such as v.to.rast does not work. GRASS is able to label the contours correctly. Using the attribute table manager is not much help - it produces an error that indicates ‘Inconsistent number of columns in table’.

I see that there is a bug report (3133) that reflects the same problem but has been fixed in 7.0.5 - I’m getting the ‘same’ error in 7.3.svn. (on OS X 10.10.5)

The error message is too long to fit on the monitor - and is not scrollable, so the full content is not visible.

Any assistance or advice much appreciated.

please post (or attach) the text outputs of v.what with -j flag and v.db.select, which are the backend commands behind the GUI dialogs. That helps us to analyze it.

Anna

Stu

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

Stu1 · February 12, 2017, 10:52pm

Anna

Thanks for the quick response.

Here’s the output from v.what -j for the query in the screenshot:

(Sun Feb 12 17:14:20 2017)
v.what -j map=DBT___Waste___3D@corH coordinates=-79:45:47.0628, 39:05:14.8848
{“Coordinates”: {“East”: “79W”, “North”: “39N”},
“Maps”:
[{“Map”: “DBT___Waste___3D”,
“Mapset”: “corH”}
]}
(Sun Feb 12 17:14:21 2017) Command finished (0 sec)

Output from v.db.select (same query):

(Sun Feb 12 17:19:57 2017)
v.db.select --overwrite map=DBT___Waste___3D@corH file=/Users/sesMacBook/Baker/CorridorH/WasteDisposal/vdbselect1
(Sun Feb 12 17:19:57 2017) Command finished (0 sec)

output: https://www.dropbox.com/s/wdxxah4et00vwhy/vdbselect1?dl=0

Another kml contour file (from a different source) displayed in the same mapset produces normal results from a query:

east, north: -79.7618228288, 39.0853199854
DESIGN_MAJOR_CONTOURS@corH:
Type: Line
Id: 5007
Length: 106.682658
Line_height: 691.997
Layer: 1
Category: 1
Driver: sqlite
Database: /Users/sesMacBook/grassdata/KML/corH/sqlite/sqlite.db
Table: DESIGN_MAJOR_CONTOURS
Key_column: cat
Attributes:
cat: 1
Name: Style2
altitudeMode: absolute
tessellate: -1
extrude: -1
visibility: -1

However, the v.what -j command produces a similar result to the one above:

(Sun Feb 12 17:29:12 2017)
v.what -j map=DESIGN_MAJOR_CONTOURS@corH coordinates=-79.7618228288, 39.0853199854
{“Coordinates”: {“East”: “79:45:42.562184W”, “North”: “39:05:07.151947N”},
“Maps”:
[{“Map”: “DESIGN_MAJOR_CONTOURS”,
“Mapset”: “corH”}
]}
(Sun Feb 12 17:29:12 2017) Command finished (0 sec)

and the v.db.select output is much shorter:

(Sun Feb 12 17:35:44 2017)
v.db.select --overwrite map=DESIGN_MAJOR_CONTOURS@corH file=/Users/sesMacBook/Baker/CorridorH/WasteDisposal/vdbselect2
(Sun Feb 12 17:35:44 2017) Command finished (0 sec)

produces:

cat>Name>description>timestamp>begin>end>altitudeMode>tessellate>extrude>visibility>drawOrder>icon
1|Style2|||||absolute|-1|-1|-1||

I can send you the two kml files if that would be helpful.

thx

Stu

···

On Sun, Feb 12, 2017 at 10:36 AM, Stuart Edwards <sedwards2@cinci.rr.com> wrote:

Hi -

I have imported a kml file that contains contours of a feature of interest. Functionally an x,y,z data set. It displays correctly in GRASS. When queried to determine the value of z, the attached error is given that indicates a lack of conformance with JSON formatting. The values of z are given for the feature in the error message but additional processing such as v.to.rast does not work. GRASS is able to label the contours correctly. Using the attribute table manager is not much help - it produces an error that indicates ‘Inconsistent number of columns in table’.

I see that there is a bug report (3133) that reflects the same problem but has been fixed in 7.0.5 - I’m getting the ‘same’ error in 7.3.svn. (on OS X 10.10.5)

The error message is too long to fit on the monitor - and is not scrollable, so the full content is not visible.

Any assistance or advice much appreciated.

please post (or attach) the text outputs of v.what with -j flag and v.db.select, which are the backend commands behind the GUI dialogs. That helps us to analyze it.

Anna

Stu

<Screen Shot 2017-02-12 at 10.29.33 AM.png>

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

annakrat · February 13, 2017, 1:13am

On Sun, Feb 12, 2017 at 5:42 PM, Stuart Edwards <sedwards2@cinci.rr.com> wrote:

Anna

Thanks for the quick response.

Here's the output from v.what -j for the query in the screenshot:

(Sun Feb 12 17:14:20 2017)
v.what -j map=DBT___Waste___3D@corH coordinates=-79:45:47.0628,
39:05:14.8848
{"Coordinates": {"East": "79W", "North": "39N"},
"Maps":
[{"Map": "DBT___Waste___3D",
"Mapset": "corH"}
]}
(Sun Feb 12 17:14:21 2017) Command finished (0 sec)

Output from v.db.select (same query):

(Sun Feb 12 17:19:57 2017)
v.db.select --overwrite map=DBT___Waste___3D@corH
file=/Users/sesMacBook/Baker/CorridorH/WasteDisposal/vdbselect1
(Sun Feb 12 17:19:57 2017) Command finished (0 sec)

Looking at the attachment, the problem is definitely in multiline
strings in your 'description' column. I suggest to create a ticket for
this. For now, you might want to consider deleting that column if it
is not needed, to be able to use the vector.

Anna

Another kml contour file (from a different source) displayed in the same
mapset produces better results from a query:

east, north: -79.7618228288, 39.0853199854
DESIGN_MAJOR_CONTOURS@corH:
  Type: Line
  Id: 5007
  Length: 106.682658
  Line_height: 691.997
  Layer: 1
  Category: 1
  Driver: sqlite
  Database: /Users/sesMacBook/grassdata/KML/corH/sqlite/sqlite.db
  Table: DESIGN_MAJOR_CONTOURS
  Key_column: cat
  Attributes:
    cat: 1
    Name: Style2
    altitudeMode: absolute
    tessellate: -1
    extrude: -1
    visibility: -1

However, the v.what -j command produces a similar result to the one above:

(Sun Feb 12 17:29:12 2017)
v.what -j map=DESIGN_MAJOR_CONTOURS@corH coordinates=-79.7618228288,
39.0853199854
{"Coordinates": {"East": "79:45:42.562184W", "North": "39:05:07.151947N"},
"Maps":
[{"Map": "DESIGN_MAJOR_CONTOURS",
"Mapset": "corH"}
]}
(Sun Feb 12 17:29:12 2017) Command finished (0 sec)

and the v.db.select output is much shorter:

(Sun Feb 12 17:35:44 2017)
v.db.select --overwrite map=DESIGN_MAJOR_CONTOURS@corH
file=/Users/sesMacBook/Baker/CorridorH/WasteDisposal/vdbselect2
(Sun Feb 12 17:35:44 2017) Command finished (0 sec)

produces:

cat|Name|description|timestamp|begin|end|altitudeMode|tessellate|extrude|visibility|drawOrder|icon
1|Style2|||||absolute|-1|-1|-1||

I can send you the two kml files if that would be helpful.

thx

Stu

On Feb 12, 2017, at 3:44 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

Hi,

On Sun, Feb 12, 2017 at 10:36 AM, Stuart Edwards <sedwards2@cinci.rr.com>
wrote:

Hi -

I have imported a kml file that contains contours of a feature of
interest. Functionally an x,y,z data set. It displays correctly in GRASS.
When queried to determine the value of z, the attached error is given that
indicates a lack of conformance with JSON formatting. The values of z are
given for the feature in the error message but additional processing such as
v.to.rast does not work. GRASS is able to label the contours correctly.
Using the attribute table manager is not much help - it produces an error
that indicates 'Inconsistent number of columns in table'.

I see that there is a bug report (3133) that reflects the same problem but
has been fixed in 7.0.5 - I'm getting the 'same' error in 7.3.svn. (on OS X
10.10.5)

The error message is too long to fit on the monitor - and is not
scrollable, so the full content is not visible.

Any assistance or advice much appreciated.

please post (or attach) the text outputs of v.what with -j flag and
v.db.select, which are the backend commands behind the GUI dialogs. That
helps us to analyze it.

Anna

Stu

<Screen Shot 2017-02-12 at 10.29.33 AM.png>

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

Stu1 · February 13, 2017, 1:13pm

On Feb 12, 2017, at 8:13 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

On Sun, Feb 12, 2017 at 5:42 PM, Stuart Edwards <sedwards2@cinci.rr.com> wrote:

Anna

Thanks for the quick response.

Here's the output from v.what -j for the query in the screenshot:

(Sun Feb 12 17:14:20 2017)
v.what -j map=DBT___Waste___3D@corH coordinates=-79:45:47.0628,
39:05:14.8848
{"Coordinates": {"East": "79W", "North": "39N"},
"Maps":
[{"Map": "DBT___Waste___3D",
"Mapset": "corH"}
]}
(Sun Feb 12 17:14:21 2017) Command finished (0 sec)

Output from v.db.select (same query):

(Sun Feb 12 17:19:57 2017)
v.db.select --overwrite map=DBT___Waste___3D@corH
file=/Users/sesMacBook/Baker/CorridorH/WasteDisposal/vdbselect1
(Sun Feb 12 17:19:57 2017) Command finished (0 sec)

Looking at the attachment, the problem is definitely in multiline
strings in your 'description' column. I suggest to create a ticket for
this. For now, you might want to consider deleting that column if it
is not needed, to be able to use the vector.

Anna

Deleting the description column eliminated the error and the file performs as expected

thanks!

Stu

Another kml contour file (from a different source) displayed in the same
mapset produces better results from a query:

east, north: -79.7618228288, 39.0853199854
DESIGN_MAJOR_CONTOURS@corH:
Type: Line
Id: 5007
Length: 106.682658
Line_height: 691.997
Layer: 1
Category: 1
Driver: sqlite
Database: /Users/sesMacBook/grassdata/KML/corH/sqlite/sqlite.db
Table: DESIGN_MAJOR_CONTOURS
Key_column: cat
Attributes:
  cat: 1
  Name: Style2
  altitudeMode: absolute
  tessellate: -1
  extrude: -1
  visibility: -1

However, the v.what -j command produces a similar result to the one above:

(Sun Feb 12 17:29:12 2017)
v.what -j map=DESIGN_MAJOR_CONTOURS@corH coordinates=-79.7618228288,
39.0853199854
{"Coordinates": {"East": "79:45:42.562184W", "North": "39:05:07.151947N"},
"Maps":
[{"Map": "DESIGN_MAJOR_CONTOURS",
"Mapset": "corH"}
]}
(Sun Feb 12 17:29:12 2017) Command finished (0 sec)

and the v.db.select output is much shorter:

(Sun Feb 12 17:35:44 2017)
v.db.select --overwrite map=DESIGN_MAJOR_CONTOURS@corH
file=/Users/sesMacBook/Baker/CorridorH/WasteDisposal/vdbselect2
(Sun Feb 12 17:35:44 2017) Command finished (0 sec)

produces:

cat|Name|description|timestamp|begin|end|altitudeMode|tessellate|extrude|visibility|drawOrder|icon
1|Style2|||||absolute|-1|-1|-1||

I can send you the two kml files if that would be helpful.

thx

Stu

On Feb 12, 2017, at 3:44 PM, Anna Petrášová <kratochanna@gmail.com> wrote:

Hi,

On Sun, Feb 12, 2017 at 10:36 AM, Stuart Edwards <sedwards2@cinci.rr.com>
wrote:

Hi -

I have imported a kml file that contains contours of a feature of
interest. Functionally an x,y,z data set. It displays correctly in GRASS.
When queried to determine the value of z, the attached error is given that
indicates a lack of conformance with JSON formatting. The values of z are
given for the feature in the error message but additional processing such as
v.to.rast does not work. GRASS is able to label the contours correctly.
Using the attribute table manager is not much help - it produces an error
that indicates 'Inconsistent number of columns in table'.

I see that there is a bug report (3133) that reflects the same problem but
has been fixed in 7.0.5 - I'm getting the 'same' error in 7.3.svn. (on OS X
10.10.5)

The error message is too long to fit on the monitor - and is not
scrollable, so the full content is not visible.

Any assistance or advice much appreciated.

please post (or attach) the text outputs of v.what with -j flag and
v.db.select, which are the backend commands behind the GUI dialogs. That
helps us to analyze it.

Anna

Stu

<Screen Shot 2017-02-12 at 10.29.33 AM.png>

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

Stu1 · February 13, 2017, 4:07pm

Anna

I now have a working vector file that displays correctly and can be queried with normal results. However after much trial and error I am still unable to access the elevation data in other modules (e.g. v.to.rast). There is always a requirement to specify the attribute - and as you can see, the geotmetric data are not attributes and do not show up in the menu of attributes. Here's the output from a query that may help visualize the problem:

east, north: -79.7630759471, 39.0874586371
DBT@corH:
  Type: Line
  Id: 885
  Length: 275.746
  Line_height: 698.602997
  Layer: 1
  Category: 885
  Driver: sqlite
  Database: /Users/sesMacBook/grassdata/KML/corH/sqlite/sqlite.db
  Table: DBT
  Key_column: cat
  Attributes:
    cat: 885
    cat_: 885
    tessellate: -1
    extrude: -1
    visibility: -1

What I need is the Line_height value, which is not an 'attribute' - neither is it 'z'

I tried exporting the file as a shape file and reimporting it - same result. Then as a GRASS ascii - no file created - and ran out of ideas. Is there a way to add Line_height as an attribute?

Any help appreciated...

Stu

annakrat · February 13, 2017, 7:27pm

On Mon, Feb 13, 2017 at 11:07 AM, Stuart Edwards <sedwards2@cinci.rr.com> wrote:

Anna

I now have a working vector file that displays correctly and can be queried with normal results. However after much trial and error I am still unable to access the elevation data in other modules (e.g. v.to.rast). There is always a requirement to specify the attribute - and as you can see, the geotmetric data are not attributes and do not show up in the menu of attributes. Here's the output from a query that may help visualize the problem:

east, north: -79.7630759471, 39.0874586371
DBT@corH:
  Type: Line
  Id: 885
  Length: 275.746
  Line_height: 698.602997
  Layer: 1
  Category: 885
  Driver: sqlite
  Database: /Users/sesMacBook/grassdata/KML/corH/sqlite/sqlite.db
  Table: DBT
  Key_column: cat
  Attributes:
    cat: 885
    cat_: 885
    tessellate: -1
    extrude: -1
    visibility: -1

What I need is the Line_height value, which is not an 'attribute' - neither is it 'z'

I tried exporting the file as a shape file and reimporting it - same result. Then as a GRASS ascii - no file created - and ran out of ideas. Is there a way to add Line_height as an attribute?

Any help appreciated...

I would try v.to.db with option start, then v.to.3d

Hope that helps

Stu

mlennert · February 14, 2017, 8:43am

On 13/02/17 20:27, Anna Petrášová wrote:

On Mon, Feb 13, 2017 at 11:07 AM, Stuart Edwards <sedwards2@cinci.rr.com> wrote:

Anna

I now have a working vector file that displays correctly and can be queried with normal results. However after much trial and error I am still unable to access the elevation data in other modules (e.g. v.to.rast). There is always a requirement to specify the attribute - and as you can see, the geotmetric data are not attributes and do not show up in the menu of attributes. Here's the output from a query that may help visualize the problem:

east, north: -79.7630759471, 39.0874586371
DBT@corH:
  Type: Line
  Id: 885
  Length: 275.746
  Line_height: 698.602997
  Layer: 1
  Category: 885
  Driver: sqlite
  Database: /Users/sesMacBook/grassdata/KML/corH/sqlite/sqlite.db
  Table: DBT
  Key_column: cat
  Attributes:
    cat: 885
    cat_: 885
    tessellate: -1
    extrude: -1
    visibility: -1

What I need is the Line_height value, which is not an 'attribute' - neither is it 'z'

I tried exporting the file as a shape file and reimporting it - same result. Then as a GRASS ascii - no file created - and ran out of ideas. Is there a way to add Line_height as an attribute?

Any help appreciated...

I would try v.to.db with option start, then v.to.3d

It would probably be nice, and IMHO not too complicated, to add line height as an option to v.to.db. Stuart, I invite you to post an enhancement request on the trac [1] for that.

Moritz

[1] https://trac.osgeo.org/grass/

Stu1 · February 14, 2017, 1:39pm

On Feb 14, 2017, at 3:43 AM, Moritz Lennert <mlennert@club.worldonline.be> wrote:

On 13/02/17 20:27, Anna Petrášová wrote:

On Mon, Feb 13, 2017 at 11:07 AM, Stuart Edwards <sedwards2@cinci.rr.com> wrote:

Anna

I now have a working vector file that displays correctly and can be queried with normal results. However after much trial and error I am still unable to access the elevation data in other modules (e.g. v.to.rast). There is always a requirement to specify the attribute - and as you can see, the geotmetric data are not attributes and do not show up in the menu of attributes. Here’s the output from a query that may help visualize the problem:

east, north: -79.7630759471, 39.0874586371
DBT@corH:
Type: Line
Id: 885
Length: 275.746
Line_height: 698.602997
Layer: 1
Category: 885
Driver: sqlite
Database: /Users/sesMacBook/grassdata/KML/corH/sqlite/sqlite.db
Table: DBT
Key_column: cat
Attributes:
cat: 885
cat_: 885
tessellate: -1
extrude: -1
visibility: -1

What I need is the Line_height value, which is not an ‘attribute’ - neither is it ‘z’

I tried exporting the file as a shape file and reimporting it - same result. Then as a GRASS ascii - no file created - and ran out of ideas. Is there a way to add Line_height as an attribute?

Any help appreciated…

I would try v.to.db with option start, then v.to.3d

It would probably be nice, and IMHO not too complicated, to add line height as an option to v.to.db. Stuart, I invite you to post an enhancement request on the trac [1] for that.

Moritz

[1] https://trac.osgeo.org/grass/

… that would be very cool. Done.

Markus_Metz · February 15, 2017, 8:32am

On Fri, Feb 10, 2017 at 5:44 PM, Uwe Fischer <gisfisch@t-online.de> wrote:

Hello list,

I have a question about dealing with duplicate polygons (dp) coming into GRASS from a polygon shapefile. The polygons are not overlapping or having gaps, but there are a number of real duplicate ones (polygons show parcels with owners, and if one parcel has two or more owners, e. g. wife and husband, this situation in the shapefile is represented by two identical polys with two database rows that only differ in the owners name).

My goal is to get rid of duplicates, having a result with only one polygon/centroid at a given location with only one owner name. The name does not matter, it can be chosen arbitrary by the system. This works fine when using ESRI “clean”-command. The structure of the database table is maintained while one (or many) of the dp is/are lost, leaving only one valid polygon.

Now, I found an older thread called “unable to get rid of duplicate polygons”. Obviously, the problem/question is the same but I could not find a solution for GRASS there.

There is no tool in GRASS that automatically removes all but one category values from a feature. You would need to use the vector digitizer or v.edit.

Alternatively, you could create a copy of the vector, remove all categories from layer 1 and 2 with
v.category type=centroid option=del cat=-1 layer=1
and

v.category type=centroid option=del cat=-1 layer=2

Then assign new categories with
v.category type=centroid option=add cat=1 layer=1

Finally try v.distance from= to= from_type=centroid from_layer=1 to_type=centroid to_layer=1 upload=to_attr to_column= column=

Markus M

So I tried:

v.clean -c input=input@mapset output=output_clean tool=snap,rmdac,bpol threshold=0.01,0,0

and

v.clean -c input=input@mapset output=output_clean tool=break,snap,rmdupl,rmdac,bpol

Nothing did work. I get a map with tree layers, one showing the islands only (layer 0), one showing the complete polygon set with duplicates (1), and one showing only the duplicates (2). I also tried to delete layer 2, assuming that this might remove the dp, but it only messed up the dataset.

What am I doing wrong?

Regards, Uwe

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