PointOnAreaOverlayer error - extra point returned

I cannot find a way to attach files to my posting.

@gcarmich if you send your sample data to mark at safe.com I'll attach it to this post

Mark, I just emailed the two files to you. Thank you for reposting for me.

@gcarmich PointOnAreaOverlayer returns all Input Points, and all Input Areas, and not just the ones that spatially intersect with each other.

In the cases of Ouput Points appearing outside the Circle Area, it is likely in this case that the Overlap Count Attribute = 0 ie. It did not overlap on the Input Area.

The "_overlaps" value was equal to 1 for this point outside the circle. It is also the last value in the list if that means anything

@gcarmich I've attached the example workspace Gilbert sent me: pointonoverlayererror.fmw There is indeed a problem where PointOnAreaOverlayer is picking up a point, if the point sits exactly on the corner of the bounding of the area feature.

Shifting the grid or changing the circle radius very slightly eliminates the problem. So I'd suspect it's something we do with calculating the spatial index for the areas. We'll get our geometry team to look at it.

The interesting thing about this bug is that it provides insight as to how spatial comparisons are made with spatial indices, and in this case how PointOnAreaOverlayer creates and uses a spatial index.

Some will be aware that determining if a spatial relationship is True or False is typically a 4 step process to create and use a Spatial Index to provide very fast spatial performance and calculations:

1. First create simplified, Minimum Bounding Rectangles (MBRs) out of the input geometries
2. Take the the Minimum X, Minimum Y, Maximum X and Maximum Y of these MBRs, and create a spatial lookup index of these Eg. In an R*Tree index
3. Lookup up whether the MBR X and Y bounds fall within any other geometry MBR X and Y bounds and create a list/array of geometries that meet this condition as the "preliminary" TRUE result
4. Then out of this much smaller list of geometries that possibly meet the Spatial condition, test the Spatial condition against the actual geometry shapes, which are typically much more complex and processor intensive to spatially compare to each other, and hence why the initial filtering by simplified MBRs makes this so much faster than just starting naively with trying to compare all complex geometries against all other geometries.

What could be speculated here is that the Point is correctly picked up in Steps 1-3 in testing its MBR (which is just the Point itself) against the Circle's MBR, and goes onto the list for final testing of the real geometries with an initial Intersection condition value set to TRUE, but in the next step rather than processing all Point geometries where the X and Y is <= and >= the Circle MBR coordinate boundaries, instead it is only passing through Point geometries where the X and Y is < and > the Circle MBR bounds, and missing the final processing step where the Point Coordinates happen to be precisely = to both the X and Y bound of the circle object and not further refining the preliminary value of TRUE that was given to the spatial intersection of the MBRs