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 <[email protected]> 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
[email protected]
http://lists.openstreetmap.org/listinfo/imports-us
