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