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…
Design and development of the real-time arrival displays has finally begun!
Wireframe showing basic layout of the display (draft)
And while that is ongoing, we are seeking early adopters to sign up to get a display for their business. The deal, in a nutshell, is this: we’re subsidizing the purchase of tablet computers set up to run a localised real-time transit display. Businesses will be responsible for somewhere between $20 and $40 of the cost of the tablet and will be responsible for maintaining it in a prominent location, with a source of electric power and a good wifi signal. We will help to supply mounting hardware, if needed, appropriate to the location. Businesses must be located on a fairly major transit line, preferably in a business district or an area with a lot of foot traffic. We’re imagining that tablets will either be placed in side-walk facing windows or placed prominently inside the business such as behind a bar.
If you’re interested in getting a display for your business, please email Daniel Schleith. He’ll get your information, answer any questions, and let you know when we’ve selected the lucky winners/trendsetters who will receive tablets.
(Please note that once the app is ready, you’ll also be able to run it in any computer with an internet browser, not just on these tablets.)
More info here.
The first proper real-time app using SORTA’s new data has finally been released! It’s name is Bus Detective, and it’s available for Android, iwidgets, and web browser. The app is being developed by the decidedly friendly people at Gaslight, a software development company downtown across from the main library. Daniel and I met with them a couple weeks ago to talk about collaborating on our recent grant to develop a real-time display for local businesses. I found them hospitable, helpful, and most importantly to me, meaningfully interested in the usefulness of the thing: about half of the office takes transit to and from work every day. They are their own beta testers!
( You may also recognize Gaslight as a sponsor of the Cincinnati Bike Map. Gaslight rocks and their office is full of bikes too. Give them highfives when you see them. )
As for the app itself, it’s pretty simple right now, as it probably should be. You can click through all of the features as quickly as I could describe them, so I’ll leave you to that. The highest praise I can give it is that it seems to work. I’ve used the app a half-dozen times, and played around with it quite a bit. The interface is nice and simple and intuitive and most surprisingly of all, the data behind it seems pretty accurate. The buses come when it says they will. Plus, that logo. Gosh.
For all the developers in the room, Bus Detective is open-source and available on GitHub. Anyone who finds a technical/useability problem with the app should report a bug there. My understanding is that more features are coming soon, so there’s that to look forward to also.
Overall rating: 4.7 stars out of 5. ( You’ve got to leave some room for improvement, right? )
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!
And here it is.
I’m pretty proud to say that beside searching for the elusive schedule padding, and possibly finding some, I managed fit in a comment about the inevitability of death, a quote from Jerry Seinfeld, and a self-deprecating jab at the idea of human rights.
Also, I put videos in a PDF. Who the hell knew that was possible?