Sliver holes remain after dissolve

[gislab]

1. Open shapefile

​http://gis-lab.info/forum/download/file.php?id=1794[[BR]]

2. Vector\Geoprocessing\Dissolve
   

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

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

The same dissolve in Arcview works flawlessly.

[lutra]

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.

[gislab]

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

[lutra]

Replying to 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?

[gislab]

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

[lutra]

Replying to 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.

[gislab]

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.

[lutra]

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?

[gislab]

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)

[gislab]

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

[lutra]

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.

[lutra]

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

[gislab]

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

[dr]

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

[lutra]

Replying to 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.

[cfarmer]

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

[strk]

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.