Skip to main content
Question

Dissolver does not merge geometries

  • September 26, 2016
  • 9 replies
  • 57 views

Forum|alt.badge.img

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?

9 replies

itay
Supporter
Forum|alt.badge.img+17
  • Supporter
  • September 26, 2016

Hi @ejmpost, your Test_dis.shp contains two features, remove the smaller one and youll get the result you are searching for.


Forum|alt.badge.img
  • Author
  • September 26, 2016
itay wrote:

Hi @ejmpost, your Test_dis.shp contains two features, remove the smaller one and youll get the result you are searching for.

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.

 

 


david_r
Celebrity
  • September 26, 2016

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.


whkarto
Contributor
Forum|alt.badge.img+14
  • Contributor
  • September 26, 2016

A good way to deal with this kind of problems is introducing a CoordinateRounder right before the Dissolver.


itay
Supporter
Forum|alt.badge.img+17
  • Supporter
  • September 26, 2016
ejmpost wrote:
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.

 

 

Ha ok now I understand your question, the dissolver works perfectly on features with common boundaries, your features dont share common boundaries.

 

If you apply a rounding to the coordinates (2 decimals) then you can get the two Test_dis features dissolved into 1.

 

 


david_r
Celebrity
  • September 26, 2016
whkarto wrote:

A good way to deal with this kind of problems is introducing a CoordinateRounder right before the Dissolver.

I agree in principle, but there is a risk that the CoordinateRounder will round the "wrong way" in some edge cases.

 


mark2atsafe
Safer
Forum|alt.badge.img+49
  • Safer
  • September 26, 2016

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


Forum|alt.badge.img
  • Author
  • September 27, 2016

The coordinaterounder did the job in this case. Snapper resulted in a geometry which was chaged too much.


Forum|alt.badge.img
  • Author
  • September 27, 2016
itay wrote:

Hi @ejmpost, your Test_dis.shp contains two features, remove the smaller one and youll get the result you are searching for.

Thanks Itay, helpfull as always ;)

 

 


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings