In this workspace, the results of AreaOnAreaOverlayer (using the default tolerance) and SpatialRelator (using a custom DE-9IM matrix) are different. I suspect it's a precision issue with the AreaOnAreaOverlayer transformer but it's curious that the transformer that doesn't allow changing the tolerance (SpatialRelator) is the one that works fine.
Hi @Jorge Rosales
I downloaded your Workspace and checked the configurations.
In the FME Viewer the result is perfect for overlaps:
So, in transformer Tester - configuration:
Thanks in Advance,
Danilo
Hi @Jorge Rosales
I downloaded your Workspace and checked the configurations.
In the FME Viewer the result is perfect for overlaps:
So, in transformer Tester - configuration:
Thanks in Advance,
Danilo
Hi @danilo_fme if two polygons overlap then _overlaps is greater than one in the common part.
According to AreaOnAreaOverlayer the two polygons don't overlap, but according to SpatialFilter (which I think uses more significant decimal places internally) they do.
@Jorge Rosales The primary difference between AreaOnAreaOverlayer and SpatialRelator is that AOnAO uses a tolerance for vertex comparisons and SpatialRelator does not. the calculated tolerance is usually very small and is reported in the log, in this case:
AreaOnAreaOverlayer (OverlayFactory): Overlaying with an automatic tolerance of 6.464405381000011e-9
but enough to match the vertices.
If you round the area coordinates (i.e. CoordinateRounder 5 decimals) then the results are similar.
@Jorge Rosales The primary difference between AreaOnAreaOverlayer and SpatialRelator is that AOnAO uses a tolerance for vertex comparisons and SpatialRelator does not. the calculated tolerance is usually very small and is reported in the log, in this case:
AreaOnAreaOverlayer (OverlayFactory): Overlaying with an automatic tolerance of 6.464405381000011e-9
but enough to match the vertices.
If you round the area coordinates (i.e. CoordinateRounder 5 decimals) then the results are similar.
@Mark Stoakes , is what I suspected, but it would be more consistent if the results of both transformers were the same using the AOnAO smaller tolerance.
@Mark Stoakes , is what I suspected, but it would be more consistent if the results of both transformers were the same using the AOnAO smaller tolerance.
@Jorge Rosales It is confusing. There are good reasons that SpatialRelator and SpatialFilter cannot use a tolerance. One is that OGC specs do not support a tolerance. Consider a point that is in tolerance of a line, but not quite on the line. Is that now inside, outside or on the line depending on whether the predicate you select is intersects, touches, contains/within? It's pretty tricky...
AreaOnAreaOverlayer is a little simpler since it only handles areas
@Mark Stoakes , is what I suspected, but it would be more consistent if the results of both transformers were the same using the AOnAO smaller tolerance.
@Mark Stoakes Yes, I agree that it is not a good idea to include a tolerance parameter in the SpatialRelator and SpatialFilter transformers. In my case the problem was that I ruled out the existence of overlaps using the AOAO (automatic tolerance) and then using the SpatialFilter I got unexpected results because for the SpatialFilter there were overlaps. In any case, as you mentioned, one solution is to round the coordinates to a few decimal places at the beginning.