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.
Best answer by markatsafe
View original
+30
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.
+2
@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.
+2
@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.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
