OpenStreetMap

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?

Hide this comment

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.

Hide this comment

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).

Hide this comment

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).

Hide this comment

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?

Hide this comment

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 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

Hide this comment

Leave a comment

Parsed with Markdown

  • Headings

    # Heading
    ## Subheading

  • Unordered list

    * First item
    * Second item

  • Ordered list

    1. First item
    2. Second item

  • Link

    [Text](URL)
  • Image

    ![Alt text](URL)

Login to leave a comment