<div dir="ltr">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 )<div>But of course that requires people to install this plugin.</div>

<div><br></div><div>or you could add all changes in such a way that they are also added to the tool that Ben proposes. </div><div><br></div><div><br></div><div>m</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">

On Wed, Oct 23, 2013 at 10:13 AM, Glenn Plas <span dir="ltr"><<a href="mailto:glenn@byte-consult.be" target="_blank">glenn@byte-consult.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On 2013-10-22 20:53, Kurt Roeckx wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Oct 21, 2013 at 10:45:22PM +0200, Kurt Roeckx wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, Oct 21, 2013 at 10:06:03PM +0200, Kurt Roeckx wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I really see no good reason not to add those IDs at this point.<br>
I don't see the harm in them.  I can only see them being useful.<br>
</blockquote>
I would actually want to propose a different import strategy:<br>
- Add the CRAB IDs to all existing addresses in Flanders<br>
- Import the rest or large parts of CRAB in one big import<br>
</blockquote>
So after feedback on this, I want to propose that instead of<br>
actually importing this that we provide the data that this import<br>
tool would generate in such a way that it's easy for people to<br>
take the data and import it themself, potentially after fixing<br>
things.<br>
<br>
This would make it easier to improve the import tool after getting<br>
feedback of what it generates wrong.<br>
</blockquote>
<br></div>
If you could export to OSM format , that would be awesome.   Like in the way Overpass does this.<br>
<br>
In pseudo:<br>
<br>
- 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.<br>
- get data from crab, craft is as such (preparse it) to facilitate merging with osm data set.<br>
- Make the diff, but create an OSM compliant xml (with meta data, otherwise you won't be able to create a changeset from it)<br>
- open the changeset with JOSM, verify, correct, validate and push.<br>
<br>
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<br>


<br>
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.<span class="HOEnZb"><font color="#888888"><br>


<br>
Glenn</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Talk-be mailing list<br>
<a href="mailto:Talk-be@openstreetmap.org" target="_blank">Talk-be@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-be" target="_blank">https://lists.openstreetmap.<u></u>org/listinfo/talk-be</a><br>
</div></div></blockquote></div><br></div>