[Talk-ca] Talk-ca Digest, Vol 131, Issue 48

[Nate Wessel]

I'm all for this, so long as it really is just for validation. I believe 
we can leave notes on tasks via the tasking manager (?), which might be 
a good way to catalogue any localized issues we see.

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com <http://natewessel.com>

On 1/26/19 2:16 PM, john whelan wrote:
> Perhaps a way forward at the moment would be to open the task manager 
> up so the tiles imported so far can be validated.
>
> Having lived with computers for many years I'm in total agreement, 
> they work very quickly but have no common sense what so ever.
>
> Cheerio John
>
> On Sat, Jan 26, 2019, 1:56 PM Nate Wessel <bike756 at gmail.com 
> <mailto:bike756 at gmail.com> wrote:
>
>     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.
>
>     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.
>
>     ...
>
>     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.
>
>     Nate Wessel
>     Jack of all trades, Master of Geography, PhD candidate in Urban
>     Planning
>     NateWessel.com <http://natewessel.com>
>
>     On 1/26/19 12:48 PM, Danny McDonald wrote:
>>     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.
>>     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.
>>     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.
>>     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".
>>     DannyMcD
>>
>>
>>
>>     _______________________________________________
>>     Talk-ca mailing list
>>     Talk-ca at openstreetmap.org  <mailto:Talk-ca at openstreetmap.org>
>>     https://lists.openstreetmap.org/listinfo/talk-ca
>     _______________________________________________
>     Talk-ca mailing list
>     Talk-ca at openstreetmap.org <mailto:Talk-ca at openstreetmap.org>
>     https://lists.openstreetmap.org/listinfo/talk-ca
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20190126/61561723/attachment.html>