So I believe you are correct that the LineOnAreaOverlayer is the source of the message. If I understand correctly, it means that there is a very complicated geometry operation going on that cannot be resolved, and so we output this - unfortunately vague - message.

This blog post will explain in general what is happening. The section that starts off "Tolerance and Ignorance" in particular highlights the problem. Basically lines are being intersected at a microscopic level, in an iterative process, and suddenly you have got 6463 intersections whereas the previous iteration only had 1 intersection.

Unfortunately I can't really say what state the data will be in. I don't know if it reverts back to the one intersection, or keeps the 6463 intersections; and I can't say if it carried on to completion or just decided to stop at that point. You are correct it probably won't apply to all features, probably just to the overlay of 2 of them. But, again, I don't know what the state of those other features would be (whether they got intersected properly or whether the process gave up before getting that far).

But, fortunately, in FME 2018 we now have new settings for tolerance in transformers like this. As that blog post explains, the solution to that sort of problems is an automated tolerance setting (we call it Anchored Vertex Adjustment) that resolves all of the issues around that massive number of intersections.

So, if you can upgrade to 2018, then set tolerance to Automatic in the LineOnAreaOverlayer and you will not get that error message (I'm 99.999% sure) and the data will be processed correctly.

If you can't upgrade to FME2018, then it's trickier to suggest a solution. One thing to try would be a CoordinateRounder (round all your coordinates to whatever you know your data accuracy to be, say 3 or 4 decimal places) and try the overlay again.

Another potential solution would be to use a Snapper to snap tiny gaps between features. Again use a snapping value of what you know your data accuracy to be.

But as that blog post says, these are not very elegant solutions. They can solve one problem but create another, unless you iterate through the data again and again. The best way to resolve this is to upgrade to FME2018. It's got newer capabilities and will produce a much better result - probably quicker too!

I used to encounter this fairly frequently with an areaonarea overlayer and ignored it without any obvious consequence for a couple of years, however i was never actually keeping the geometries produced by that transformer, just calculating overlapping areas - ymmw

Hi @Mark2AtSafe and @egomm,

Thanks for the replies; I suspected that asking about this would only serve to increase the fuzziness of the state of the calculation process; and consequently my decision about whether to rely on the results.

Mark, I will look at the blog post and some on the mitigation strategies that you have suggested. (Due to corporate software repackaging and deploy I may be with 2015 for some time, it is a shame as the new vertex adjustment tolerance settings sound great.)

Egomm, I had also previousy seen this behaviour with AreaOnArea as well, I think I ignored it or downsampled the data to mitigate the matter, in this case however I can't do the same.

Thanks for the advice,

Rob

I frequently face this issue with the AreaAmalgamator even in FME 2019.0. Generally I get it solved by adding a CoordinateRounder in front. When I am in meters I use just 1 decimal and it is good enough for my data. I wonder though why Safe didn't add a tolerance option to the AreaAmalgamator.