On Tracing from Poor Imagery

Posted by asciiphil on 27 June 2012 in English (English)

I came across this section of an Interstate today:

The Effects of Non-Orthorectified Imagery

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:

Freeway Traced from Orthorectified Imagery

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.

Comment from Paul Johnson on 28 June 2012 at 02:07

Wow, what renderer is that?

Comment from stevage on 28 June 2012 at 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.

Comment from Sanderd17 on 28 June 2012 at 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).

Comment from asciiphil on 28 June 2012 at 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).

Comment from Paul Johnson on 29 June 2012 at 19:58

@asciiphil: Oh, cool; does it check relations or just the ref= on the way? Which takes priority?

Comment from asciiphil on 29 June 2012 at 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 . I still need to get around to documenting the tagging it understands, but most of the details are in these talk-us@ posts:

Comment from mapmaker1559 on 21 November 2016 at 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"? :)

Comment from asciiphil on 21 November 2016 at 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.)

Login to leave a comment