<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 2013-10-23 10:28, Marc Gemis wrote:<br>
</div>
<blockquote
cite="mid:CAJKJX-TOCa3JkJo0OWfQ0=ktyZvp=8-eK_sietqB0ebRZZqYcA@mail.gmail.com"
type="cite">
<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>
</blockquote>
<br>
The great thing about having to go dig deep in the data itself is
that it will be fairly easy to structure this the way JOSM does it.
Since you already have to deal with different formats, why spend
time on an extra one ? All you need to do is save 'the result' set
locally and start looking at the format. It would be a huge
feature. I'm not against csv's but their use is limited, xml's (not
my favorite!) however gives a structure to the data and makes the
data also more human readable. Next to being an established
standard.<br>
<br>
<blockquote
cite="mid:CAJKJX-TOCa3JkJo0OWfQ0=ktyZvp=8-eK_sietqB0ebRZZqYcA@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div>or you could add all changes in such a way that they are
also added to the tool that Ben proposes. <br>
</div>
</div>
</blockquote>
<br>
I would just not invent a new output format to work with locally...
Although using sqlite as a locale storage (whatever tool) would also
help a lot speedwise.<br>
<br>
When using subsets of data instead of 'everthing from bounding box',
the plus-side of working with a limited dataset is that the manual
editing , selecting things 'in bulk' is a lot easier in a tool
like JOSM, as such JOSM becomes your tool to manually process and
verify it. A well known tool... So you don't need to reinvent the
wheel (validation for example). Just glue JOSM right in.<br>
<br>
as an example, when Colruyt is taken over by Delhaize and you want
to change the operator on all stores with name 'Colruyt', my steps
would be:<br>
<br>
- Export using Overpass, in the query decide if you want to do nodes
or ways (or both). -> .osm file only containing the nodes I'm
interested in (and metadata)<br>
- Validate right of the bat to get an idea of the current state<br>
- open in JOSM, search/replace using all features in JOSM (regex,
case insensitive, key exact and non exact search)<br>
- Do this again for all typo's in common keys (and delete the crap)<br>
- Validate ( use errors to focus on certain keys )<br>
- search for bad keys, stuff that doesn't belong on those nodes
(always something lingering around)<br>
- Check addr:* keys , all of them. <br>
- Use Address plugins to complete missing information<br>
- Validate<br>
- Search for notes, comments and read them (they might give clues
about problems you missed). Update them as you fix.<br>
- Validate<br>
- Prepare for merge problems (someone might have touched one of the
nodes/ways)<br>
- Now Fix remaining validation errors until it's 100% clean (or are
false)<br>
- Validate<br>
- Upload<br>
- Merge (if needed)<br>
- Upload<br>
<br>
Any tool that comes our way that supports OSM format kan be injected
in any of those phases. That's awesome. I would be using a tool
like that. Since it can take input from any source that you are
able to bring to common ground, being OSM format. (XML). I would
be using all tools that are suited and add value in such a way to
meet a certain problem.<br>
<br>
If the tools that parse CRAB would use plugins to read from a(ny)
datasource ... Then you might be creating something that lasts. I
would love to try it out.<br>
<br>
Glenn<br>
<br>
<blockquote
cite="mid:CAJKJX-TOCa3JkJo0OWfQ0=ktyZvp=8-eK_sietqB0ebRZZqYcA@mail.gmail.com"
type="cite">
<div dir="ltr">
<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
moz-do-not-send="true" 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>
_______________________________________________<br>
Talk-be mailing list<br>
<a moz-do-not-send="true"
href="mailto:Talk-be@openstreetmap.org"
target="_blank">Talk-be@openstreetmap.org</a><br>
<a moz-do-not-send="true"
href="https://lists.openstreetmap.org/listinfo/talk-be"
target="_blank">https://lists.openstreetmap.org/listinfo/talk-be</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Talk-be mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Talk-be@openstreetmap.org">Talk-be@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk-be">https://lists.openstreetmap.org/listinfo/talk-be</a>
</pre>
</blockquote>
<br>
</body>
</html>