I tried a slightly modified version of Safe's example of how to use the shortestpathfinder. I found that when I used two 'From- to' inputs that were identical, that there were no problems but when I slightly modified the coordinates, it would only accept one of the two. This was resolved by cranking up the From-to network snapping but I don't know if that's an option for you.

If you modified the coordinates then it makes sense that they would no longer route if they weren't snapped to the network.

I send the exact same line in on it's own and a shortest path is found. If i send the exact same line in with 1679 other lines, the original line exits the no path port.

I managed to isolate the two routes that were 'conflicting', the features were adjacent to each other in the order they entered the transformer

The end point of one was the start point of the second.

Setting the Allow U-Turns parameter to 'No' and keeping the original order resulted in one feature from the shortest path port and one feature from the no route port.

Setting the Allow U-Turns parameter to 'No' but reversing the order of the from-to lines entering the transformer resulted in both shortest paths being generated

Setting the Allow U-Turns parameter to 'Yes' resulted in both shortest paths being generated irrespective of order

I've not been able to create the same issue with a simpler network that i can share unfortunately but it looks like the process for determining u turns is not considering a from-to line in isolation?

Hi @egomm I've reproduced the problem and have now filed FMEENGINE-61035. If two From-To lines are in feature order AND the last vertex of the first is the same as the first vertex of the second AND the paths that would be created overlap where the lines meet AND U-turns are not allowed THEN the second From-To line comes out of the NoPath port. I think you've accidentally found a needle in a haystack. ;)

Thanks, just trying to work out how best to do a test so these features never appear alongside each other as an interim measure.

Ended up putting the no route through a second shortest path finder.

Arrggghhh - found another needle. Shortest path is not always the shortest path. Different shortest paths are obtained when a feature is fed through in isolation. Suspect it's the same issue but somewhat harder to identify and resolve

Hi @ebygomm Please send us another repro if you can. Thanks!

I'll see what I can do

This problem (FMEENGINE-61035) is now fixed in the latest FME 2020 betas.