In the attachenent a situation of two geometries. I want to dissolve them to one with no innerlines based on the same id. So it must be one bif smooth geomtetry. This is not working with the dissolver or topologybuilder. I also tries using areabuilder and aggregator. Does anyone has a solution?
Question
Dissolver does not merge geometries
This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.
+18- Supporter
Hi @ejmpost, your Test_dis.shp contains two features, remove the smaller one and youll get the result you are searching for.
Hi @ejmpost, your Test_dis.shp contains two features, remove the smaller one and youll get the result you are searching for.
The problem is probably related to floating point (in)accuracy (more here), making FME think that there are tiny sub-millimeter gaps between the two geometries.
You can fix it by introducing a Snapper before the Dissolver with a small tolerance, e.g. 0.0001, type Vertex or Segment snapping.
+14- Contributor
A good way to deal with this kind of problems is introducing a CoordinateRounder right before the Dissolver.
+18- Supporter
Hi itay,thanks for the reply. Indeed, there are two features. But the smaller one needs te be added to the bigger one or the other way around. It must become one polygon. When I delete the smaller one I get a hole between other (not in the dataset included) features.
If you apply a rounding to the coordinates (2 decimals) then you can get the two Test_dis features dissolved into 1.
A good way to deal with this kind of problems is introducing a CoordinateRounder right before the Dissolver.
+59- Safer
A few thoughts.
Yes, I suspect the same, that floating point conversion makes the coordinates not match up exactly. Lest folk get worried about this, in general:
- This sort of thing only occurs where data is stored as integers meant to represent floating points (as Shape does). The same site David quotes explains why this is not a good idea.
- It (integer storage) is not usually an issue even then, unless you try to compare the coordinates (eg ChangeDetector) with a format stored in native floating point.
- This is an issue here because although the edges of these polygons line up, the actual vertices don't. That (and other reasons) is why it's best practice for polygons that are supposed to align, to have the same set of vertices. If they did here, it would work fine.
The filename you have suggests that you ran this in QGIS and it dissolved the data. Presumably that's because QGIS is automatically rounding your data to avoid this problem (or it is doing all its work using integers, which doesn't bear thinking about). FME is purposely NOT rounding your data (because we instinctively don't like to change your coordinates) and so throws up some rare oddities like this.
So, two solutions have been suggested: rounding or snapping.
I would go with rounding when you have vertices that are supposed to match but don't. eg you read two "identical" features, one from Shape, one from DWG, and they don't give the same coordinates.
I wouldn't use rounding here because you are trying to match line segments. I can visualize it in my mind, but it's hard to explain. Basically you're rounding the end points of a line, and there's no guarantee that the middle of that line will pass through an X/Y with the same precision that you've rounded the ends to. Therefore an adjacent (but differently verticed) line is not guaranteed to match.
I can draw a diagram if necessary. Let me know.
Snapping is better. Snapping may deform the line (eg a line that was straight now has a kink in it - something else I'd have to diagram to fully explain) but the edge pieces will now be a match.
I've long wondered if FME should have an option to set the number of decimal places it works to in all the transformers. That way most of these issues would be avoided I think. Please do file an 'idea' on this site if you agree. But still, most of this answer was to assure you that these oddities are rare
The coordinaterounder did the job in this case. Snapper resulted in a geometry which was chaged too much.
Hi @ejmpost, your Test_dis.shp contains two features, remove the smaller one and youll get the result you are searching for.