Change detection - how to measure geometry change between original and revised

Interesting challenge!

One thing to watch out for when using the area-method, is that there is a possibility that the vertices have changed position in such a way that the area does not change, or changes minimally. That is usually an exception, but I’ve seen it happen. So calculating area alone is not something I would rely on.

Another approach might be to explode all the vertices into separate points, then compare those (using Group By on the polygon ID). There should be at least one or two that do not match, so then you know where the change has happened.

But I think I’d start experimenting with either the Clipper or the AreaOnAreaOverlayer. Of course it depends on why and how you need to know where a change has happened as well. Different methods have different advantages (the point-method would be good for reporting visually, the area-method would be better for subsequent calculations I think - but it really depends on what the underlying information request is...).

Interested to see what others come up with :-)

I’ve had this discussion with a client a while ago regarding 2 datasets containing buildings that have some interesting differences. 

Dataset A shows the building footprint (i.e. the part touching the ground), dataset B shows the top-down view (so including overhanging balconies and stuff). They have to be within a certain tolerance of eachother.

We started by comparing the difference in area, if it was more than x% different we would flag it for human checking, if it was lower than that we’d look at the individual points. If the closest B neighbor to a point in A was more than y cm away we would again flag it as an error. This was not helped by the fact B might have unnecessary extra vertices.

When I’ve encountered similar problems before and I’ve found that the coordinates have a different number of decimal places. Resolving that gave me the expected outputs

That is frequently a cause for geometries flagged as different, very true. A lot of software store all the decimals they can calculate in the database - which is very tricky, takes up too much space, and can give a very false sense of accuracy to people who do not know about accuracy, reliability and precision of measured coordinates.

However: With Vector Tolerance set to 1.5 (as seen in the screenshot of the OP) I’d expect that to not be flagged by FME. If it is, I’d consider that a bug.

I think I previously had the tolerance set to the default of 0 and that was the cause of the numerous geometries changes being detected. Now set to 1.5metres these

have gone away. 

Nevertheless, I still wonder why the list > attributeName element geometryObject provide no detailed information about the coordinate/precision change

I think the problem there is how. How would you report on geometry changes in a text-attribute?

I can think of several ways, but none of them are very clear. The clearest would be to overlay both geometries, because then the human eye would see fairly quickly what has changed. But “a slice cut off on the East side” doesn’t really cut it imho (OK, I’m exaggerating a bit here to get a point across 😉). Even a list of vertices that differ between the 2 geometries, however accurate and precise, still does not tell you exactly what has changed - although that would be my favorite, because that should allow you to spot differences caused by decimal places far quicker. The biggest problem there is that I sometimes have to deal with incredibly complex geometries, which could make the list extremely long. And how do you differentiate in such a list between the outer polygon and islands inside, or even islands inside islands? It may even need a warning that adding those lists can slow down your workspace because of the amount of data generated. So the how-part of this is the trickiest, I think. But maybe someone from Safe could shed some light on this? Is it worth filing an idea, even? I would support that, actually.

 Hi ​@j.botterill, the detailed change list currently only outputs a binary flag for geometry changes. It doesn't populate the original and revised values the way it does for attribute changes.
The workaround is to compute that change with other transformers, as suggested in the thread so far. In addition to the great suggestions so far, the HausdorffDistanceCalculator built by ​@redgeographics on FME Hub, is worth exploring for measuring vertex displacement. Just note it compares vertex positions, so extra vertices added along an otherwise unchanged edge can register a distance even where the shape hasn't moved.
We don't currently have anything in the works so far, but I think it's definitely worth submitting an FME Idea to quantify specific geometric changes. As ​@s.jager mentioned, it may be tricky to implement for complex geometry changes, but hopefully the Idea gets the ball rolling and invites more suggestions from the community for our developers to investigate further and prioritize.