The usage notes in the PointonLinerOverlayer says that aggregates are not supported, so this is probably "works as designed".
Splitting the line prior to aggregation is straightforward enough, the trick is then identifying the group by.
I would experiment with PointOnLineOverlayer, a tester for overlaps (separate out the lines that were split from the rest of the dataset), a NetworkTopologyCalculator on the non split lines, and then a SpatialRelator (Touches) with the split lines as the requestor and the results of the NetworkTopologyCalculator as the supplier (merge attributes). That should give every feature an _network_id that can be used as a group by on the Aggregator.
Note that the Aggregator should be fed the output of the SpatialRelator and the output of the NetworkTopologyCalculator.
Thanks jdh.
Alas, although a nice attempt, which may work in other cases, this approach gives me a lot of separate non-clipped "groups", each with their individual id, which is not what I wanted.
The clipped lines needs to define the grouping, the rest just need to follow suit, based on "connectivity".
I ended up solving it with a stored procedure in SQL Server instead, iterating over the non-grouped lines, and performing the "touch" on end nodes excluding the "clipping" ones. The important word here is "iterating", as the network can be quite extensive, needing multiple runs to cover.
But your suggestion did expand my "toolbox", so you get an accept nonetheless :-)
Cheers
As you have a solution now I guess I don't need to answer, but for the record...
Yes, the problem for that transformer is that an aggregate might not be all valid geometry. For example, if you send an aggregate into the PointOnLineOverlayer, that aggregate might be a mix of lines and points and areas and rasters and who knows what else. That's why the input is deaggregated.
Using a path (PathBuilder) will work, but only on lines with no branches, which I suspect is not the case here.
Besides that, I'm stumped. I think jdh's suggestion - trying to identify and reconstruct the appropriate parts of the aggregate - is the only way, even if she didn't quite get what you wanted this time. I think I would purposely deaggregate the data before the overlayer. That way you get a specific part number. Then if a feature is split you will have duplicate part numbers and can use that to figure out what to reconnect.
