Yep. The USGS contributes funding towards Maryland’s aerial imagery, so the imagery gets integrated into the USGS’s offerings. It takes a lot longer to show up on the USGS’s servers, but the USGS gets the full extent of the imagery. (Maryland clips it pretty close to the state line, even though the planes fly a bit further out.)

Or the data is out of date and the interchange has been reworked; I’ve seen both. But it’s also likely that someone entered the data before there was good aerial imagery of the spot and was going from memory and estimates, which is not horrible, since it’s right enough to be better than no data (even if the topology is a little off).

Relations take priority. If there’s no relation or it doesn’t understand the relation, the way’s ref= tag just gets rendered in a lozenge.

The shields are from the same code that I linked from talk-us@ in April. I don’t have the disk space or bandwidth to host general access to my TopOSM rendering, but the proof-of-concept shield rendering is still at http://elrond.aperiodic.net/shields/ . I still need to get around to documenting the tagging it understands, but most of the details are in these talk-us@ posts: http://lists.openstreetmap.org/pipermail/talk-us/2012-April/007735.html http://lists.openstreetmap.org/pipermail/talk-us/2012-April/007752.html http://lists.openstreetmap.org/pipermail/talk-us/2012-April/007781.html

Paul: It’s TopOSM with some of my own modifications, most notably the addition of the highway shields from osm-shields.

stevage, Sanderd17: Those are good points, and I wouldn’t argue that imperfect imagery means you shouldn’t add things. I think people should consider how their imagery might be wrong, which is more of an issue when it’s old and has things that don’t exist anymore, but I thought this was a nice illustration of one incorrectness that aerial imagery can exhibit.

Also, I came across this while doing a general cleanup on I-68 that included adding surveyed speed limits, aligning ways to imagery, making sure all the road’s bridges and lane counts were represented accurately, and making sure all the interchanges were topologically and geometrically correct (among other fixes, I found a few motorway_links that were pointing the wrong direction).

I’ve dealt a lot with shared nodes in a variety of situations, both created by me and others. I’m not enamored of the practice of sharing nodes between roads and areas, but I prefer if adjacent area features share nodes. That reflects the reality that they abut each other and makes adjustments (if the river shifts course, or just if you’re improving the accuracy of the ways) easier.

One of the two alternatives is using adjacent nodes, which makes adjustments a pain, can make targetting the right node problematic if they’re really close, and doesn’t reflect the situation on the ground.

The other alternative is building multipolygons out of shared ways. I used to do area features this way, but found that the tools we have don’t always deal well with this, and (subjectively speaking) they seemed to be broken by other mappers more often. These days, I try to make area features with continuous, closed outer ways, even if I need to use a multipolygon to add inner ways. When I need multiple outer ways (because there are more than 2000 nodes along the perimeter, usually), I try to break it into pieces in such a way that the line between the endpoints of each piece remains entirely in the interior of the feature, although it’s not always possible to do that.

The odbl=clean tag is probably not the way to go for this. That tag means, roughly, “There are people in the edit history of this object who have not agreed to the new license, but I’m saying that its current state is not at all derived from those people’s contributions.” For the coastline, all of its nodes’ positions are from people who haven’t agreed to the new license, and the only way to get it compatible would be to retrace the entire thing. And, as mentioned above, people are looking at ways to replace this tainted data all long the West Coast of the US.

Also, it won’t be horrible if some coastline data is removed during the license changeover. Most renderings don’t use that data directly: they use shapefiles derived from the data, so we can continue to use the old shapefiles until the coastlines are ready to generate new ones. The missing data will still have to dealt with, but we have more time to do it than it might at first appear.

I tag rail trails as highway=path (or highway=cycleway or highway=footway, depending on the trail) and railway=abandoned. Also, following some tagging I've seen NE2 do, I also add an old_railway_operator= tag when I know what company owned the railway when it was last in operation.

There's a page on the wiki, osm.wiki/Contours , that discusses how to make your own shapefiles. The short version is: get a files with elevation data in them, then run gdal_contour to generate contour shapefiles from the raster images. If you don't have a better source for elevation data, SRTM (linked by Sanderd17 above) has near-worldwide coverage at an acceptable resolution. (If you're in the US, the National Elevation Database is much better quality.)