[Talk-us] Updating unchanged TIGER imports to TIGER 2013
enf at pobox.com
Sat Mar 16 00:03:39 UTC 2013
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?
On Tue, Mar 12, 2013 at 6:34 PM, Richard Welty <rwelty at 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
>> and only carefully reviewing additions?
>> i think the best approach is to manually review early ones to develop
> comfort level with the non-overlapping case.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Talk-us