Re: [Talk-ca] Place Tagging

[OSM Volunteer stevea]

On Jan 24, 2019, at 11:03 AM, Danny McDonald  wrote:
> A place does not need to incorporated to be a place=town, city, village.  
> That is not how it works anywhere in OSM - there are many unincorporated 
> places with these tags, worldwide.  The tagging in Ottawa is a good guide, 
> with e.g. Richmond a village, but e.g. Centretown and Stittsville 
> place=suburbs, based on distinctness.

I don't believe I said it did, I do believe I said that a city is always 
incorporated, a town or village, "maybe."

And, as I also said, "local tagging as a consensus or guide" is something to 
consider.  This isn't alway black-and-white, nor easy.  As we "do our best," 
things eventually emerge as correct, though it usually takes some time and 
effort to get there.  (Consensus does).

SteveA

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

Re: [Talk-ca] Place Tagging

[Danny McDonald]

A place does not need to incorporated to be a place=town, city, village.
That is not how it works anywhere in OSM - there are many unincorporated
places with these tags, worldwide.  The tagging in Ottawa is a good guide,
with e.g. Richmond a village, but e.g. Centretown and Stittsville
place=suburbs, based on distinctness.
DannyMcD

On Thu, Jan 24, 2019, 1:53 PM OSM Volunteer stevea <
stevea...@softworkers.com wrote:

> On Jan 24, 2019, at 7:50 AM, Danny McDonald  wrote:
> > My understanding of place tagging is that place=city, place=town, and
> place=village are for distinct urban settlements, whether or not they are
> separate municipalities.
>
> Correct, in that these tags can be placed upon a node, way or relation (if
> a boundary relation, a node with role admin_centre is correct).  Sometimes
> a way (often a closed polygon) is not precisely known, or is, but license
> restrictions prevent those data from entering OSM.  In that case, a simple
> node tagged place=* with appropriate value is used, as documented at
> https://wiki.osm.org/wiki/Key:place .  Though, be aware and careful
> regarding "incorporated" areas; see below.
>
> > Place=suburb is for large parts of urban settlements (such as North York
> in Toronto, or Kanata in Ottawa).
>
> While I am not a political scientist, I did participate in the development
> of consensus in the United_States in
> https://wiki.osm.org/wiki/United_States_admin_level , a complex task
> indeed (and I'll say we only have it "largely correct," certainly not
> "exactly correct").  While Canada has similarities, it certainly is unique
> in admin_level, appropriately documented at
> https://wiki.osm.org/wiki/Canada_admin_level .  Yet an important concept
> found in many countries, Canada included, is that of "incorporation" —
> whether an urban settlement is a "body corporate."  Cities always are,
> suburbs and towns, depending on differing context for each of these, may or
> may not be.
>
> > Whether to classify a place as a place=city/town/village or place=suburb
> depends on the facts on the ground (I.e. whether a place is part of a
> larger urban settlement), and not primarily on municipal/administrative
> boundaries.
>
> I can't speak for all of Canada, but I can speak to what OSM documents in
> our place=* wiki:  that urban and rural populated places are distinguished
> by two separate tables there, so it is useful to understand how OSM
> characterizes these as slightly different (with specific tags in each
> table).  This is regardless of how any particular country might use the
> same names.  For example, place=suburb has a very specific semantic as it
> is used in OSM, contrasted with how "real world" "suburb" might mean an
> incorporated (smaller) city near a (larger) city, OR it might mean a
> district/area/small region INSIDE of an incorporated city (how OSM means
> it).  We must be careful to tag in OSM with how OSM means things, mapping
> our "real world" semantics onto OSM semantics.
>
> > Municipal boundaries might be somewhat relevant in determining if a
> place is distinct (e.g. Vaughan is a city, not a suburb), but they are a
> relatively minor factor.
>
> I don't know what this means exactly.  Municipal boundaries ARE EXACTLY
> relevant in determining if a place is distinct:  they literally distinguish
> it.  In "real world speak" Vaughn might be called a suburb, but unless it
> meets OSM's place=suburb definition, it shouldn't be tagged that way in
> OSM.  This isn't minor, it is "either correct or incorrect."
>
> > The main way that municipal names are mapped is through admin boundary
> relations, not place nodes (although many municipalities have the same name
> as their largest urban settlement, of course).
>
> Yes, this is true, although for many smaller human settlements (and some
> larger ones), place nodes simply "will have to" suffice.
>
> > The way to distinguish between a place=city, place=town, and
> place=village is population size, with nearby places shading things a bit
> (so a smaller population size qualifies for a place=town in Northern
> Ontario).  Very roughly, a city has population >50k, a town has population
> 5k-50k, and a village is <5k.
>
> OSM's place wiki notes that a village is more like "200 to town size" so
> that 5k edge is fuzzy.  The USA admin_level wiki documents some "rules of
> thumb" here, but, yes, these can be rough, and are sometimes "stretched"
> (or "shaded" as you say) a bit so that wide-zoom views of very rural areas
> (e.g. northern Ontario) show settlements a bit more clearly.
>
> > There seems to be a persistent mis-understanding of this scheme, where
> various editors (mainly @OntarioEditor and various other accounts
> controlled by them) believe that place=city/town/village are for
> municipalities, whether or not the municipality has one major urban
> settlement with the same name as the municipality or not.  They are also
> tagging all unincorporated places in a municipality as place=suburb,
> 

Re: [Talk-ca] Ongoing Place Reclassification needs to be stopped, possibly reverted

[Martin Chalifoux via Talk-ca]

I know in Quebec the place=village tag has been adopted to tag the 
municipalities other than town, cities and suburb, regardless of population. I 
think, but don’t know for sure, the main reason for this is actually the 
rendering engine(s). The place=village tag get a nice rendering that allow to 
identify the municipalities visually on the map. When the municipality, label  
and other tags are used (instead of village), they render very small and are 
not useful. There is a need for municipality names to stand out at a descent 
zoom level on the map, regardless of population. That is important for 
navigating the territory. So I guess my bit of advise is to not only look at 
the pure logic of OSM tagging to understand what is being done in the field and 
also how rendering is done and maybe you will get a better understanding of why 
people do that they do. Now there are tons of rendering engines beside 
openstreetmap.org  but that one is a good place to 
start with.

I also agree that a more consistent scheme needs to be worked out. It is hard 
to maintain the current one. In Quebec there has been mergers over the years 
and often multiple villages are now in one municipality and both informations 
need to show in OSM somehow.

Martin

> On Jan 24, 2019, at 13:24, Danny McDonald  wrote:
> 
> Repeating this, since it seemed to get bumped by all the building import 
> talk.  Now with a catchier subject line. 
> DannyMcD
> 
> My understanding of place tagging is that place=city, place=town, and 
> place=village are for distinct urban settlements, whether or not they are 
> separate municipalities.  Place=suburb is for large parts of urban 
> settlements (such as North York in Toronto, or Kanata in Ottawa).  Whether to 
> classify a place as a place=city/town/village or place=suburb depends on the 
> facts on the ground (I.e. whether a place is part of a larger urban 
> settlement), and not primarily on municipal/administrative boundaries.   
> Municipal boundaries might be somewhat relevant in determining if a place is 
> distinct (e.g. Vaughan is a city, not a suburb), but they are a relatively 
> minor factor.  The main way that municipal names are mapped is through admin 
> boundary relations, not place nodes (although many municipalities have the 
> same name as their largest urban settlement, of course).  The way to 
> distinguish between a place=city, place=town, and place=village is population 
> size, with nearby places shading things a bit (so a smaller population size 
> qualifies for a place=town in Northern Ontario).  Very roughly, a city has 
> population >50k, a town has population 5k-50k, and a village is <5k.
> 
> There seems to be a persistent mis-understanding of this scheme, where 
> various editors (mainly @OntarioEditor and various other accounts controlled 
> by them) believe that place=city/town/village are for municipalities, whether 
> or not the municipality has one major urban settlement with the same name as 
> the municipality or not.  They are also tagging all unincorporated places in 
> a municipality as place=suburb, regardless of size or distinctness.  Finally, 
> they are using the official title of the municipality to determine if it is a 
> city/town/village, whether than using population size.  This can lead to very 
> misleading results, as Ontario municipalities called towns range in size from 
> 313 to 195k, and Ontario municipalities called cities range in size from 8k 
> to 2.7M.  Quebec “ville”s (which means town or city) range in size from 5 to 
> 1.6M.
> 
> To give an example, consider Minto 
> (https://www.openstreetmap.org/relation/7486154 
> ) in southwest Ontario.  It 
> has two distinct population centres, Harriston and Palmerston.  In the OSM 
> scheme, both are tagged as place=town, and the municipality name Minto (since 
> it does not correspond to a distinct urban settlement) does not get a place 
> tag (except perhaps as a place=municipality at the municipal offices).  The 
> mistaken scheme is to tag Harriston and Palmerston as place=suburb, and 
> create a place=town node for Minto.
> 
> Any thoughts?
> 
> 
> ___
> 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] Place Tagging

[OSM Volunteer stevea]

On Jan 24, 2019, at 7:50 AM, Danny McDonald  wrote:
> My understanding of place tagging is that place=city, place=town, and 
> place=village are for distinct urban settlements, whether or not they are 
> separate municipalities.

Correct, in that these tags can be placed upon a node, way or relation (if a 
boundary relation, a node with role admin_centre is correct).  Sometimes a way 
(often a closed polygon) is not precisely known, or is, but license 
restrictions prevent those data from entering OSM.  In that case, a simple node 
tagged place=* with appropriate value is used, as documented at 
https://wiki.osm.org/wiki/Key:place .  Though, be aware and careful regarding 
"incorporated" areas; see below.

> Place=suburb is for large parts of urban settlements (such as North York in 
> Toronto, or Kanata in Ottawa).

While I am not a political scientist, I did participate in the development of 
consensus in the United_States in 
https://wiki.osm.org/wiki/United_States_admin_level , a complex task indeed 
(and I'll say we only have it "largely correct," certainly not "exactly 
correct").  While Canada has similarities, it certainly is unique in 
admin_level, appropriately documented at 
https://wiki.osm.org/wiki/Canada_admin_level .  Yet an important concept found 
in many countries, Canada included, is that of "incorporation" — whether an 
urban settlement is a "body corporate."  Cities always are, suburbs and towns, 
depending on differing context for each of these, may or may not be.

> Whether to classify a place as a place=city/town/village or place=suburb 
> depends on the facts on the ground (I.e. whether a place is part of a larger 
> urban settlement), and not primarily on municipal/administrative boundaries.

I can't speak for all of Canada, but I can speak to what OSM documents in our 
place=* wiki:  that urban and rural populated places are distinguished by two 
separate tables there, so it is useful to understand how OSM characterizes 
these as slightly different (with specific tags in each table).  This is 
regardless of how any particular country might use the same names.  For 
example, place=suburb has a very specific semantic as it is used in OSM, 
contrasted with how "real world" "suburb" might mean an incorporated (smaller) 
city near a (larger) city, OR it might mean a district/area/small region INSIDE 
of an incorporated city (how OSM means it).  We must be careful to tag in OSM 
with how OSM means things, mapping our "real world" semantics onto OSM 
semantics.

> Municipal boundaries might be somewhat relevant in determining if a place is 
> distinct (e.g. Vaughan is a city, not a suburb), but they are a relatively 
> minor factor.

I don't know what this means exactly.  Municipal boundaries ARE EXACTLY 
relevant in determining if a place is distinct:  they literally distinguish it. 
 In "real world speak" Vaughn might be called a suburb, but unless it meets 
OSM's place=suburb definition, it shouldn't be tagged that way in OSM.  This 
isn't minor, it is "either correct or incorrect."

> The main way that municipal names are mapped is through admin boundary 
> relations, not place nodes (although many municipalities have the same name 
> as their largest urban settlement, of course).

Yes, this is true, although for many smaller human settlements (and some larger 
ones), place nodes simply "will have to" suffice.

> The way to distinguish between a place=city, place=town, and place=village is 
> population size, with nearby places shading things a bit (so a smaller 
> population size qualifies for a place=town in Northern Ontario).  Very 
> roughly, a city has population >50k, a town has population 5k-50k, and a 
> village is <5k.

OSM's place wiki notes that a village is more like "200 to town size" so that 
5k edge is fuzzy.  The USA admin_level wiki documents some "rules of thumb" 
here, but, yes, these can be rough, and are sometimes "stretched" (or "shaded" 
as you say) a bit so that wide-zoom views of very rural areas (e.g. northern 
Ontario) show settlements a bit more clearly.

> There seems to be a persistent mis-understanding of this scheme, where 
> various editors (mainly @OntarioEditor and various other accounts controlled 
> by them) believe that place=city/town/village are for municipalities, whether 
> or not the municipality has one major urban settlement with the same name as 
> the municipality or not.  They are also tagging all unincorporated places in 
> a municipality as place=suburb, regardless of size or distinctness.  Finally, 
> they are using the official title of the municipality to determine if it is a 
> city/town/village, whether than using population size.  This can lead to very 
> misleading results, as Ontario municipalities called towns range in size from 
> 313 to 195k, and Ontario municipalities called cities range in size from 8k 
> to 2.7M.  Quebec “ville”s (which means town or city) range in size from 5 to 
> 1.6M.
> 
> To give an example, 

[Talk-ca] Ongoing Place Reclassification needs to be stopped, possibly reverted

[Danny McDonald]

Repeating this, since it seemed to get bumped by all the building import
talk.  Now with a catchier subject line.
DannyMcD

My understanding of place tagging is that place=city, place=town, and
place=village are for distinct urban settlements, whether or not they are
separate municipalities.  Place=suburb is for large parts of urban
settlements (such as North York in Toronto, or Kanata in Ottawa).  Whether
to classify a place as a place=city/town/village or place=suburb depends on
the facts on the ground (I.e. whether a place is part of a larger urban
settlement), and not primarily on municipal/administrative boundaries.
Municipal boundaries might be somewhat relevant in determining if a place
is distinct (e.g. Vaughan is a city, not a suburb), but they are a
relatively minor factor.  The main way that municipal names are mapped is
through admin boundary relations, not place nodes (although many
municipalities have the same name as their largest urban settlement, of
course).  The way to distinguish between a place=city, place=town, and
place=village is population size, with nearby places shading things a bit
(so a smaller population size qualifies for a place=town in Northern
Ontario).  Very roughly, a city has population >50k, a town has population
5k-50k, and a village is <5k.

There seems to be a persistent mis-understanding of this scheme, where
various editors (mainly @OntarioEditor and various other accounts
controlled by them) believe that place=city/town/village are for
municipalities, whether or not the municipality has one major urban
settlement with the same name as the municipality or not.  They are also
tagging all unincorporated places in a municipality as place=suburb,
regardless of size or distinctness.  Finally, they are using the official
title of the municipality to determine if it is a city/town/village,
whether than using population size.  This can lead to very misleading
results, as Ontario municipalities called towns range in size from 313 to
195k, and Ontario municipalities called cities range in size from 8k to
2.7M.  Quebec “ville”s (which means town or city) range in size from 5 to
1.6M.

To give an example, consider Minto (
https://www.openstreetmap.org/relation/7486154) in southwest Ontario.  It
has two distinct population centres, Harriston and Palmerston.  In the OSM
scheme, both are tagged as place=town, and the municipality name Minto
(since it does not correspond to a distinct urban settlement) does not get
a place tag (except perhaps as a place=municipality at the municipal
offices).  The mistaken scheme is to tag Harriston and Palmerston as
place=suburb, and create a place=town node for Minto.

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

Re: [Talk-ca] Canada Building imports wiki page

[Nate Wessel]

John,

I mentioned several times in the various email threads that I planned to 
make substantial changes to the wiki. If you think something I added is 
a value judgment, I encourage you to point it out, on the wiki itself 
ideally. I think I've mostly been restructuring the page (without 
deleting much) and adding content on data quality.


Best,

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

On 1/24/19 12:56 PM, OSM Volunteer stevea wrote:

On Jan 24, 2019, at 9:29 AM, john whelan  wrote:

You seem to have made rather large changes without consultation including 
changing the title of the project.  You have also added some value judgments.  
A number of people were involved in the original and it might have been nice to 
consult with them before making such drastic changes.  The word consensus 
springs to mind.

I make no comment on whether the changes are good or bad merely extensive 
without apparent consultation.

John, much consensus is achieved in wiki Discussion(s), simply click the 
Discussion tab, https://wiki.osm.org/wiki/Talk:Canada_Building_Import and 
notice that there are four threads/sections under Discussion there already.

If some "number of people" were involved in the original, they are perfectly 
welcome to join there.

I'm not saying "don't do this in talk-ca" I am saying "there are often 
more-appropriate (vs. less-appropriate) places to have a discussion to achieve consensus."  
Sometimes, it makes sense to have an off-list email conversation in a one-on-one or one-on-many 
fashion.  Thanks.

SteveA
California


On Jan 24, 2019, at 9:40 AM, OSM Volunteer stevea  
wrote:

On Jan 24, 2019, at 9:29 AM, john whelan  wrote:

You seem to have made rather large changes without consultation including 
changing the title of the project.  You have also added some value judgments.  
A number of people were involved in the original and it might have been nice to 
consult with them before making such drastic changes.  The word consensus 
springs to mind.

I make no comment on whether the changes are good or bad merely extensive 
without apparent consultation.

John, much consensus is achieved in wiki Discussion(s), simply click the 
Discussion tab, https://wiki.osm.org/wiki/Talk:Canada_Building_Import and 
notice that there are four threads/sections under Discussion there already.

If some "number of people" were involved in the original, they are perfectly 
welcome to join there.

I'm not saying "don't do this in talk-ca" I am saying "there are often 
more-appropriate (vs. less-appropriate) places to have a discussion to achieve consensus."  
Sometimes, it makes sense to have an off-list email conversation in a one-on-one or one-on-many 
fashion.  Thanks.

SteveA
California


___
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] Canada Building Import wiki page

[Nate Wessel]

Hi all,

I just want to let everyone know that I moved the OSM wiki page for the 
Canadian building import, much discussed of late on this list. My hope 
is that this name is easier to search and more clearly conveys what we 
are trying to do.


All history for the page is preserved and a redirect has been created. 
I'll check for any remaining broken links in just a second.


Original:
https://wiki.openstreetmap.org/w/index.php?title=WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan=no

Current:
https://wiki.openstreetmap.org/wiki/Canada_Building_Import

If you haven't checked the wiki in the last week, there have been a lot 
of changes, and any contributions from users with experience working 
with this data would be greatly appreciated. The goal is to have crystal 
clear documentation of the import plan which follows the guidelines laid 
out on the import guidelines page.


Best,

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

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

Re: [Talk-ca] Canada Building imports wiki page

[OSM Volunteer stevea]

On Jan 24, 2019, at 9:29 AM, john whelan  wrote:
> You seem to have made rather large changes without consultation including 
> changing the title of the project.  You have also added some value judgments. 
>  A number of people were involved in the original and it might have been nice 
> to consult with them before making such drastic changes.  The word consensus 
> springs to mind.
> 
> I make no comment on whether the changes are good or bad merely extensive 
> without apparent consultation. 

John, much consensus is achieved in wiki Discussion(s), simply click the 
Discussion tab, https://wiki.osm.org/wiki/Talk:Canada_Building_Import and 
notice that there are four threads/sections under Discussion there already.

If some "number of people" were involved in the original, they are perfectly 
welcome to join there.

I'm not saying "don't do this in talk-ca" I am saying "there are often 
more-appropriate (vs. less-appropriate) places to have a discussion to achieve 
consensus."  Sometimes, it makes sense to have an off-list email conversation 
in a one-on-one or one-on-many fashion.  Thanks.

SteveA
California

> On Jan 24, 2019, at 9:40 AM, OSM Volunteer stevea  
> wrote:
> 
> On Jan 24, 2019, at 9:29 AM, john whelan  wrote:
>> You seem to have made rather large changes without consultation including 
>> changing the title of the project.  You have also added some value 
>> judgments.  A number of people were involved in the original and it might 
>> have been nice to consult with them before making such drastic changes.  The 
>> word consensus springs to mind.
>> 
>> I make no comment on whether the changes are good or bad merely extensive 
>> without apparent consultation. 
> 
> John, much consensus is achieved in wiki Discussion(s), simply click the 
> Discussion tab, https://wiki.osm.org/wiki/Talk:Canada_Building_Import and 
> notice that there are four threads/sections under Discussion there already.
> 
> If some "number of people" were involved in the original, they are perfectly 
> welcome to join there.
> 
> I'm not saying "don't do this in talk-ca" I am saying "there are often 
> more-appropriate (vs. less-appropriate) places to have a discussion to 
> achieve consensus."  Sometimes, it makes sense to have an off-list email 
> conversation in a one-on-one or one-on-many fashion.  Thanks.
> 
> SteveA
> California


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

Re: [Talk-ca] Canada Building imports wiki page

[john whelan]

You seem to have made rather large changes without consultation including
changing the title of the project.  You have also added some value
judgments.  A number of people were involved in the original and it might
have been nice to consult with them before making such drastic changes.
The word consensus springs to mind.

I make no comment on whether the changes are good or bad merely extensive
without apparent consultation.

Cheerio John

On Thu, 24 Jan 2019 at 12:13, Nate Wessel  wrote:

> Hi all,
>
> Just a heads up that I've moved the page documenting the plan to import
> buildings across Canada, much discussed on this list of late. The idea is
> that the new title is more concise, easily searchable, and clearly explains
> what we're trying to do. All page history has been preserved and a redirect
> has been put in place.
>
> Previous:
> https://wiki.openstreetmap.org/w/index.php?title=WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan=no
>
> Current: https://wiki.openstreetmap.org/wiki/Canada_Building_Import
>
> If you haven't looked at the wiki lately, there have been some big
> changes, and more on the way. The goal is to get this page to clearly and
> explicitly document the import plan, not only to guide editors, but also to
> set people's minds at ease, answer any questions, and as a useful
> description of where all this data came from once the import is over.
>
> Please feel encouraged to edit the page to get it in line with the
> documentation required for import as described on the import guidelines
> page.
>
> https://wiki.openstreetmap.org/wiki/Import/Guidelines
>
> Best,
> --
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> ___
> 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] Fwd: Ongoing Canadian building import needs to be stopped, possibly reverted

[john whelan]

We're over the 40 k limit again so I trimmed it.

I get the impression that just adding the building outline or even an
approximation of a building outline adds value to the map.

My own house has a cantilever on the back so the upper story extends beyond
the basement outline.  It also has a porch on the front which has a
basement.

My personal view is a rectangle that represents the basic shape is more
than acceptable however I can appreciate that some might like to have a
greater level of detail.

I personally feel this can be added later.

Cheerio John

On Thu, Jan 24, 2019, 12:03 PM 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.
>>>
>>>
>>>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Canada Building imports wiki page

[Nate Wessel]

Hi all,

Just a heads up that I've moved the page documenting the plan to import 
buildings across Canada, much discussed on this list of late. The idea 
is that the new title is more concise, easily searchable, and clearly 
explains what we're trying to do. All page history has been preserved 
and a redirect has been put in place.


Previous: 
https://wiki.openstreetmap.org/w/index.php?title=WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan=no 



Current: https://wiki.openstreetmap.org/wiki/Canada_Building_Import

If you haven't looked at the wiki lately, there have been some big 
changes, and more on the way. The goal is to get this page to clearly 
and explicitly document the import plan, not only to guide editors, but 
also to set people's minds at ease, answer any questions, and as a 
useful description of where all this data came from once the import is over.


Please feel encouraged to edit the page to get it in line with the 
documentation required for import as described on the import guidelines 
page.


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

Best,

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

___
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

[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 

[Talk-ca] Place Tagging

[Danny McDonald]

My understanding of place tagging is that place=city, place=town, and
place=village are for distinct urban settlements, whether or not they are
separate municipalities.  Place=suburb is for large parts of urban
settlements (such as North York in Toronto, or Kanata in Ottawa).  Whether
to classify a place as a place=city/town/village or place=suburb depends on
the facts on the ground (I.e. whether a place is part of a larger urban
settlement), and not primarily on municipal/administrative boundaries.
  Municipal boundaries might be somewhat relevant in determining if a place
is distinct (e.g. Vaughan is a city, not a suburb), but they are a
relatively minor factor.  The main way that municipal names are mapped is
through admin boundary relations, not place nodes (although many
municipalities have the same name as their largest urban settlement, of
course).  The way to distinguish between a place=city, place=town, and
place=village is population size, with nearby places shading things a bit
(so a smaller population size qualifies for a place=town in Northern
Ontario).  Very roughly, a city has population >50k, a town has population
5k-50k, and a village is <5k.

There seems to be a persistent mis-understanding of this scheme, where
various editors (mainly @OntarioEditor and various other accounts
controlled by them) believe that place=city/town/village are for
municipalities, whether or not the municipality has one major urban
settlement with the same name as the municipality or not.  They are also
tagging all unincorporated places in a municipality as place=suburb,
regardless of size or distinctness.  Finally, they are using the official
title of the municipality to determine if it is a city/town/village,
whether than using population size.  This can lead to very misleading
results, as Ontario municipalities called towns range in size from 313 to
195k, and Ontario municipalities called cities range in size from 8k to
2.7M.  Quebec “ville”s (which means town or city) range in size from 5 to
1.6M.

To give an example, consider Minto (
https://www.openstreetmap.org/relation/7486154) in southwest Ontario.  It
has two distinct population centres, Harriston and Palmerston.  In the OSM
scheme, both are tagged as place=town, and the municipality name Minto
(since it does not correspond to a distinct urban settlement) does not get
a place tag (except perhaps as a place=municipality at the municipal
offices).  The mistaken scheme is to tag Harriston and Palmerston as
place=suburb, and create a place=town node for Minto.

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