Sorry to be unclear. The logic is is: 1. Find all the nodes in existing ways that match TIGER 2006 TLIDs. 2. Provisionally move all of them to the corresponding TIGER 2013 locations. 3. Go through the ways again, and back out any moved nodes that have a neighbor that was not itself moved or does not match a TIGER 2013 node. 4. Repeat step 3 until there are no additional changes.
I think the result should be that each area being moved is entirely buffered on all sides by at least one existing node that TIGER 2013 thinks is correct. This should also handle adjoining ways: if a node is proposed to be moved in one way but is also used in another way in which its neighbors can't be confirmed, it should cause that node to be rolled back wherever it is used. I really do not want to consider only ways that have not been edited at all because it is so common for a few blocks in a way to have been corrected and the rest left misaligned. I don't think it would really help, either, because none of these ways exist in isolation: they all eventually connect to something that has been edited. I don't know how to guard against the case where TIGER is simply wrong. By inspection it seems to be right more often than it was in 2006, and I don't have reason to think its changes were made in bad faith, but I don't know. I don't think the particular LA case can happen, because nodes will be moved within a way only if the entire 2006 TLID is still contiguous within the way. If intervening points have been added or some of the control points have been deleted, it will no longer match and will not be moved. (It does assume that TLIDs all run the same direction in 2013 TIGER as in 2006, which may not be a valid assumption.) Sorry for the lack of instructions on the code. I will add a README for everything that it needs to have in place to work. It is unfortunately reliant on having copies in a particular directory structure of 2006 and 2013 TIGER, the north American OSM extract, and a by-county file of the TLIDs that were historically associated with all ways. Is there a convention for where people keep these files so I can conform to it? I run the program myself just by doing $ ./find-tiger-changes > tiger.osc The osc file produced for Boone/Hamilton/Clinton/Tipton County, Indiana is https://docs.google.com/file/d/0B6gxjm4UN7VjU3J4dkw4QVNZRWM/edit?usp=sharing Eric On Sat, Mar 16, 2013 at 7:56 PM, Paul Norman <[email protected]> wrote: > Do you have a written description of the logic you are intending to use?** > ** > > ** ** > > If you only consider ways where none of the child nodes have been moved as > potential candidates for geometry changes this will avoid the > self-intersecting way problem. The self-intersecting way problem is not > confined to cases where someone has moved an OSM node to an incorrect > location. I see two obvious cases **** > > ** ** > > **1. **The TIGER 2012 geometry is wrong.**** > > **2. **You mix two geometries which are right, but ordering > problems lead to a self-intersecting or badly wrong geometry. See > http://3.bp.blogspot.com/-apHSW0kuiN0/UIczscIpvZI/AAAAAAAABW0/KR3gUr_wZEQ/s1600/redaction_weird_offramp.pngfrom > the section on redaction damage on > http://ksmapper.blogspot.ca/2012/10/licensed-to-map-what-happened-to-la.html.htmlfor > the types of problems. > **** > > ** ** > > You might need to treat end nodes specially and make sure that the next > node in any adjoining ways is also an unmoved TIGER 2005 node.**** > > ** ** > > Your code seems to be a mix of graphing code and diff generation code. > There is also no instructions for running it.**** > > ** ** > > Could you provide .osc files for a couple counties? I know .osc files are > hard for most people to review, but they’d help me at least.**** > > ** ** > > *From:* Eric Fischer [mailto:[email protected]] > *Sent:* Saturday, March 16, 2013 6:48 PM > *To:* [email protected] > *Subject:* [Imports-us] Updating TIGER imports in OpenStreetMap to TIGER > 2013**** > > ** ** > > Hi everyone. (And sorry to anyone who has already seen the earlier version > of this on talk-us.)**** > > ** ** > > At the time OpenStreetMap imported the US Census TIGER map data, the > Census was in the middle of their "Accuracy Improvement Program" that > greatly improved the alignment of TIGER features in many areas for the 2010 > census. Many of the more recent TIGER corrections have since also been > applied to OpenStreetMap, particularly in major metro areas, but not > generally not systematically, and many others, particularly in rural areas, > have not been applied.**** > > ** ** > > I would like to update OpenStreetMap with as many of the corrections that > have been made to TIGER as can be applied to Open StreetMap without > altering anything that has been edited directly in OSM.**** > > ** ** > > In most cases this just means moving unedited OSM nodes that came from > TIGER to the positions that TIGER currently indicates, although in some > cases TIGER edges have had nodes added or removed, so the corresponding OSM > ways must also have nodes added or removed. I don't propose to delete or > move any intermediate points that have been linked to other OSM ways, or to > move any nodes that have been moved in OSM since the TIGER import. I also > don't propose to change any tags on the nodes or ways.**** > > ** ** > > Although this process will never change the topology of the network, it > could potentially cause some odd-looking results where someone has moved > (but not to the correct location) an OSM node that connects to an updated > TIGER node, making streets have abrupt turns or cross over themselves. I > think the safe thing to do is not to move any nodes that are connected by a > way to a node that is more than a few feet from where TIGER thinks it > should be, and to make a separate list of these conflicts that can be > manually investigated.**** > > ** ** > > There are also many cases where TIGER 2013 knows about streets that were > not built or not mapped in TIGER 2006. Some of these have also been added > by OSM contributors but many others have not been. I think the right thing > to do for these is to generate speculative OSM equivalents, but rather than > checking any of them in directly, use something like MapRoulette to review > each of them to see whether or not it ought to be adopted.**** > > ** ** > > The code I've been writing to generate the .osc XML for these changes, > mostly only tested so far on a few Indiana counties, is at > https://github.com/ericfischer/osm-tiger-update A rendering of what the > changes look like in those counties is at > http://www.flickr.com/photos/walkingsf/8562893003/**** > > ** ** > > Please let me know what you think of the idea and if there is a better way > to do it. Thanks,**** > > ** ** > > Eric**** >
_______________________________________________ Imports-us mailing list [email protected] http://lists.openstreetmap.org/listinfo/imports-us
