You could also make a csv file with the diffs and open that with the OpenData plugin in JOSM. (see my presentation at ESI on import VMM monitoring stations ) But of course that requires people to install this plugin.
or you could add all changes in such a way that they are also added to the tool that Ben proposes. m On Wed, Oct 23, 2013 at 10:13 AM, Glenn Plas <[email protected]> wrote: > On 2013-10-22 20:53, Kurt Roeckx wrote: > >> On Mon, Oct 21, 2013 at 10:45:22PM +0200, Kurt Roeckx wrote: >> >>> On Mon, Oct 21, 2013 at 10:06:03PM +0200, Kurt Roeckx wrote: >>> >>>> I really see no good reason not to add those IDs at this point. >>>> I don't see the harm in them. I can only see them being useful. >>>> >>> I would actually want to propose a different import strategy: >>> - Add the CRAB IDs to all existing addresses in Flanders >>> - Import the rest or large parts of CRAB in one big import >>> >> So after feedback on this, I want to propose that instead of >> actually importing this that we provide the data that this import >> tool would generate in such a way that it's easy for people to >> take the data and import it themself, potentially after fixing >> things. >> >> This would make it easier to improve the import tool after getting >> feedback of what it generates wrong. >> > > If you could export to OSM format , that would be awesome. Like in the > way Overpass does this. > > In pseudo: > > - get data from osm (assuming here , the data is partial, so lets say, > everything with an 'addr' tag in your field of view.) , the same effect > you have when exporting a certain key using overpass. > - get data from crab, craft is as such (preparse it) to facilitate merging > with osm data set. > - Make the diff, but create an OSM compliant xml (with meta data, > otherwise you won't be able to create a changeset from it) > - open the changeset with JOSM, verify, correct, validate and push. > > So, truthfully, I think a tool like you envision is still interesting and > the more we do, the better and less manual JOSM work to do. But we need to > do chunks of it, we should do this for small area's. it's also easier to > (later on) fix things that went wrong yet unnoticed, that way you don't > have to deal with huge changesets finding that single node on page 450 > (ever tried paging through changesets using the site ? ;-) . Even a > perfect full import in one go would give us headaches later. It keeps > things managable > > I think it's great you want to do this, I'm just not too positive about > the success and it's not that I doubt your skills, it's that I doubt we'll > be able to cover all exceptions that you usually run into in a decent > timeframe. The problem is not so much the bulk of perfect tagged stuff , > but the ones that need special treatment. It could turn out to be a > bigger job than anticipated right now. > > Glenn > > > > > ______________________________**_________________ > Talk-be mailing list > [email protected] > https://lists.openstreetmap.**org/listinfo/talk-be<https://lists.openstreetmap.org/listinfo/talk-be> >
_______________________________________________ Talk-be mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-be
