Something that folks using HustleTime have asked for is a way to see the destination of each train that’s arriving.
The MTA provides this data on their station arrival boards, they often read something like this:
1. (G) Church Ave 4min
2. (F) Coney Island 8min
3. (G) Court Square 9min
4. (F) Jamaica 179 Street 10min
5. (F) Kings Hwy 12minThis is actually a useful bit of information, and it brings me to question how I organize HustleTime’s ArrivalNotifications.
There are a couple of issues here:
1) Even though the MTA gives out information in terms of North and South, human beings don’t think that way. Straphangers generally think in terms of Uptown and Downtown, or even Manhattan bound, Queens bound, etc.
2) I’m limited (figuratively) by real estate. I don’t have a whole lot of room in this format to give users more information.
So what I’ve decided I’m going to do is organize this as option. I’ll let users choose if they want the “compact” (i.e. current) version of the Arrival Notification or let them see a more detailed “to be named” notification, and I’m currently debating between 2 layouts:
There are pluses and minuses to both layouts… What I like about the top one is that the timetable is intuitive, you’re seeing the departures in order, regardless of their destination. It is possible in this view, however to show only incoming uptown trains, or in very busy stations (like West4th or Atlantic avenue’s Pacific street platform) to not see particular trains at all, even when ignoring.
The bottom ArrivalNotification separates out Northbound and Southbound departures, showing the next 2 in either direction, so addressing the issues I have with the top notification.
It’s also worth noting that both of these options will infringe on the map space, so I may need to work out how much less of the map will remain visible with the larger view enabled.
Regardless of the Ui I choose to implement, I need to set up some things on the back end to allow for this information to passed to the front end.
GTFS
GTFS is particularly inextricable to me, and according to GTFS documentation trips should have a key called stop_headsign that “appears on signage identifying the trip’s destination to riders.”
But this is the MTA, and there’s no such key in the feeds, so I need to figure out how the MTA actually gets that information on their signs.
When a feed is decoded there’s an entity called :stop_time_update that contains what’s essentially an array of all the information for a particular train along its route.
if I take the last element of this array and assign it to a variable, I can preserve this station as I iterate through each element in that array, where I pull out all the actual departure data:
last_stop = entity.trip_update.stop_time_update.last[:stop_id]
.
.
.
for entity in lineFeed.entity do
last_stop = entity.trip_update.stop_time_update.last[:stop_id]
for upd in entity.trip_update.stop_time_update do
if upd.departure
if upd.departure.time && upd.departure.time > (timeNow + 5)
oneArrival = {train: entity.trip_update.to_hash[:trip][:route_id], time: upd.departure.time, station: upd.stop_id, destination: last_stop}
data_array.push(oneArrival)
end
end
.
.
.Basically what I’m doing here is hanging on to the last stop of each :trip_update as I iterate through and add it into the arrivals as a key called destination
Now with the Redis data containing the final stops for each arrival, I can do the business of sending that to the front end and render SOMETHING in the app.
I’ll get to that later.