For the last few months I’ve been scraping SORTA’s real-time GTFS data for vehicle positions. I don’t really have any plans for what to do with all of it, but it’s easy for me to collect and I figure someone else may have a use for it somewhere down the road. This could eventually be a very interesting dataset for looking at e.g. changes in on-time performance, traffic congestion, bunching, etc.
Essentially, for each vehicle in operation at a given moment, I’ve been storing its:
vehicle_id: vehicle ID given by the API
trip_id: trip_id given by the API. I believe this corresponds to the trip_id in the GTFS package for the corresponding period.
report_time: the timestamp field, per vehicle, given by the API. This is stored as Greenwich time, without a time zone, so you need to subtract a few hours to get to local time.
location: I’ve been storing everything in a PostGIS database, and the location datatype in this case is geometry(POINT,4326). Postres dumps this as a hexadecimal string.
The API updates all vehicle locations every 30 seconds and I’ve been requesting updates every 25 seconds and ignoring duplicates, so I should have all of the data on vehicle positions that have been made publicly available. I’ve tried to keep my script running steadily, but there have inevitably been a few interruptions as the postgresql server has been restarted, etc, so there may be some big gaps. Where there is any data, it should be complete; It just may skip out for a day or two. The earliest date I have is 2017-05-16 17:59:36.
Anyway, here is the script I’ve been using along with ancillary files:
It’s been requested that I post offer some fresh thoughts on the issue of the Cincinnati streetcar project, in light of the two years I’ve spent so far in Toronto, a city with, indeed, many streetcars of it’s own. It’s a fun writing prompt, so here goes!
First, to understand the context, you’ll need to be familiar with my earlier remarks on the streetcar project, then underway. I did a whole series of posts outlining in detail the various weaknesses and infirmities of a project, which I think by accounts on either side had been too much discussed, and by my account too little understood. The series is some of my better writing on this blog and for anyone with an interest in the topic I would of course recommend that you read it in full.
I’ll try to summarize for the sake of rhetorical clarity though: my position on the Cincinnati streetcar project is basically that both advocates for the project and it’s detractors were pretty seriously misguided. Advocates seem generally to have conceived of the project in isolation from the rest of the transit system. It’s goal for them was primarily one of economic development in the city core, with actual transportation as a secondary or even tertiary goal. These priorities resulted in a project that serves poorly as actual transportation and which integrates very poorly with regional bus services, most of which overlap the streetcar route in some way, and which constitute the overwhelming bulk of actual transit in the region. The project opponents for their part acted like belligerent children and failed to offer any serious critique of the project. They also seriously misrepresented the project costs and pretended to be fiscal conservatives while ignoring concurrent highway expansion projects with costs orders of magnitude higher and even more dubious benefits. I do not believe that “expanding the system” will help anything because the streetcar should not be conceived of as a parallel transit “system”. That whole conception is deeply flawed and will lead to more mistakes.
Now having written that, from memory, I guess one thing that should be clear is that my opinion hasn’t changed much. But the question was: How has my experience in Toronto informed that? What is the streetcar experience in Toronto?
Toronto’s transit system (the TTC or Toronto Transit Commission) is indeed a “system” in a meaningful sense. Paying the standard fare entitles one to travel across the whole network on any number of “modes” (bus, express bus, streetcar, streetcar in designated ROW, subway, LRT) operated by the TTC. The routes form a mostly non-overlapping rectilinear grid which spans the entire city.
For most trips it’s necessary to change vehicles and often to change between “modes” in the process. This is generally easy because the TTC makes it pretty straightforward to transfer, especially at subway stations where transfers happen within a fare-paid-zone. High frequency service on most lines minimizes waits for connecting services. For a deeper discussion of this network structure, and a contrast with a network more like Cincinnati’s, I recommend A very Public Solution, by Paul Mees.
Anyway, most major streets in Toronto are served by some kind of transit services and some of these happen to still be streetcars. In fact, I believe TTC has perhaps the largest streetcar operation in North America at least in terms of daily ridership on those routes. These streetcars however are a part of a large, integrated network, and which part of that network they happen to be seems as much a product of history as of planning. The actual vehicles range from long low-floor modern vehicles to single and articulated high-floor models from I think the 60’s or 70’s. Streetcars operate both within designated rights of way, as on Spadina or St. Clair avenues, or mixed with other street traffic as is the case pretty much everywhere else. Often something on or near the tracks will be under construction and the streetcars will be replaced for days or weeks with single or articulated buses with little effective change in service levels. The operation of these routes with buses is a common occurrence and not one that I’ve ever really heard anyone remark on.
Streets with streetcars do not generally have better service, nor worse service for that matter, at least as far as I can tell. For example, I live near Dufferin Street, which has articulated buses running as often as every three minutes during peak service. Another nearby transit street is Queen Street, which is usually served by streetcars along it’s entire length, though again, sometimes these are replaced by buses for some or all of the route. Queen street is narrow and extremely congested during the day, meaning that service on this street is generally much slower than that on Dufferin and much more prone to bunching. It’s not terribly uncommon to see three or even four streetcars one after another. The peak frequency is pretty similar, so the level of service on these streets is really the result of local traffic congestion more than the type of vehicle being operated. One way that the TTC is looking at dealing with such congestion is by working with the City to remove non-local car traffic from streets with transit services that are currently at or beyond capacity, as is now being considered in the King Street Pilot Study.
All of this, all of my experience here so far reinforces the idea that the quality of a transit service is not about the kind of vehicle being operated, but about the way it’s operated, whether it is mixed with traffic, scheduled with adequate headways, given reasonable connections with other services, etc. The only instance where the vehicle as such really matters is where it’s capacity varies. Articulated vehicles (streetcars or buses) carry more people than single vehicles, and require fewer drivers per passenger, saving on operating costs if the vehicles are reasonably well utilized. Perhaps I should also add that the number and width of doors can also matter, though this would make little difference in Cincinnati given current passenger volumes on most lines. Boarding speed is another element of overall line capacity though, so this is really just another dimension of that. And again, line capacity is not an issue that Cincinnati is facing in any real way.
These are the sorts of details by which a transit project should be considered and described. That the Cincinnati streetcar continues to be discussed in very different terms indicates to me that it’s primary purpose is not to effect the efficient movement of people through or within the urban core. It’s primary purpose, so far as I can tell is to signal that Cincinnati is “with it”, that OTR is a cool neighborhood, and that it’s safe to invest here because the neighborhood is now more closely aligned to the trends of other places which have seen dramatic recent increases in property values. If that was the goal, then we should be discussing whether a streetcar is the most efficient means of accomplishing it. Perhaps it is; I’m not a real-estate developer and such questions are beyond my purview.
What about it’s popular success such as it is? To the extent that the streetcar does or does not meet ridership projections or expectations, I think we would need to consider how such projections are to be made. Surely different models exist for projecting demand for transit services and demand for e.g. a ride at an amusement park or a brand of shampoo. One model would probably look at landuse, density, travel demand and the competitiveness of alternative modes etc., and another may consider popular sentiment, advertising, product placement, etc. I would leave the reader to wonder which model is more appropriate here, and if there is popular demand, to the alignment of which variables this can most rightly be attributed.
In case anyone is interested, I’ve begun storing data from SORTA’s GTFS-realtime feed. I started the script today and I see no reason to stop it unless I start running out of space on my server. I’ve got GTFS trip_id’s, vehicle_id’s, locations and timestamps for every vehicle location update from here until infinity.
Let me know in the comments if you happen to be interested and I’ll find a way to share the data!
So, as you may remember, I’ve been tasked with developing a live display using SORTA’s real-time API. The basic idea is to put tablet computers around town in store windows, behind bars, on coffee shop counters, etc, which will alert people to the fact that there is a bus coming (they are almost always almost here) to take them where they might already plan on going. To that end I’ve been developing a web application that can run in a browser. When full-screened, it turns any monitor into a real-time display.
The tablets that we distribute to businesses will basically just have a link to the web-app stuck to their home screens. Which means of course that the tablets/laptops/typewriters y’all are using right now to read this can also function as a real-time display! Power to the people, I say.1
Well, development has been progressing more or less slowly over the last couple months (Did I mention that I graduated, got married (before it was legal!) and moved to another country? Well, I did. I’ve been busy.) but the app is finally ready to share as a beta version available at http://cincymap.org/rt/ .
To get started, pan to your location (or hit the button that asks for your location) and select some stops. For the love of jesus, make them close together; I didn’t design this for crazy teleporting people2. Then hit the button to use the selected stops and the app will load arrival times for those stops and start refreshing them when new data is available.
One of my big goals for this app is that it should help show people what’s available and where transit is actually going, not just when the obscure number X local is departing northbound, so maps are a big part of this. Right now, I have the app displaying the actual route on a background of OpenStreetMap tiles, with the portion already travelled diminished and the part yet ahead in a darker color. The map also has a bit of animation going on to highlight the whole remainder of the route before zooming back into the immediate context of the stop.
I’d appreciate any constructive feedback suggestions that anyone has, but please keep in mind that I’m still actively developing this. If you’re about to suggest something obvious, I’m probably about to do it anyway. Keep the suggestions subtle!
Goals for the next few days:
Modify stylesheets to allow for portrait oriented screens.
Find a tileset that I can use without bothering anyone. I’m pretty sure the OSM people will be a little peeved if I use the basic tiles in a production app. Something black and white perhaps?
Remove the route numbers from all but the first departures for each route. The colors can distinguish for the rest, or perhaps I can just make the number a lot smaller to allow a bit more map space.
Distinguish between arrivals that are real-time and those which are only scheduled. This shouldn’t matter once Gaslight makes an update to their API.
Give an indication of direction for each of the upcoming arrivals on the right side. This matters a lot for two-way stop selections, but it’s not super obvious how to do it technically in a way that will give intuitive results. I’m thinking something like this.
Goals for the next month:
Play with displaying vehicle locations when vehicles are off-screen. I’m planning to have this ready to present at the NACIS conference in Minneapolis this October. Right now I have the app generating random vehicle locations for the purposes of testing some ideas, until we get the vehicle locations API up and running3.
This post was written in the winter of 2014, but for some reason I got distracted and never posted it. Now I’m cleaning house, and here it is! In case you were wondering why it’s about winter weather…
About twice a week, I find myself waiting for the #17 at 13th and Main, heading up to UC for the day. The #17 works well for me since the geography department is on the west side of campus anyway, though in the winter more often than not I find myself wishing for a bus, any bus, for the love of god, when is the bus coming? My hands are freezing! I find myself here almost every day, but about twice a week, like I say, I find myself in a particular situation: passed up by a bus that’s going the same place I’m going, its clean, brightly lit, warm interior mocking me through it’s big windows. I don’t care it’s it’s going to the other side of campus. I just want on.
The M+ has just passed by. My inclination is to run for it’s next stop, but my position on 13th street denies me the option.
Once I see the M+ coming up Main, it’s too late to run south to the courthouse stop, too far and still too late to run up to it’s next stop at Findlay market. This is why the M+ is marginally faster than the other buses. It doesn’t stop for people like me, people of course, not at it’s limited and clearly signed set of stops.
The 13th Street stop is the one closest to my house and it’s always my starting place when catching transit up to campus. I always look south when I get there, and if I don’t see anything coming, sometimes I’ll sneak toward the courthouse, stop by stop, never getting too far away in case a bus pops out of nowhere. (Sometimes I creep north, constantly looking back…do I have time to grab a baguette?!? I pay for it, already half-way out the door.) The courthouse stop, see, has better frequency toward campus since it works for both the #17 and the M+, two high-frequency lines going where I want to go. Since they don’t usually arrive at exactly the same time, their headways compound and we get some constructive interference.
But it’s more complicated than this. Because the schedules for the #17 and M+ don’t work together, aren’t coordinated, reliably interrelated, I never know which to catch, which will actually get me to Braunstein Hall first. Both are frequent enough that I wouldn’t bother looking at a schedule if I wanted either, and both are so often just a little late or early that it wouldn’t do me much good if I did. In the absence of real-time-location information…you know what? Let’s let this derailment happen. Why not?
Where the h*ll is that real-time data, SORTA? What’s the deal here? This is getting really frustrating, now that the real-time info is posted at half a dozen stops. You’ve missed at least three of your own deadlines for releasing it. Stop making excuses and get your shit together!!!! RAAAGHAHG!!!1
*Phew* OK. Back on track. Without that real-time data, I’m essentially looking to ascertain the quantum state of the buses. Buses here are both a wave and a particle. Clearly working in a regular pattern, they still come in discrete chunks which can be discovered only by measurement and then never exactly predicted.
What’s a boy to do?
Stop fussing and wait an extra minute perhaps. That would be too simple though.
A big part of my problem here is that the schedules aren’t coordinated, meaning that they overlap and interact with each other in unpredictable ways. If they were coordinated, I could decide now which stop is usually the better one and stick to that decision.
In this particular situation, there’s not a good case to be made that these ones should be coordinated since they split off from each other once they get to the hill, but my dilemma illustrates a broader problem with the way SORTA has conceived of BRT: as a fast express line mostly redundant to a slow local service. Schedule coordination is impossible where lines are running at different speeds.
And this same problem becomes more dramatic when I consider other destinations. Lets say I want to get to Norwood, or once there, even further out to Kenwood. In the first case, I would have to take a bigger risk in walking toward the courthouse stop. The #4 turns east around the corner from the courthouse stop, meaning that I can’t even see it coming.
The best choice would necessarily be based on expected waiting times and expected travel times. A better-than-probabilistic decision can’t realistically be made during higher-frequency hours since the normal(in the non-statistical sense at least) delays, disrupt shorter and more-frequent trips more, relatively speaking. In the later case, I would most likely be presented with the same optimizing tactic that finds me sneaking south on Main Street. That is: walk to the nearest stop on Montgomery Road and once there, inch toward the closest higher-frequency stop, taking in any case whichever bus comes first. Once I know the position of one bus, the one having just arrived, I won’t typically wait around for the next since it’s position is unknown and possibly very distant. Assuming both came at once, and were both stopping, the choice would be easy: the faster one.
The problem here is one of lost potential. It’s not a bad situation by any stretch(I have two reasonably frequent-transit options! Yay!) but it could be better. Rather than having two transit lines in the same corridor running at ten-minute headways, one dramatically faster than other, we could have one line, significantly faster than what we have now, running more consistently, more frequently, and importantly: more simply.
Express lines, as SORTA have conceived them, split the baby.
I’m excited to announce that I’ll be spending part of this summer working with Daniel Schleith and Brad Thomas on a rather exciting project… Thanks to a grant from People’s Liberty, we’re going to have the opportunity to develop what I believe will be the first application to make use of SORTA’s recently released real-time data.
The goal of the project is to get real-time arrival displays into businesses along major transit lines. These will be privately owned and operated computer displays that ingest real-time data through the interwebs and display localized arrival predictions for nearby stops. We’ll be developing a display/app1, and subsidizing the purchase of tablet computers which can then be mounted behind a bar, in a shop window, near the door of the coffee shop, etc.
I’m sure I’ll have lots more to say here on the topic in the near future, but for now, I leave you with hope only.