Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[James]

That is incorrect, some building parts could be bigger if they are
surrounding the building as an overhang etc. You can't assume building will
be bigger

On Thu., Jan. 24, 2019, 11:51 a.m. Nate Wessel  Is it sufficient to tag fragments as building:part without indicating
> which part or how many stories? If the data is properly structured, this
> seems like something that could be handled in preprocessing by checking for
> overlapping polygons. It looks like perhaps we might just have to find the
> largest part for the footprint (building=yes) and any intersecting smaller
> buildings (building:part=yes).
>
> We might also need to generate some building relations for more complex
> features.
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 1/24/19 11:40 AM, Yaro Shkvorets wrote:
>
> OSM wiki: https://wiki.openstreetmap.org/wiki/Key:building:part
> It's not in the import wiki though since whoever wrote it didn't know
> about it at the time.
> Here's what I mean by mapping 3D features in our case. Say there is a
> residential tower on a podium. In the StatsCan data usually you would find
> both of these outlines - large podium outline and smaller tower outline
> inside it. They would both be tagged with "building=yes" tag. Obviously we
> can't upload that as-is. We can either just remove tower outline leaving
> only 2D podium outline. Or, we can tag the tower outline with
> "building:part=yes". Someone local can add other tags to it later on, such
> as "building:levels", "building:material", "building:min_level",
> "addr:housenumber" (if there are two towers on one podium with different
> house numbers for example), etc. I find the latter approach to be the right
> one.
>
> On Thu, Jan 24, 2019 at 11:15 AM Nate Wessel  wrote:
>
>> Hi Yaro,
>>
>> I just had a chance to look at the documentation on the source data and I
>> wasn't able to find anything about 3D features or parts of buildings being
>> mapped separately. Are you guessing here, or is there documentation on
>> this? If so can you point us to it?
>>
>> In any case, the big shapefiles from StatsCan don't provide enough
>> information to reconstruct any 3D geometries, so I'd be inclined to remove
>> these from the import unless they can be brought in from another source
>> with better documentation / attribute tagging. (i.e. City of Toronto?)
>>
>> Thanks,
>> Nate Wessel
>> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
>> NateWessel.com 
>>
>> On 1/18/19 2:48 PM, Yaro Shkvorets wrote:
>>
>> Jarek,
>> There is no question we want this data. I went through much of it in
>> Toronto and Kingston and I found it to be very good, consistent and
>> precise. Time-wise it's somewhat current with 2016 ESRI imagery (sometimes
>> ahead, sometimes slightly behind) and is well-aligned with it. It offers 3D
>> features (when several buildings appear overlapped in the dataset) but you
>> just need to be familiar with `building:part` tag to sort through it. I
>> haven't looked at other provinces but in Ontario I really have no
>> complaints about dataset quality whatsoever. Also I don't get Nate's
>> "wildly unsimplified geometries" comment. IMO geometries are just perfectly
>> detailed.
>>
>>
>> On Fri, Jan 18, 2019 at 2:00 PM Jarek Piórkowski 
>> wrote:
>>
>>> Some more thoughts from me.
>>>
>>> Building outlines, particularly for single-family subdivisions as seen
>>> in Canadian suburbs, are extremely labour-intensive to map manually.
>>>
>>> My parents' house is now on OSM - accurately. They live in a city with
>>> about 10,000 buildings, and about 0.5 active mappers. This wouldn't
>>> been completed manually in the next 5 years.
>>>
>>> An option to do this automatically with a computer algorithm detecting
>>> objects from imagery could be suggested, but this has not been very
>>> accurate in OSM in the past, even when there is decent imagery. The
>>> only other feasible data source is government, where they have such
>>> data more or less.
>>>
>>> The alternative is of course the opinion that we should not have
>>> building outlines until someone goes through and adds the buildings
>>> manually. In practice what I've seen done in Toronto is that bigger
>>> buildings are mapped on best-effort basis from survey and imagery,
>>> while areas of single-family houses are left blank. This isn't
>>> _wrong_, and maybe some prefer this.
>>>
>>> I would also like to note that building outlines will _never_ be
>>> completely verifiably up to date. I can't go into most people's
>>> backyards and verify that there isn't a new addition on their house. A
>>> building might be legally split into two different properties without
>>> it being evident from the street. Imagery is out of date the day after
>>> it's taken, and proper offset can be difficult to establish in big
>>> cities where GPS signal is erratic. Pragmatically, I can tell you 

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[Yaro Shkvorets]

>>It looks like perhaps we might just have to find the largest part for the
footprint (building=yes) and any intersecting smaller buildings
(building:part=yes).
Yes, that's what I usually do. I also sometimes delete non-important
building parts that don't add anything valuable to the map but only
complicate things. Not sure how to better explain that in the wiki, it's a
personal judgement thing I guess.


On Thu, Jan 24, 2019 at 11:49 AM Nate Wessel  wrote:

> Is it sufficient to tag fragments as building:part without indicating
> which part or how many stories? If the data is properly structured, this
> seems like something that could be handled in preprocessing by checking for
> overlapping polygons. It looks like perhaps we might just have to find the
> largest part for the footprint (building=yes) and any intersecting smaller
> buildings (building:part=yes).
>
> We might also need to generate some building relations for more complex
> features.
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 1/24/19 11:40 AM, Yaro Shkvorets wrote:
>
> OSM wiki: https://wiki.openstreetmap.org/wiki/Key:building:part
> It's not in the import wiki though since whoever wrote it didn't know
> about it at the time.
> Here's what I mean by mapping 3D features in our case. Say there is a
> residential tower on a podium. In the StatsCan data usually you would find
> both of these outlines - large podium outline and smaller tower outline
> inside it. They would both be tagged with "building=yes" tag. Obviously we
> can't upload that as-is. We can either just remove tower outline leaving
> only 2D podium outline. Or, we can tag the tower outline with
> "building:part=yes". Someone local can add other tags to it later on, such
> as "building:levels", "building:material", "building:min_level",
> "addr:housenumber" (if there are two towers on one podium with different
> house numbers for example), etc. I find the latter approach to be the right
> one.
>
> On Thu, Jan 24, 2019 at 11:15 AM Nate Wessel  wrote:
>
>> Hi Yaro,
>>
>> I just had a chance to look at the documentation on the source data and I
>> wasn't able to find anything about 3D features or parts of buildings being
>> mapped separately. Are you guessing here, or is there documentation on
>> this? If so can you point us to it?
>>
>> In any case, the big shapefiles from StatsCan don't provide enough
>> information to reconstruct any 3D geometries, so I'd be inclined to remove
>> these from the import unless they can be brought in from another source
>> with better documentation / attribute tagging. (i.e. City of Toronto?)
>>
>> Thanks,
>> Nate Wessel
>> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
>> NateWessel.com 
>>
>> On 1/18/19 2:48 PM, Yaro Shkvorets wrote:
>>
>> Jarek,
>> There is no question we want this data. I went through much of it in
>> Toronto and Kingston and I found it to be very good, consistent and
>> precise. Time-wise it's somewhat current with 2016 ESRI imagery (sometimes
>> ahead, sometimes slightly behind) and is well-aligned with it. It offers 3D
>> features (when several buildings appear overlapped in the dataset) but you
>> just need to be familiar with `building:part` tag to sort through it. I
>> haven't looked at other provinces but in Ontario I really have no
>> complaints about dataset quality whatsoever. Also I don't get Nate's
>> "wildly unsimplified geometries" comment. IMO geometries are just perfectly
>> detailed.
>>
>>
>> On Fri, Jan 18, 2019 at 2:00 PM Jarek Piórkowski 
>> wrote:
>>
>>> Some more thoughts from me.
>>>
>>> Building outlines, particularly for single-family subdivisions as seen
>>> in Canadian suburbs, are extremely labour-intensive to map manually.
>>>
>>> My parents' house is now on OSM - accurately. They live in a city with
>>> about 10,000 buildings, and about 0.5 active mappers. This wouldn't
>>> been completed manually in the next 5 years.
>>>
>>> An option to do this automatically with a computer algorithm detecting
>>> objects from imagery could be suggested, but this has not been very
>>> accurate in OSM in the past, even when there is decent imagery. The
>>> only other feasible data source is government, where they have such
>>> data more or less.
>>>
>>> The alternative is of course the opinion that we should not have
>>> building outlines until someone goes through and adds the buildings
>>> manually. In practice what I've seen done in Toronto is that bigger
>>> buildings are mapped on best-effort basis from survey and imagery,
>>> while areas of single-family houses are left blank. This isn't
>>> _wrong_, and maybe some prefer this.
>>>
>>> I would also like to note that building outlines will _never_ be
>>> completely verifiably up to date. I can't go into most people's
>>> backyards and verify that there isn't a new addition on their house. A
>>> building might be legally 

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[Kevin Farrugia]

Data is currently stored in OSM by mappers this way, regardless of the
source. I don't think a height or which part is needed to use the building
part tags. It provides the basis for later additions should a mapper be so
inclined to add it.

---
Kevin Farrugia

On Thu., Jan. 24, 2019, 11:51 a.m. Nate Wessel  Is it sufficient to tag fragments as building:part without indicating
> which part or how many stories? If the data is properly structured, this
> seems like something that could be handled in preprocessing by checking for
> overlapping polygons. It looks like perhaps we might just have to find the
> largest part for the footprint (building=yes) and any intersecting smaller
> buildings (building:part=yes).
>
> We might also need to generate some building relations for more complex
> features.
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 1/24/19 11:40 AM, Yaro Shkvorets wrote:
>
> OSM wiki: https://wiki.openstreetmap.org/wiki/Key:building:part
> It's not in the import wiki though since whoever wrote it didn't know
> about it at the time.
> Here's what I mean by mapping 3D features in our case. Say there is a
> residential tower on a podium. In the StatsCan data usually you would find
> both of these outlines - large podium outline and smaller tower outline
> inside it. They would both be tagged with "building=yes" tag. Obviously we
> can't upload that as-is. We can either just remove tower outline leaving
> only 2D podium outline. Or, we can tag the tower outline with
> "building:part=yes". Someone local can add other tags to it later on, such
> as "building:levels", "building:material", "building:min_level",
> "addr:housenumber" (if there are two towers on one podium with different
> house numbers for example), etc. I find the latter approach to be the right
> one.
>
> On Thu, Jan 24, 2019 at 11:15 AM Nate Wessel  wrote:
>
>> Hi Yaro,
>>
>> I just had a chance to look at the documentation on the source data and I
>> wasn't able to find anything about 3D features or parts of buildings being
>> mapped separately. Are you guessing here, or is there documentation on
>> this? If so can you point us to it?
>>
>> In any case, the big shapefiles from StatsCan don't provide enough
>> information to reconstruct any 3D geometries, so I'd be inclined to remove
>> these from the import unless they can be brought in from another source
>> with better documentation / attribute tagging. (i.e. City of Toronto?)
>>
>> Thanks,
>> Nate Wessel
>> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
>> NateWessel.com 
>>
>> On 1/18/19 2:48 PM, Yaro Shkvorets wrote:
>>
>> Jarek,
>> There is no question we want this data. I went through much of it in
>> Toronto and Kingston and I found it to be very good, consistent and
>> precise. Time-wise it's somewhat current with 2016 ESRI imagery (sometimes
>> ahead, sometimes slightly behind) and is well-aligned with it. It offers 3D
>> features (when several buildings appear overlapped in the dataset) but you
>> just need to be familiar with `building:part` tag to sort through it. I
>> haven't looked at other provinces but in Ontario I really have no
>> complaints about dataset quality whatsoever. Also I don't get Nate's
>> "wildly unsimplified geometries" comment. IMO geometries are just perfectly
>> detailed.
>>
>>
>> On Fri, Jan 18, 2019 at 2:00 PM Jarek Piórkowski 
>> wrote:
>>
>>> Some more thoughts from me.
>>>
>>> Building outlines, particularly for single-family subdivisions as seen
>>> in Canadian suburbs, are extremely labour-intensive to map manually.
>>>
>>> My parents' house is now on OSM - accurately. They live in a city with
>>> about 10,000 buildings, and about 0.5 active mappers. This wouldn't
>>> been completed manually in the next 5 years.
>>>
>>> An option to do this automatically with a computer algorithm detecting
>>> objects from imagery could be suggested, but this has not been very
>>> accurate in OSM in the past, even when there is decent imagery. The
>>> only other feasible data source is government, where they have such
>>> data more or less.
>>>
>>> The alternative is of course the opinion that we should not have
>>> building outlines until someone goes through and adds the buildings
>>> manually. In practice what I've seen done in Toronto is that bigger
>>> buildings are mapped on best-effort basis from survey and imagery,
>>> while areas of single-family houses are left blank. This isn't
>>> _wrong_, and maybe some prefer this.
>>>
>>> I would also like to note that building outlines will _never_ be
>>> completely verifiably up to date. I can't go into most people's
>>> backyards and verify that there isn't a new addition on their house. A
>>> building might be legally split into two different properties without
>>> it being evident from the street. Imagery is out of date the day after
>>> it's taken, and proper 

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[Nate Wessel]

Is it sufficient to tag fragments as building:part without indicating 
which part or how many stories? If the data is properly structured, this 
seems like something that could be handled in preprocessing by checking 
for overlapping polygons. It looks like perhaps we might just have to 
find the largest part for the footprint (building=yes) and any 
intersecting smaller buildings (building:part=yes).


We might also need to generate some building relations for more complex 
features.


Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 1/24/19 11:40 AM, Yaro Shkvorets wrote:

OSM wiki: https://wiki.openstreetmap.org/wiki/Key:building:part
It's not in the import wiki though since whoever wrote it didn't know 
about it at the time.
Here's what I mean by mapping 3D features in our case. Say there is a 
residential tower on a podium. In the StatsCan data usually you would 
find both of these outlines - large podium outline and smaller tower 
outline inside it. They would both be tagged with "building=yes" tag. 
Obviously we can't upload that as-is. We can either just remove tower 
outline leaving only 2D podium outline. Or, we can tag the tower 
outline with "building:part=yes". Someone local can add other tags to 
it later on, such as "building:levels", "building:material", 
"building:min_level", "addr:housenumber" (if there are two towers on 
one podium with different house numbers for example), etc. I find the 
latter approach to be the right one.


On Thu, Jan 24, 2019 at 11:15 AM Nate Wessel > wrote:


Hi Yaro,

I just had a chance to look at the documentation on the source
data and I wasn't able to find anything about 3D features or parts
of buildings being mapped separately. Are you guessing here, or is
there documentation on this? If so can you point us to it?

In any case, the big shapefiles from StatsCan don't provide enough
information to reconstruct any 3D geometries, so I'd be inclined
to remove these from the import unless they can be brought in from
another source with better documentation / attribute tagging.
(i.e. City of Toronto?)

Thanks,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban
Planning
NateWessel.com 

On 1/18/19 2:48 PM, Yaro Shkvorets wrote:

Jarek,
There is no question we want this data. I went through much of it
in Toronto and Kingston and I found it to be very good,
consistent and precise. Time-wise it's somewhat current with 2016
ESRI imagery (sometimes ahead, sometimes slightly behind) and is
well-aligned with it. It offers 3D features (when several
buildings appear overlapped in the dataset) but you just need to
be familiar with `building:part` tag to sort through it. I
haven't looked at other provinces but in Ontario I really have no
complaints about dataset quality whatsoever. Also I don't get
Nate's "wildly unsimplified geometries" comment. IMO geometries
are just perfectly detailed.


On Fri, Jan 18, 2019 at 2:00 PM Jarek Piórkowski
mailto:ja...@piorkowski.ca>> wrote:

Some more thoughts from me.

Building outlines, particularly for single-family
subdivisions as seen
in Canadian suburbs, are extremely labour-intensive to map
manually.

My parents' house is now on OSM - accurately. They live in a
city with
about 10,000 buildings, and about 0.5 active mappers. This
wouldn't
been completed manually in the next 5 years.

An option to do this automatically with a computer algorithm
detecting
objects from imagery could be suggested, but this has not
been very
accurate in OSM in the past, even when there is decent
imagery. The
only other feasible data source is government, where they
have such
data more or less.

The alternative is of course the opinion that we should not have
building outlines until someone goes through and adds the
buildings
manually. In practice what I've seen done in Toronto is that
bigger
buildings are mapped on best-effort basis from survey and
imagery,
while areas of single-family houses are left blank. This isn't
_wrong_, and maybe some prefer this.

I would also like to note that building outlines will _never_ be
completely verifiably up to date. I can't go into most people's
backyards and verify that there isn't a new addition on their
house. A
building might be legally split into two different properties
without
it being evident from the street. Imagery is out of date the
day after
it's taken, and proper offset can be difficult to establish
in big
cities where GPS signal 

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[John Whelan]

>they can be brought in from another source with better documentation / 
attribute tagging. (i.e. City of Toronto?)


I understand The City of Toronto Open Data License has been submitted to 
the OSM Legal Working Group some time ago.  The Federal Government 2.0 
license and the City of Ottawa Open Data license have been approved but 
they have requested any variations be submitted to them for review.


Translation even though some of this data came from the City of Toronto 
originally my understanding is currently we can't use open data from 
Toronto directly.  I believe it was a Toronto mapper who submitted all 
three licenses to the Legal Working Group originally.


There was quite a bit of discussion during the Ottawa Open Data import 
about licensing and some assumptions that had been made were found to be 
not quite as has been assumed.


Cheerio John

Nate Wessel wrote on 2019-01-24 11:14 AM:


Hi Yaro,

I just had a chance to look at the documentation on the source data 
and I wasn't able to find anything about 3D features or parts of 
buildings being mapped separately. Are you guessing here, or is there 
documentation on this? If so can you point us to it?


In any case, the big shapefiles from StatsCan don't provide enough 
information to reconstruct any 3D geometries, so I'd be inclined to 
remove these from the import unless they can be brought in from 
another source with better documentation / attribute tagging. (i.e. 
City of Toronto?)


Thanks,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 1/18/19 2:48 PM, Yaro Shkvorets wrote:

Jarek,
There is no question we want this data. I went through much of it in 
Toronto and Kingston and I found it to be very good, consistent and 
precise. Time-wise it's somewhat current with 2016 ESRI imagery 
(sometimes ahead, sometimes slightly behind) and is well-aligned with 
it. It offers 3D features (when several buildings appear overlapped 
in the dataset) but you just need to be familiar with `building:part` 
tag to sort through it. I haven't looked at other provinces but in 
Ontario I really have no complaints about dataset quality whatsoever. 
Also I don't get Nate's "wildly unsimplified geometries" comment. IMO 
geometries are just perfectly detailed.



On Fri, Jan 18, 2019 at 2:00 PM Jarek Piórkowski > wrote:


Some more thoughts from me.

Building outlines, particularly for single-family subdivisions as
seen
in Canadian suburbs, are extremely labour-intensive to map manually.

My parents' house is now on OSM - accurately. They live in a city
with
about 10,000 buildings, and about 0.5 active mappers. This wouldn't
been completed manually in the next 5 years.

An option to do this automatically with a computer algorithm
detecting
objects from imagery could be suggested, but this has not been very
accurate in OSM in the past, even when there is decent imagery. The
only other feasible data source is government, where they have such
data more or less.

The alternative is of course the opinion that we should not have
building outlines until someone goes through and adds the buildings
manually. In practice what I've seen done in Toronto is that bigger
buildings are mapped on best-effort basis from survey and imagery,
while areas of single-family houses are left blank. This isn't
_wrong_, and maybe some prefer this.

I would also like to note that building outlines will _never_ be
completely verifiably up to date. I can't go into most people's
backyards and verify that there isn't a new addition on their
house. A
building might be legally split into two different properties without
it being evident from the street. Imagery is out of date the day
after
it's taken, and proper offset can be difficult to establish in big
cities where GPS signal is erratic. Pragmatically, I can tell you
from
personal experience that building data in lovingly-mapped Berlin is
also worse than 1 meter accuracy. So again: best effort.

What do we get from having buildings? A sense of land use (arguably
replaceable with larger landuse areas). A way to roughly estimate
population density. A way to gauge built-up density. A data
source for
locating buildings in possible flood zones, or fire risk. Statistics:
as open data, queryable by APIs that are already used, in format
more-or-less common worldwide.

Examples were given of rowhouse- or de-facto rowhouse-buildings where
a part is attached to the wrong building. This does not alter any of
the above examples. It's wrong, but is it substantially more wrong
than a blank subdivision, or one with only a few buildings mapped? Is
it better to have a null, or be off by 5%? The legal truth is in
property records, and we can't measure houses with a ruler, so
  

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[Yaro Shkvorets]

OSM wiki: https://wiki.openstreetmap.org/wiki/Key:building:part
It's not in the import wiki though since whoever wrote it didn't know about
it at the time.
Here's what I mean by mapping 3D features in our case. Say there is a
residential tower on a podium. In the StatsCan data usually you would find
both of these outlines - large podium outline and smaller tower outline
inside it. They would both be tagged with "building=yes" tag. Obviously we
can't upload that as-is. We can either just remove tower outline leaving
only 2D podium outline. Or, we can tag the tower outline with
"building:part=yes". Someone local can add other tags to it later on, such
as "building:levels", "building:material", "building:min_level",
"addr:housenumber" (if there are two towers on one podium with different
house numbers for example), etc. I find the latter approach to be the right
one.

On Thu, Jan 24, 2019 at 11:15 AM Nate Wessel  wrote:

> Hi Yaro,
>
> I just had a chance to look at the documentation on the source data and I
> wasn't able to find anything about 3D features or parts of buildings being
> mapped separately. Are you guessing here, or is there documentation on
> this? If so can you point us to it?
>
> In any case, the big shapefiles from StatsCan don't provide enough
> information to reconstruct any 3D geometries, so I'd be inclined to remove
> these from the import unless they can be brought in from another source
> with better documentation / attribute tagging. (i.e. City of Toronto?)
>
> Thanks,
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 1/18/19 2:48 PM, Yaro Shkvorets wrote:
>
> Jarek,
> There is no question we want this data. I went through much of it in
> Toronto and Kingston and I found it to be very good, consistent and
> precise. Time-wise it's somewhat current with 2016 ESRI imagery (sometimes
> ahead, sometimes slightly behind) and is well-aligned with it. It offers 3D
> features (when several buildings appear overlapped in the dataset) but you
> just need to be familiar with `building:part` tag to sort through it. I
> haven't looked at other provinces but in Ontario I really have no
> complaints about dataset quality whatsoever. Also I don't get Nate's
> "wildly unsimplified geometries" comment. IMO geometries are just perfectly
> detailed.
>
>
> On Fri, Jan 18, 2019 at 2:00 PM Jarek Piórkowski 
> wrote:
>
>> Some more thoughts from me.
>>
>> Building outlines, particularly for single-family subdivisions as seen
>> in Canadian suburbs, are extremely labour-intensive to map manually.
>>
>> My parents' house is now on OSM - accurately. They live in a city with
>> about 10,000 buildings, and about 0.5 active mappers. This wouldn't
>> been completed manually in the next 5 years.
>>
>> An option to do this automatically with a computer algorithm detecting
>> objects from imagery could be suggested, but this has not been very
>> accurate in OSM in the past, even when there is decent imagery. The
>> only other feasible data source is government, where they have such
>> data more or less.
>>
>> The alternative is of course the opinion that we should not have
>> building outlines until someone goes through and adds the buildings
>> manually. In practice what I've seen done in Toronto is that bigger
>> buildings are mapped on best-effort basis from survey and imagery,
>> while areas of single-family houses are left blank. This isn't
>> _wrong_, and maybe some prefer this.
>>
>> I would also like to note that building outlines will _never_ be
>> completely verifiably up to date. I can't go into most people's
>> backyards and verify that there isn't a new addition on their house. A
>> building might be legally split into two different properties without
>> it being evident from the street. Imagery is out of date the day after
>> it's taken, and proper offset can be difficult to establish in big
>> cities where GPS signal is erratic. Pragmatically, I can tell you from
>> personal experience that building data in lovingly-mapped Berlin is
>> also worse than 1 meter accuracy. So again: best effort.
>>
>> What do we get from having buildings? A sense of land use (arguably
>> replaceable with larger landuse areas). A way to roughly estimate
>> population density. A way to gauge built-up density. A data source for
>> locating buildings in possible flood zones, or fire risk. Statistics:
>> as open data, queryable by APIs that are already used, in format
>> more-or-less common worldwide.
>>
>> Examples were given of rowhouse- or de-facto rowhouse-buildings where
>> a part is attached to the wrong building. This does not alter any of
>> the above examples. It's wrong, but is it substantially more wrong
>> than a blank subdivision, or one with only a few buildings mapped? Is
>> it better to have a null, or be off by 5%? The legal truth is in
>> property records, and we can't measure houses with a ruler, so OSM can
>> only be a 

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[Nate Wessel]

Hi Yaro,

I just had a chance to look at the documentation on the source data and 
I wasn't able to find anything about 3D features or parts of buildings 
being mapped separately. Are you guessing here, or is there 
documentation on this? If so can you point us to it?


In any case, the big shapefiles from StatsCan don't provide enough 
information to reconstruct any 3D geometries, so I'd be inclined to 
remove these from the import unless they can be brought in from another 
source with better documentation / attribute tagging. (i.e. City of 
Toronto?)


Thanks,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 1/18/19 2:48 PM, Yaro Shkvorets wrote:

Jarek,
There is no question we want this data. I went through much of it in 
Toronto and Kingston and I found it to be very good, consistent and 
precise. Time-wise it's somewhat current with 2016 ESRI imagery 
(sometimes ahead, sometimes slightly behind) and is well-aligned with 
it. It offers 3D features (when several buildings appear overlapped in 
the dataset) but you just need to be familiar with `building:part` tag 
to sort through it. I haven't looked at other provinces but in Ontario 
I really have no complaints about dataset quality whatsoever. Also I 
don't get Nate's "wildly unsimplified geometries" comment. IMO 
geometries are just perfectly detailed.



On Fri, Jan 18, 2019 at 2:00 PM Jarek Piórkowski > wrote:


Some more thoughts from me.

Building outlines, particularly for single-family subdivisions as seen
in Canadian suburbs, are extremely labour-intensive to map manually.

My parents' house is now on OSM - accurately. They live in a city with
about 10,000 buildings, and about 0.5 active mappers. This wouldn't
been completed manually in the next 5 years.

An option to do this automatically with a computer algorithm detecting
objects from imagery could be suggested, but this has not been very
accurate in OSM in the past, even when there is decent imagery. The
only other feasible data source is government, where they have such
data more or less.

The alternative is of course the opinion that we should not have
building outlines until someone goes through and adds the buildings
manually. In practice what I've seen done in Toronto is that bigger
buildings are mapped on best-effort basis from survey and imagery,
while areas of single-family houses are left blank. This isn't
_wrong_, and maybe some prefer this.

I would also like to note that building outlines will _never_ be
completely verifiably up to date. I can't go into most people's
backyards and verify that there isn't a new addition on their house. A
building might be legally split into two different properties without
it being evident from the street. Imagery is out of date the day after
it's taken, and proper offset can be difficult to establish in big
cities where GPS signal is erratic. Pragmatically, I can tell you from
personal experience that building data in lovingly-mapped Berlin is
also worse than 1 meter accuracy. So again: best effort.

What do we get from having buildings? A sense of land use (arguably
replaceable with larger landuse areas). A way to roughly estimate
population density. A way to gauge built-up density. A data source for
locating buildings in possible flood zones, or fire risk. Statistics:
as open data, queryable by APIs that are already used, in format
more-or-less common worldwide.

Examples were given of rowhouse- or de-facto rowhouse-buildings where
a part is attached to the wrong building. This does not alter any of
the above examples. It's wrong, but is it substantially more wrong
than a blank subdivision, or one with only a few buildings mapped? Is
it better to have a null, or be off by 5%? The legal truth is in
property records, and we can't measure houses with a ruler, so OSM can
only be a statistical source. And then there's the question of
verifiability - some of these buildings are connected to their
neighbour building inside. I've really struggled at distinguishing
what exactly is a "building" on Old Toronto avenues even with
street-side survey.

Bluntly, OSM is not perfect in Canada. I have pet peeves I can quote,
and I'm sure many of you do as well. If we import, the question is:
are we making it better?

1. Do we want this data?
2. Is it generally of acceptable quality?
3. Is there a mechanism to spot and reject where data is
particularly bad?

Cheers,
Jarek, who should really get back to updating built-last-year
stuff at Fort York

On Fri, 18 Jan 2019 at 09:31, Kyle Nuttall
mailto:kyle.nutt...@hotmail.ca>> wrote:
>
> The pilot project that took place in Ottawa for all these
building imports is what got me 

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[Blake Girardot]

Hi,

Tangentially, I often remap areas with poor mapping and use the
replace geometry tool. I estimate it adds about 5% time to the over
all remapping effort, which is totally acceptable for the benefits of
careful redoing and saving of object history and I encourage folks to
use that way where there is good hand crafted existing data where an
import or improvement is going on.

Here is a tutorial video that shows how I work with it and if done
right, why remapping and replace geometry are only about 5% more
effort than deleting and re mapping from scratch. It also directly
applies to the import conflation process and I use it anytime I am
involved in that type of workflow.

https://youtu.be/Kv5AOmX8M9g

Respectfully,
Blake

On Fri, Jan 18, 2019 at 11:14 PM Nate Wessel  wrote:
>
> Hi Yaro,
>
> Thanks for marking this as on-hold in the tasking manager. I know I came in 
> like a wrecking ball and I really appreciate y'all holding things up while we 
> discuss.
>
> I'd be happy to validate data and help import the rest of central Toronto 
> once we're up and running again! I use the data in this area a lot in my 
> work... so I have a vested interest in keeping it at it's best :-)
>
> As to the conflation issue, one of the things we're doing in the other import 
> I'm working on is that we've essentially split it into two parts. First we're 
> importing buildings that don't conflict with OSM at all - this is the easy 
> part - and only later will we go in a bit more surgically and try to add tags 
> to existing ways and replace geometries with better data. We haven't started 
> that part yet, though I imagine it will be a real slog. IMO, it seems like a 
> lot to ask that editors do both things at once as these are really very 
> different tasks, especially given the size of the tasks here.
>
> I wonder if you'd have any interest in a similar separation of tasks for this 
> import? I think one of the benefits is that less experienced mappers can get 
> their hands dirty on the easier new-data-import part, without having to be 
> expert on which geometry is better, how to preserve way histories and tags, 
> etc. Like I said, we haven't started this part yet in the other import, but 
> even I find the prospect a little daunting!
>
> Best,
>
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com
>
> On 1/18/19 2:15 PM, Yaro Shkvorets wrote:
>
> Nate,
> I'll change the project name to reflect that the import is on hold. As a 
> local mapper, if you want to take a lead on the Toronto import that'd be 
> great.
> I did review some of DannyMcD's edits last night 
> (Mississauga-Brampton-Vaughan) and to be honest was rather disappointed with 
> the quality. It appears Danny chose to import only new buildings (i.e. 
> residential homes mostly), leaving most of the existing hand-traced 
> non-residential building outlines in OSM untouched. That's unfortunate, the 
> dataset offers some really good data and leaving half of it behind makes it 
> more difficult to revisit in the future.
> In my edits (Markham-Scarborough-East York) I was aiming to replace as many 
> existing geometries with outlines from the import as possible. I think that's 
> what we should be trying to do going forward.
> Looking forward to your comments and discussion.
>
>
>
> On Fri, Jan 18, 2019 at 1:07 PM Nate Wessel  wrote:
>>
>> Hi all,
>>
>> I've just joined the talk-ca list, so please accept my apologies for not 
>> addressing this list earlier. I'm happy to take this thread off the imports 
>> list for now and onto talk-ca until things are ready to begin again. The 
>> next person to reply can please feel free to remove that email if they agree.
>>
>> I've just made a note on the draft import plan wiki page noting that the 
>> import has been stopped:
>>
>> https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan
>>
>> I would really appreciate it if the person with admin access to the tasking 
>> manager projects could please take those offline for the moment, or perhaps 
>> place them in a validation-only mode if that's possible.
>>
>> Like I said in my last email, which perhaps didn't make it to the talk-ca 
>> list 
>> (https://lists.openstreetmap.org/pipermail/imports/2019-January/005886.html) 
>> I'm now proposing that we leave the data that has already been imported and 
>> enter a phase of thorough validation on that data.
>>
>> My plan, over the next several days, is to do a general survey of the 
>> quality of the data that has been imported so far and make a list of 
>> systematic issues I see that should be addressed before we can consider 
>> moving forward again. I'll add those comments to the conversation in talk-ca 
>> and on the wiki page (link above), as I feel is appropriate. As I said 
>> before, I'm of the mind that this import did not get adequate review or 
>> approval and did not follow all the import guidelines. I 

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[Nate Wessel]

Hi Yaro,

Thanks for marking this as on-hold in the tasking manager. I know I came 
in like a wrecking ball and I really appreciate y'all holding things up 
while we discuss.


I'd be happy to validate data and help import the rest of central 
Toronto once we're up and running again! I use the data in this area a 
lot in my work... so I have a vested interest in keeping it at it's best :-)


As to the conflation issue, one of the things we're doing in the other 
import I'm working on is that we've essentially split it into two parts. 
First we're importing buildings that don't conflict with OSM at all - 
this is the easy part - and only later will we go in a bit more 
surgically and try to add tags to existing ways and replace geometries 
with better data. We haven't started that part yet, though I imagine it 
will be a real slog. IMO, it seems like a lot to ask that editors do 
both things at once as these are really very different tasks, especially 
given the size of the tasks here.


I wonder if you'd have any interest in a similar separation of tasks for 
this import? I think one of the benefits is that less experienced 
mappers can get their hands dirty on the easier new-data-import part, 
without having to be expert on which geometry is better, how to preserve 
way histories and tags, etc. Like I said, we haven't started this part 
yet in the other import, but even I find the prospect a little daunting!


Best,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 1/18/19 2:15 PM, Yaro Shkvorets wrote:

Nate,
I'll change the project name to reflect that the import is on hold. As 
a local mapper, if you want to take a lead on the Toronto import 
that'd be great.
I did review some of DannyMcD's edits last night 
(Mississauga-Brampton-Vaughan) and to be honest was rather 
disappointed with the quality. It appears Danny chose to import only 
new buildings (i.e. residential homes mostly), leaving most of the 
existing hand-traced non-residential building outlines in OSM 
untouched. That's unfortunate, the dataset offers some really good 
data and leaving half of it behind makes it more difficult to revisit 
in the future.
In my edits (Markham-Scarborough-East York) I was aiming to replace as 
many existing geometries with outlines from the import as possible. I 
think that's what we should be trying to do going forward.

Looking forward to your comments and discussion.



On Fri, Jan 18, 2019 at 1:07 PM Nate Wessel > wrote:


Hi all,

I've just joined the talk-ca list, so please accept my apologies
for not addressing this list earlier. I'm happy to take this
thread off the imports list for now and onto talk-ca until things
are ready to begin again. The next person to reply can please feel
free to remove that email if they agree.

I've just made a note on the draft import plan wiki page noting
that the import has been stopped:


https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan

I would really appreciate it if the person with admin access to
the tasking manager projects could please take those offline for
the moment, or perhaps place them in a validation-only mode if
that's possible.

Like I said in my last email, which perhaps didn't make it to the
talk-ca list
(https://lists.openstreetmap.org/pipermail/imports/2019-January/005886.html)
I'm now proposing that we leave the data that has already been
imported and enter a phase of thorough validation on that data.

My plan, over the next several days, is to do a general survey of
the quality of the data that has been imported so far and make a
list of systematic issues I see that should be addressed before we
can consider moving forward again. I'll add those comments to the
conversation in talk-ca and on the wiki page (link above), as I
feel is appropriate. As I said before, I'm of the mind that this
import did not get adequate review or approval and did not follow
all the import guidelines. I think therefore we need to take
stock, cross the t's, dot the i's, and move this thing back toward
where it needs to be. Step one is a thoroughly documented wiki
page outlining the proposal and responding to everything required
in the import guidelines.
https://wiki.openstreetmap.org/wiki/Import/Guidelines

I know there are people excited about this import, and people who
are eager to get back to work bringing buildings in, but I think
everyone will be happier in the end if we take the time to do this
right. We don't need to stop forever - we just need to stop until
we get things right. I sincerely respect the good intentions of
everyone involved in this and I hope we can all work together to
make OSM a map known for it's coverage AND it's quality.

Best,

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[john whelan]

Could you update the wiki to include these instructions please.

Thanks John

On Fri, 18 Jan 2019 at 14:53, Yaro Shkvorets  wrote:

> John,
> >> Traditionally or the party line is if its been mapped already then to
> preserve the history you either leave it alone or manually correct it.
> Manually correcting it is very time consuming.  Often the decision is made
> to leave the existing way in the map.
>
> JOSM offers very convenient way to do it called "Replace geometry". Select
> both ways, old and new, press Ctrl-Shift-G, merge any conflicting tags and
> you preserve the history, tags and have new improved outline in a couple of
> clicks.
>
> On Fri, Jan 18, 2019 at 2:30 PM john whelan  wrote:
>
>> And that is a problem with imports.  Traditionally or the party line is
>> if its been mapped already then to preserve the history you either leave it
>> alone or manually correct it.  Manually correcting it is very time
>> consuming.  Often the decision is made to leave the existing way in the map.
>>
>> I'm not going to say one method is correct over the other but the least
>> contentious is to add only things are are not there already.
>>
>> Cheerio John
>>
>> On Fri, 18 Jan 2019 at 14:17, Yaro Shkvorets  wrote:
>>
>>> Nate,
>>> I'll change the project name to reflect that the import is on hold. As a
>>> local mapper, if you want to take a lead on the Toronto import that'd be
>>> great.
>>> I did review some of DannyMcD's edits last night
>>> (Mississauga-Brampton-Vaughan) and to be honest was rather disappointed
>>> with the quality. It appears Danny chose to import only new buildings (i.e.
>>> residential homes mostly), leaving most of the existing hand-traced
>>> non-residential building outlines in OSM untouched. That's unfortunate, the
>>> dataset offers some really good data and leaving half of it behind makes it
>>> more difficult to revisit in the future.
>>> In my edits (Markham-Scarborough-East York) I was aiming to replace as
>>> many existing geometries with outlines from the import as possible. I think
>>> that's what we should be trying to do going forward.
>>> Looking forward to your comments and discussion.
>>>
>>>
>>>
>>> On Fri, Jan 18, 2019 at 1:07 PM Nate Wessel  wrote:
>>>
 Hi all,

 I've just joined the talk-ca list, so please accept my apologies for
 not addressing this list earlier. I'm happy to take this thread off the
 imports list for now and onto talk-ca until things are ready to begin
 again. The next person to reply can please feel free to remove that email
 if they agree.

 I've just made a note on the draft import plan wiki page noting that
 the import has been stopped:


 https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan

 I would really appreciate it if the person with admin access to the
 tasking manager projects could please take those offline for the moment, or
 perhaps place them in a validation-only mode if that's possible.

 Like I said in my last email, which perhaps didn't make it to the
 talk-ca list (
 https://lists.openstreetmap.org/pipermail/imports/2019-January/005886.html)
 I'm now proposing that we leave the data that has already been imported and
 enter a phase of thorough validation on that data.

 My plan, over the next several days, is to do a general survey of the
 quality of the data that has been imported so far and make a list of
 systematic issues I see that should be addressed before we can consider
 moving forward again. I'll add those comments to the conversation in
 talk-ca and on the wiki page (link above), as I feel is appropriate. As I
 said before, I'm of the mind that this import did not get adequate review
 or approval and did not follow all the import guidelines. I think therefore
 we need to take stock, cross the t's, dot the i's, and move this thing back
 toward where it needs to be. Step one is a thoroughly documented wiki page
 outlining the proposal and responding to everything required in the import
 guidelines.
 https://wiki.openstreetmap.org/wiki/Import/Guidelines

 I know there are people excited about this import, and people who are
 eager to get back to work bringing buildings in, but I think everyone will
 be happier in the end if we take the time to do this right. We don't need
 to stop forever - we just need to stop until we get things right. I
 sincerely respect the good intentions of everyone involved in this and I
 hope we can all work together to make OSM a map known for it's coverage AND
 it's quality.

 Best,
 Nate Wessel
 Jack of all trades, Master of Geography, PhD candidate in Urban Planning
 NateWessel.com 

 On 1/17/19 9:05 PM, OSM Volunteer stevea wrote:

 The thread link is:  
 

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[Yaro Shkvorets]

Jarek,
There is no question we want this data. I went through much of it in
Toronto and Kingston and I found it to be very good, consistent and
precise. Time-wise it's somewhat current with 2016 ESRI imagery (sometimes
ahead, sometimes slightly behind) and is well-aligned with it. It offers 3D
features (when several buildings appear overlapped in the dataset) but you
just need to be familiar with `building:part` tag to sort through it. I
haven't looked at other provinces but in Ontario I really have no
complaints about dataset quality whatsoever. Also I don't get Nate's
"wildly unsimplified geometries" comment. IMO geometries are just perfectly
detailed.


On Fri, Jan 18, 2019 at 2:00 PM Jarek Piórkowski 
wrote:

> Some more thoughts from me.
>
> Building outlines, particularly for single-family subdivisions as seen
> in Canadian suburbs, are extremely labour-intensive to map manually.
>
> My parents' house is now on OSM - accurately. They live in a city with
> about 10,000 buildings, and about 0.5 active mappers. This wouldn't
> been completed manually in the next 5 years.
>
> An option to do this automatically with a computer algorithm detecting
> objects from imagery could be suggested, but this has not been very
> accurate in OSM in the past, even when there is decent imagery. The
> only other feasible data source is government, where they have such
> data more or less.
>
> The alternative is of course the opinion that we should not have
> building outlines until someone goes through and adds the buildings
> manually. In practice what I've seen done in Toronto is that bigger
> buildings are mapped on best-effort basis from survey and imagery,
> while areas of single-family houses are left blank. This isn't
> _wrong_, and maybe some prefer this.
>
> I would also like to note that building outlines will _never_ be
> completely verifiably up to date. I can't go into most people's
> backyards and verify that there isn't a new addition on their house. A
> building might be legally split into two different properties without
> it being evident from the street. Imagery is out of date the day after
> it's taken, and proper offset can be difficult to establish in big
> cities where GPS signal is erratic. Pragmatically, I can tell you from
> personal experience that building data in lovingly-mapped Berlin is
> also worse than 1 meter accuracy. So again: best effort.
>
> What do we get from having buildings? A sense of land use (arguably
> replaceable with larger landuse areas). A way to roughly estimate
> population density. A way to gauge built-up density. A data source for
> locating buildings in possible flood zones, or fire risk. Statistics:
> as open data, queryable by APIs that are already used, in format
> more-or-less common worldwide.
>
> Examples were given of rowhouse- or de-facto rowhouse-buildings where
> a part is attached to the wrong building. This does not alter any of
> the above examples. It's wrong, but is it substantially more wrong
> than a blank subdivision, or one with only a few buildings mapped? Is
> it better to have a null, or be off by 5%? The legal truth is in
> property records, and we can't measure houses with a ruler, so OSM can
> only be a statistical source. And then there's the question of
> verifiability - some of these buildings are connected to their
> neighbour building inside. I've really struggled at distinguishing
> what exactly is a "building" on Old Toronto avenues even with
> street-side survey.
>
> Bluntly, OSM is not perfect in Canada. I have pet peeves I can quote,
> and I'm sure many of you do as well. If we import, the question is:
> are we making it better?
>
> 1. Do we want this data?
> 2. Is it generally of acceptable quality?
> 3. Is there a mechanism to spot and reject where data is particularly bad?
>
> Cheers,
> Jarek, who should really get back to updating built-last-year stuff at
> Fort York
>
> On Fri, 18 Jan 2019 at 09:31, Kyle Nuttall 
> wrote:
> >
> > The pilot project that took place in Ottawa for all these building
> imports is what got me hooked into OSM in the first place. I would make
> only very minor changes here and there. I even attempted to draw building
> footprints but got burnt out after only doing a single street, which was
> very discouraging for me to continue.
> >
> > When I saw the entire neighbourhood get flooded with new buildings that
> weren't there before, I was entirely intrigued and actually got on board
> with the locals to help with the process. I've been hooked since and have
> been to many meetups afterwards. Helping out with projects completely
> unrelated to the initial building import.
> >
> > I'm entirely of the belief that it is much more encouraging for a new
> user to make a minor change (eg. changing `building=yes` to
> `building=detached`) than it is to add every single minor detail to each
> object from scratch (visiting the location, drawing the building footprints
> manually, adding address data, etc.). It's 

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[john whelan]

And that is a problem with imports.  Traditionally or the party line is if
its been mapped already then to preserve the history you either leave it
alone or manually correct it.  Manually correcting it is very time
consuming.  Often the decision is made to leave the existing way in the map.

I'm not going to say one method is correct over the other but the least
contentious is to add only things are are not there already.

Cheerio John

On Fri, 18 Jan 2019 at 14:17, Yaro Shkvorets  wrote:

> Nate,
> I'll change the project name to reflect that the import is on hold. As a
> local mapper, if you want to take a lead on the Toronto import that'd be
> great.
> I did review some of DannyMcD's edits last night
> (Mississauga-Brampton-Vaughan) and to be honest was rather disappointed
> with the quality. It appears Danny chose to import only new buildings (i.e.
> residential homes mostly), leaving most of the existing hand-traced
> non-residential building outlines in OSM untouched. That's unfortunate, the
> dataset offers some really good data and leaving half of it behind makes it
> more difficult to revisit in the future.
> In my edits (Markham-Scarborough-East York) I was aiming to replace as
> many existing geometries with outlines from the import as possible. I think
> that's what we should be trying to do going forward.
> Looking forward to your comments and discussion.
>
>
>
> On Fri, Jan 18, 2019 at 1:07 PM Nate Wessel  wrote:
>
>> Hi all,
>>
>> I've just joined the talk-ca list, so please accept my apologies for not
>> addressing this list earlier. I'm happy to take this thread off the imports
>> list for now and onto talk-ca until things are ready to begin again. The
>> next person to reply can please feel free to remove that email if they
>> agree.
>>
>> I've just made a note on the draft import plan wiki page noting that the
>> import has been stopped:
>>
>>
>> https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan
>>
>> I would really appreciate it if the person with admin access to the
>> tasking manager projects could please take those offline for the moment, or
>> perhaps place them in a validation-only mode if that's possible.
>>
>> Like I said in my last email, which perhaps didn't make it to the talk-ca
>> list (
>> https://lists.openstreetmap.org/pipermail/imports/2019-January/005886.html)
>> I'm now proposing that we leave the data that has already been imported and
>> enter a phase of thorough validation on that data.
>>
>> My plan, over the next several days, is to do a general survey of the
>> quality of the data that has been imported so far and make a list of
>> systematic issues I see that should be addressed before we can consider
>> moving forward again. I'll add those comments to the conversation in
>> talk-ca and on the wiki page (link above), as I feel is appropriate. As I
>> said before, I'm of the mind that this import did not get adequate review
>> or approval and did not follow all the import guidelines. I think therefore
>> we need to take stock, cross the t's, dot the i's, and move this thing back
>> toward where it needs to be. Step one is a thoroughly documented wiki page
>> outlining the proposal and responding to everything required in the import
>> guidelines.
>> https://wiki.openstreetmap.org/wiki/Import/Guidelines
>>
>> I know there are people excited about this import, and people who are
>> eager to get back to work bringing buildings in, but I think everyone will
>> be happier in the end if we take the time to do this right. We don't need
>> to stop forever - we just need to stop until we get things right. I
>> sincerely respect the good intentions of everyone involved in this and I
>> hope we can all work together to make OSM a map known for it's coverage AND
>> it's quality.
>>
>> Best,
>> Nate Wessel
>> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
>> NateWessel.com 
>>
>> On 1/17/19 9:05 PM, OSM Volunteer stevea wrote:
>>
>> The thread link is:  
>> https://lists.openstreetmap.org/pipermail/imports/2019-January/005878.html
>>
>> SteveA
>>
>>
>
> --
> Best Regards,
>   Yaro Shkvorets
> ___
> 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] Ongoing Canadian building import needs to be stopped, possibly reverted

[Yaro Shkvorets]

Nate,
I'll change the project name to reflect that the import is on hold. As a
local mapper, if you want to take a lead on the Toronto import that'd be
great.
I did review some of DannyMcD's edits last night
(Mississauga-Brampton-Vaughan) and to be honest was rather disappointed
with the quality. It appears Danny chose to import only new buildings (i.e.
residential homes mostly), leaving most of the existing hand-traced
non-residential building outlines in OSM untouched. That's unfortunate, the
dataset offers some really good data and leaving half of it behind makes it
more difficult to revisit in the future.
In my edits (Markham-Scarborough-East York) I was aiming to replace as many
existing geometries with outlines from the import as possible. I think
that's what we should be trying to do going forward.
Looking forward to your comments and discussion.



On Fri, Jan 18, 2019 at 1:07 PM Nate Wessel  wrote:

> Hi all,
>
> I've just joined the talk-ca list, so please accept my apologies for not
> addressing this list earlier. I'm happy to take this thread off the imports
> list for now and onto talk-ca until things are ready to begin again. The
> next person to reply can please feel free to remove that email if they
> agree.
>
> I've just made a note on the draft import plan wiki page noting that the
> import has been stopped:
>
>
> https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan
>
> I would really appreciate it if the person with admin access to the
> tasking manager projects could please take those offline for the moment, or
> perhaps place them in a validation-only mode if that's possible.
>
> Like I said in my last email, which perhaps didn't make it to the talk-ca
> list (
> https://lists.openstreetmap.org/pipermail/imports/2019-January/005886.html)
> I'm now proposing that we leave the data that has already been imported and
> enter a phase of thorough validation on that data.
>
> My plan, over the next several days, is to do a general survey of the
> quality of the data that has been imported so far and make a list of
> systematic issues I see that should be addressed before we can consider
> moving forward again. I'll add those comments to the conversation in
> talk-ca and on the wiki page (link above), as I feel is appropriate. As I
> said before, I'm of the mind that this import did not get adequate review
> or approval and did not follow all the import guidelines. I think therefore
> we need to take stock, cross the t's, dot the i's, and move this thing back
> toward where it needs to be. Step one is a thoroughly documented wiki page
> outlining the proposal and responding to everything required in the import
> guidelines.
> https://wiki.openstreetmap.org/wiki/Import/Guidelines
>
> I know there are people excited about this import, and people who are
> eager to get back to work bringing buildings in, but I think everyone will
> be happier in the end if we take the time to do this right. We don't need
> to stop forever - we just need to stop until we get things right. I
> sincerely respect the good intentions of everyone involved in this and I
> hope we can all work together to make OSM a map known for it's coverage AND
> it's quality.
>
> Best,
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 1/17/19 9:05 PM, OSM Volunteer stevea wrote:
>
> The thread link is:  
> https://lists.openstreetmap.org/pipermail/imports/2019-January/005878.html
>
> SteveA
>
>

-- 
Best Regards,
  Yaro Shkvorets
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[Jarek Piórkowski]

Some more thoughts from me.

Building outlines, particularly for single-family subdivisions as seen
in Canadian suburbs, are extremely labour-intensive to map manually.

My parents' house is now on OSM - accurately. They live in a city with
about 10,000 buildings, and about 0.5 active mappers. This wouldn't
been completed manually in the next 5 years.

An option to do this automatically with a computer algorithm detecting
objects from imagery could be suggested, but this has not been very
accurate in OSM in the past, even when there is decent imagery. The
only other feasible data source is government, where they have such
data more or less.

The alternative is of course the opinion that we should not have
building outlines until someone goes through and adds the buildings
manually. In practice what I've seen done in Toronto is that bigger
buildings are mapped on best-effort basis from survey and imagery,
while areas of single-family houses are left blank. This isn't
_wrong_, and maybe some prefer this.

I would also like to note that building outlines will _never_ be
completely verifiably up to date. I can't go into most people's
backyards and verify that there isn't a new addition on their house. A
building might be legally split into two different properties without
it being evident from the street. Imagery is out of date the day after
it's taken, and proper offset can be difficult to establish in big
cities where GPS signal is erratic. Pragmatically, I can tell you from
personal experience that building data in lovingly-mapped Berlin is
also worse than 1 meter accuracy. So again: best effort.

What do we get from having buildings? A sense of land use (arguably
replaceable with larger landuse areas). A way to roughly estimate
population density. A way to gauge built-up density. A data source for
locating buildings in possible flood zones, or fire risk. Statistics:
as open data, queryable by APIs that are already used, in format
more-or-less common worldwide.

Examples were given of rowhouse- or de-facto rowhouse-buildings where
a part is attached to the wrong building. This does not alter any of
the above examples. It's wrong, but is it substantially more wrong
than a blank subdivision, or one with only a few buildings mapped? Is
it better to have a null, or be off by 5%? The legal truth is in
property records, and we can't measure houses with a ruler, so OSM can
only be a statistical source. And then there's the question of
verifiability - some of these buildings are connected to their
neighbour building inside. I've really struggled at distinguishing
what exactly is a "building" on Old Toronto avenues even with
street-side survey.

Bluntly, OSM is not perfect in Canada. I have pet peeves I can quote,
and I'm sure many of you do as well. If we import, the question is:
are we making it better?

1. Do we want this data?
2. Is it generally of acceptable quality?
3. Is there a mechanism to spot and reject where data is particularly bad?

Cheers,
Jarek, who should really get back to updating built-last-year stuff at Fort York

On Fri, 18 Jan 2019 at 09:31, Kyle Nuttall  wrote:
>
> The pilot project that took place in Ottawa for all these building imports is 
> what got me hooked into OSM in the first place. I would make only very minor 
> changes here and there. I even attempted to draw building footprints but got 
> burnt out after only doing a single street, which was very discouraging for 
> me to continue.
>
> When I saw the entire neighbourhood get flooded with new buildings that 
> weren't there before, I was entirely intrigued and actually got on board with 
> the locals to help with the process. I've been hooked since and have been to 
> many meetups afterwards. Helping out with projects completely unrelated to 
> the initial building import.
>
> I'm entirely of the belief that it is much more encouraging for a new user to 
> make a minor change (eg. changing `building=yes` to `building=detached`) than 
> it is to add every single minor detail to each object from scratch (visiting 
> the location, drawing the building footprints manually, adding address data, 
> etc.). It's just overwhelming for a new user.
>
> It is very much a cat-and-mouse type scenario with community driven projects 
> like OSM. Apparently the issue with this import is the lack of community 
> involvement but I can for sure tell you that this import will help flourish 
> the community in the local areas. Especially if they only need to add or 
> change minor tags than if they would have had to create all of this data by 
> hand. With an import this size there is bound to be some errors that slip 
> through. That's where the community comes through to correct these minor 
> things.
>
> This is the whole point of OSM. A user creates an object with as much 
> information as they know and the next user comes and adds onto that, and the 
> next user adds and/or updates even more. Neither of those users on their own 
> could have 

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[Nate Wessel]

Hi all,

I've just joined the talk-ca list, so please accept my apologies for not 
addressing this list earlier. I'm happy to take this thread off the 
imports list for now and onto talk-ca until things are ready to begin 
again. The next person to reply can please feel free to remove that 
email if they agree.


I've just made a note on the draft import plan wiki page noting that the 
import has been stopped:


https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan

I would really appreciate it if the person with admin access to the 
tasking manager projects could please take those offline for the moment, 
or perhaps place them in a validation-only mode if that's possible.


Like I said in my last email, which perhaps didn't make it to the 
talk-ca list 
(https://lists.openstreetmap.org/pipermail/imports/2019-January/005886.html) 
I'm now proposing that we leave the data that has already been imported 
and enter a phase of thorough validation on that data.


My plan, over the next several days, is to do a general survey of the 
quality of the data that has been imported so far and make a list of 
systematic issues I see that should be addressed before we can consider 
moving forward again. I'll add those comments to the conversation in 
talk-ca and on the wiki page (link above), as I feel is appropriate. As 
I said before, I'm of the mind that this import did not get adequate 
review or approval and did not follow all the import guidelines. I think 
therefore we need to take stock, cross the t's, dot the i's, and move 
this thing back toward where it needs to be. Step one is a thoroughly 
documented wiki page outlining the proposal and responding to everything 
required in the import guidelines.

https://wiki.openstreetmap.org/wiki/Import/Guidelines

I know there are people excited about this import, and people who are 
eager to get back to work bringing buildings in, but I think everyone 
will be happier in the end if we take the time to do this right. We 
don't need to stop forever - we just need to stop until we get things 
right. I sincerely respect the good intentions of everyone involved in 
this and I hope we can all work together to make OSM a map known for 
it's coverage AND it's quality.


Best,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 1/17/19 9:05 PM, OSM Volunteer stevea wrote:

The thread link is:  
https://lists.openstreetmap.org/pipermail/imports/2019-January/005878.html

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

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[Kyle Nuttall]

The pilot project that took place in Ottawa for all these building imports is 
what got me hooked into OSM in the first place. I would make only very minor 
changes here and there. I even attempted to draw building footprints but got 
burnt out after only doing a single street, which was very discouraging for me 
to continue.

When I saw the entire neighbourhood get flooded with new buildings that weren't 
there before, I was entirely intrigued and actually got on board with the 
locals to help with the process. I've been hooked since and have been to many 
meetups afterwards. Helping out with projects completely unrelated to the 
initial building import.

I'm entirely of the belief that it is much more encouraging for a new user to 
make a minor change (eg. changing `building=yes` to `building=detached`) than 
it is to add every single minor detail to each object from scratch (visiting 
the location, drawing the building footprints manually, adding address data, 
etc.). It's just overwhelming for a new user.

It is very much a cat-and-mouse type scenario with community driven projects 
like OSM. Apparently the issue with this import is the lack of community 
involvement but I can for sure tell you that this import will help flourish the 
community in the local areas. Especially if they only need to add or change 
minor tags than if they would have had to create all of this data by hand. With 
an import this size there is bound to be some errors that slip through. That's 
where the community comes through to correct these minor things.

This is the whole point of OSM. A user creates an object with as much 
information as they know and the next user comes and adds onto that, and the 
next user adds and/or updates even more. Neither of those users on their own 
could have added as much detail as all of their knowledge combined.

Are we supposed to just wait for a user who can add every single building with 
centimetre precision and every bit of detail simply because we can't? No, of 
course not. We do the best we can and have other users who know more than we do 
build on that.

I fully endorse this import because I would love to see what it does for the 
local communities that apparently need to figure this import out for themselves.

Cheers,
Kyle

On Jan. 18, 2019 05:40, James  wrote:
As Frederik Ramm once said(sorry i'm paraphrasing from memory please don't 
shoot me) There has never been a GO-Nogo for imports, you bring it up on the 
mailing lists with reasonable delay, is there no objections(in this case no one 
was saying anything about it for 2-3 weeks) then email the list that the import 
would start.

On Fri., Jan. 18, 2019, 12:59 a.m. Alan Richards 
mailto:alarob...@gmail.com> wrote:
Along the lines of what Jarek said, sometimes silence just means tacit 
acceptance, or that it's not that controversial. There's quite a bit of 
government data here that is supposedly "open" but unavailable for OSM, so I'm 
very glad Stats Can was able to find a way to collect municipal data and 
publish it under one national license. I was surprised myself it hadn't got 
more attention, but I'm firmly onboard with more imports if done with care.
Manually adding buildings - especially residential neighborhoods, is about the 
most boring task I can think of, yet it does add a lot to the map.

I'll admit I hadn't looked at the data quality myself, but I just did review 
several task squares around BC and they look pretty good. Houses were all in 
the right place, accurate, and generally as much or even more detailed than I 
typically see. Issues seemed to be mostly the larger commercial buildings being 
overly large or missing detail, but in general these are the buildings most 
likely to be already mapped. To a large degree, it's up the individual importer 
to do some quality control, review against existing object, satellite, etc. If 
we have specific issues we can and should address them, but if the data is 
largely good then I see no need to abort or revert.

alarobric

On Thu, Jan 17, 2019 at 7:41 PM Jarek Piórkowski 
mailto:ja...@piorkowski.ca>> wrote:
On Thu, 17 Jan 2019 at 21:46, OSM Volunteer stevea
mailto:stevea...@softworkers.com>> wrote:
> Thanks, Jarek.  Considering I am a proponent of "perfection must not be the 
> enemy of good" (regarding OSM data entry), I think data which are "darn good, 
> though not perfect" DO deserve to enter into OSM.  Sometimes "darn good" 
> might be 85%, 95% "good," as then we'll get it to 99% and then 100% over 
> time.  But if the focus on "how" isn't sharp enough to get it to 85% (or so) 
> during initial entry, go back and start over to get that number up.  85% 
> sounds arbitrary, I know, but think of it as "a solid B" which might be 
> "passes the class for now" without failing.  And it's good we develop a 
> "meanwhile strategy" to take it to 99% and then 100% in the (near- or at most 
> mid-term) future.  This isn't outrageously difficult, though it does take 
> 

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[James]

As Frederik Ramm once said(sorry i'm paraphrasing from memory please don't
shoot me) There has never been a GO-Nogo for imports, you bring it up on
the mailing lists with reasonable delay, is there no objections(in this
case no one was saying anything about it for 2-3 weeks) then email the list
that the import would start.

On Fri., Jan. 18, 2019, 12:59 a.m. Alan Richards  Along the lines of what Jarek said, sometimes silence just means tacit
> acceptance, or that it's not that controversial. There's quite a bit of
> government data here that is supposedly "open" but unavailable for OSM, so
> I'm very glad Stats Can was able to find a way to collect municipal data
> and publish it under one national license. I was surprised myself it hadn't
> got more attention, but I'm firmly onboard with more imports if done with
> care.
> Manually adding buildings - especially residential neighborhoods, is about
> the most boring task I can think of, yet it does add a lot to the map.
>
> I'll admit I hadn't looked at the data quality myself, but I just did
> review several task squares around BC and they look pretty good. Houses
> were all in the right place, accurate, and generally as much or even more
> detailed than I typically see. Issues seemed to be mostly the larger
> commercial buildings being overly large or missing detail, but in general
> these are the buildings most likely to be already mapped. To a large
> degree, it's up the individual importer to do some quality control, review
> against existing object, satellite, etc. If we have specific issues we can
> and should address them, but if the data is largely good then I see no need
> to abort or revert.
>
> alarobric
>
> On Thu, Jan 17, 2019 at 7:41 PM Jarek Piórkowski 
> wrote:
>
>> On Thu, 17 Jan 2019 at 21:46, OSM Volunteer stevea
>>  wrote:
>> > Thanks, Jarek.  Considering I am a proponent of "perfection must not be
>> the enemy of good" (regarding OSM data entry), I think data which are "darn
>> good, though not perfect" DO deserve to enter into OSM.  Sometimes "darn
>> good" might be 85%, 95% "good," as then we'll get it to 99% and then 100%
>> over time.  But if the focus on "how" isn't sharp enough to get it to 85%
>> (or so) during initial entry, go back and start over to get that number
>> up.  85% sounds arbitrary, I know, but think of it as "a solid B" which
>> might be "passes the class for now" without failing.  And it's good we
>> develop a "meanwhile strategy" to take it to 99% and then 100% in the
>> (near- or at most mid-term) future.  This isn't outrageously difficult,
>> though it does take patience and coordination.  Open communication is a
>> prerequisite.
>>
>> Thank you for this commitment. I wish others shared it. Unfortunately
>> the reality I've been seeing in OSM is that edits which are 90+% good
>> (like this import) are challenged, while edits which are 50+% bad
>> (maps.me submissions, wheelmap/rosemary v0.4.4 going to completely
>> wrong locations for _years_) go unchallenged or are laboriously
>> manually fixed afterward.
>>
>> --Jarek
>>
>> ___
>> 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] Ongoing Canadian building import needs to be stopped, possibly reverted

[Alan Richards]

Along the lines of what Jarek said, sometimes silence just means tacit
acceptance, or that it's not that controversial. There's quite a bit of
government data here that is supposedly "open" but unavailable for OSM, so
I'm very glad Stats Can was able to find a way to collect municipal data
and publish it under one national license. I was surprised myself it hadn't
got more attention, but I'm firmly onboard with more imports if done with
care.
Manually adding buildings - especially residential neighborhoods, is about
the most boring task I can think of, yet it does add a lot to the map.

I'll admit I hadn't looked at the data quality myself, but I just did
review several task squares around BC and they look pretty good. Houses
were all in the right place, accurate, and generally as much or even more
detailed than I typically see. Issues seemed to be mostly the larger
commercial buildings being overly large or missing detail, but in general
these are the buildings most likely to be already mapped. To a large
degree, it's up the individual importer to do some quality control, review
against existing object, satellite, etc. If we have specific issues we can
and should address them, but if the data is largely good then I see no need
to abort or revert.

alarobric

On Thu, Jan 17, 2019 at 7:41 PM Jarek Piórkowski 
wrote:

> On Thu, 17 Jan 2019 at 21:46, OSM Volunteer stevea
>  wrote:
> > Thanks, Jarek.  Considering I am a proponent of "perfection must not be
> the enemy of good" (regarding OSM data entry), I think data which are "darn
> good, though not perfect" DO deserve to enter into OSM.  Sometimes "darn
> good" might be 85%, 95% "good," as then we'll get it to 99% and then 100%
> over time.  But if the focus on "how" isn't sharp enough to get it to 85%
> (or so) during initial entry, go back and start over to get that number
> up.  85% sounds arbitrary, I know, but think of it as "a solid B" which
> might be "passes the class for now" without failing.  And it's good we
> develop a "meanwhile strategy" to take it to 99% and then 100% in the
> (near- or at most mid-term) future.  This isn't outrageously difficult,
> though it does take patience and coordination.  Open communication is a
> prerequisite.
>
> Thank you for this commitment. I wish others shared it. Unfortunately
> the reality I've been seeing in OSM is that edits which are 90+% good
> (like this import) are challenged, while edits which are 50+% bad
> (maps.me submissions, wheelmap/rosemary v0.4.4 going to completely
> wrong locations for _years_) go unchallenged or are laboriously
> manually fixed afterward.
>
> --Jarek
>
> ___
> 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] Ongoing Canadian building import needs to be stopped, possibly reverted

[Jarek Piórkowski]

On Thu, 17 Jan 2019 at 21:46, OSM Volunteer stevea
 wrote:
> Thanks, Jarek.  Considering I am a proponent of "perfection must not be the 
> enemy of good" (regarding OSM data entry), I think data which are "darn good, 
> though not perfect" DO deserve to enter into OSM.  Sometimes "darn good" 
> might be 85%, 95% "good," as then we'll get it to 99% and then 100% over 
> time.  But if the focus on "how" isn't sharp enough to get it to 85% (or so) 
> during initial entry, go back and start over to get that number up.  85% 
> sounds arbitrary, I know, but think of it as "a solid B" which might be 
> "passes the class for now" without failing.  And it's good we develop a 
> "meanwhile strategy" to take it to 99% and then 100% in the (near- or at most 
> mid-term) future.  This isn't outrageously difficult, though it does take 
> patience and coordination.  Open communication is a prerequisite.

Thank you for this commitment. I wish others shared it. Unfortunately
the reality I've been seeing in OSM is that edits which are 90+% good
(like this import) are challenged, while edits which are 50+% bad
(maps.me submissions, wheelmap/rosemary v0.4.4 going to completely
wrong locations for _years_) go unchallenged or are laboriously
manually fixed afterward.

--Jarek

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

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[OSM Volunteer stevea]

On Jan 17, 2019, at 6:27 PM, Jarek Piórkowski  wrote:
> When no one is responding, sometimes it is because they are fine with
> the message as-is. I read it. I was fine with it. This isn't an
> Australian election.

I'm not sure about the allusion to Australian elections, so I'll let that pass 
(over my head).  I will self-admonish at not saying more in November at the 
"reboot post," as while I felt then that these (BC2020) efforts would go awry 
(again) this time (and here we are) I also felt like some (would, do) see me as 
a loud-mouth with an unwelcome message.  Despite my continuing desire to be 
polite ("you catch more flies with honey than you do with vinegar"), no amount 
of sugar-coating was going to sweeten a dearth of consensus and a 
still-vinegar-sour early-draft wiki into the green flag of "let's proceed."

I tried to write as much as I thought helpful into that wiki, however, it never 
became more sharply focused, which badly needed doing.  Lesson learned (by me, 
how about Canadian OSM volunteers?).  Honestly, I am not looking to flog 
anybody here, let's simply learn how to do this better.  There are kernels of 
success here that can be further developed, so, go do that.  Figure out how, 
first, then proceed.  Most/all of the principal and important players talking 
to each other while/as you do so seems like "first grade" to me and isn't 
really so hard, it's more like effort that needs to be truly expended rather 
than wished for instead.  OSM isn't a crowdsourcing magic trick.  Especially 
with nationwide efforts, it's "one building (rail line, bike route, park 
boundary...) at a time."  Do that well (early) and scale that up (after).

> I must say I find the panic about imperfect building shapes is a bit
> amusing considering the very poorly manually-drawn sidewalks I've been
> seeing and having to fix in Toronto, or thousands of laneways having a
> descriptive "name" added by our corporate friends. Do we aim for
> perfect, or for good? Because if it's perfect, I see a _lot_ to be
> reverted or deleted.

Thanks, Jarek.  Considering I am a proponent of "perfection must not be the 
enemy of good" (regarding OSM data entry), I think data which are "darn good, 
though not perfect" DO deserve to enter into OSM.  Sometimes "darn good" might 
be 85%, 95% "good," as then we'll get it to 99% and then 100% over time.  But 
if the focus on "how" isn't sharp enough to get it to 85% (or so) during 
initial entry, go back and start over to get that number up.  85% sounds 
arbitrary, I know, but think of it as "a solid B" which might be "passes the 
class for now" without failing.  And it's good we develop a "meanwhile 
strategy" to take it to 99% and then 100% in the (near- or at most mid-term) 
future.  This isn't outrageously difficult, though it does take patience and 
coordination.  Open communication is a prerequisite.

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

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[Jarek Piórkowski]

On Thu, 17 Jan 2019 at 21:04, OSM Volunteer stevea
 wrote:
>> The import was discussed on talk-ca and in my opinion there was a consensus 
>> of opinion it should go ahead. The data comes from the municipalities of 
>> which there are some 37,000 separate ones in Canada.  The idea of a single 
>> import plan was suggested on talk-ca by someone not involved rather than 
>> have 37,000 different import plans.  Many municipalities are very small.
> There was a serious dearth of reply, and nothing even approaching "consensus 
> of opinion," indicating (to me and likely others) that a nationwide import 
> did not have the wide, national consensus it must have to continue.  John, 
> we're simply going to disagree about that, it seems.  Especially in light of 
> the events in this desire/wiki/project going back to 2017, MUCH more 
> consensus ought to have been built.  I kept my mouth largely shut at the 
> reboot two months ago, yet here we are.

When no one is responding, sometimes it is because they are fine with
the message as-is. I read it. I was fine with it. This isn't an
Australian election.

I must say I find the panic about imperfect building shapes is a bit
amusing considering the very poorly manually-drawn sidewalks I've been
seeing and having to fix in Toronto, or thousands of laneways having a
descriptive "name" added by our corporate friends. Do we aim for
perfect, or for good? Because if it's perfect, I see a _lot_ to be
reverted or deleted.

--Jarek

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

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[OSM Volunteer stevea]

The thread link is:  
https://lists.openstreetmap.org/pipermail/imports/2019-January/005878.html

SteveA

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

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

[OSM Volunteer stevea]

This is redirected (by request of its author) from a thread on the (talk-) 
imports mailing list at .
On Jan 17, 2019, at 4:55 PM, John Whelan  wrote:
> The import was discussed on talk-ca and in my opinion there was a consensus 
> of opinion it should go ahead. The data comes from the municipalities of 
> which there are some 37,000 separate ones in Canada.  The idea of a single 
> import plan was suggested on talk-ca by someone not involved rather than have 
> 37,000 different import plans.  Many municipalities are very small.

There was a serious dearth of reply, and nothing even approaching "consensus of 
opinion," indicating (to me and likely others) that a nationwide import did not 
have the wide, national consensus it must have to continue.  John, we're simply 
going to disagree about that, it seems.  Especially in light of the events in 
this desire/wiki/project going back to 2017, MUCH more consensus ought to have 
been built.  I kept my mouth largely shut at the reboot two months ago, yet 
here we are.

> If you look at Canada there are locations with poor imagery and lots of 
> buildings and my suspicion is some were being imported without the licenses 
> really meeting the OSM licensing requirements.

Really?  Then, fix this.  That's a bit blunt of me, yes, yet, there it is.  
Stop.  Fix this.  You need coordination, via built-in tools like wiki, this 
list, and a real dialog made up of real conversation for this to continue.  
There appears to be a desire to do this, but there does not appear to be 
anybody willing to take responsibility to do it right, except perhaps 
(presently) Yaro, who John apparently not only has never met, but in all 
likelihood, has never communicated with.  Hence, "let your wiki communicate for 
you."  It is very good at this, I speak from personal experience on nationwide 
efforts, though I will tell you it takes work, dedication, time and writing 
skills.  Dismissing wiki as "too detailed" or "ineffective" is not a green flag 
to begin a race.  It means "stop, fix the wiki so anybody who comes along will 
know what to do."  So:  "bzzzt."  Not there yet, though, it seems Yaro was able 
to glean enough to make progress.  Grow his kernel of expertise and expand what 
works about it.

> Many locations in Canada do not have a group of OpenStreetMap local mappers.  
> Many locations do.  Locating local groups is difficult.  My understanding is 
> it has always been it is the local community who make the decision to do an 
> import.  We did use talk-ca and if you wish to continue the conversation then 
> I would suggest that is the place to hold the conversation.  I think the 
> problem here is defining the ideal local community.  It is probably somewhere 
> between the whole of Canada and each individual municipality and contains 
> groups of local mappers.

Really?  Then, fix this.  A national project (nearly single-handedly) like this 
into OSM is a very, very tall order.  It seems quite disingenuous to me to 
initiate these data and "hope for the best."  It's not exactly the same as 
giving matches, gasoline, dynamite, liquor and car keys to teenagers and being 
surprised at a tragic outcome, but it does stray in that direction of 
irresponsibility.  This time, I don't think you are allowed to be surprised.

> The intent is certainly to involve local mappers, building outlines by 
> themselves are especially interesting but building outlines with added tags 
> are much more interesting.  We need boots on the ground, we need local 
> mappers onside. 

You (John, others, the poorly-focused impetus to import these data...) DID get 
local mappers involved.  Today, I believe John implied or said he hasn't even 
communicated with them.  (Or barely has).  Yet while some work seems patient 
and better quality, enough bad data alarmed Nate (and others, myself included) 
enough to say something.  This simply shouldn't happen.

Please right your ship.  I don't pretend to represent all of OSM as I ask this, 
but I do stand tall in this project and politely ask you to do so.  Nate wrote 
some powerfully-potent directions for this building importation to go in with 
his later post.  Those are a good start, a "productive way forward."  Talk-ca 
(this channel) and wiki (including its Talk page, Discussion tab) are 
wide-area, very open, vetted, scrutinizable methodologies to communicate about 
this.  Let's keep the way(s) forward OPEN for discussion so this doesn't happen 
any longer.  Please!

We don't need 37,000 import plans and nobody is suggesting we do.  We do need 
good project management to import Canada's buildings.  There, I said it.  
(Again).  This starts with good, open communication.  Nothing less will do, or 
you consign your project to a whispered hope upon the wind, and that won't do 
it.

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