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.
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!
The map will be on the presses shortly and should be ready for distribution by the end of August. I had actually finished just before I left for Europe a couple weeks ago, but there was a little trouble with the folding that delayed things. I had to wait until my new (European) phone plan kicked in to let me call my partner who is now working with the printer for me.
That link up there goes to the folder where I’m keeping the most recent raster version of the map for the printer. It may yet be updated a teeny bit. PLEASE NOTE that the color is not optimised for RGB yet. I designed this for a specific printer/paper and, trust me, the colors look better on paper. You can get a bit closer to seeing the actual color of the map by looking at this image. Once I get back home and back to my desktop computer, I’ll be able to work on an RGB color-corrected PDF version for the web. I thought y’all might like something to look at in the meantime though :-)
Also note that there is a 1/3″ bleed included in those images which will be trimmed off. That too will change in the PDF/web version.
I can’t wait to see these little buggers finished! ^-^
Individual Sponsors: Justin Ogilby Minh Nguyen
Jack & Lyn Martin
I’m back in town now after a little trip to New York. Off to DAAP shortly to test-print/color-check some things I was playing with on the train.
I decided that one of the inset maps will show regional trails between Cincinnati, Columbus, Dayton, Xenia, etc. Another will detail elevation, and a third will highlight transit and retail areas. I’ve also been riding all around the city, which is much more tiring and time-consuming than I had expected, looking for speed limit signs and finding water fountains. If anyone knows of any fountains on the west side outside of Mt. Echo park, you could save me some time by telling me about them!
The most difficult part has been working on my script to identify dead-ends in OpenStreetMap data, but that’s coming along too.
I’ll try and post some screenshots here later this week as I develop things I feel ready sharing!
The Cincinnati Bike Map, now so nearly complete, seeks sponsors to help finish the work and get the project to print.
Here’s the basic idea: Most bicyclists, most of the time, are using the streets. They’re using the streets for increasingly diverse ends in fact, from training for a race to picking up groceries. Such diverse users, each with their own ends and abilities, must have objective information on the conditions of the roadway, most notably of their potential relation to it’s automotive traffic, if they are to make informed decisions when planning their trips or finding their way.
Beyond this navigational goal, the map is also an advocacy tool, showing objectively what someone might expect were they to try riding a bike. This role emphasizes the importance of a tangible, printed map, as opposed to a shifting, digital one, in conveying a reliable, secure reality that people can learn to understand and depend on; a security they must feel if they are to try something they are unused to1.
Concretely, the map will measure 24″x31″, fold down to a pocket-size 4″x5.16″, and take in 210 square miles of Cincinnati and Northern Kentucky at a 1:28,000 scale. 10,000 copies will be printed locally and distributed for free through a variety of outlets targeting cyclists and potential cyclists. All data and work will be available, freely under an open license2.
Your sponsorship supports this work and gets your name on the map. Sponsorship Levels:
Individual: $50 — get a thank-you shout-out on the map, and as many copies as you can use/distribute mailed to your home address.
Silver Level: $200 — The above and your organization’s logo on the map.
Gold Level: $500 — The above and two lines of text next to your logo such as a url, address or coordinate location on the map
If you’re interested in sponsoring, please send me an email with your information. You can and use the button below to donate through paypal or I can give you an address to send a check.
I’m shooting for publication in Late July or Early August.
Thanks to a very generous grant from the Haile Foundation, we’re most of the way to our goal of $7,000 for production and printing.
Raised already: $6,800
Left to go: $200 )
What the money will be used for:
About 80% of the money will go directly to printing and distribution costs. The rest will help me keep a roof over my head while I finish the project since I have no real income over the summer. That’s right, about $1,400 to pay a highly educated cartographer for a couple month’s hard work. I live pretty cheap ;-)
What still needs done:
There are a few places I know I need to ground-truth the OpenStreetMap data and make updates and corrections, notably the West Side and parts of NKY. I’m sure this involves at least three days on a bike, riding around checking speed limits, verifying the existence of water fountains and traffic lights, one-way streets and various other things.
I need to finish thinking through the necessary contents of a couple inset maps, pull those together and fit them into the layout.
Several over-all stylistic choices need to be made still, including the final colour-contours for the elevation layer which still aren’t totally satisfying.
Once the data and layout are completely finalized, the map needs detailed annotation and careful labelling of the more detailed features.
Then finally, distribution, which I expect will take a couple weeks on and off.
I thank you heartily and preemptively for your support.
And this secure reality really is secure and stable, despite our learned desire for up-to-the-moment updates. Infrastructure changes at an extremely slow, incremental pace. I also want to make clear that while I’m emphasizing a tangible, printed map, adding a digital version to this website is a trivial task, so an online version will certainly be available as well. ↩
Meaning that I’m not hogging the ideas here. I’m trying to make bike maps better, not make a buck off of updating them. ↩