Do not re-link stops that were already linked by TransitToTaggedStopsModule

[hannesj]

No description provided.

[novalis]

I'm not really up on the latest state of OTP testing, but would it be possible to have some sort of test for this code?

[abyrd]

@hannesj please supply a description for any pull request, including details of issue it solves or a link to the issue. Issue #2371 which appears above because it references this PR seems to be about a different issue, which happens to reference this PR in a comment.

I see that the message on the commit also says it fixes #2371, but these seem like different issues to me. @hannesj can you give a bit more information? If I merge this commit we may have an inaccurate message in the git log, and the issue would be closed by a possibly unrelated commit.

[hannesj]

@abyrd Sorry for the long delay.

The main issue which this PR solves is, if a stop is already linked by the TransitToTaggedStopsModule, then it would be linked multiple times to the street graph, which would enable shortcuts through the stop nodes. Also, if we already have the correct position form OSM, then it would link the node to a more inferior place in the street graph.

[evansiroky]

With my recent PR of #2817 and improvements to PR #2762 there was some revival of the discussion in #2371, so I decided to look at this PR to see what it might do. This PR makes sense in either the case where the double StreetTransitLink (STL) traversal even for same stops was allowed or with the #2817 implementation. I don't think allowing a double STL traversal to the same stop is a good idea and so I think #2817 is the right way to go. But even with #2817, there will still be duplicate STLs created when the TransitToTaggedStopsModule is enabled. Those duplicate STLs won't cause computational incorrectness, but as noted the street splitting of the stops could result in inferior insertion into OSM. Furthermore, not adding them as proposed here would result in slightly faster queries due to not traversing unneeded edges.

[t2gran]

This PR base was the master branch , so to apply it on the new dev-1.x and dev-2.x branches I had to cherry pick the commit (only 1) onto the target branches. Changing the base did not work, because other commits from the master would then be carried over.

This is the manual cherry-picked commits, witch completes this PR:

• dev-1.x f91a903
• dev-2.x 8a530fc