Calculating area of overlap for one feature layer against another, and filtering based on percentage of overlap.

There are quite a few strategies for using AreaOnAreaOverlayer to test the overlap of A vs B.  One more common method I would use is to first find an A.ID vs B.ID table using NeighborFinder, and then restrict AreaOnAreaOverlayer to just these pairs using the Group By Parameter.  This will stop it attempting to test geometries in Table A against other geometries in Table A and creating Eg. thousands….millions etc. of slivers.

However, I’m going to put a left-field solution up though which is a Spatial SQL based solution that can be high-performing and maybe easier sometimes to translate existing SQL into FME.

What we can do is create a temporary Spatialite Database in-workspace, and run SQL against this.  The first bit is a bit clunky, in needing to generate a temporary FME file name and joining that to the records to use FeatureWriter to create a temporary Spatialite Database, but after that we can run SQL against this to mimic the original PostGIS syntax.

The ST_DWithin() part of the clause is a bit funny, in that the second part of the clause that uses ST_Intersection() will only evaluate to True if Distance is = 0………..not 100 metres.  So instead below I’ve just used ST_Intersects() as the test rather than ST_DWithin().

Within the SQLExecutor then is a replica of the original PostGIS SQL, although as above, used ST_Intersects() rather than ST_DWithin().  I think the original author was worried about coordinate rounding errors for triggering the spatial index so was using ST_DWithin() as a kind of buffer to make sure the spatial index in PostGIS picked up all possible intersecting candidates, but in Spatialite, its spatial index already has a degree of buffering in it to handle these edge cases so we don’t need to use that strategy.

SELECT A.A_ID, B.B_ID
FROM A,B
WHERE ST_Intersects(A.geometry,B.geometry)
AND ST_Area(ST_Intersection(A.geometry, B.geometry))/ST_Area(B.geometry)<0.1

--Queries in Spatialite do not automatically make use of the Spatial R*Tree Indices when call Eg. ST_Intersects()
--They must be manually used within the query to optimise query speed
--Spatialite uses a programmatic wrapper object called "SpatialIndex" that allows easier search
--through the separate spatial index tables.

--To limit which rows of A will be compared with which rows from B
--Specify the name of the table to search its spatial index "f_table_name"
--and specify what geometry to test if it interesects the spatial index row within "search_frame"

--The best way is to use the table that has the most geometries that already have their Minimum Bounding Rectangles (MBR)
--Pre-indexed, which is Table A.
--We will ask which rows from A have Minimum Bounding Rectangles that interesect with the Minimum Boundaring Rectangles of B
--which is what happens by specifying B geometries as the Search Frame.  Spatialite will convert the more complex B geometries
--to an MBR Search Box "Frame"

--Spatial Index lookup then takes the form of, for any Row of A being tested in the WHERE, check if its spatially indexed MBR is
--is intersected by any MBR of B.  Note that can use any geometry expression "search_frame" including buffering to get an equivalent
--"Within a certain distance" spatial index search.  Eg. search_frame = ST_Buffer(ST_Envelope(B.Geometry),100) would create an enveloping
--box from the B geometries to turn a complex geometry into a simple one, and then buffer this box by 100 distance units
--This is the equivalent of using a spatial index to check if Within 100 metres

AND A.ROWID IN (
    SELECT ROWID 
    FROM SpatialIndex
    WHERE f_table_name = 'A' 
        AND search_frame = B.geometry)