I have a polygon dataset, which amongst other things needs to have the coordinates of its vertices rounded to a centimeter. It seems that CoordinateRounder is not topology-aware, so I end up having self-intersections, which I cannot (completely) repair afterwards.
I'm new to FME, so maybe I am missing something here?
+11Hi @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)
@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.
+2That'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;
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.
The ArcSDEGridSnapper may be worth looking at
ArcSDEGridSnapper has been deprecated starting FME 2020
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.
@riverag If you're able to attach a sample dataset I'm sure members of the community would try and give you a solution.
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.
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.
