If anyone is interested in a progress report: I've been doing a lot more work on this in github to incorporate feedback that people have provided on- and off-list and to improve robustness, and I think it is pretty close to being usable.
I haven't found a completely satisfactory way to handle the transitions between edited and unedited sections of the map, since any position adjustments either to the OSM-edited locations or to the TIGER-edited ones seem to introduce some sort of distortion somewhere. The best thing I have come up with is a policy of not moving any nodes that are connected by a way to another node that is can't be matched to one from either the old or new version of TIGER, and therefore must be represent a substantial edit on the OSM side. The areas that ought to be moved but can't be without risking conflict can be a separate output file to look at manually. The other thing that has come up is that there are a lot of TIGER edges that do not correspond to OSM ways in either their old or new version. In Indiana most of these seem to be linear water. Were these intentionally excluded from OSM? Or would it be useful to try to pick them up as part of the set of changes representing additions to TIGER between 2006 and 2013? Eric On Tue, Mar 12, 2013 at 6:34 PM, Richard Welty <rwe...@averillpark.net>wrote: > On 3/12/13 9:32 PM, Eric Fischer wrote: > >> Thanks for the helpful comments. At least anecdotally, I think I have >> actually seen the TIGER merge lead to more anomalies in gridded areas than >> in hills, maybe because people feel more comfortable making minor edits to >> mostly-regular grids. >> >> I completely agree that any new ways imported from TIGER will have to be >> reviewed manually, if for no other reason because they generally don't >> connect to any existing node. >> >> I am intending to produce the additions and adjustments as separate .osc >> files that can be examined for correctness in JOSM before being applied. >> Would people generally be comfortable with accepting node relocations that >> don't cause any ways to overlap themselves without extensive manual >> review, >> and only carefully reviewing additions? >> >> i think the best approach is to manually review early ones to develop > some > comfort level with the non-overlapping case. > > richard > >
_______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
