Bug report #3126

Sliver holes remain after dissolve

Added by Maxim Dubinin about 14 years ago. Updated over 13 years ago.

Status:Closed
Priority:Low
Assignee:Jürgen Fischer
Category:Vectors
Affected QGIS version: Regression?:No
Operating System:All Easy fix?:No
Pull Request or Patch supplied: Resolution:invalid
Crashes QGIS or corrupts data: Copied to github as #:13186

Description

1. Open shapefile
http://gis-lab.info/forum/download/file.php?id=1794

2. Vector\\Geoprocessing\\Dissolve

Results in creation of sliver holes. Example: http://gis-lab.info/forum/download/file.php?id=1793

Seems like a problem with numerical precision or GEOS issue(?).

The same dissolve in Arcview works flawlessly.

slivers_shp.zip (89.8 KB) Giovanni Manghi, 2010-10-31 10:06 AM

overlapping_shp.zip (14.3 KB) Giovanni Manghi, 2010-10-31 10:06 AM

History

#1 Updated by Giovanni Manghi about 14 years ago

The original shapefile has already slivers, do you expect the dissolve tool to fix them? It seems to be so geometrically unclean that GRASS is taking a long time to import it into a mapset.

#2 Updated by Maxim Dubinin about 14 years ago

any chance to see the proof for "slivers"?

here is mine that's something is wrong and artifacts appear where they should not.

on the picture, overlaid is red - 'sliver' resulting after QGIS dissolve and initial nodes:
http://gis-lab.info/images/screenshots/20101030-722-7kb.jpg

#3 Updated by Giovanni Manghi about 14 years ago

Replying to [comment:2 gislab]:

any chance to see the proof for "slivers"?

this question is a reply to me?

if yes, just import your vector into grass.

Then my question stands, in a vector such this, with already topology problems, do you expect the dissolve tool of qgis to fix them?

#4 Updated by Maxim Dubinin about 14 years ago

I don't have grass.

Did you check out my picture above?

Here is more, if you convert source polygons to nodes and add XY and compare it with the result of the dissolve, you will see that some of the adjacent nodes that do not get dissolved have EXACTLY the same coords.

Please see one more picture: http://gis-lab.info/images/screenshots/20101031-d76-34kb.jpg

#5 Updated by Giovanni Manghi about 14 years ago

  • Status changed from Open to Closed
  • Resolution set to invalid

Replying to [comment:4 gislab]:

I don't have grass.

Ok. Try Install it and import your vector, you'll see that the it is really unclean in origin, for this reason you cannot expect that the dissolve tool to fix the slivers (because is not its function), nor you can expect a clean dissolve of the vector because as is clear, it is not topologically correct.

After importing it in GRASS you'll have the original vector in 3 layers: the correct polygons, the slivers/holes, and the overlapping areas.

I'll attach them all to this ticket.

If you want to do a dissolve of your vector you'll have to:

import it in GRASS, apply one or more v.clean modules in order to remove slivers and then export it.

#6 Updated by Maxim Dubinin about 14 years ago

Thank you for your time, but I didn't ask about GRASS.

I asked why dissolve isn't working correctly in QGIS and gave two pieces of evidence that something is wrong. Did you have a look at the pictures above?

Picture 1 showed that the hole after dissolve do not match the input nodes.
Picture 2 showed that the nodes with matching coords did not get dissolved.

I will try to isolate the case more clearly, but please, don't close my tickets only because there is some software somewhere, which can help me out. As I said in the very beginning, dissolving the same data in Arcview worked without ANY problems.

Thanks.

#7 Updated by Giovanni Manghi about 14 years ago

  • Status changed from Closed to Feedback
  • Resolution deleted (invalid)

I may have misunderstand the problem, but you can always reopen the ticket ;)

Back to the beginning: I'm just saying that I cannot see any reason why the dissolve tool should fill the holes that are in your vector.

Do you think that the dissolve tool should work in a different way?

#8 Updated by Maxim Dubinin about 14 years ago

ok, problem 1: extra holes

1. Download isolated sample, http://gis-lab.info/share/1.zip
2. Dissolve in fTools by FED_OKR, not a sliver in the result
3. Convert sample to nodes
4. Overlay nodes over dissolved

problem 2: same points do not get dissolved

1. Add XYs to point layer
2. Take identify tool and click on any of the pairs of points, note that the coordinates are the same (at least that's what my identify says)

#9 Updated by Maxim Dubinin about 14 years ago

damn breaks, sorry :( and I meant "note" not "not" in problem 1, point 2.

#10 Updated by Giovanni Manghi about 14 years ago

  • Status changed from Feedback to Closed
  • Resolution set to invalid

Hi gislab,
here the following.

The vector "1.zip" is topologically unclean, no way you can change/correct this in QGIS right now. It would be nice to have a tool for it, this is because I'll add to this ticket Carson, and eventually (if you agree) we can change the summary and the description to something such "add a tool to correct topology". I would suggest to open a new ticket, but if you feel I'm wrong just reopen this one.

The situation is the following:

AFAIK dissolve is made by GEOS and at least by default it does nothing (while dissolving) to correct problems like slivers/overlapping areas. So in any case is NOT a QGIS problem.

You say that the same operation under Arc* gives you a clean vector, so it would be very interesting if you can attach the vector obtained trough the dissolve with arc* to give it a look.

One more time: you vector is unclean and nor GEOS nor QGIS can do a lot for this (QGIS for sure, GEOS probably not). Actually this is the typical case we use to show how to clean vectors by using GRASS.

Import the vector in GRASS, take the "1_polygon" layer (the one with the correct polygons) and then apply the v.clean module with the "*rmarea*" option. This way it will eliminate all the slivers.

And actually this will work just fine with the vectors you posted, without having to leave QGIS, just use the GRASS plugin.

#11 Updated by Giovanni Manghi about 14 years ago

Nevertheless I agree that at least QGIS should warn that the attached polygon (1.zip) does have geometry errors. Actually if you toggle editing and select the nodes with the node tool it tells (in the lower left corner) "0 geometry error(s) found".

#12 Updated by Maxim Dubinin about 14 years ago

I sensed that this could be GEOS issue (see very first post).
I've attached a result of dissolve in plain old Arcview using Geoprocessing Dissolve with no extra tricks, no problem at all (note that Arcview is not topological GIS).

http://gis-lab.info/data/samples/adjacent-unclean-polygons-dissolve-arcview.7z

I will try to figure out what exactly is wrong as I'm still not positive on exact reason. 'Topologically unclean' sounds rather vague and suspicious to me, I'll keep looking ;)

#13 Updated by dr - about 14 years ago

It seems that Arcview use a tolerance during geometry union operations. See also #3184

#14 Updated by Giovanni Manghi about 14 years ago

Replying to [comment:13 dr]:

It seems that Arcview use a tolerance during geometry union operations. See also #3184

so my guess is confirmed. Is GEOS capable of using a tolerance during dissolve operations? If yes it would be nice to have an option available in the ftools dissolve tool.

#15 Updated by cfarmer - about 14 years ago

From a relatively quick Googling around, it appears as though GEOS does not employ any sort of tolerance when performing unions (which is what dissolve uses). There was some talk about snap-rounding to fix some issues with slivers, but this isn't really a sure-fire fix. One way around these sorts of issues (similar to snap-rounding) could be to simply round off the geometry coordinates at some level. This would likely reduce the number of high-precision slivers, but wouldn't get ride of all of them, and might not be great in cases where a high level of precision is needed (i.e. the distortion might be too large).

Carson

#16 Updated by Sandro Santilli over 13 years ago

GEOS only employs snaprounding IFF w/out it it could not properly node the input, so it's a fallback rather than a feature. The approach is to keep as much precision as possible during union operations.

Starting with GEOS-3.3.0 an entry point for snapping is available in the C-Api.
Not sure it's needed as Qgis might be perfectly capable of doing the snapping part itself.

I guess it might make sense to expose an option in the qgis gui to do some snapping/renoding before running an union.

Mind you: this is not a bug, as the vertices of those slivers are most likely not exactly the same, altought they might look like identical when converted from binary to decimal representation.

Also available in: Atom PDF