HI @daniel, if you need to control the coordinates precision of feature geometries, consider using the CoordinateRounder transformer.

Note: You can specify the number of decimal places of coordinate values using the CoordinateRounder, but it doesn't mean changing the computational precision (i.e. the number of significant digits). Even if you round coordinate values with the transformer, FME still calculates spatial relations by the full precision of 64 bit floating point number.

The AreaOnAreaOverlayer transformer has no tolerance, e.g. FME will report two geometries originating from oracle layers as overlapping whereas determining the overlap within oracle using intersect with 0.005 tolerance would report the overlap as 0

Exactly, this is also the case with e.g. ArcGIS and the tolerance/precision settings defined in the feature classes; FME does not use them.

Hi @takashi and @egomm. Thanks for your responses. I have tried the CoordinateRounder but as you mentioned this does not change the computational precision used in the AreaOnAreaOverlayer. Therefore even if I round the coordinates in both my input layers to 0 decimal places (1 metre precision), after it has gone through the AreaOnAreaOverlayer it still produces a large number of sliver geometries. Does anyone have a workflow suggestion for how a tolerance value can be implemented in a spatial intersection? I've tried using the AnchoredSnapper and Snapper but am having no luck.

@daniel, have you tried "Segment Snapping" for the Snapping Type parameter of the Snapper/AnchoredSnapper?

If tolerance is essential I normally end up going back to Oracle...

Maybe try to buffer both area layers with e.g. -0.001m before sending them trough the AreaOnAreaOverlayer. This makes the areas slightly smaller and therefore eliminating slivers within this 0.001m range at the edges.

Maybe use the CoordinateRounder after the AreaOnAreaOverlayer?

My current process is piping the 2 layers (each for a tracking attribute added) into the AreaOnAreaOverlayer then using a tester to keep areas of overlap (where both tracking attributes = 1). For this work space it is producing about 3700 polygons whereas when I do a spatial intersection for the same two layers using GeoMedia software it produces about 1400 polygons. GeoMedia I know uses a tolerance of 0.0001 metres. @Mark2AtSafe

Using the CoordinateRounder after the AreaOnAreaOverlayer did not reduce the number of polygons when used in combination with the Snapper transformer (using "Segment Snapping" and Snapping Tolerance of 1 metre). When I add another Snapper ("Vertex Snapping") it does reduce the polygon count but only by a couple of hundred. @bakkermans

Using a negative buffer on both layers does reduce the polygon count but again not by a substantial amount. Only if I set each bufferer to minus 1 metre and even then it is still producing more polygons than in GeoMedia which has a tolerance of 0.0001 metres.

My guess is you are creating a lot of very small areas on the outside of the overlapping areas. To loose these you can add a Tester using the test clause @Area() > (your tolerance for minimum area).

@erik_jan

Yes, I have done that in the past - using a tester to remove slivers based on their area. However, I don't think this is an ideal solution. What I want to achieve is the same result as other GIS software or database where a tolerance can be defined for example as @egomm

mentioned in oracle using intersect a tolerance can be set.

We do realize that the "intolerant" nature of our intersections in FME can get us into trouble. A couple ideas @daniel may want to try:

1) The SliverRemover transformer could be used to patch things up after you do the overlay. Though I've not used it myself, I think you'd throw out all the areas that were smaller than whatever your threshold was (via Tester on @Area() ) and then route that into SliverRemover. Again, some playing would be needed. But my understanding is that this should do the trick.

2) The MRFCleaner family of extra-cost transformers (these come from MRF in Calgary) specifically do what you want and allow each layer to have its own tolerance as well. Contact sales@safe.com if you want to evaluate them.

I don't think it is possible to produce exactly the same result in FME. There are lots of steps you can take to improve the results, as mentioned above, but I don't think you'll ever get an identical result.

In the past I've ended up stringing two workbenches together, one which writes the data into oracle, the second which starts with a sql creator which performs the intersection within oracle and continues from there.

Thanks for all the responses @daleatsafe

Cheers. I've sent an email to sales team about MRFCleaner package as this might be the solution I'm looking for.

@egomm

I'll have a look into the SQLcreator although it would be good to have everything done within a single FME workspace. I'm not thinking about just this workspace but a large number of other workspaces in my organization which also use the AreaOnAreaOverlayer transformer at some point in the workflow. In this particular workspace both layers are all ready in Oracle so I tested the spatial intersection with 'mask = anyinteract' and a tolerance of 0.0001 in order to compare with the query result from GeoMedia which also uses a tolerance of 0.0001. This Oracle query returned almost the same number of polygons as GeoMedia - 1451 polygons (Oracle query) vs. 1449 polygons (GeoMedia query).