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
Posted in: Data | Maps | Talking about Transit
Tags: | | | |

Comments

Leave a Comment