Below the fold is an interesting presentation from Tim Moore of BART on their API usage.
This post is the introduction to a series of posts on transport modelling (he’s using the Queen’s English, note the use of “bus pairing” over the American “bus bunching”). It is well worth a look, especially for the acknowledgements of the trade-offs in modelling and planning service.
The goal of this post: To introduce you to the world of theoretical transit modelling, validate the field, and motivate you to listen to what models are able to tell us.
To appreciate this post: In order to follow some of the conclusions presented in this post, an understanding of fairly basic high school math is needed.
TL;DR: I make the case that mathematical models are a misunderstood but valid way of gaining valuable insights about transit with a relatively small amount of investment. I introduce the real-world concept of bus pairing, and go through a 1964 derivation that leads to an equation that describes this phenomenon. I conclude with
Passenger information has been on the mind of the transit industry for over a century! An electronic passenger information sign was installed at at Boston’s Park Street in the 1890s-1900s. At the time, there were numerous (40+?) lines running through the station, and when properly staffed, this would have been pretty helpful.
I have not been able to pin down the exact source of this. I believe it was from one of the Boston Transit Commission annual reports, but I have not found a copy of the exact issue.
An interesting post on the gtfs-realtime group is worth following.
Beginning to addressing problems that some have with the GTFS/GTFS-rt ‘standards,’ which some sticklers decry as mere de-facto standards, as they don’t follow standards development processes.‘ Developing the GTFS in typical tech industry fashion, these practices were acknowledged, but not closely followed.
The complete original post saved for posterity (because you never know if it’ll be available in the future) is below the fold.
Continue reading “Will GTFS-rt move further into the standards realm?”
A recurring question on the transit-developers list regards how calendaring works in GTFS. It is a little opaque at first, but in the end it’s rather simple. This post aims to solve that by walking through a few examples.
The two relevant files within the GTFS are calendar.txt and calendar_dates.txt. Each of these files references service_id, an “ID that uniquely identifies a set of dates when service is available for one or more routes” Every trip in trips.txt has a service_id, and that’s what is used to tie calendars and calendar dates to trips.
Continue reading “On Calendars and Calendar_Dates”