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.
Parola
Comentario de Baloo Uriza no 28 de Xuño de 2012 ás 02:07
Wow, what renderer is that?
Comentario de stevage no 28 de Xuño de 2012 ás 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.
Comentario de Sanderd17 no 28 de Xuño de 2012 ás 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).
Comentario de asciipip no 28 de Xuño de 2012 ás 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).
Comentario de Baloo Uriza no 29 de Xuño de 2012 ás 19:58
@asciiphil: Oh, cool; does it check relations or just the ref= on the way? Which takes priority?
Comentario de asciipip no 29 de Xuño de 2012 ás 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
Comentario de mapmaker1559 no 21 de Novembro de 2016 ás 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”? :)
Comentario de asciipip no 21 de Novembro de 2016 ás 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.)