How to represent "further out" arrivals at a stop?

[elliottwilliams]

Unless I'm mistaken, right now a station will only show that it has a vehicle approaching if that vehicle is no more than 3 stops away. This is probably fine for frequent, short loops (e.g. Silver Loop), but I think it poses some problems on larger, more infrequent routes.

Scenario: I'm trying to take the 1B from Cary to Greyhouse (true story). I select the "Stadium & Russell" stop. Currently, there is a 1B arriving in 8 minutes that is 5 stops away, and another arriving in 38 minutes that is 25 stops away. Neither would be shown and I would be left to assume that 1B doesn't come here.

So, here's a proposal:

• Routes currently are related to their stations. Can stations carry some relationship to all routes they serve? This might involve listening to route activate and deactivate events, and updating internal representation of stations as routes are activated on them.
• Similarly, can routes know which vehicles are on them at a given time? This would entail observing the vehicle_update event on the route's topic and updating an associated_vehicles property or similar.
• If both of these things were the case, the client interaction on a station view would look like this:
  1. Call last_event on station's id to get the data needed to show the view.
  2. Subscribe to all routes on the station to detect the progression of vehicles towards a station. Distance in stops and ETA can be calculated, though ETA depends on knowing the schedule.
  3. Call meta.last_event on each vehicle on routes that serve the station to get a vehicle's data before its next heartbeat.
  4. Subscribe to station to detect station updates. Because we're watching routes for vehicle movement, the approach and depart are superfluous, but we still care about deactivate.

If this were implemented, I think vehicle-on-station events could be removed.

[faultyserver]

I like this idea, and it solves a lot of questions I was having with implementation. To address each point:

• This will be pretty easy to implement. On an activate event from a route, Conductor can create the associations on each station, and vice versa on deactivate. Since associated objects are kept in a Set, there won't be any duplicates.
• This is currently happening. On an update event from a vehicle, Conductor finds the route that the vehicle is currently on, associates the vehicle to that route, and then sends a vehicle_update event to it.
• I think keeping the depart event would be nice, since it provides an event hook for when a vehicle leaves a station, which could be useful for notifying users that they missed their bus or something. In other words, I've already implemented it, so I might as well keep it.

[faultyserver]

This should be closed by bfd566f0c4ee1c9ed1bca9893b332c8b16fdc70b.