<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">English only since I've slept minus 3
hours. Sorry.<br>
<br>
I can't help but aggree fully. In analogy, as we speak I'm
trying to migrate data from a poi list of over 1000 poi's with my
own version of this database using the customer foreign key to
make this happen. (for an API) I'm actually pretty much against
this action but there are few alternatives since it was poorly
planned by the customer. I'm doing a full merge, so coordinates
will come from mine, labels from the customer -They are actually
bus stops-, public ones that are used by private transport in
Antwerp, used by collective transporting services by BASF etc.).<br>
<br>
This is only 1000 poi's and it's a merger's hell. Arrival times
differ between both version, even validity is offset. Sometimes
important stuff has been put in a comment field. This makes me
remember how hard it is to automate these things, I've done acts
like that before, but here I am using an excell sheet(dump
customer) and an sqlite database to construct this single table
instead... <br>
<br>
I just cannot create an algorithm of my common sense on how to go
about each record.<br>
<br>
The reason why I'm against such an action is because I cannot
trust neither sources of the data to be consistent. You might
manage to import 30%, even 60% without problem, but it will be
like the 80/20 percent rule. 20% of the effort and time will be
spent in importing 80% of the data, and vice versa, you'll spend
80% of your time on the remaining 20% of the data. You might
also end up spending weeks using overpass to correct OSM before
import. I've done a lot of those and I assure you, it's just
crazy the kind of mistakes you find in OSM alone.
addr:postcode=Zemst , addr:city=1980 first one that pops in my
mind. I've done lots of corrections like that. But that is just
one of many idiotic things, honest mistakes and ignorance at work,
all well meant efforts, with the best intentions.<br>
<br>
So in the end, we'll need something like Ben proposed. It's a lot
more fun indeed and it gives ownership, just perfect.<br>
<br>
Glenn<br>
<br>
On 2013-10-22 07:12, Marc Gemis wrote:<br>
</div>
<blockquote
cite="mid:CAJKJX-Q4dGxsDiSutFizYZnrhzQYTG4Ad28z+Sta8nBYwqDvJg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Nederlands onderaan</div>
<div><br>
</div>
Allow me to explain why I'm against a full automatic import of
the Crab data, as proposed on this mailing list
<div><br>
</div>
<div>I understand that this is the fastest way to get the data
into OSM and ready for use by everybody.</div>
<div>However, the data will then be owned by 1 or 2 people that
did the import. They will not be able to cope with the
consequences of the data they imported. The import software
will have some flaws (double addresses, missing buildings, bad
buildings, problems with associatedStreet merging, etc.)</div>
<div>Will you clean up the mess that others made ?</div>
<div><br>
</div>
<div>If, on the other hand, you allow people to import their own
chunks of data (via the tool made by the French, a lot of
people "own" the data. Every contributor takes some pride in
the data s/he added and will be glad to make corrections to
it. Even during the initial import improvements to the
imported & existing data will be made. The more people
that do this, the better.</div>
<div><br>
</div>
<div>It's all about community building. Build a community around
this import. This community will do other things as well
afterwards.</div>
<div><br>
</div>
<div>You can hear the same message in all presentations on
import at the SOTM US and SOTM conferences. Please take a look
at those videos.</div>
<div><br>
</div>
<div><br>
</div>
<div>----- Nederlands---</div>
<div>Sta me toe om uit te leggen waarom ik tegen een volledige
geautomatiseerde import van Crab data ben, zoals ergens
voorgesteld werd.</div>
<div><br>
</div>
<div>
Ik begrijp dat sommigen de data snel in OSM willen krijgen,
zodat het door iedereen kan gebruikt worden. Het gevolg
daarvan is dat de gegevens door 1 of 2 mensen aangemaakt is.
Zij kunnen niet alle probleempjes oplossen die ontstaan door
deze invoer. Ik denk hierbij aan foutjes in de software die
ervoor zorgen dat er dubbele adressen zijn of problemen met de
associatedStreet-relaties. Ook wordt er tijdens de import ook
niks gedaan aan ontbrekende of foutieve gebouwen. Wie gaat die
problemen aanpakken die door anderen gemaakt zijn ?</div>
<div><br>
</div>
<div>Als je aan de andere kant, iedereen toelaat om stukjes
gegevens te importeren en onmiddellijk te verbeteren, krijg je
een groep van mensen die de gegevens bezit/beheert. Deze
mensen gaan in zekere zin fier zijn op hun werk en proberen de
fouten eruit te halen. Hoe meer van deze mensen hoe beter.</div>
<div><br>
</div>
<div>Het gaat dus over het opbouwen van een community. Bouw aub
een community op rond deze import. Op langere termijn zal osm
er wel bij varen.</div>
<div><br>
</div>
<div>I meen deze boodschap ook te horen in alle presentaties
rond imports die gegeven zijn op de SOTM US en SOTM
conferenties. Kijk maar eens naar die videos. (wel in het
Engels)</div>
<div><br>
</div>
<div>groeten</div>
<div><br>
</div>
<div>m</div>
</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>