[Imports-us] A proposal for handling the tiger realignment

Thomas Colson thomas_colson at nps.gov
Mon Aug 26 17:06:48 UTC 2013

Chiming in for the NPS: most, if not all, of our footprints occur in these
"low population/low mapping" areas that would qualify for the automated
edit. Would that impact any current NPS mapping efforts?

-----Original Message-----
From: Brian May [mailto:bmay at mapwise.com] 
Sent: Wednesday, August 14, 2013 12:50 PM
To: Eric Fischer
Cc: Imports US
Subject: Re: [Imports-us] A proposal for handling the tiger realignment

My vote would be for the first aggressive option. I don't think losing
previous OSM edits and having to recreate them is an option.

Also, I'm thinking its much more doable to manually do one section of a
county at a time as well.

The process would go something like:

- fire up JOSM
- load existing OSM for an area of review
- turn on Bing
- open the .osc file and set as the active layer
- delete nodes from the .osc that are not in the review area
- review the changes that the .osc would make against Bing and the original
- delete nodes in the .osc file that should not be included in an update
based on visual inspection
- upload the edited .osc changeset
- close JOSM
- start a new JOSM session and download the same area
- fix any "weirdness"
- upload changes

Does that sound right?

And the .osc for that county would need to be re-run to pick up the changes.


On 8/14/2013 11:44 AM, Eric Fischer wrote:
> The aggressive version would move most of those but wouldn't know what 
> to do with South Spartan Avenue, so it would be left where it was, 
> awkwardly connected to the rest, and someone would have to fix it 
> manually. That's probably the right thing to do in any county where 
> someone will promise that they will fix all the problems, though.
> Probably really the right thing to do with renumbered TLIDs is to 
> delete the old version from OSM and add the new version back in, but 
> the additions would lose any road reclassifications, one-way 
> annotations, and relations that might have been added on the OSM side, 
> and would have to be carefully checked to make sure they didn't 
> duplicate roads that had been independently added in OSM.
> Eric
> On Wed, Aug 14, 2013 at 7:24 AM, Brian May <bmay at mapwise.com> wrote:
>> OK, thanks for looking into it. That's a bummer. Is it possible "more 
>> aggressive" techniques would pick these up?
>> Brian
>> On 8/13/2013 8:30 PM, Eric Fischer wrote:
>>> The chain of causality is that, in county 121017, node 96238986 
>>> (28.763443,-82.534412) can't be moved because it is connected to 
>>> node 96242483 (28.763425,-82.53623) which can't be moved because it 
>>> is connected to node 96232423 (28.763424,-82.536941) which can't be 
>>> moved because it is connected to node 96223319 
>>> (28.763426,-82.537816) which can't be moved because it is connected 
>>> to node 96227957 (28.763426,-82.539013) which can't be moved because 
>>> it is connected to node 96257290 (28.7604,-82.539025) which is from 
>>> TLID 86219342 (South Spartan Avenue) which no longer appears in 
>>> TIGER apparently because it was renumbered for a route split so that 
>>> the driveway a little bit to the north could be mapped.
>>> I need to add some more debug output so that it's easier to trace 
>>> why something is not moved, but I don't know how to fix the root cause.
>>> Eric
>>>> Eric,
>>>> I checked some areas in Citrus County FL which still has a lot of 
>>>> bad tiger and noticed many areas where the code did not provide 
>>>> updated nodes and ways, but had major tiger 2010 improvements and 
>>>> no one touching the original OSM ways/nodes, except for a bot. 
>>>> Example location: 28.76355, -82.5346.
>>>> Your thoughts?
>>>> Brian

Imports-us mailing list
Imports-us at openstreetmap.org

More information about the Imports-us mailing list