For the last few months I’ve been scraping SORTA’s real-time GTFS data for vehicle positions. I don’t really have any plans for what to do with all of it, but it’s easy for me to collect and I figure someone else may have a use for it somewhere down the road. This could eventually be a very interesting dataset for looking at e.g. changes in on-time performance, traffic congestion, bunching, etc.
Essentially, for each vehicle in operation at a given moment, I’ve been storing its:
vehicle_id: vehicle ID given by the API
trip_id: trip_id given by the API. I believe this corresponds to the trip_id in the GTFS package for the corresponding period.
report_time: the timestamp field, per vehicle, given by the API. This is stored as Greenwich time, without a time zone, so you need to subtract a few hours to get to local time.
location: I’ve been storing everything in a PostGIS database, and the location datatype in this case is geometry(POINT,4326). Postres dumps this as a hexadecimal string.
The API updates all vehicle locations every 30 seconds and I’ve been requesting updates every 25 seconds and ignoring duplicates, so I should have all of the data on vehicle positions that have been made publicly available. I’ve tried to keep my script running steadily, but there have inevitably been a few interruptions as the postgresql server has been restarted, etc, so there may be some big gaps. Where there is any data, it should be complete; It just may skip out for a day or two. The earliest date I have is 2017-05-16 17:59:36.
Anyway, here is the script I’ve been using along with ancillary files:
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!
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/ .
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:
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 running3.
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.