<div dir="ltr">It's possible that there might be a conflict. Once your changes are checked in, the data will no longer match old TIGER, so my code won't try to do anything to those streets, but if changes from my process went in first, it could mess up what you are working on. That said, there are still all kinds of problems I need to solve before any automated updates can go in, so your changes will probably make it in first.<div>
<br></div><div>Eric</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 26, 2013 at 10:06 AM, Thomas Colson <span dir="ltr"><<a href="mailto:thomas_colson@nps.gov" target="_blank">thomas_colson@nps.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Chiming in for the NPS: most, if not all, of our footprints occur in these<br>
"low population/low mapping" areas that would qualify for the automated<br>
edit. Would that impact any current NPS mapping efforts?<br>
<div class="HOEnZb"><div class="h5"><br>
-----Original Message-----<br>
From: Brian May [mailto:<a href="mailto:bmay@mapwise.com">bmay@mapwise.com</a>]<br>
Sent: Wednesday, August 14, 2013 12:50 PM<br>
To: Eric Fischer<br>
Cc: Imports US<br>
Subject: Re: [Imports-us] A proposal for handling the tiger realignment<br>
<br>
My vote would be for the first aggressive option. I don't think losing<br>
previous OSM edits and having to recreate them is an option.<br>
<br>
Also, I'm thinking its much more doable to manually do one section of a<br>
county at a time as well.<br>
<br>
The process would go something like:<br>
<br>
- fire up JOSM<br>
- load existing OSM for an area of review<br>
- turn on Bing<br>
- open the .osc file and set as the active layer<br>
- delete nodes from the .osc that are not in the review area<br>
- review the changes that the .osc would make against Bing and the original<br>
OSM<br>
- delete nodes in the .osc file that should not be included in an update<br>
based on visual inspection<br>
- upload the edited .osc changeset<br>
- close JOSM<br>
- start a new JOSM session and download the same area<br>
- fix any "weirdness"<br>
- upload changes<br>
<br>
Does that sound right?<br>
<br>
And the .osc for that county would need to be re-run to pick up the changes.<br>
<br>
Brian<br>
<br>
On 8/14/2013 11:44 AM, Eric Fischer wrote:<br>
> The aggressive version would move most of those but wouldn't know what<br>
> to do with South Spartan Avenue, so it would be left where it was,<br>
> awkwardly connected to the rest, and someone would have to fix it<br>
> manually. That's probably the right thing to do in any county where<br>
> someone will promise that they will fix all the problems, though.<br>
><br>
> Probably really the right thing to do with renumbered TLIDs is to<br>
> delete the old version from OSM and add the new version back in, but<br>
> the additions would lose any road reclassifications, one-way<br>
> annotations, and relations that might have been added on the OSM side,<br>
> and would have to be carefully checked to make sure they didn't<br>
> duplicate roads that had been independently added in OSM.<br>
><br>
> Eric<br>
><br>
> On Wed, Aug 14, 2013 at 7:24 AM, Brian May <<a href="mailto:bmay@mapwise.com">bmay@mapwise.com</a>> wrote:<br>
>> OK, thanks for looking into it. That's a bummer. Is it possible "more<br>
>> aggressive" techniques would pick these up?<br>
>><br>
>> Brian<br>
>><br>
>><br>
>> On 8/13/2013 8:30 PM, Eric Fischer wrote:<br>
>>> The chain of causality is that, in county 121017, node 96238986<br>
>>> (28.763443,-82.534412) can't be moved because it is connected to<br>
>>> node 96242483 (28.763425,-82.53623) which can't be moved because it<br>
>>> is connected to node 96232423 (28.763424,-82.536941) which can't be<br>
>>> moved because it is connected to node 96223319<br>
>>> (28.763426,-82.537816) which can't be moved because it is connected<br>
>>> to node 96227957 (28.763426,-82.539013) which can't be moved because<br>
>>> it is connected to node 96257290 (28.7604,-82.539025) which is from<br>
>>> TLID 86219342 (South Spartan Avenue) which no longer appears in<br>
>>> TIGER apparently because it was renumbered for a route split so that<br>
>>> the driveway a little bit to the north could be mapped.<br>
>>><br>
>>> I need to add some more debug output so that it's easier to trace<br>
>>> why something is not moved, but I don't know how to fix the root cause.<br>
>>><br>
>>> Eric<br>
>>><br>
>>>> Eric,<br>
>>>><br>
>>>> I checked some areas in Citrus County FL which still has a lot of<br>
>>>> bad tiger and noticed many areas where the code did not provide<br>
>>>> updated nodes and ways, but had major tiger 2010 improvements and<br>
>>>> no one touching the original OSM ways/nodes, except for a bot.<br>
>>>> Example location: 28.76355, -82.5346.<br>
>>>><br>
>>>> Your thoughts?<br>
>>>><br>
>>>> Brian<br>
>>>><br>
>><br>
<br>
<br>
<br>
</div></div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Imports-us mailing list<br>
<a href="mailto:Imports-us@openstreetmap.org">Imports-us@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/imports-us" target="_blank">http://lists.openstreetmap.org/listinfo/imports-us</a><br>
<br>
<br>
_______________________________________________<br>
Imports-us mailing list<br>
<a href="mailto:Imports-us@openstreetmap.org">Imports-us@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/imports-us" target="_blank">http://lists.openstreetmap.org/listinfo/imports-us</a><br>
</div></div></blockquote></div><br></div>