1 Boarding 2 Next Page 3 4

An update on the real-time display development

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/ .

Beta version of the real-time app

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:

  1.  Modify stylesheets to allow for portrait oriented screens.
  2. 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?
  3. 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.
  4. 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.
  5. 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:

  1. 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.

Show 3 footnotes

  1. and being a JavaScript-based web app, it’s implicitly open-source to the extent that my code comments can be interpretted.
  2. The basic use-case is a business on a two-way street with transit in both directions
  3. with JSON output
Comments: 2
Posted in: Data | Maps | Talking about Transit
Tags: | | | |

Moderating two definitions of access

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.

Too far.

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.

Show 1 footnote

  1. real-time data DOES exist now!
Comments: Leave one?
Posted in: Access | Analysis | Simplicity
Tags: | | | | | | |

Real-time display project funded!

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.

Show 1 footnote

  1. F&OSS, of course.
Comments: 5
Posted in: Back to Basics
Tags: | | | | | | |

Haiku

Trying
At least and
Not badly, they
Know their role

Stuck!
Only working here for now
Ready to defend
The way things
Are

Haiku is dumb. Or perhaps just poorly transliterated?

Iambic tetrameter???

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.

Comments: Leave one?
Posted in: Aphorism
Tags: | | |

“without raising fares”

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

  1. More fare revenue than ever
  2. 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:

a shitty decade for transit

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.

Comments: 2
Posted in: Analysis | Data | Politics
Tags: | | | | |

Another Stab at the 2014 Ridership Dataset

I’m taking a self-guided course in R this semester — that is, teaching myself, but with deadlines — and since I’ve been playing with transit data for the most part, it seems appropriate to tickle y’all with some of the mildly interesting data visualizations that I’ve so far produced.

I’ll be using the 2014 SORTA spatio-temporal ridership dataset, which I’ve already sliced a couple different ways on this blog. The first was here with a set of animated maps andthe second here showing basic peaking in passenger activity through time.

This time, I’m going to take that later analysis a little further by breaking out passenger activity into lines. Go ahead and take a look at the graphic, which I’ll explain in more detail below.

SORTA 2014 ridership by time and lineOk. So first, it’s important to understand what we’re measuring here. Our dataset tells us the average number of people getting on a bus (boarding) and the average number getting off (alighting) for each scheduled stop. There are1 about 162,000 scheduled stops on a weekday. Of those, I was able to identify a precise, scheduled time for all but ~ 2,0002. Of the remaining ~160,000 the dataset tells me that 77,763 have at least 0.1 people boarding or alighting on an average weekday. I used those stops to calculate a weighted density plot over the span of the service day for each route. Added together of course, the individual routes sum to the total ridership for the system3.  I then sorted the routes by their total ridership and plotted them.

The first thing that becomes clear, to me at least, is that a minority of SORTA’s lines account for a large majority of actual riders. These lines by the way are precisely the ones featured in the Cincinnati Transit Frequency Map, and I’ve used their color from that map to distinguish them in the chart above. The remaining routes, as I knew even before I had this data, are relatively unimportant.

transit map of Uptown Cincinnati

May 2013 routing

The one grey line mixed in among the colored lines is the m+ (a latecomer to the frequency map), which does actually run all day on weekdays.

Now another interesting question, to me at least, is what this would look like without the pea under the mattress; how large are the rush-hour peaks if we exclude the peak-only lines from the chart? Let’s try it. I’ll also reverse the order, so we can see some of the larger lines with less distortion.SORTA 2014 ridership by time and line no-expressWell, the rush-hours are still pretty distinct. More distinct than I would have expected. It’s an open question whether this is the result of more service in the rush-hours, or more crowding at the same level of service.

One last way (for now) to slice the data will be to take the total ridership at any given moment, and relativize each line’s total, showing each line’s percent share of the total. To keep it easy to read, I’ll leave the peak-only lines out of this one too.SORTA all-day lines ridership flow diagramI found it slightly surprising how straight these lines are. Only toward the end of the day do we see a major wobble in any direction, and that’s essentially the result of a few lines shutting down earlier than the others.

Show 3 footnotes

  1. or were when this data was collected
  2. These ~2,000 stops seem to account for about 1,000 passengers
  3. Minus the missing values for the records which couldn’t be matched.
Comments: Leave one?
Posted in: Data
Tags: | | | |
1 Boarding 2 Next Page 3 4