And what if everyone had an even probability of visiting some other fellow cyclist who lived between 3 and 8 kilometers away from them? This would be a beautiful and strange world. Here is what the traffic might look like in that world, assuming there were no effects of congestion. Thicker lines have more bikes:
Line thickness is scaled to the log of a measure of betweenness, based on optimal paths for bicycles, as defined according to current OSM data and OSRM‘s default bicycle routing profile. ‘People’ were located randomly inside their 2010 home census block and routes were calculated between random pairs of people where the straight-line distance between them was between 3 and 8 kilometers. The distance limits are to simulate reasonable cycling trips and work against MAUP effects.
This is the first step in a project to develop mode-specific street hierarchies, which can be used in transport maps where auto-based classification schemes are undesireable or unavailable. In the coming days, I’ll work on a better weighting scheme (than population density) and look at other modes and cities. I’ll be working the results into a poster for NACIS 2017, showing the different hierarchical classifications that result for cycling, walking, and driving modes, hopefully across three cities with widely different development patterns (Cincinnati, Toronto, …?)
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.
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.
I said when I was working on the bike map that I would get around to publishing the ‘source code’, and now that I’m preparing to leave the city, I feel I ought to finally do that. So! The basic idea of this post will be a step by step instruction for how to make yourself (or your city) an updated Cincinnati Bike Map. Strictly speaking, this will work for other cities too, but please note that the map was designed for Cincinnati in 2014 and other cities in other times, with different (data) structures may simply not work well at all.
Let’s get started!
Step 1: Get the software you’ll need: QGIS, PostGIS(a PostgreSQL extension), osm2pgsql, osm2po, GRASS, PHP(for one of the scripts), and Inkscape and GIMP for the final layout. All are free and open source and run on Linux (but probably other things too).
Step 2:Update the data! A big and important step. The vector data is all from OpenStreetMap and the process of editing OSM is well documented elsewhere, so I needn’t go into it at all here.
Step 3: Go to OpenStreetMap and navigate to the area you want to download. Be generous and include at least ten extra miles on all sides of the map you’ll be making. Click the ‘export’ tab and use the ‘Overpass API’. It will prompt you to download a large .osm XML file to your computer.
Step 4: Import that data into a PostGIS database twice: once with osm2pgsql and once with osm2po. The first will bring in the OSM data as-is, with as many tags as you care to import. To do it the way I did it, you should use this osm2pgsql.style file. The second one, osm2po will slice the linear path data (the streets and stuff) into a table of routable nodes and edges. For that one, you may want to try this configuration file. If that doesn’t work, the real point of it is to include paths that bikes can use (paths, pedestrian streets, stairs, etc), which are not included by default, while leaving out the rest.
Step 5: Process the data from osm2pgsql using this SQL script. It does quite a few things, including setting (short) street labels, calculating speed in mph, setting default speeds and lane-counts for no-data streets, identifying landmark buildings, and pulling a number of features into a consistent format for better/easier rendering.
Step 6: Run this SQL script to merge the two tables you’ve imported into one table that is both routable and has all of the important attributes/tags from OSM.
Step 7: Run tarjan.php on the new/duplicate segments table. This script uses Tarjan’s Algorithm to identify edges that connected at both ends to the main street network, and those that are not, leaving the results in a boolean field on that table.
Step 8: Once the dangling edges are identified, run this SQL script to drop the minor paths that go nowhere. Major dead-ending streets will be kept. Things like driveways will be dropped.
Step 9: Get the elevation data. I used data from the USGS (use their national map tool to download). I found that of the two decent resolutions available, one was too course (I could see pixels) and the other was too fine (I could see buildings). I chose to smooth out the finer data, using a neighborhood average in GRASS. I suppose you could also go at that the other way though too, increasing the resolution and then smoothing. The point is to get an amount of detail that just looks right and doesn’t have any visible pixelation: use your gut!
Step 10: Now you have all the data ready to go in your PostGIS database, and you just need to drop it into QGIS and style it. I wish things were easy enough that I could share a simple stylesheet with you; the way QGIS does it, the style information is all bound up with information about the table. That means that if your table/database/column/everything names are different from the ones I used, you’re going to have trouble making this run smoothly. In the interest of giving something here though instead of nothing, I’ll link to the QGIS map files used to render the main and inset maps (hills, transit, and trails). These may not be directly useful, but you could look at them as XML files, and see precisely how things were styled including line widths, hex colors, etc. It may also be useful to sample colors directly from the digital version of the map using something like GIMP. Once ready, export these maps as 300+DPI rasters using the following templates: main map, 1/3 scale inset maps.
Step 11: Now we have the base maps, we’re finally ready for the layout! I did the layout in Inkscape SVG, linking to the exported raster maps which I placed in an adjacent directory. You’ll have to re-link those, but the frames should still be in the right position.
Step 12: Profit.
Well, that’s about the gist of it. … I don’t actually think that hardly covers it, but there’s not enough time in the world to document everything for an uncertain future that may or may well not contain good bike maps. And anyway, I don’t expect anyone to slavishly duplicate my approach. We’ll call it a limited edition ;-)
If someone does actually want a real update though, I’m always available to answer questions, or if you’re the type to cut right to the chase, for hire. Email me!
Well, it will also be up for a week or so after that, but tomorrow is the night with all the people and the free food. If y’all haven’t been to DAAPworks before, it’s DAAP’s senior show, and it’s actually got a lot of interesting work in the areas of transport, civic design, cartography, and architecture1.
My quick run through the building today, on my way to see the cranky ogres who run the plotting machines in the photo cave, dredged up at least five truly gorgeous maps, most of those local, and two of them definitely using OSM! It’s so rarely we get to see such pretty things. Here, to whet your desires, is a map from a DAAPworks of a couple years past, not my own, that I think is just incredible.
Like this one, a lot of the maps that are most beautiful don’t actually make much sense if you think about them too hard, or even a little. But such things, maps, landscapes, transit plans, buildings, are worth seeing, I think, because they remind us of the potential for grace and beauty in all things, good, bad, or nonsensical — and perhaps also of the excitement of the mind untamed by repetitive mental labor and cautious hedging.