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.

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

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.