Cannot transfer between stops at exactly the same location

[Flix-Ita]

Dear all,

We noted an incorrect and strange behaviour of OTP when trying to organize an itinerary linking different trips based on different GTFS feeds..

This incorrect behaviour was for each single trip the need of an offset between the starting and ending point with respect to their correct values, and inability to link a sequnece of trips in a unique itinerary.
The problem disappeared when all routes, trips, etc. were set in an unique GTFS feed

It is surprising that the OTP can not give the itinerary consisting of sequence of trips taken from several GTFS feeds. Is it possible to make the OTP work with several GTFS feeds at the same time? Is any people faced with the same problem ?

All the data is uploaded here: https://groups.google.com/forum/#!topic/opentripplanner-dev/Fa4FMn5gQng

Thank you very much.
Flix

[abyrd]

Hello, OTP is regularly used with large numbers of GTFS feeds in a single graph, and I have never encountered this problem so it is certainly possible to use several feeds at once.

Please clarify what you mean by "need of an offset between the starting and ending point with respect to their correct values".

Note to anyone debugging this: Links to all input data have been provided on the opentripplanner-dev mailing list in a message on 30 November 2016.

[Flix-Ita]

We defined a sequence of routes, the next starting at the same position of the end of the previous, to be able to compose a unique path starting from the first and ending to the last.

If we compile in OTP different GTFS feeds, each one for one route, it happens as follows:
for each single route - to help OTP to find the route (otherwise it doesn't find it) we have to move input and output position a little out from the small circles in the map indicating the real starting and ending node.
for a path linking several routes together - OTP doesn't find any solution, no matter how we try to move starting or ending position.

If a single GTFS feed, containing the same sequence of routes, is compiled in OTP all previous problems disappear.
However the best thing is to try our GTFS files uploaded at https://groups.google.com/forum/#!topic/opentripplanner-dev/Fa4FMn5gQng

[barslett]

To me, this seems connected to the fact (bug?) that it is impossible to create an itinerary that includes two stops with identical coordinates. We have had this problem because of poor data quality for a number of railway stations, where different platforms had been assigned the exact same coordinates. This caused long detours in itineraries to avoid changing trains on these stations.

In your case, it sounds like you have the same pattern of redundant stops, generated for the different GTFS feeds?

[gmenga1]

In a first experiment ending point of one route and starting point of the next were (erroneously for us) sligtly different. Even then OTP didn't work. We thought that that difference was the responsible.
We rebuid the routes with identical contiguous starting and ending points. With separate GTFS feeds OTP was still not working.
But, then, how do you explain that when the same routes where included in a unique GTFS feed OTP worked correctly?

[abyrd]

@barslett thanks for the insight, that does indeed sound like it could be related. If the two stops are very close together, it's possible that the code that connects them to the street network is re-using the same vertex in the street network to connect both of them. This would mean paths using a transfer between those two stops would have two stop-to-street link edges in a row, which are generally forbidden: https://github.com/opentripplanner/OpenTripPlanner/blob/master/src/main/java/org/opentripplanner/routing/edgetype/StreetTransitLink.java#L87

That certainly seems like it could cause this bug. I'm now trying to figure out whether this prohibition is outdated and should just be removed. Are there still any structures in the graph where sequences of multiple StreetTransitLinks would allow shortcuts around the street network?

[gmenga1]

I really don't know what does the underlying Street map, and how it interacts with the GTFS feeds.
Exactly to avoid such unknow interaction that we joined directly our GTFS routes.
Nevertheless, it is curious that putting all routes in one feed OTP works fine.
There is something unclear (may not be a bug, but certaintly an unwanted behaviour) .
Nothing bad of putting all routes in one feed, but then the file is difficult to manage when the dimension grows. May I ask you to test our GTFS feeds?

[abyrd]

Realistically I will not have time to look into this for several days, but of course we want to see these bugs resolved, both those reported by @gmenga1 and @Flix-Ita and the one mentioned by @barslett. If by "joined directly" you mean that you put the same stops in exactly the same locations in multiple feeds, because of this bug your attempt in fact backfired. I am guessing that if you put the stops farther apart in multiple feeds it will work.

[gmenga1]

We will try to separate the starting points of each route from ending points of the previous, and we will let you know the results. However I'm wondering of what will do OTP/OSM in trying to connect the two links. It can be generated an unwanted (random) transit time in the connection.
We are making a high level planning system for multimodality, so we want to model only macroscopic events. the transfers will be represented by only default transfer times.

[abyrd]

Several of us at Conveyal just discussed this ticket at our routing meeting yesterday. The concern in the past was that such sequence of two or more StreetTransitLink (STL) edges was being used as a shortcut around the street network, but we were unable to come up with a reason a single transit stop would be connected to multiple street network edges, so it's not clear how a sequence of multiple STL edges would be encountered except in the completely valid case described in this ticket (walking from one stop to the another one very close to it). That is to say, with current graph topology, a sequence of two STL edges would always have a street vertex in the middle, not a transit vertex (such a sequence would be used to pass from stop to stop via a street rather than street to street via a stop), so they should be harmless.

I'm not yet ready to remove the no-double-STL-in-paths restriction yet, but as a test could all of you try removing the conditional I linked to above (https://github.com/opentripplanner/OpenTripPlanner/blob/master/src/main/java/org/opentripplanner/routing/edgetype/StreetTransitLink.java#L87) and seeing if this resolves your problem?

[gmenga1]

I thank you very much. We will try your suggestion to remove that condition and we will check.
However, I have a question that is puzzling me: why does OTP work fine putting all route in a unique feed?

[abyrd]

The theory is that when you put them in the same feed, there are no duplicate stops. Route A and B share the same stop, rather than using two separate stops that are linked separately to the street network. The latter produces a different graph topology.

[hannesj]

@abyrd I found an issue if TransitToTaggedStopsModule is used. The stops already linked by that class will be linked again, as the check was removed in the linker rewrite. #2372 should fix that issue.

[gmenga1]

EUREKA the suggestion of @abyrd to comment the restriction of no-double-STL-in-paths had success.
It means that I was able to link in a unique itinerary several routes where the end node of one was coincident with the starting point of the next, and each route was defined in a separate GTFS feed.
Moreover I discovered why, when the points were not coincident, I wasn't able to find any itinerary.
I forgot to say that my OSM network was greatly reduced, so no city roads were present in the graph, but only freeway and truckway between cities. So OTP was unable to find the connection no matter how closed were the contiguous points. Thanks again for the suggestion