<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 12:43, Marc Gemis wrote:<br>
</div>
<blockquote
cite="mid:CAJKJX-SsrXCLYPbfnp43tu4_4jr2WsXFpiob8G=XYHup5DM7TA@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Oct 23, 2013 at 12:16 PM,
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 bgcolor="#FFFFFF" text="#000000">
<div class="im">
<div>On 2013-10-23 10:28, Marc Gemis wrote:<br>
</div>
<blockquote 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>
</div>
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.
<div class="im"><br>
<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>You know that after importing the csv file, you have an
osm layer that you can save and work with. So if you
happen to have a tool that exports the new/update records
in csv format (any decent DB-tool can generate files in
that format), you do not have to write a tool that
generates OSM-xml.</div>
<div>So when you can determine the new/updated records in
the Crab DB (I do not know in which format the updates
from Crab are provided) with a simple SQL query, you
export the result in csv, import with the OpenData plugin
and you don't need to write any other program. That's all
that I wanted to say.</div>
<div> <br>
</div>
</div>
</div>
</div>
</blockquote>
Yeah, I understand the reasoning but I'm thinking at some point you
want to inject something halfway , so in this case, you need to
update the csv's (record, line based). Then it gets complicated
-perhaps-. I was just thinking idealistically out loud. I'm
thinking, how would a complex building be represented in a csv
format, I think I would get frustrated using it as my local app
working storage (that's what I consider it to be in this case) Your
shortcut to results seems worth considering, I aggree. Thanks for
bringing this feature to my attention too.<br>
<br>
It doesn't hurt bringing idea's on the table I hope.<br>
<br>
Glenn<br>
</body>
</html>