Spatial join one to many - keep all target features

You have some other options than SpatialRelator. Perhaps try the PointOnAreaOverlayer, which gives you both outputs with all attributes and _overlaps attribute that represents the count

Another way is to use workflow transformers by having the Parcels reader (initiator) going into a FeatureReader that has the dataset for Addresses (result). Make use of the Spatial Filter (imitator OGC intersects result) in the constraints section. For the output, you can specify results only for the accumulation mode

Hi ​@bmoody81 ,

I suspect that the Tester setting could cause the unexpected result.

whether or not one of the joined fields from address points has a value

Instead of the current criteria above, try filtering features simply based on if the number of related supplier features is 1 or more, as in: 0 < _related_supplires.

Thanks ​@takashi.  I tested your suggestion but got an identical result as my previous tester configuration.  I took a closer look at my ArcGIS GIS spatial join and my output has around 3,500 parcels that did not join to an address (join_count = 0).  The Tester in FME has 24K+ that failed.  This makes me think that something may be misconfigured within the Relator.  

Based on the result I’m looking for, do you see any adjustments that could be made on the Relator?  

 

Thanks ​@j.botterill I tried using the FeatureReader but it was running extremely slow.  I got through about 5% of the data in the course of 1.5 hours.  Not sure if I have this configured correctly.  Any advice is appeciated

 

I think your SpatialReletor parameters setting is correct. 

Can you check if the parcel layer and the address point layer have an identical coordinate system?

Can you modify and run the workspace like this to check if address points intersect with the parcels failed from the Tester?

I would second the suggestion on checking the coordinate systems and also the comment about trying the PointOnAreaOverlayer as an alternative. The SpatialRelator and SpatialFilter should also behave in the same way so I don’t expect a difference there but it would just be interesting to see if there is a difference.

You’re definitely at the point where you need to look into the data in the workflow i.e., check the data coming in from the input feature types (again coordinate system is important here) The background map in the inspector if turned on will automatically reproject the data to fit - FME transformers usually do not check the coordinate system.  

If the workflow from Takashi doesn’t give you any more hints the PointOnAreaOverlayer could help debugging here because it can also output the points as well as the areas - in this case you can also check which points did and did not overlap.