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

[Nate Wessel]

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
> https://lists.openstreetmap.org/listinfo/talk-ca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20190126/a5db76f9/attachment.html>