[GRASS-user] topological errors in v.extract results

GRASS GRASS user
1

Dear all,

At the moment I am struggling quite a bit with GRASS topology errors for two of my maps which result from v.dissolve.

Input maps are imported with v.in.ogr without topological errors. However, the output maps from v.dissolve result into

406458 areas, but only

182176 centroids

in map A and

1058018 areas, but only

995283 centroids

in map B

After patching and cleaning both layers v.to.db gives no correct result for sides. Often areas have –sides like this:

cat>left>right

1||-1|

Then I ran v.build -e on both in order to investigate.

For both, the number of errors reported by v.build is exactly the difference between the number of areas and the number of centroids in each map.

Any hints or suggestions for alternative approaches to dissolving areas with common attributes?

I am interested in the individual areas (= one category and one entry in the attribute table per area) anyway and will try v.extract directly, if that sounds reasonable?

Cheers

Stefan

2

Short update: I see that the difference between number of areas and number of centroids is already present after v.in.ogr…

Is that correct?

Is not an area defined as a closed boundary with a centroid inside? Should not then the number of centroids be equal to the number of areas?

I am using GRASS GIS 7.0.4 on Ubunut 14.04 LTS BTW.

I try to compare with GRASS GIS 7.1 but import there is painfully slow.

So I had at: https://trac.osgeo.org/grass/ticket/2185

However, I use exactly the same data, from the same database, on the same (local) harddrive in 7.1 and it is just !much! slower than 7.0.4 on import… Snapping vertices Step 1 takes significantly longer than with 7.0.4

Cleaning topology in 7.1 from a GRASS vector map earlier imported with 7.0.4svn is BTW not noticeably slower in 7.1 compared to 7.0.4…

I am glad for any hints,

Stefan

3

On Wed, Aug 17, 2016 at 11:54 AM, Blumentrath, Stefan
<Stefan.Blumentrath@nina.no> wrote:

Short update: I see that the difference between number of areas and number
of centroids is already present after v.in.ogr…

Is that correct?

Is not an area defined as a closed boundary with a centroid inside? Should
not then the number of centroids be equal to the number of areas?

Areas without centroid are generally ok, they are holes inside other
areas, equivalent to inner rings of shapefile polygons. As long as
there are no warnings in the output of v.in.ogr or v.build, there are
no topological errors.

I am using GRASS GIS 7.0.4 on Ubunut 14.04 LTS BTW.

I try to compare with GRASS GIS 7.1 but import there is painfully slow.

So I had at: https://trac.osgeo.org/grass/ticket/2185

However, I use exactly the same data, from the same database, on the same
(local) harddrive in 7.1 and it is just !much! slower than 7.0.4 on
import... Snapping vertices Step 1 takes significantly longer than with
7.0.4

There is no GRASS 7.1, so I guess you mean 7.2 or trunk. Are you using
the environment variable GRASS_VECTOR_LOWMEM? This variable affects
snapping only in 7.2 and trunk: less memory but longer processing
time.

Markus M

Cleaning topology in 7.1 from a GRASS vector map earlier imported with
7.0.4svn is BTW not noticeably slower in 7.1 compared to 7.0.4...

I am glad for any hints,

Stefan

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

4

On Wed, Aug 17, 2016 at 11:54 AM, Blumentrath, Stefan
<Stefan.Blumentrath@nina.no> wrote:
[...]

I try to compare with GRASS GIS 7.1 but import there is painfully slow.

So I had at: https://trac.osgeo.org/grass/ticket/2185

However, I use exactly the same data, from the same database, on the same
(local) harddrive in 7.1 and it is just !much! slower than 7.0.4 on
import... Snapping vertices Step 1 takes significantly longer than with
7.0.4

G72 and trunk use a new search tree for snapping that needs much less
memory. Unfortunately, balancing this search tree did not scale well
with millions of vertices. I improved the balancing method in trunk
r69253 and G72 r69254.

Markus M

Cleaning topology in 7.1 from a GRASS vector map earlier imported with
7.0.4svn is BTW not noticeably slower in 7.1 compared to 7.0.4...

I am glad for any hints,

Stefan

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

5

Thanks Markus!

-----Original Message-----
From: Markus Metz [mailto:markus.metz.giswork@gmail.com]
Sent: 25. august 2016 18:36
To: Blumentrath, Stefan <Stefan.Blumentrath@nina.no>
Cc: grass-user grass-user (grass-user@lists.osgeo.org) <grass-user@lists.osgeo.org>
Subject: Re: [GRASS-user] topological errors in v.extract results

On Wed, Aug 17, 2016 at 11:54 AM, Blumentrath, Stefan <Stefan.Blumentrath@nina.no> wrote:
[...]

I try to compare with GRASS GIS 7.1 but import there is painfully slow.

So I had at: https://trac.osgeo.org/grass/ticket/2185

However, I use exactly the same data, from the same database, on the
same
(local) harddrive in 7.1 and it is just !much! slower than 7.0.4 on
import... Snapping vertices Step 1 takes significantly longer than
with
7.0.4

G72 and trunk use a new search tree for snapping that needs much less memory. Unfortunately, balancing this search tree did not scale well with millions of vertices. I improved the balancing method in trunk
r69253 and G72 r69254.

Markus M

Cleaning topology in 7.1 from a GRASS vector map earlier imported with
7.0.4svn is BTW not noticeably slower in 7.1 compared to 7.0.4...

I am glad for any hints,

Stefan

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