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: | | | |

Businesses: request a real-time display

Design and development of the real-time arrival displays has finally begun!1

MetroNow App Wireframe

Wireframe showing basic layout of the display (draft)

And while that is ongoing, we are seeking early adopters to sign up to get a display for their business. The deal, in a nutshell, is this: we’re subsidizing the purchase of tablet computers set up to run a localised real-time transit display. Businesses will be responsible for somewhere between $20 and $40 of the cost of the tablet and will be responsible for maintaining it in a prominent location, with a source of electric power and a good wifi signal. We will help to supply mounting hardware, if needed, appropriate to the location. Businesses must be located on a fairly major transit line, preferably in a business district or an area with a lot of foot traffic. We’re imagining that tablets will either be placed in side-walk facing windows or placed prominently inside the business such as behind a bar.

If you’re interested in getting a display for your business, please email Daniel Schleith. He’ll get your information, answer any questions, and let you know when we’ve selected the lucky winners/trendsetters who will receive tablets.

(Please note that once the app is ready, you’ll also be able to run it in any computer with an internet browser, not just on these tablets.)

More info here.

Show 1 footnote

  1. Well, it actually began a couple weeks ago, and I haven’t had a chance to post until now.
Comments: Leave one?
Posted in: Psychological | Talking about Transit
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: | | | | | | |

Schedule Padding in Time

An excerpt from (the background section of) the first draft of my thesis proposal:

“The bus is so slow! Isn’t rail just better?”
The popular confusion created by the conflation of coaches and railcars with their typical relation to automotive traffic has wasted billions of public dollars1 (and caused me no end of frustration). Though the superficial wheel may not much matter, the general public is right to sense a distinction in the reliability and speed of transit services that operate in mixed traffic and those that are given priority over such traffic. As the public more and more aggressively demands train-based transit services, these should be read as demands for increased speed and reliability (among several other things) and planners should respond by modifying existing services to meet these demands.

Speed and reliability are a function in large part of how many potential delays a line will encounter along it’s course. Random delay results from unplanned disruptions such as higher than expected passenger loads, traffic, serial red lights, etc. Scheduled delay, also known as schedule ‘padding’ is delay that is built into scheduled transit services that allows them to be tolerant of unscheduled disruptions by acknowledging their average effects in advance. Agencies try to balance scheduled and unscheduled delay to create schedules that are neither too slow nor too often disrupted by random delay. While the public often reacts negatively to random delay events, they’re typically unaware of schedule padding, though both are dependent on basically the same environmental factors.

Since the public, and not transit schedulers, are in control it becomes important to explain delay and it’s causes and effects to a lay audience and thereby to direct them toward a fruitful response. Further, since funds for radical infrastructure interventions may be difficult to find in the current political regime, attention should be focused on marginal cases and incremental improvements to surface-running bus lines.

Simply, the question is: where can the smallest new delay-avoidance technique create the biggest improvement in speed and reliability for existing services?

*close-quote*

As a first step toward an answer to this question, I’ve created a rough measure of the amount of schedule padding identifiable from just the schedule information itself. It’s not perfect by any means, but I’m going to run with it for a moment and see where it leads me. First I identified all unique trip segments in the transit system. A segment is defined here as the travel between two unique stops, so…

( stop A -> travel -> stop B ) = segment 1
( stop B -> travel -> stop C ) = segment 2
( stop A -> travel -> stop B ) = segment 1 again
( stop B -> travel -> stop A ) = segment 3
for a total of 4 segments, 3 unique in our example.

For SORTA’s current GTFS schedule, we observe:

Total Segments Unique Segments
Weekday 164,621 5,159
Saturday 103,757 3,914
Sunday 69,380 3,550

Each segment has some times associated with it:

  1. A departure from the first stop
  2. An arrival at the second stop
  3. Implicitly, the time scheduled to complete the segment.

Because schedulers expect that the amount of time it will take a bus to get from A to B will be different at different times of day, these otherwise identical segments will have different durations. By finding the deviation from the minimum duration for each segment, we can get a crude measure of the schedule padding built into the system.

For SORTA:

Hours of Padding Scheduled Vehicle Hours % padding
Weekday 414.60 1,925.22 21.53%
Saturday 174.19 1,036.57 16.80%
Sunday 97.36 664.13 14.66%

This method estimates that 21.5% of the weekday schedule is actually scheduled delay, more than 400 hours of it, each weekday. That is, at least relative to the fastest any bus is scheduled to complete a segment. Just where is this scheduled delay anyway? When and where are the schedules most heavily padded? I’ll save a spatial exploration for later, but let’s take a very preliminary peek into the temporal dimension.

The first question we must ask is: when are all of the segments? By taking a central moment as the time, we can plot them, in a kernel-smoothed histogram :

SORTA segments per hourThis clearly shows the basic level of service throughout the day and week. It’s not a great measure of that as such, but it does give us a definite sense of the balanced weekday rush-hours and diminished weekend service.

Then since most of the segments are padded,we ask when are the segments without padding? On the same scale, we get:

SORTA unpadded segments per hourAs we might have expected, there is less random delay and thus less need for padding when the streets and buses are less congested: early morning and late at night. It also appears that there are relatively fewer padded segments on the weekends, though the total number of unpadded segments is roughly the same as on weekdays.

Ok, so when is the padding itself and how much of it is there? Note that we’re measuring something different here: hours of padding per hour.

SORTA padding in timeNow, this definitely has a different shape than the overall distribution of schedule segments, but it’s a little hard to compare them when they’re so far apart. Let’s combine all of these into one plot. I might have got a little carried away in Inkscape…SORTA Schedule Padding by Time-of-Day

I’ll just let that speak for itself for now. We’ll get into spatial visualizations of this data next, and eventually real-time comparisons and measures in space-time.

Show 1 footnote

  1. Citation needed…
Comments: 2
Posted in: Back to Basics | Data
Tags: | | |

Why the buses just stop

A friend of mine just emailed with a very good question: Why do the buses just stop sometimes, with no one getting on or off, no traffic jam, etc, and no clear reason why they  aren’t running?

The Answer:
The buses here operate on a fixed schedule, with a set time for each and every stop. Planners try to adjust these times to accommodate varying traffic conditions like rush hours and other factors. Obviously, they can’t do this perfectly, and sometimes buses tend to run late, ie slower than the schedule says they ought to. Just as often, they should tend to get early. This can happen if traffic is particularly light, there aren’t as many passengers as usual, or maybe the bus just hits a string of green lights. When that happens, the driver tries to stay on-schedule by driving more slowly, or sometimes stopping completely. When they do stop completely, they’ll often take the opportunity to read a couple pages of their magazine, send a text, take a bite of lunch, etc.

To someone who doesn’t know what’s going on, it probably looks like the driver is behaving quite capriciously. Many systems make announcements explaining any longer-than-usual waits, but I’ll speculate that SORTA and TANK don’t do this because they’re not seriously trying to attract or retain new passengers. They see themselves as serving a relatively captive and stable audience who has already spent a lot of time learning the system’s quirks. This also explains their complete inattention to providing easy-to-understand overviews of the system in favour of obtuse and overly detailed maps and schedules.

Comments: 2
Posted in: Back to Basics
Tags: | | |

TANK’s Failure of Communication

Fireworks are worth shutting down a major city.

Said no one ever, but for the dipshit who decided that’s what Cincinnati was going to do.

For the second year in a row, I have been confounded by a preposterous barrier: at 7pm today, all the bridges shut down. Every one of them. For everyone. For the second year in a row, this has disrupted well laid plans with my boyfriend in Kentucky. This year it was fireworks at a friend’s house. Last year it was an anniversary dinner already in the oven.

Now let’s be clear; disruptions are normal in some transportation systems and that’s why we have redundancies. Bus not working? Take a bike. No go there? Hail a cab. Still no? Walk!
What we’re dealing with here is a complete breakdown in the whole system for every mode. There is no tunnel under the river. Every crossing is shut. With the number of boats in the water, swimming isn’t even safe. I was lucky last year though: one of my redundancies worked. After trying to bike across literally every bridge, the fourth police officer I talked to told me TANK might be running. It was, and I caught the last one over with my bike, arriving very late to dinner, but still, arriving.

This time though, I didn’t make it. Seeing the bridges were closed, and remembering last year, I headed directly to the TANK stop on fourth. I got there and was relieved to see half a dozen people at the stop. Now normally, this is a good sign. It means that the bus is almost there, because people have had time to pile up.

But in this case, it was a sign of TANK’s complete failure to communicate the fact that they simply stopped operating the most critical link in their whole system.1

When SORTA shuts down a stop, or changes service on short notice, at least they post signs literally over top of the bus stop signs. “This stop is closed temporarily. Walk to …” Something like that. (Other agencies often go quite a bit beyond that.)

For TANK’s downtown stops tonight, there was absolutely nothing. And as I write this, I’m certain that there are people sitting on those dirty little benches in front of the Federal Reserve cursing a late bus that they don’t know will simply never come.

Now, without defending the logic of the shut-down decision, I presume that it goes something like this: People driving on bridges would get distracted and wreck their cars…yadda yadda yadda. Now let’s not even get into why humans on foot cant cross (I can feel my blood pressure really starting to rise at this point). Let’s assume that that’s the logic and point out that the only people who can and do drive TANK buses are professional drivers who presumably can’t be so easily distracted, and certainly not on an otherwise empty road. Why the flying fuck can’t TANK keep running normally through the fireworks??? I understand that some stupid car-blind engineer might think to shut down the bridges, but what really gets me is that no one at TANK had the balls or the ability or perhaps the desire to stand up for themselves and insist that they continue to operate a critical service through this silly spectacle.

That failure being swallowed of necessity, it’s even more galling that they didn’t think to post even one notice at their single most active stop2 where, as I say, people are almost certainly still waiting at this very moment for a bus that won’t ever come.

I’m properly pissed. I’m pissed at the City. I’m pissed at TANK for not standing up for themselves, and I’m pissed at TANK doubly for not telling it’s passengers that they won’t be coming. To my mind, this is as big a (short-term) failure as a transit system is capable of making.

TANK, you should be ashamed. Learn from it, but feel shame no less for that pragmatic consolation. TANK failed it’s riders tonight.

Show 2 footnotes

  1. I am prepared to back this up with data already provided by TANK.
  2. Again, I can prove this.
Comments: Leave one?
Posted in: Talking about Transit
Tags: | | |
1 Boarding 2 Next Page 3 4