That sounds like a good idea to me. I want to be careful not to break anything.<div><br></div><div>Eric<br><br><div class="gmail_quote">On Tue, Mar 12, 2013 at 6:34 PM, Richard Welty <span dir="ltr"><<a href="mailto:rwelty@averillpark.net" target="_blank">rwelty@averillpark.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 3/12/13 9:32 PM, Eric Fischer wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks for the helpful comments. At least anecdotally, I think I have<br>
actually seen the TIGER merge lead to more anomalies in gridded areas than<br>
in hills, maybe because people feel more comfortable making minor edits to<br>
mostly-regular grids.<br>
<br>
I completely agree that any new ways imported from TIGER will have to be<br>
reviewed manually, if for no other reason because they generally don't<br>
connect to any existing node.<br>
<br>
I am intending to produce the additions and adjustments as separate .osc<br>
files that can be examined for correctness in JOSM before being applied.<br>
Would people generally be comfortable with accepting node relocations that<br>
don't cause any ways to overlap themselves without extensive manual review,<br>
and only carefully reviewing additions?<br>
<br>
</blockquote></div>
i think the best approach is to manually review early ones to develop some<br>
comfort level with the non-overlapping case.<span class="HOEnZb"><font color="#888888"><br>
<br>
richard<br>
<br>
</font></span></blockquote></div><br></div>