<div dir="auto">Perhaps a way forward at the moment would be to open the task manager up so the tiles imported so far can be validated.<div dir="auto"><br></div><div dir="auto">Having lived with computers for many years I'm in total agreement, they work very quickly but have no common sense what so ever.</div><div dir="auto"><br></div><div dir="auto">Cheerio John</div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Jan 26, 2019, 1:56 PM Nate Wessel <<a href="mailto:bike756@gmail.com">bike756@gmail.com</a> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p>Getting a clear idea of what needs to be fixed is what validation
is all about. Having a second set of eyes look through everyone's
imported data in a systematic way will give us ideas for what we
need to fix moving forward. It can't be just a matter of looking
at a bunch of automated validation script outputs and issuing a
checkmark. Machines can do that - us humans can do better, and
that's a big part of the beauty of OSM: the human element. <br>
</p>
<p>If I may be permitted a tangent, I was fairly troubled at the
last State of the Map US conference that the focus of attention
seemed to have turned to a surprising degree toward "what cool
things can machines do with data" from the focus I saw in earlier
years, which was much more "how can we get more people engaged?".
Machines don't make quality data - only consistent errors. I'm
glad the big tech companies were buying us all beers (there was
soooo much free beer...) but we shouldn't adopt their narrow focus
on labor efficiency and automation. I don't think efficiency is
why we are all here.</p>
<p>...<br>
</p>
<p>I was going to address some of your other points, but I think my
little digression actually highlighted some of the differences in
the way we seem to be approaching all of these issues. I'm not a
fan of automation and efficiency at the cost of quality (in this
context), while that is a compromise you and others seem willing
to make. We may not be able to talk our way out of that difference
of opinion; the root of the issue is likely just a different
vision of OSM and why we each care about it. <br>
</p>
<div class="m_-6305613092154300058moz-signature">Nate Wessel<br>
<span style="font-size:10px;color:#777">Jack of all trades, Master
of Geography, PhD candidate in Urban Planning<br>
<a href="http://natewessel.com" target="_blank" rel="noreferrer">NateWessel.com</a></span>
<br>
<br>
</div>
<div class="m_-6305613092154300058moz-cite-prefix">On 1/26/19 12:48 PM, Danny McDonald
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">1. In terms of validation, it would be helpful to
have a clear idea of what sorts of problems need to be fixed.
I have re-validated almost all of the areas I imported (and
all of them in Central Toronto), and fixed all of the building
related errors/warnings I found (with a few exceptions) there
weren't many errors, and many pre-dated the import. The only
JOSM warning I didn't fix is "Crossing building/residential
area". Yaro's and John's areas don't seem to have many errors
either, although there a few isolated "Crossing
building/highway" warnings (and some "building duplicated
nodes" errors). I have also split big retail buildings in
dense areas.
<div>2. I'm fine with simplification, I think we should just
do it. In terms of orthogonalization, I don't understand
why non-orthogonal buildings are a problem. If they are,
JOSM allows them to be auto-fixed.<br>
<div>3. I agree that the task manager squares are too big in
central Toronto. A separate task can be created for
central Toronto only, with smaller squares. I think the
square size is fine outside of Toronto, as long as the
squares are split appropriately.</div>
<div>4. In terms of conflation, I agree that deleting and
re-adding buildings is not desirable, but I don't agree
that that means it should never be done, no matter the
time cost. The ideal solution here is some sort of
script/plugin that auto-merges new and recently added
buildings - basically, an iterated "replace geometry".</div>
</div>
<div>DannyMcD</div>
</div>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
</blockquote>
</div>
</div>
<br>
<fieldset class="m_-6305613092154300058mimeAttachmentHeader"></fieldset>
<pre class="m_-6305613092154300058moz-quote-pre">_______________________________________________
Talk-ca mailing list
<a class="m_-6305613092154300058moz-txt-link-abbreviated" href="mailto:Talk-ca@openstreetmap.org" target="_blank" rel="noreferrer">Talk-ca@openstreetmap.org</a>
<a class="m_-6305613092154300058moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk-ca" target="_blank" rel="noreferrer">https://lists.openstreetmap.org/listinfo/talk-ca</a>
</pre>
</blockquote>
</div>
_______________________________________________<br>
Talk-ca mailing list<br>
<a href="mailto:Talk-ca@openstreetmap.org" target="_blank" rel="noreferrer">Talk-ca@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk-ca" rel="noreferrer noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk-ca</a><br>
</blockquote></div>