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

Joseph Eisenberg joseph.eisenberg at gmail.com
Sun Jan 10 22:13:44 UTC 2021


Sometimes the Census bureau has to pick whether or not to include a certain
edge city or suburb in a metropolitan area, and their choices are not
always perfect. If local mappers believe the census divisions are wrong,
they are free to ignore them. But in most cases this will make it difficult
to pick a population=* value.

For the example of Mt. Vernon WA - this "Metropolitan area" is a single
county with only 129,000 people, and it is part of the larger Seattle CSA.
As mentioned, for small cities and large towns, including suburbs of larger
cities, it is fine to just use the municipal population.

Since the Urban area population is only 67,767 vs 36,006 for the city
limits, this is less than a single power of 2 difference, which should be
about as good as we can expect for these numbers.

I am hoping that we can fix problems with big cities like Miami or Atlanta,
where the population in the city limits is only 7% of the urban area
population. I was only planning to make changes for metros with 1 million
people to start, then work down to 500k or so, if it looks necessary.

> Re: ", let's add a tag to the cities to indicate which urban area they
belong to and let software add the population totals"

That tag was "is_in=" and most editors consider it to be deprecated. I
still have used that tag in Indonesia when there are no verifiable
administrative boundaries (because the government has not drawn them
yet...).

I actually like the idea of adding "is_in" tags to represent that a
place=suburb node "is in" the nearby place=city, but this would not help
us, since the population figures belong to the municipalities. You would
have to do some rather complex calculations to get from nodes back to the
admin areas and then add up the population numbers, and that still wouldn't
get you the same figures as available from the census for the urbanized
area, because municipalities like Anchorage can include large rural areas.
Even the city limits of Tokyo include a rural villages in the mountains (
https://en.wikipedia.org/wiki/Hinohara), while excluding most of the metro
area. So to get something like the urban-only area, you would have to
calculate from the census block level using density thresholds, like how
the census determined the urbanized areas:

And right now database users are looking at these population=* tags on the
nodes, so we should try to make them as reasonable as possible. I believe
the census urbanized areas are the best option we have,

On Sun, Jan 10, 2021 at 1:44 PM Clifford Snow <clifford at snowandsnow.us>
wrote:

> I've lived in a number of urban areas, Minneapolis, Chicago, Kansas City,
> Seattle plus a few more. I must admit living in Minneapolis I never
> consider St. Paul part of our urban area. The Twin Cities was a much better
> description. People I know in Vancouver Washington might say they are
> across the river from Portland, but they have an independent streak that
> would never allow them to say they are in the Portland area. I now live in
> Mount Vernon, WA. I was surprised to find out that the Mount Vernon urban
> area included next door Burlington as well as Clear Lake and Sedro-Woolley.
> Maybe I might consider Burlington and Mount Vernon to be one area, but
> never Clear Lake or Sedro-Woolley.
>
> We are a geospatial database. If we must, let's add a tag to the cities to
> indicate which urban area they belong to and let software add the
> population totals. Realize of course that approach will miss the
> unincorporated area. Let's not add an urban population to one city when
> that population covers a number of other cities. If we take this approach
> we could be smart and instead of calling it the Minneapolis urban area, it
> could be the Twin Cities urban area.
>
> Using the example of my current location, Mount Vernon, I'm not sure that
> I'd welcome someone adding the population of those three cities to a Mount
> Vernon urban area. Maybe we should just leave urban areas to the Census
> Bureau.
>
> Best,
> Clifford
>
> On Sun, Jan 10, 2021 at 12:53 PM Joseph Eisenberg <
> joseph.eisenberg at gmail.com> wrote:
>
>>
>> *Re: "place POIs are commonly tagged with wikidata=* and website=* tags
>> that should probably be different from the ones on the administrative
>> boundary."*
>>
>> Thank you for mentioning this. I also think that wikidata= and website=
>> tags should go on the appropriate municipality boundary feature, if they
>> represent the municipality rather than the place.
>>
>> Wikipedia articles often mention both the municipality and the metro area
>> - for example the wikipedia article for Portland mentions the area of the
>> city and the area of the urbanized area, and has the population for the
>> municipality and the population of the metro area. This seems to be
>> standard practice for large us cities, so it might be ok to link the
>> wikipedia article with the place=city node.
>>
>> I don't use wikidata much, but it seems like there should be separate
>> wikidata objects for 1) the downtown/historic center 2) the municipality 3)
>> the urbanized area 4) the metropolitan area 5) the combined statistical
>> area (if present), no?
>>
>> *Re: "Los Angeles-Long Beach-Santa Ana. Long Beach and Santa Ana would
>> still be affected by population fragmentation within Orange County. For San
>> Francisco-Oakland, San Francisco would get the overall urbanized area
>> population, while Oakland..."*
>>
>> In my experience (I have lived in Berkeley next to Oakland, Long Beach,
>> Irvine next to Santa Aana, and San Diego, and frequently visit Castro
>> Valley and Pleasanton and San Mateo in the San Francisco area), people who
>> live in Orange County do not consider themselves to live in Santa Ana
>> unless they live in the city limits. "Orange County" is the term they use
>> to describe the place where they live when talking to people from outside
>> of the local region, though they might say "Los Angeles" to someone across
>> the country or from another country.
>>
>> People who live right next to Long Beach might say they live in Long
>> Beach if they are in Signal Hill, Hawaiian Gardens or one of the small
>> unincorporated areas, but the name does not extend much beyond that.
>>
>> Similarly, no one in Berkeley thinks they live in the "Oakland area", but
>> just the (San Francisco) "Bay Area" or perhaps "In San Francisco" to
>> non-Californians. Therefore I think it is fine if Oakland, San Jose, Long
>> Beach, Santa Ana and other "edge cities" get just the population within
>> their municipal boundaries.
>>
>> Practically, when trying to properly geocode searches, or design
>> low-zoom-level maps, edge cities and suburbs are going to get merged or
>> crowded out by the central city.
>>
>> -- Joseph Eisenberg
>>
>> PS: (San Jose is an annoying special case since it is considered a
>> separate metro area by the Census, but we will have to live with that)
>>
>> On Sun, Jan 10, 2021 at 10:12 AM Minh Nguyen <
>> minh at nguyen.cincinnati.oh.us> wrote:
>>
>>> Vào lúc 14:47 2021-01-09, Joseph Eisenberg đã viết:
>>> > 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.
>>> >
>>> https://censusreporter.org/profiles/40000US71317-portland-or-wa-urbanized-area/
>>> > <
>>> https://censusreporter.org/profiles/40000US71317-portland-or-wa-urbanized-area/
>>> >
>>> >
>>> > Minneapolis, MN would have population=2885614 instead of only 429k
>>> >
>>> https://censusreporter.org/profiles/40000US57628-minneapolis-st-paul-mn-wi-urbanized-area/
>>> > <
>>> https://censusreporter.org/profiles/40000US57628-minneapolis-st-paul-mn-wi-urbanized-area/>
>>>
>>> >
>>> >
>>> > But Anchorage would decrease slightly from 288k to 249K
>>> >
>>> https://censusreporter.org/profiles/40000US02305-anchorage-ak-urbanized-area/
>>> > <
>>> https://censusreporter.org/profiles/40000US02305-anchorage-ak-urbanized-area/
>>> >
>>> >
>>> > 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.
>>>
>>> If I understand correctly, the Census definition of an urbanized area
>>> would fall somewhere between the central city and the whole
>>> metropolitan/micropolitan statistical area in terms of population. I'm
>>> sympathetic to this idea because the place node should ideally represent
>>> a human settlement, not entirely bound by administrative divisions.
>>> (This is why there can be a place=town inside a census-designated place.)
>>>
>>> On the other hand, the waters are already muddy because place POIs are
>>> commonly tagged with wikidata=* and website=* tags that should probably
>>> be different from the ones on the administrative boundary. (Wikidata can
>>> but seldom distinguishes between administrative and territorial
>>> entities. A city might have one official website for government
>>> operations and another that functions as a business/tourism portal.)
>>> Also, it isn't uncommon for the place POI to have been moved to the
>>> location of City Hall, whereas it should ideally be at the origin of the
>>> street grid or town square or something to that effect. But these are
>>> all pedantic considerations compared to population, which affects the
>>> place visually even at low zoom levels.
>>>
>>> I'm not sure we can totally eliminate awkward situations by migrating
>>> these central cities to urban area populations. For example, the
>>> second-largest urban area is Los Angeles-Long Beach-Santa Ana. Long
>>> Beach and Santa Ana would still be affected by population fragmentation
>>> within Orange County. For San Francisco-Oakland, San Francisco would get
>>> the overall urbanized area population, while Oakland would remain
>>> untouched despite plenty of population in surrounding suburbs,
>>> incorporated and unincorporated.
>>>
>>> > 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.
>>>
>>> The U.S. isn't alone in having administrative boundaries that divide a
>>> population center. Are there other examples outside the U.S. where
>>> statistical areas are used as a basis for place POI populations instead
>>> of administrative areas? If we depart from the more obvious definition
>>> we've been using, then global consistency would be important to maintain
>>> intuitiveness at lower zoom levels.
>>>
>>> Even if we don't end up changing the population=* tags to the urbanized
>>> area population, that figure seems useful enough to put in a suffixed
>>> tag like population:urban=* (along with population:urban:date=*).
>>>
>>> --
>>> minh at nguyen.cincinnati.oh.us
>>>
>>>
>>> _______________________________________________
>>> Talk-us mailing list
>>> Talk-us at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-us
>>>
>> _______________________________________________
>> Talk-us mailing list
>> Talk-us at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>
>
> --
> @osm_washington
> www.snowandsnow.us
> OpenStreetMap: Maps with a human touch
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20210110/7aa7a50a/attachment-0001.htm>


More information about the Talk-us mailing list