Someone talk me out of this tileset

Is it too bold? It has to be too bold, right? Cause I think I kind of like it a lot.

See this version of the app directly!

In any case I got a couple new things working since yesterday:

  1.  Trigonometry: I don’t totally understand it, but it is orienting those arrows that appear after a minute to tell you which way the bus is heading.
  2. That tileset. Yum.
  3.  Route numbers have been removed from the second or third appearance of each route. Is anyone reading this colorblind? Can I get some feedback on that?

Yet to accomplish:

  1. Still need to accommodate portrait oriented screens (I’m using CSS vmin a lot right now).
  2. De-emphasise departures which are not real-time.
  3. Vehicle locations! Make them real instead of generating them randomly ;-)
Comments: 5
Posted in: Design
Tags: | | | | |

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

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

SORTA: Set your data free!

SORTA recently announced(among other things) that it’s new uptown transit center will get next-arrival-time signs with real-time information just like Government Square has had for about a year.

next arrival time sign at government square transit center

Basically, an electric sign tells waiting passengers exactly when the next vehicle is going to be there based on that vehicle’s actual location as determined by an on-board GPS device.

This is fantastic news! Next-arrival-time signs do a number of good things:

Such a delightful development raises a question though. While I appreciate that SORTA is adding these signs in a second location, I wonder why the information the signs provide couldn’t be available online such as through a smart phone or even via text message1. It would seem to me that if it’s possible for even one such sign to work, then a whole system must already be in place to manage and share the location information between buses and signs.

arrival time speaker at govenment square in cincinnati ohio

There’s no good reason that same system couldn’t be adapted to exchange information in the same way between buses and smart-phones or buses and computers. Instead of having permanent next-arrival-time signs in only two places, we could have them anywhere there’s an internet connection. We could carry them in our pockets!

This isn’t an original idea. There’s actually a bar in Portland OR that has a big ol’ sign by the door telling patrons if they have time for another drink.

And there’s also a website that couldn’t be simpler to use telling passengers exactly when the streetcar is coming to any stop you might select(in either direction). And there’s applications already built for smart phones…

Tri-Met streetcar sign

TriMet Does not own or operate this bar. They shared their data and people used it.

And closer to home, the University of Cincinnati is already offering a live map of their student shuttles.

So what’s keeping us from having such convenient transit information here in Cincinnati? We have the GPS systems in place, the concept has been demonstrated in more than a dozen cities, and there’s software already developed to help disseminate this data to the public.

SORTA: You need to release a web API to let developers make the data you’re already collecting even more useful to the riding public. If two signs are better than one, isn’t an unlimited number of signs, available exactly where and when people need them very much better?

I know what you’re going to say…”We’ve got too many things to do, we don’t want to maintain anything, and IT stuff is hard damnit!” Let me assure you, this can be a very, very simple project. This time last year I was developing an application programming interface for the Bureau of Transportation Statistics. This isn’t something you need to maintain and update. You need to set it and forget it. You don’t want to change the interface.

Not only would such an API be useful for people looking for the next arrival time, it could potentially be incredibly interesting as a teaching tool for helping the public understand how the system works. It could help us compare scheduled times and speeds to actual times and speeds throughout the day and let citizens hold public officials accountable for their decisions on infrastructure projects that effect transit. SORTA, if you want to make a case that your proposed BRT lines on major corridors need a designated right of way, what could do that better than a map showing the actual locations and speeds of buses in those crowded corridors at rush hour?

Set your data free, SORTA! Let us help you make our transit system truly useful and customer friendly! Let us advocate for better service with meaningful data!

(I’d be happy to personally help walk someone through setting this up, and I might even be willing to contribute a bit of code…you just need to ask!)

Show 1 footnote

  1. DC provides this service for example, and I know a few other cities do too. There’s a sign at each stop with that stops ID number and a 5 digit number for people to text. You text the number with the ID number and the number of the route and it replies within a few seconds with the expected arrival time.
Comments: 6
Posted in: Data
Tags: | |