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!
I wrote this paper for a class, not for an actual audience, so please moderate your harshest criticisms. It was the final project of my last class ever!! Such relief.
A silly paper
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.
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 people. 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 running.
I’ve been wanting to do this for ages… and I finally did!
The idea is this:
- Create a square.
- If the square has more than n things inside it, divide it into four parts.
- Do the same for each of those squares and so on recursively.
My recent pet project, cul-de-sacs (threshold = 10 or less per):
Dayton got a bit cut off, unfortunately. Trust me though: it has plenty of sprawl! This image sort of gives you an idea how the process works.
Population density, based on 2010 census blocks (threshold = 100 people or less per):
14 levels deep! This one took a couple hours. Click through for a larger image.
Many more to come, I’m sure, now that I’ve written the script…
Spotted this map while out and about yesterday (…and quickly appropriated it for the geography grad office).
People I don’t know making maps?? WHHAAAAT? How exciting! And screen-printed no less.
As everyone may or may not know, there’s no obvious and standard ontology in the world of cartography and map data, meaning that each dataset has its own way of describing and encoding the objects of the world. Its own familiar quirks. I was able to pick this out as OSM data by the too-thick blotches in the railyard, where I remembered I had failed to properly classify some of the shorter segments.
Just another way of looking at speed distributions. This shows the distribution of observed speeds across several thousand route segments by percentile of the speeds on each segment. The animation changes as we’re shown different parts of the speed distribution on each segment.
Not totally sure if it’s useful yet, but it is kind of pretty.