On Jan 24, 2019, at 7:50 AM, Danny McDonald <mparra...@gmail.com> 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, 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.

In addition to me posting this, I'd simply say "read existing wiki 
documentation," as well as "keep talking about it" (whether in private emails, 
the Discussion tab on appropriate wiki, sometimes known as "a Talk page") or 
here in talk-ca.  It is best to stick to established OSM tenets as documented, 
though some flexibility for "how we wish to or must do things here" 
more-or-less can't be helped, so aim for the nice balance between those.

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

Reply via email to