Hi @riverag​ ,

as far as I now, rounding coordinates it's mostly used for points, when you need less precision (e.g. you have data digitized at 1:1000 scale to be represented at 1:100000 scale) or you need to fit data to a storage type with limit in coordinates representation.

If I understand correctly your use case, you do not need to round the coordinates, but to shorten the lenght of the polygon segments, which leads at least to the deformation of the polygon itself.

Can I ask you why?

Hi,

I actually do need to round the coordinates of the vertices of the polygons. The length of the segments is not important but in special cases the "movement" of the vertices through rounding can destroy topology of the polygons because either segments are very short, or very close to each other (sliver polygons).

The reason for the rounding is a target storage type (which I don't have control over) which only accepts coordinates with limited precision.

@riverag​ Perhaps try Generalizer first, using Thin No Point algorithm and Preserve Shared Boundaries. Then round the coordinates. Preserving the shared boundaries, breaks up the areas and then rebuilds them so you should get topologically correct polygons.

I've attached a small example using data from gadm36.org (FME 2020.2)

Thank you for your reply, I feel like this is a step in the right direction, however the Generalizer seems to create topological problems of its own with my data. As with the CoordinateRounder, I feel like the issue is with "thin" polyongs, not necessarily polygons with neighbouring vertices close-by. Here's a good example (I set tolerance to 0.1 to get a good example). No rounding involved, just the Generalizer.

base_set:

generalized:

failed:passed:

repaired:

ws:

While the topology seems to be repaired in the end, the lost polygon (yellow) is actually very big, it's just that it has a "pointy" end which collapses (self-intersection) in the process.

Did you try an AnchoredSnapper or Snapper?

That's a great suggestion. I have tried the Snapper. I'm not sure how it can prevent the topology from being ruined, but it seems to be a great way to repair the topology after the rounding. However, having tried this with different data and different tolerances, I noticed that sometimes the holes of donut-polygons are wrongfully "filled out" using this method. I am still looking into the reason for this, as it seems an otherwise good way to repair the data.

One thing you can do is to do multiple anchored snappers with different tolerances.

For example;

• First snapper does a small X unit to get everything nearly identical to snap
• Second snapper increases/decreases by X units to get the next portion you need snapped
• Third snapper to get the last little bit snapped

Use your measure tool in the inspector to get an idea of the tolerance you need for each step

Doing it that way will give you a lot of control over how the donuts are handled for the final result.

The ArcSDEGridSnapper may be worth looking at

I don't have this transformer. I assume because I don't have ArcMap.

ArcSDEGridSnapper has been deprecated starting FME 2020

@riverag​ If you're able to attach a sample dataset I'm sure members of the community would try and give you a solution.

I attached some data and the workspace I use. The problem is more visible rounding to precision 2, but the problem appears for precision 3 as well.

It appears that for this dataset and this workspace the Generalizer already damages the topology in some cases. I feel like an approach which takes into account distance between points can always fail, as the self intersections seem to appear between points and lines.

If all segments are longer than the Generalizer distance, nothing will happen to the geometry. The self-intersection after the rounding happens, because a (rounded) point jumps over a line.

@riverag​  Thanks for attaching the sample data. Your great diagram above illustrates why you can't have both - topology and generalization. This is essentially a cartographic problem where you need to exaggerate the thin slivers at the new 'scale'. SherbendGeneralizer might be another option as it does prevent lines crossing as it thins, but in the end I think you'll have to rebuild the topology and accept some topology changes where edges collapse.