[OSM-talk] [Talk-us] Correct source for population=* tags on US metropolitan cities

Joseph Eisenberg joseph.eisenberg at gmail.com
Sat Jan 9 23:24:33 UTC 2021

Re: > the urban area population includes many other cities around
Minneapolis (like St. Paul). What population would we put on St. Paul?
Re: > For the sake of clarity in the case of Portland, OR with a proposed
population of  2,072,553. What would Vancouver show?

For suburbs and small towns which are not the central city of a
metropolitan area, we can just use the latest census data for the area
which most closely matches. In most cases this will just be the area within
the city limits, since the US Census does not give figures for parts of
urbanized areas. So the population=* for Vancouver, Washington will just be
184,463 as of 2019 (https://en.wikipedia.org/wiki/Vancouver,_Washington) -
and the same number should be on the boundary=administrative +
admin_level=8 feature which represents the city limits.

Similarly, the population of the place=city node for St. Paul, MN would be
308,096, and the same value should be on the admin boundary, since people
who live in Woodbury MN and other surrounding suburbs would be unlikely to
say that they live "in St. Paul" - though they probably tell New Yorkers
and Californians that they live "In Minneapolis".

Basically I believe that the place=city node is representing not just the
"downtown" or "city centre", but the center of a whole urbanized area which
has cultural, economic and practical connections. So the population=*
should include not just that one municipality, but all the surrounding
municipalities which are part of the continuous urbanized area.

There is no new problem with double-counting of the same population in 2
different nodes, because we already put population=* numbers on
place=neighbourhood or place=suburb nodes which are within the city limits.
Anyone who is trying to look at the whole population of an area already
should be looking at our administrative boundaries, which represent
official divisions, or more likely depending on a reliable source like
figures directly from the census (or wikidata?)

-- Joseph Eisenberg

On Sat, Jan 9, 2021 at 3:00 PM Ian Dees <ian.dees at gmail.com> wrote:
> We should put the population of the city represented by the node on the
node, not the urbanized area that surrounds the node.
> Your example of Minneapolis is a good one: the urban area population
includes many other cities around Minneapolis (like St. Paul). What
population would we put on St. Paul?
> On Sat, Jan 9, 2021 at 4:50 PM Joseph Eisenberg <
joseph.eisenberg at gmail.com> wrote:
>> Proposal:
>> Use the census data on Urbanized Areas to set the "population=" value
for "place=city" nodes, rather than using the whole metro population or
just the population of the central municipality.
>> Rationale:
>> The tag "population=*" is helpful as a way to distinguish small
place=city features (which might have less than 50,000 people in rural
States) from huge cities. Many database users depend on this information
for rendering decisions at low zoom levels (large scales) and as a general
estimation of the "importance" of a place.
>> However, currently most population figures are taken from the population
in the municipal boundaries, since this is often what is on local signs and
easily available from the census. While this is fine for towns and small
cities which are contained in one municipality, it often misses
unincorporated urban areas next to the city limits, and for large cities it
badly underestimates the population of the area which is considered part of
the "place".
>> For example, many people in West Hollywood or East Los Angeles would
consider that they live in the larger place "Los Angeles", even though they
live in a different municipality or an unincorporated area. Someone who
lives in Vancouver, Washington will often tell people they live "In
Portland" when talking to someone from outside of the region, since it
functions as a suburb of the Portland, Oregon metro area.
>> So I propose that we should use an estimate of the urban population for
the population=* tag when tagging metropolitan places. Usually this will
lead to a larger population number, except in rare cases like Anchorage.
>> In particular, I would like to use the US Census "urbanized area"
figures, since these are much more sensible than the numbers from
metropolitan areas based on county boundaries which can include distant
towns and rural areas.
>> This would mean that the place=city node for Portland, Oregon would have
population=2072553 (representing the whole urbanized area) rather than just
654000 from the city limits.
>> Minneapolis, MN would have population=2885614 instead of only 429k
>> But Anchorage would decrease slightly from 288k to 249K
>> Usually the difference would not change the relative rank of cities very
much, but it would be good to have the population figure map the
OpenStreetMap "place" concept, rather than the city limit boundaries.
>> Eventually this could improve maps of the USA and help them better match
those in other countries, where city limits tend to be much larger than in
the case of many US cities, which often have many separate municipalities
for suburbs.
>> Of course it will still be appropriate to add the precise population=*
to the boundary=administrative feature which represents the municipality,
and database users could choose to emphasize those features instead.
>> -- Joseph Eisenberg
>> PS: the 2010 population figures of US Urbanized Areas are on wikipedia,
and this year we will get updated 2020 figures, so it would be a good time
to make this change. The biggest difference will be for Miami, Florida,
where the central municipality is only 7% of the population of the whole
urbanized area:
>> _______________________________________________
>> Talk-us mailing list
>> Talk-us at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20210109/1ac07ba4/attachment-0001.htm>

More information about the talk mailing list