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.
At least and
Not badly, they
Know their role
Only working here for now
Ready to defend
The way things
Haiku is dumb. Or perhaps just poorly transliterated?
I rode the TANK and I did see
a friendly driver condescend
to stop the bus and wait for me
the only rider end to end.
“Remove your hoods!” the speaker blares,
the driver has gone mute it seems.
Uncivil stretch from here to there,
we nod our heads and sheath our dreams.
I think these work better for English, but maybe I just like rhymes like some sort of poetic simpleton.
And fuck SORTA, by the way. Those damn speakers are dehumanizing and awful. They said they were for ad revenues and now they have the system in place they’re abusing us with their own radio voice actor shit every ten damn seconds.
A wee nit to pick from SORTA’s recent “State of Metro'” dog and pony show:
I distinctly remember one of the speakers saying something like ‘and all this without raising fares!’, and this to my feeble memory reeked of bullshit, so I found the numbers again and ran them to see if I was remembering correctly. I was indeed.
Here are the facts, as reported by SORTA to the Federal Transit Administration. Over the period where we have data on both fare revenues and ridership (currently 2002 to 2012) SORTA has been steadily getting more money from fare revenues while moving fewer passengers. We are currently at the nadir of this trend, with
More fare revenue than ever
Fewer passenger trips than ever
When SORTA says by the way that they are a ‘most efficient’ agency, a title pinned on them by the laughably unscientific UC Economics Center, it is precisely this measure they have in mind. There is hardly a better example of doublespeak to be found. Here’s the trend:
In order to plot both agencies together, I normalized fares and passenger trips to the same range. The scale is linear.
Now you may rightly note that the standard fare for a zone 1 trip hasn’t changed lately. But that’s not the only kind of fare that can be paid. It might not even be the most common! I don’t know for certain. I haven’t personally paid standard fare in quite a while because my transit use is partly subsidized by UC. So for example, the fare revenue variable in this data almost certainly includes UC’s cash subsidy for my fare as well as the dollar I put in myself. Multiply that by the dozens of private fare subsidies each agency probably negotiates (or drops) each year and you get a more dynamic picture. Fare could also be effected, though probably isn’t, by people using transit cards more or less, while paying the same monthly price.
But anyway, I’ll be damned if f the total price paid by riders or their agents, on a per-trip basis doesn’t constitute a better definition of ‘fare’ than SORTA’s standard zone-1 single-segment price. And by that definition, fares have risen from $0.76 in 2002 to $1.78 in 2012 (+134%). For TANK, the change is from $0.72 in 2002 to $1.16 in 2012 (+60%). Adjusting for inflation, the changes are 84% and 26% respectively. So much for SORTA’s unchanging fares theory lie.
I’ll end with an ineffectual plea to the people at SORTA. Please, understand that when you speak in lies and euphemisms, no matter how nice your breakfast spread, you turn off clever people and retain only the idiots and the cynical. People from all three of these categories vote, to be sure, but I know who I’d rather spend my time with. And I know who could build the better transit system.