Dual Carriageways

When I first started editing OSM, I was mostly doing residential roads and bike trails. Eventually I worked my way to major roads. Some of them had dual carriageways. In my case these were also US/State highways. Somehow I got the two mixed up in my head and thought that mapping any dual carriageway road required relations. Since I didn't know much about relations at the time I was kind of scared to touch them. Turns out relations ARE used to describe highways however they are not required for dual carriageway roads.

Since I've recently been working on "dualizing" roads in the Kansas City area, I thought I would throw up a quick post about the process. It has probably already been done (I seem to recall a "TIGER fixup" tutorial that described the process) but here is my version.

To Start off with, let's define a dual carriageway road. There may be some difference of opinion (there usually is in OSM) but in general it is any road where the opposing streams of traffic are separated by a physical barrier. A grass median (think interstates) or a strip of trees in the middle of a boulevard are prime examples. Sometimes the barrier is just a small strip of raised pavement or bricks. Regardless, it is something that would make your car go "bump" or even cause damage if you were to try and drive through/over it.

Airports, Part 2

In my first installment of the airport series I presented some basic mapping techniques I used while mapping rural airports in Kansas. One comment I got on IRC suggested using a slightly different tagging scheme for displaced thresholds. The suggestion (I believe it was from pnorman) was to tag it with two tags. One being aeroway=runway and the other being runway=displaced_threshold. While I haven't gone back and changed my previous work, this may be a better way of doing it. First of all, they would get rendered on the default map. I know, I know... "don't tag for the renderer!" But here's the thing: This is technically not incorrect. Displaced thresholds are considered part of the runway and are included when the runway length is specified. So tagging it as a runway but then specifying that it is a specific type of runway is not incorrect tagging. On standard maps it would be rendered as part of the runway but someone making an aeronautical themed map could use the runway=displaced_threshold tag to differentiate it and produce a customized rendering.

Before I go on, I am just going to repost a link to the OSM wiki page for Airports as a reference.

Now on to some new material. I was moving west-to-east through Kansas so the first "big deal" airport I came to was the Salina Municipal Airport. Its 17/35 runway is a massive 12,300 feet (3.8 kilometers) long. Any aircraft currently in service could land here with room to spare. Why does a municipal airport in a city of under 50,000 people in the middle of Kansas have such a massive runway? The military, of course! This facility was built at the beginning of World War II and was used to train heavy bomber crews. Then during the cold war it became part of Strategic Air Command operations until it was closed and turned over to the city of Salina in 1965. (source: wikipedia) Now it serves mostly general aviation but is also used by Kansas State University's aviation program which is based at the Salina campus. A few years ago it was used by Steve Fossett as the start and end point of his solo, nonstop flight around the globe. And I got to bill them for the telecommunications services they used while doing it! (My current day job deals a lot with the telecom billing system at KSU)

I promise, I'll get to the mapping in this post, eventually. But I should point out that this is one thing I love about contributing to OSM. Seeing something unusual in aerial imagery can often lead to an hour spent on wikipedia or a fun discussion on IRC involving people from around the world or, occasionally, a field trip to go see what the heck is happening "on the ground" to cause it to show up a certain way in aerial imagery.

Airports, Part 1

For the past few days I've gone on an airport binge in OpenStreetMap. I ended up learning a lot about airports. It was fun to start mapping, then come across something different or notice a new detail and realizing that this too can be mapped! Here are my musings on the subject. Feel free to tell me I did it all wrong in the comments :)

The recent import of airport nodes from www.ourairports.com and the subsequent discussion sparked the idea to map easily identifiable runways from aerial imagery. So I downloaded all "aeroway=aerodrome" nodes within Kansas from the XAPI. In addition to the above mentioned import, a lot of airports were imported from USGS GNIS (Geographic Names Information System) back in early 2009. In total there were just under 600.

This being Kansas, a vast majority of those 600 "airports" are nothing more than a flat spot in a field where farmer Joe lands his crop duster. They have such names as "Lundgren Hereford Ranch Airport" or "Flying N Ranch Airport." They should probably be downgraded from "aerodrome" to something else and not rendered at zoom level 10 like they are now. Right now looking at western Kansas at z10 reveals a ridiculous number of airports being rendered. I have yet to see any consensus on a tagging scheme for smaller airports so I mostly just ignored them. Additionally, the aerial imagery I was using (USGS NAIP) wasn't really good enough to reliably pinpoint these grass strips in the middle green fields. It also didn't help that the GNIS information is often off by quite a bit so I wasn't sure if the runway was just blending in or if there really wasn't one in the field I was looking at but rather 2 fields over.

The more interesting airports are the municipal air fields. Most of these have a paved runway, sometimes in addition to a grass one. Even small airports stick out when they have a paved runway:

Updated TIGER map

For a full history of this post you may want to read these three posts first: 1, 2 and 3.

When I first presented my nationwide TIGER map at wherecamp5280, Samat mentioned that he was surprised that his county wasn't more heavily edited since he has done a lot of work there. A few days ago we were chatting on IRC (#osm on oftc.net) and he asked a question that made me realize that the map did indeed have a serious flaw in it. Earlier today a discussion came up on the talk-us mailing list that made me notice that the same error exists in the TIGER edited map that MapQuest (re)set up. So I decided to look at correcting it.

The error is that I was only looking at the latest version of the ways. This means that any edits between the original import and the mass edit that expanded street names were not taken into account. Both the import and the abbreviation expansion happened well before I started mapping so I didn't even consider this fact. As Antony Pegg says later in the mailing list thread, it is too expensive to go back and look at all previous versions. Especially since you would have to use a FULL planet file since the regular ones only contain the current version of objects, not a full history.

But we don't really care about the contents of the edits or who performed them... we just care that they happened. The initial import obviously created version 1 of the ways and if nothing else changed, then version 2 was created by balrog-kun in the name expansion edit. If any edits happened between the import and the name edit, then the ways will be on version 3 or higher. Thus any TIGER way with a version higher than 2 must have been edited by someone other than these users, even if one of them was the last to touch a way.

So here is the updated map which takes this into consideration:

Nationwide TIGER Map

Update: You should of course still read this post because it is is awesome but there is a new post with an updated version of the map here.

I presented most of this material this weekend at WhereCamp5280 and promised to put this online soon. I have a few more details and maybe some raw data that I will put in another post after I get back home after Thanksgiving but for now I'll throw up what I have.

Well after some sweat, blood and tears (mostly on the part of my hard drives) I was eventually successful in extracting the data I needed to make a map of the entire US! If you just want the map feel free to skip down but I am going to document my trials and tribulations a little.

First, some things that did not work:

Two more TIGER maps

After my last post there were some requests for me to do additional states. So I imported Colorado and New Mexico since they are kind of one big block. However doing 50 states a couple at a time will be rather cumbersome so I think after this I will try to coax osmosis into doing a more fine-tuned import so that I can import only the things I need but do it for the entire US at once.

I also learned some more quirks about ArcMap. The program is amazing in some ways but user interface is not one of them. I was also unable to figure out how to use two different fields to join my data to the counties shapefile. So that was slightly frustrating but I was able to work around it.

Anyway, until I get around to poking osmosis again,
I give you Colorado:

TIGER ways in Kansas

Update: I have a second post with two more state maps up here. More to come!
Update 2: Here are two more posts with nationwide maps.

If you are at all familiar with OpenStreetMap, especially in the US then you will know that most of the roads here are imported from the US Census Bureau TIGER data. This data was imported from the current data in 2007. It is fairly complete but the accuracy leaves a lot to be desired in some areas. For example look at this screen shot comparing the TIGER data to reality (USGS aerial imagery in this case). Some roads are off by over 200 meters. And there are even worse spots - this was just one I was able to find quickly.

Example of bad TIGER data

While the data was pretty complete when it was made, it is now several years old and missing many new housing developments and does not reflect instances where roads were moved. The good news is that, this being a census year, there will be new TIGER data available from the Census Bureau starting at the end of the year. It will be more complete and probably more accurate considering that GPS technology has made some advances over the last 10 years.

Well that's great but the question is how do we use the new data to improve OSM? In the software world this would be an ideal situation to use a diff utility to determine what had changed between two versions and apply patches to update the old version. But I am not aware of any geo-spatial diff utilities.

So how about just deleting the old data and re-importing the new stuff? This would obviously be a disaster in areas with active mappers. All the work they have put into correcting existing TIGER ways would be destroyed and replaced with data that is probably better than the old TIGER import but also probably worse than what local mappers have done.

BUT...