<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">Am 06.01.2017 um 22:22 schrieb john
whelan:<br>
</div>
<blockquote
cite="mid:CAJ-Ex1EzGT-VfVvt=5+DeV1erq27nUzxTP1PE_3c45JoFV8d=g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small">>When
Simon says "Canvec and broken import is essentially a synonym"
that is not an<br>
exaggeration, if you mention Canvec in a typical European
community<br>
meeting you usually just get a big sigh in return. <br>
<br>
</div>
<div class="gmail_default"
style="font-family:verdana,sans-serif;font-size:small">I think
you have to understand a bit more about CANVEC data what it is
and how the quality varies. <br>
</div>
</div>
</blockquote>
<br>
Obviously the original quality and general suitability of a dataset
for use in OSM is one of the points that has to considered prior to
an import. However that is not the issue here, assuming that the
original data is roughly correct and valid in a topologically /
technical sense: it just doesn't compute to take that valid geo-data
and turn it in to broken OSM data, and it makes even less sense, if
that is at all possible, to do that in sparsely populated remote
areas. <br>
<br>
In the past we've had notable OSM participants that have actually
suggested that we should and can just throw some broken xxxx at the
crowd and it will come back out fixed and shiny. I would hope that
we have consensus that, based on the experience of the last decade
of OSM, that doesn't actually work and you end up overwhelming the
communities with stuff they "should be fixing" and it just doesn't
get done. <br>
<br>
IMHO in conclusion any import should not take place if the data
doesn't work "as is" post import in OSM and we shouldn't leave such
data in OSM just because of some twisted reasoning that the importer
will feel better if it is not reverted. Nobody is suggesting that
such an import, at whatever level of granularity (for example a
single changeset). can't be redone once the issues have been fixed.
<br>
<br>
Which brings us back on topic. Yuris mechanical edit is, as
mechanical edits go (not an import so at least a different flavour),
not totally unreasonable. It should have been discussed beforehand,
but the main issue is that it is, at least perceived as, adding to
that "should be fixing" pile in a large way and somebody sitting in
NYC deciding what should be top priority for the local communities
around the globe.<br>
<br>
That is on top of multiple other edits that have added wikidata tags
in not so controlled and reasonable circumstances, for example to
the, known to be wonky, African place data that has been bit-roting
for ages (see above) . I assume they have been reverted, but maybe
not.<br>
<br>
Could we let this whole thing cool down and agree that for now there
should be no further mass adding of wikidata tags in any form till
we get a handle on how to proceed?<br>
<br>
Simon<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>