[Imports-us] A proposal for handling the tiger realignment
enf at pobox.com
Sat Aug 10 20:25:45 UTC 2013
Here's an example of what can go wrong, and how I am attempting to resolve
a couple of streets in Knox County, Indiana called North Wood Drive. TIGER
in 2006 mapped it as two streets with loops at the end, plus a circle
around the whole thing. TIGER in 2010 relocated the two streets, removed
the loops, and apparently changed the circle to a different feature class.
The problem is that there is no automatic way to distinguish between an old
TIGER way that was deleted and one that was simply renumbered, so as far as
the realignment tool knows, those loops may still exist with a different
ID. So when it moves the two ways for North Wood Drive, it must also leave
their endpoints connected to the loops.
The result is the horrible mess on the right hand side of
http://farm8.staticflickr.com/7292/9475677213_2f1374862f_o.png with most of
the two branches relocated as they should be, but with the endpoints
snapping back across the nonexistent circle to reach the nonexistent loop.
The conservative approach that I have been trying to take is the left hand
side of that image, where the entire thing is left in place except for the
southernmost segment of the road because everything north of that is linked
in OSM to things that can't be checked against TIGER. It introduces its own
smaller flaw by moving the intersection with North Buck Thal Road where
TIGER says it is now but having to jog abruptly to connect with the rest of
the old TIGER street, but at least there aren't any horrible cases of roads
crossing over each other.
In this case there is probably actually some potential to detect that the
loops were deleted from TIGER because there is nothing new connected to the
ends of the TIGER roads where the loops used to be. I should see if there
are more cases like that.
On Fri, Aug 9, 2013 at 12:04 PM, Eric Fischer <enf at pobox.com> wrote:
> I'm doing a terrible job trying to reply to this from my phone. I'll give
> you some concrete examples of conflicts at the joins once I am back at a
> real computer later today.
> On Aug 9, 2013 10:45 AM, "alex at mapbox.com" <alex at mapbox.com> wrote:
>> > since there is no information then about how those two relate.
>> Can you expand on this?
>> On Aug 9, 2013, at 1:27 PM, Eric Fischer <enf at pobox.com> wrote:
>> It doesn't move any nodes that anyone else has moved. The tricky part is
>> the edges where one point has been moved and TIGER wants to move an
>> adjacent point, since there is no information then about how those two
>> On Aug 9, 2013 10:22 AM, "Alex Barth" <alex at mapbox.com> wrote:
>>> On Thu, Aug 8, 2013 at 11:33 PM, Serge Wroclawski <emacsen at gmail.com>wrote:
>>>> What that means is that we can create a metric of OSM activity in an
>>>> area, and by doing that, decide whether or not the area should have an
>>>> automated import process, or a manual review process.
>>> Ccorrect me if I'm wrong (eric fischer) - isn't that what the automated
>>> script inherently does by only touching nodes that haven't been touched by
>>> Imports-us mailing list
>>> Imports-us at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Imports-us