1 Boarding 2 Next Page 3 4

A silly academic paper about Cincinnati’s 591-6000 roadkill dataset

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

Comments: Leave one?
Posted in: Data | Silly Bullshit
Tags: | | |

Dead-end Ratios

Just some Cincinnati-themed output from some work I’ve been doing recently… this is a map of the percent of streets, by length, which are dead-ends (for cars).

Cincinnati car dead-end ratiosData is from OpenStreetMap. The darker area on the map is defined by a street density of greater than 4km of roads per km2. The X and Y scales are in kilometers. Now a few other random cities for comparison. Smoothing was done with circular gaussian kernels with a standard deviation (bandwidth) of 2km.


houston_carAtlanta:atlanta_carCleveland:cleveland_carMuch more on this to be presented at the NACIS 2016 annual meeting this October!

Comments: Leave one?
Posted in: Analysis | modes
Tags: | | |

Rethinking the Urban Bike Map

Gosh. I’m going to do one of those academic blog posts where I self-promote by telling you that I’ve just published a paper and that you should go read it. I hate those. But, I had actually been meaning to make my thoughts into a blog post or two, and without the intervention of my academic advisor at the time, I would have; now the thing is a paper instead of a post, a full year after it would have been a post, and have I mentioned that you should read it? It’s about bike maps, and what I hate about bike maps and how I attempted to make them better as a genre, by example, and then by overly formal peer-reviewed explication.

The paper is in Cartographic Perspectives which is the journal of the very cool North American Cartographic Information Society who’s conference I attended last year. Cool people. Very friendly. If anyone out there is considering being a cartographer in North America, I recommend you do it, and not just for the conferences and open access journals.

P.S. Here is a link to the article PDF just in case the above link breaks when the issue gets published.

Comments: 4
Posted in: Bicycles | Maps | Psychological
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: | | | |

Moderating two definitions of access

This post was written in the winter of 2014, but for some reason I got distracted and never posted it. Now I’m cleaning house, and here it is! In case you were wondering why it’s about winter weather…


About twice a week, I find myself waiting for the #17 at 13th and Main, heading up to UC for the day. The #17 works well for me since the geography department is on the west side of campus anyway, though in the winter more often than not I find myself wishing for a bus, any bus, for the love of god, when is the bus coming? My hands are freezing! I find myself here almost every day, but about twice a week, like I say, I find myself in a particular situation: passed up by a bus that’s going the same place I’m going, its clean, brightly lit, warm interior mocking me through it’s big windows. I don’t care it’s it’s going to the other side of campus. I just want on.

The M+ has just passed by. My inclination is to run for it’s next stop, but my position on 13th street denies me the option.

Too far.

Once I see the M+ coming up Main, it’s too late to run south to the courthouse stop, too far and still too late to run up to it’s next stop at Findlay market. This is why the M+ is marginally faster than the other buses. It doesn’t stop for people like me, people of course, not at it’s limited and clearly signed set of stops.

The 13th Street stop is the one closest to my house and it’s always my starting place when catching transit up to campus. I always look south when I get there, and if I don’t see anything coming, sometimes I’ll sneak toward the courthouse, stop by stop, never getting too far away in case a bus pops out of nowhere. (Sometimes I creep north, constantly looking back…do I have time to grab a baguette?!? I pay for it, already half-way out the door.) The courthouse stop, see, has better frequency toward campus since it works for both the #17 and the M+, two high-frequency lines going where I want to go. Since they don’t usually arrive at exactly the same time, their headways compound and we get some constructive interference.

But it’s more complicated than this. Because the schedules for the #17 and M+ don’t work together, aren’t coordinated, reliably interrelated, I never know which to catch, which will actually get me to Braunstein Hall first. Both are frequent enough that I wouldn’t bother looking at a schedule if I wanted either, and both are so often just a little late or early that it wouldn’t do me much good if I did. In the absence of real-time-location information…you know what? Let’s let this derailment happen. Why not?

Where the h*ll is that real-time data, SORTA? What’s the deal here? This is getting really frustrating, now that the real-time info is posted at half a dozen stops. You’ve missed at least three of your own deadlines for releasing it. Stop making excuses and get your shit together!!!! RAAAGHAHG!!!1

*Phew* OK. Back on track. Without that real-time data, I’m essentially looking to ascertain the quantum state of the buses. Buses here are both a wave and a particle. Clearly working in a regular pattern, they still come in discrete chunks which can be discovered only by measurement and then never exactly predicted.

What’s a boy to do?

Stop fussing and wait an extra minute perhaps. That would be too simple though.

A big part of my problem here is that the schedules aren’t coordinated, meaning that they overlap and interact with each other in unpredictable ways. If they were coordinated, I could decide now which stop is usually the better one and stick to that decision.

In this particular situation, there’s not a good case to be made that these ones should be coordinated since they split off from each other once they get to the hill, but my dilemma illustrates a broader problem with the way SORTA has conceived of BRT: as a fast express line mostly redundant to a slow local service. Schedule coordination is impossible where lines are running at different speeds.

And this same problem becomes more dramatic when I consider other destinations. Lets say I want to get to Norwood, or once there, even further out to Kenwood. In the first case, I would have to take a bigger risk in walking toward the courthouse stop.¬† The #4 turns east around the corner from the courthouse stop, meaning that I can’t even see it coming.

The best choice would necessarily be based on expected waiting times and expected travel times. A better-than-probabilistic decision can’t realistically be made during higher-frequency hours since the normal(in the non-statistical sense at least) delays, disrupt shorter and more-frequent trips more, relatively speaking. In the later case, I would most likely be presented with the same optimizing tactic that finds me sneaking south on Main Street. That is: walk to the nearest stop on Montgomery Road and once there, inch toward the closest higher-frequency stop, taking in any case whichever bus comes first. Once I know the position of one bus, the one having just arrived, I won’t typically wait around for the next since it’s position is unknown and possibly very distant. Assuming both came at once, and were both stopping, the choice would be easy: the faster one.

The problem here is one of lost potential. It’s not a bad situation by any stretch(I have two reasonably frequent-transit options! Yay!) but it could be better. Rather than having two transit lines in the same corridor running at ten-minute headways, one dramatically faster than other, we could have one line, significantly faster than what we have now, running more consistently, more frequently, and importantly: more simply.

Express lines, as SORTA have conceived them, split the baby.

Show 1 footnote

  1. real-time data DOES exist now!
Comments: Leave one?
Posted in: Access | Analysis | Simplicity
Tags: | | | | | | |

Recursive grids for density measures

I’ve been wanting to do this for ages… and I finally did!

The idea is this:

  1. Create a square.
  2. If the square has more than n things inside it, divide it into four parts.
  3. Do the same for each of those squares and so on recursively.

My recent pet project1, 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):

population density cincinnati quadgrid

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…

Show 1 footnote

  1. I love the idea of a density measure of sprawl!
Comments: Leave one?
Posted in: Data | Maps | Silly Bullshit
Tags: | | |
1 Boarding 2 Next Page 3 4