Here's an example of what can go wrong, and how I am attempting to resolve the conflicts.
http://www.openstreetmap.org/edit?editor=id#map=17/38.81678/-87.28315 shows 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. Eric On Fri, Aug 9, 2013 at 12:04 PM, Eric Fischer <[email protected]> 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. > > Eric > On Aug 9, 2013 10:45 AM, "[email protected]" <[email protected]> wrote: > >> > since there is no information then about how those two relate. >> >> Can you expand on this? >> >> >> http://twitter.com/lxbarth >> >> On Aug 9, 2013, at 1:27 PM, Eric Fischer <[email protected]> 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 >> relate. >> >> Eric >> On Aug 9, 2013 10:22 AM, "Alex Barth" <[email protected]> wrote: >> >>> >>> On Thu, Aug 8, 2013 at 11:33 PM, Serge Wroclawski <[email protected]>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 >>> contributors? >>> >>> >>> _______________________________________________ >>> Imports-us mailing list >>> [email protected] >>> http://lists.openstreetmap.org/listinfo/imports-us >>> >>>
_______________________________________________ Imports-us mailing list [email protected] http://lists.openstreetmap.org/listinfo/imports-us
