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

[James]

There is also fours states to a task..clear..no action, yellow...completed
and green: validated! (there's also unvalidated to flag a tile as not being
done again/not being validated) You can leave comments as well!

On Sat., Jan. 26, 2019, 7:53 p.m. 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 
>
> 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 
>> 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
>> s 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 
>>
>> 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 
>> listTalk-ca@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-ca
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [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 

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  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
s 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 

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@openstreetmap.org  
https://lists.openstreetmap.org/listinfo/talk-ca

___
Talk-ca mailing list
Talk-ca@openstreetmap.org 
https://lists.openstreetmap.org/listinfo/talk-ca

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

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

[john whelan]

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  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
> s 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 
>
> 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 
> listTalk-ca@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-ca
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [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 s 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 

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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

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

[Danny McDonald]

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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca