OpenStreetMap
I came across this section of an Interstate today:
Notice how the Interstate looks a little like it’s been draped across the terrain’s ridges and valleys? That’s probably because the road was originally traced from non- (or not fully) orthorectified imagery. (From perusing the history of the way’s geometry, it looks like the culprit was someone in the US Census Bureau; the waviness was there in the TIGER import.)
I matched the geometry up to Maryland’s six-inch imagery (which is, in my experience, excellently aligned and rectified) with this result:
This post is just a reminder that you should be evaluating the qualities of the aerial imagery you use and not just blindly tracing from it.
Discuție
Comentariu de la Baloo Uriza pe 28 iunie 2012 la 02:07
Wow, what renderer is that?
Comentariu de la stevage pe 28 iunie 2012 la 07:37
I think it’s a reminder that you don’t have to get it perfect first time. There wasn’t much wrong with the original tracing - it was perfectly fine for navigation. If the original tracer decided “this imagery isn’t perfect, I’m not going to use it”, there wouldn’t have been any highway at all.
Imperfect is much better than nothing.
Comentariu de la Sanderd17 pe 28 iunie 2012 la 10:25
I agree with stevage. Only the rendering looked a bit weird, but it was perfectly usable. It was even good routing and searching (what you don’t have with certain features that are rendered great but lacking other qualities).
Although accuracy improving should always be done when possible, it’s not as valuable as adding new data (both rendered and un-rendered).
Comentariu de la asciipip pe 28 iunie 2012 la 11:54
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).
Comentariu de la Baloo Uriza pe 29 iunie 2012 la 19:58
@asciiphil: Oh, cool; does it check relations or just the ref= on the way? Which takes priority?
Comentariu de la asciipip pe 29 iunie 2012 la 21:07
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
Comentariu de la mapmaker1559 pe 21 noiembrie 2016 la 00:17
@asciiphil: Did you know that the “MD 2014 6 Inch Aerial Imagery” is actually the exact same as the “USGS Large Scale Imagery”? :)
Comentariu de la asciipip pe 21 noiembrie 2016 la 03:05
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.)