Proposal:Population

The Feature Page for the approved proposal Key:population is located at Key:population

Key:population
Proposal status:	Approved (active)
Proposed by:	?
Tagging:	population=<number>
Statistics:
Vote start:	2006-12-28
Vote end:	2007-10-14

old content

A nice feature for the map rendering of place names (cities, towns, ...); Place names can be scaled according to population, giving a better hint how big a place is. It also makes rendering at low zoom levels better as small places can be left out.

The place-key can still be used, but it is not strictly necessary to use it - different countries are usually having slightly different definitions for place categories, anyway. The number of inhabitants is a physical property, thus universal.

As the population is only used for name scaling, it does not have to be very precise and can be approximated.

To make rendering easier, each value of the place tag (city, town, village, hamlet, ...) could be assigned a population number, making it possible to just look at the population tag to scale fonts accordingly while keeping backwards compatibility.

Opinion

Maybe I am too late? But I still vote against this. We need to have some distinction for town sizes but population is the wrong measure.

• How do you count the population for highly urbanized areas? Where does Paris stop and the banlieu start?
• How do you keep this up to date
• What about big cities that are intertwined (Tokyo area for example) based on population you'll still get too many names.
• Is population really a measure of importance? Den Haag is smaller than Rotterdam but it is the capital so it should appear first on maps

I would support another classification on importance like for example from important to less important

- major administratif centres (I'd call them capitals but that would bring us trouble in some areas where there is political dispute, ie Taiwan) - major cities (having a sphere of influence over the complete country, eg in France those would be Lyon and Marseille) - regional centres (having a regional sphere of influence) - cities (having a local sphere of influence) - towns --Bartv 08:22, 29 November 2006 (UTC)

This is a tough one, for two reasons - areas of cities (like Bartv mentions) - when zoomed in far enough, I would expect "London" to disappear, and all the smaller areas (Mayfair, South Kensington, Fulham) to show instead. You would have to make it clear if Urban dwellers can be double counted, i.e. once for Wimbledon Village, once for Wimbledon (town), once for London (city). Secondly, I would expect little villages to show up at low zoom levels if they are in the middle of nowhere - e.g. it doesn't matter how big Ullapool is; it's in the middle of nowhere, major transport interchange (road/ferry) so it's strategically important when looking at large areas. Gravitystorm 19:22, 29 November 2006 (UTC)

• I'll support this one on the "Why not?" principle. If someone is prepared to do the work, why not? It would be useful here in Australia and other countries with distinct seperated population centres to gauge what facilities a town might have.

What about distinguishing between towns that are part of an urban area (i.e. close together) and towns are that are far apart (e.g. a small town in the middle of nowhere)? Ideally, the latter should show up on a map, but the former should not to avoid clutter. How should this be done? Should we use "type=urban" or "type=rural"? Should the renderer sort all the towns in a tile or group of tiles in descending order by population, then only render x towns starting from the top of the list, and discard the rest? Andrewpmk 02:09, 24 August 2007 (BST)

Revisiting population

This vote appears to have been dormant for a few weeks. Let's have another look at population.

The previous arguments against the population tag include: inappropriate unit of measure, inclusion/exclusion of merged suburbs, updates, label rendering, duplication, proximity, other factors. It appears that some of these arguments have been addressed since they were originally posted.

• appropriate unit of measure - population is the only appropriate unit of measure for population. It may not be ideal for all circumstances when assigning relative importance of different areas but it is always the best measure of population. Population adds a data point for a physical value of an area. Just as place=city,town,hamlet adds a value for a political classification.

• duplication and inclusion/exclusion of suburbs and surrounding areas - the is_in tag offers a hierarchy for places. This could be used to mark the inclusion area for the listed population.

• updates - frequency of updates is a concern for all data in OSM, not just the population tag. If the population is noted from regional street signs we can only expect to be as upto date as those signs. Is one update every few years good enough? Loclal experts with an interest can keep the information relevant.

• label rendering at various scales - The current on-line renderers appear to do this now.

• proximity and other factors - proximity and other factors can make a place more significant than would be suggested by only its

population. This is not an argument against population but an argument for other tags to indicate importance for reasons other than population.

Revisitin Opinion

• I agree to the critisms with the Idea above, but also agree to the "why not" theory. I won't be using it because I think the data should really exsist within wikipedia, and the status of hamlet/village/town sorts out what renders where. But there is nothing wrong with the tag itself asuming that a tag is nessesery. The population is usually clear from the area that the place renders over, although densities may varie that still gives an ok idea. Ben. 03:14 3rd February 2007 (UTC)

Population requires a date

A number for a population is not as static as height, location, size etc. It may change every minute. Thus I feel that a population would have to be accompanied by a date. Maybe a place could even track changes in population.

I did not see a real propopsal for the syntax. Should it be just like this?

 k="population" v=number

I feel that you would need as well a date and a precision. A simple syntax could be

 k="population_date" v=date

... and there may be different choices for the date syntax (which should be a topic of its own) such as

This should rather be census=year for places that uses census to calculate population (such as Brazil, every 5 year) or estimate=year where estimated population is used. To give date of population more accurate than year is meaningless, and to use data where you only have decade or century accuracy is pointless as this indicates that the data is outdated. --Skippern 14:38, 30 November 2008 (UTC)

• 2007-12-31 - an exact date, the basic type
• 2007-12-31 14:00 - even higher precision by time
• 2007-12 - month only
• 2007 - year only
• 2007-W52 - giving weeks, although you'd have to define how weeks are counted
• 2007-Q4 - quartals
• 200* - decade
• 20** - century
• 2007-11..12 - periods
• ...

Precision could be given e.g. as

 k="population_precision" v="1"

... which would be a precise number, Other values could be

• 10 - by ten
• 100, h - by hundred
• 1000, k, 1k - thousand
• 10000, 10 000, 10k - ten thousand
• 100000, 100 000, 100k - hundred thousand
• 1000000, 1 000 000, 1000k, M, 1M - million

Yet another concept would be to create a new data primitive, such as data:

 <tag k="population" v="123">
 <tag k="date"       v="2007-12-31"
 <tag k="precision"  v="1">

 <tag k="population" v="100">
 <tag k="date"       v="1990"
 <tag k="precision"  v="10">

A place then would reference various data sources.

Votes

• I vote against this proposal.--Bartv 08:22, 29 November 2006 (UTC)
• I approve this proposal MikeCollinson 09:13, 3 December 2006 (UTC)

The two votes above are from a previous round of voting that appears indecicive. Please vote again, below.

Revisiting voting

• I approve this proposal Rw 13:55, 28 December 2006 (UTC)
• I approve this proposal Ben. 03:15, 3rd February 2007 (UTC)
• I disapprove this proposal, I think the updating and suburb problems realistically aren't going to be solved TomChance 13:12, 3 February 2007 (UTC)
• I approve this proposal, I consider it a reasonable approximation of the size a place. It is a quantative guage, not a statistically precise value. MikeCollinson 02:11, 18 February 2007 (UTC)
• I approve this proposal, although probably a rough indication, it can be used to have cities of certain sizes appear at specific zoomlevels. Spaetz 21 March 2007
• I approve this proposal, as a first-order approximation to allow renderers to display more relevant names on zoomed-out maps. Morwen 14:30, 26 March 2007 (BST)
• I approve this proposal, we should store this piece of data even if there is no way of displaying it. Ivansanchez 11:28, 25 July 2007 (BST)
• I approve this proposal, and we could add population:source to address the source of the counting or population:date to record the date of datas --EdoM (lets talk about it) 11:41, 31 August 2007 (BST)
• I approve this proposal. Andrewpmk 20:48, 1 September 2007 (BST)
• I approve this proposal. --Alban 14:13, 2 September 2007 (BST)
• I approve this proposal. (with is_in to remove double-counting problems) --SpeedEvil 18:43, 14 October 2007 (BST)

What had been approved ?

Please summarize the approved tag(s). Thanks.

• population=<a reasonable numeric approximation of population of a place> e.g. population=100000

Old discussion

Hi, If this population feature has been adopted; what is going to happen to it now? And also: Since I'm reading this because of the use on my home city, with city rights and approximately 33000 inhabitants yet indicated as a town of 10000: How is this supposed to function in practice? Mysha