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

Brian May bmay at mapwise.com
Wed Aug 14 16:49:39 UTC 2013


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 OSM
- 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.

Brian

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
>>>>
>>





More information about the Imports-us mailing list