GTFS-RT extension to add completely new routes

[leonardehrenfried]

Summary

This adds a GTFS-RT extension which allows you to add completely new routes that are unknown before the realtime update arrives.

There is one catch though: the stops do have to be known in advance.

It also allows you to define feeds where the transfer generator doesn't check if a stop is used by a pattern. This is useful when you want to add stops that you can later add realtime-added routes to. Otherwise they would not be linked for transfers.

Unit tests

Added.

Documentation

Autogenerated.

[slvlirnoff]

Do you want to check for a route that you might have already created? For instance if this trip is sent several time through the gtfs-rt interface?

[leonardehrenfried]

This is a good suggestion and I just tried it out.

However, the problem is that these ADDED routes are not added to the transit index so it's actually quite hard to figure out if it already exits.

Nevertheless, since the route is added to trip pattern which is cached it is still the same instance when there are two consecutive updates. I've also added a test to check that this is the case.

[leonardehrenfried]

Do you think this is enough?

[slvlirnoff]

Mmm good question, it reveals an existing potential issue when your trip times matches a pattern of another added trip times on another route and isn't properly added with the right route reference as a result. For car pool, if two users provide a similar trop between two city, only one of the user route will be created with two trip times. If there's important information in the route to identify and contact the driver that might be an issue.

Similarly for transit, if two added trips, initially for two different routes/bus lines, share the same set of stops, they might both be displayed as on the same bus line. I feel the cache should be depending on the route id too.

Also the route not being added to the graph index could be problematic if you want to get the route details by route id later on, I feel this would be necessary.

[leonardehrenfried]

I actually found a way to add the route the graph index. It was rather easy: bcc4096

[t2gran]

I just looked at the on commit above and found two issues - this is why we need to refactor the TransitModel. Of cause you can make the index for route a concurrent map, but by injecting the implementaion/editor into the Snapshot you exposes the Snapshot for threading issues. This adds another stone to the task of refactoring the transit model, but I am not sure if we have another choice...

[leonardehrenfried]

If you have a suggestion I'm happy to implement it.

BTW, the Siri updater does the same thing:

OpenTripPlanner/src/ext/java/org/opentripplanner/ext/siri/SiriTimetableSnapshotSource.java

Line 563 in 124ced0

transitModel.getTransitModelIndex().addRoutes(route);

[hannesj]

routeExists(tripId.getFeedId(), tripDescriptor) is already checked on the previous if, so no need to check it a second time. There is still some shared code between the two blocks, but we can refactor it at a later stage

[mpaine-act]

Does GTFS-RT Trip Modifications supersede GTFS-ServiceChanges?