Render settled areas at mid-level zooms about openstreetmap-americana

[1ec5]

which are ignored by standard carto due to being a American issue.

I think there’s a misunderstanding about why CDPs don’t render. The community intentionally chose a tag that would not render in any mainstream, general-purpose renderer. Statistical boundaries are by no means unique to the U.S., and CDP boundaries aren’t the only kind of statistical boundary, but openstreetmap-carto doesn’t render any of them.

CDPs were originally imported from TIGER 2005 as boundary=administrative admin_level=8, which did render. The 2010 Census came with a new definition of CDP and therefore consolidated, split, renamed, and reshaped a significant number of CDPs, so we had very little confidence in the TIGER-imported CDPs. Many mappers preferred that the CDPs be deleted outright, since they were already on the far end of the verifiability spectrum, but boundary=census was a concession to mappers who were committed to updating the CDPs in their area or using the boundaries with this caveat emptor in geocoding or querying.

If CDPs are considered within scope for this project, despite the mix of 2000 and 2010 definitions, then it will be challenging to display them in a way that isn’t misleading. Even if a CDP is named after the human settlement, a label on the centroid may be somewhere other than where residents would consider the center of the settlement to be. This is especially true of 2000 CDPs, which were not required to match real-world names or popular notions of a community’s boundaries. Even setting aside that issue, the effect would be similar to labeling a river city at its centroid instead of at its downtown by the riverbank.

Styling a CDP as a linear boundary can also be problematic. Most TIGER-imported boundaries have inexplicable jogs and exaggerations – even USGS topographical maps can be more reliable, if outdated. But whereas it’s possible for us to clean up municipal boundaries to match more accurate sources or surveys, we basically have to live with the TIGER CDP boundaries as they are. Apart from the unique situations in Alaska and Hawaii, these considerations are pretty uniform across the country (including in Maryland).

If the goal is to ensure representation of unincorporated communities, a more reliable strategy would be to render place POIs, which explicitly represent population centers. If some sense of the populated area’s extent is desired, then a faint gray fill can avoid setting too high an expectation of precision or accuracy, but there are better sources for these geometries, such as the Census Bureau’s urbanized areas/urban clusters or, globally, Natural Earth urban polygons derived from satellite imagery.

[Korgi2]

We would have to sort out state-by-state where:

* CDPs should be used in place of administrative boundaries, because municipal boundaries don't exist (such as Maryland and Alaska) and/or aren't duplicated

* CDPs should be used in addition to administrative boundaries

Also, we need to determine when/whether CDPs should be rendered as boundaries or as labels, and whether this is state-specific as well.

Yeah there is a bit of work involved but I don't think it would be too difficult, just a bit of slogging through lists. I'd be willing to help as well where I could.

[ZeLonewolf]

We would have to sort out state-by-state where:

• CDPs should be used in place of administrative boundaries, because municipal boundaries don't exist (such as Maryland and Alaska) and/or aren't duplicated
• CDPs should be used in addition to administrative boundaries

Also, we need to determine when/whether CDPs should be rendered as boundaries or as labels, and whether this is state-specific as well.

[ZeLonewolf]

I'd like to summarize some of the recent Slack discussions:

• We probably do not need to use CDP name tags to render the names of places, because this labelling would be better accomplished using place=* nodes, potentially with population=* tagging to help deconflict overlapping labels.
• The boundaries of CDPs are "fuzzy" concepts and don't correspond to firm boundaries on the ground. Therefore, we would not want to render a prominent casing or stroke on a CDP.
• There is support for rendering CDPs as a fill-only, in order to indicate built-up areas. These would render only at mid-zoom levels where it's close enough that we want to see where settlements are, but not so close that we would actually directly show settlement features such as land use, minor roads, POIs, etc.

If we go the route described in the last bullet, CDPs could serve as a proxy for generalized land use / land cover rendering. See openstreetmap-carto renderings of New Jersey or Rhode Island at zoom 10-12 for an example of this rendering. The benefit of the CDP approach is that it isn't reliant on comprehensive residential/commercial/industrial land use data for attractive rendering at mid-zooms, and thus we would have a way to avoid the type of problem that currently results in two green states plus a square in Pennsylvania on the land cover side.

openstreetmap-carto rendering at zoom 7:

The drawback of rendering CDPs to represent "settled areas" is that it basically only works in the United States. Thus, we would need to live with this concept only working domestically and/or identify an alternate scheme for foreign locations.

Another option is to use an external source, such as Natural Earth's settled areas layer to achieve settled area rendering, either in conjunction with CDPs, or instead of them.

At present, additional work is needed in the map to identify and replace any remaining pre-2020 CDP boundaries with the latest geometries from US government sources.

[ZeLonewolf]

This is an example of settled areas drawn on a printed American-style map. It appears that this AAA map uses a slight border to indicate (most likely) "city limits" and only includes the most prominent cities.

[1ec5]

If we go the route described in the last bullet, CDPs could serve as a proxy for generalized land use / land cover rendering. See openstreetmap-carto renderings of New Jersey or Rhode Island at zoom 10-12 for an example of this rendering. The benefit of the CDP approach is that it isn't reliant on comprehensive residential/commercial/industrial land use data for attractive rendering at mid-zooms, and thus we would have a way to avoid the type of problem that currently results in two green states plus a square in Pennsylvania on the land cover side.

If a generalized representation of built-up places is the goal, then consider the Census Bureau’s urban areas as a more reliable external source for them. Natural Earth urban polygons would be the global alternative. openstreetmap-carto used to use the latter as a populated place generalization at low zoom levels before migrating to OSM landuse/landcover areas (in gravitystorm/openstreetmap-carto#2969, I think).

[ZeLonewolf]

If a generalized representation of built-up places is the goal, then consider the Census Bureau’s urban areas as a more reliable external source for them.

Is there an easy way to look at this on a map so we can get a sense of what might be included or excluded in "urban areas"?

[jleedev]

It's unfortunately left out of TIGERweb, here's a screenshot:

(Colored based on area)

[ZeLonewolf]

That looks really good, and about what I'd expect. Perhaps at lower zooms it could be laid on top of an external source of land cover or topo or "something else" for an overall basemap at the lower zooms. (Hence the need for someone other than me to think through the design aesthetic)

[Korgi2]

If CDPs are considered within scope for this project, despite the mix of 2000 and 2010 definitions, then it will be challenging to display them in a way that isn’t misleading. Even if a CDP is named after the human settlement, a label on the centroid may be somewhere other than where residents would consider the center of the settlement to be. This is especially true of 2000 CDPs, which were not required to match real-world names or popular notions of a community’s boundaries. Even setting aside that issue, the effect would be similar to labeling a river city at its centroid instead of at its downtown by the riverbank.

I notice a big part of your worry in regards to this is the outdated boundaries from the older 2000 and 2010 census. However, hopefully, these shape issues should have been smoothed out with the release of the 2020 census shapefile a few month's ago. Also in my experience, I don't see many CDP shapes going wildly into unoccupied territory that would contribute to a label over areas people aren't living in. At least in Ohio, the CDP boundaries tend to hug the settlement of the CDP quite well and I haven't had any silly shape-covers-100-square-miles-of-farm type stuff. I do notice another one of your issues is the unnatural jutting, but isn't that a problem faced by normal settlement borders as well?

[1ec5]

I notice a big part of your worry in regards to this is the outdated boundaries from the older 2000 and 2010 census. However, hopefully, these shape issues should have been smoothed out with the release of the 2020 census shapefile a few month's ago.

Yeah, I was commenting specifically on rendering boundary=census relations from OSM. Current CDP data from TIGER would be, well, current, but if we’re using an external data source then it might as well be one designed for this purpose rather than demographic analysis.

Also in my experience, I don't see many CDP shapes going wildly into unoccupied territory that would contribute to a label over areas people aren't living in.

I was referring to a labeling a centroid even though the CDP is named after an unincorporated population center that would have a proper center elsewhere (for example, approximately where the post office is located). Typically there would be some population density over the centroid too, but to a viewer it would seem like an arbitrary placement.

Typically, I encounter centroid place labels on a four-color choropleth map that renders every boundary as a fill and the label as almost a watermark over the fill. Such maps wouldn’t give CDPs the same fill treatment as administrative boundaries, because the boundary between a purple fill and a yellow fill would imply precision just like a dotted line would.

I do notice another one of your issues is the unnatural jutting, but isn't that a problem faced by normal settlement borders as well?

The problem does occur just as much with administrative boundaries in TIGER, but at least we’re able to refine those boundaries in OSM, and in some places we’ve done quite a good job of it.

[Korgi2]

but if we’re using an external data source then it might as well be one designed for this purpose rather than demographic analysis.

I don't know of a source like this outside of census/TIGERs decadely updates. If they exist I really double they would be free to use within OSM.

You lost me at four-color choropleth as I stopped understanding what you were specifically referring to so I don't have much to say on that. I was speaking with Lonewolf however, and he floated the idea of having optional vector layers for users to customize their experience using americana. With that, it might be possible to have some of render system without it causing the clutter and lack-of-verifiability that you are concerned about with the shapefile. If it is a optional toggle, it can be rendered while still only being viewed by those who wish to use it for viewing/data purposes.

[1ec5]

I don't know of a source like this outside of census/TIGERs decadely updates. If they exist I really double they would be free to use within OSM.

I’m specifically suggesting the urban areas provided by the Census Bureau, which are linked in #18 (comment) and visualized in #18 (comment). They’re in the public domain just like TIGER. I think it’d be a great idea to pull in an external dataset like this as part of a postprocessing step, rather than requiring them to be mapped.

As someone who promoted the boundary=census compromise, I also have no problem with maintaining CDPs in OSM with that tag. Just because we map CDPs doesn’t mean they have to take precedence over other representations of unincorporated areas.

You lost me at four-color choropleth as I stopped understanding what you were specifically referring to so I don't have much to say on that.

Sorry, it’s hard to explain without a photo but I didn’t have a camera handy. Here’s a map that plasters a city with its name right across the middle, instead of labeling downtown (where the arrow points). It gets away with it because the city limits are clearly visually associated with the label:

Minor cities get labels wherever there’s sufficient whitespace, which would be the least populous parts of the city (in the case of Amberley Village, an large park owned by a neighboring city):

Here’s a four-color choropleth map that also places labels over whitespace:

I don’t mean to say that this non-downtown label placement is problematic, only that it requires giving the borders prominence, which would be more intuitive for incorporated areas than for CDPs.

[Korgi2]

I think it’d be a great idea to pull in an external dataset like this as part of a postprocessing step, rather than requiring them to be mapped.

Woulld you be ok with CDPs as a external dataset instead of trying to map them within OSM?

[1ec5]

I don’t see why the two have to be mutually exclusive. CDP boundaries in OSM can still be useful for reverse geocoding and data analysis even if that boundary data doesn’t get used by a renderer. As I’m sure you can tell by now, I think there are better alternatives than CDPs as a visual representation of unincorporated populated places.

[Korgi2]

Yeah but the thing is I just personally want to see them rendered...

[1ec5]

Personal preferences could be supported by a vector tile–based renderer to a certain extent, though every optional layer has a tradeoff in terms of style maintainability and bandwidth usage. If we were building a debugging style, similar to the osm.org data layer, then any boundary of any kind would be desirable for inclusion, but I was under the impression that this would be a more opinionated, user-friendly style.

Assuming CDPs are included in the default style or an optional layer, what treatment would you suggest? Rendering them as a faint fill would avoid setting unreasonable expectations about precision, but CDPs are generally only for unincorporated areas, so what would the style do for incorporated areas? If the idea is to give admin_level=8 boundaries the same kind of fill to represent populated areas, then Indianapolis would have a big square behind it that would include plenty of farmland, and the eastern half of New Orleans would be filled in like a populated area despite being a virtually uninhabited National Wildlife Refuge. Urban areas (that is, urbanized areas and urban clusters) don’t have this problem, because they go wherever the people are.

[Korgi2]

Assuming CDPs are included in the default style or an optional layer, what treatment would you suggest?

I don't really know honestly oof

[1ec5]

Print maps highlight settled areas in hues ranging from highlighter yellow (typical of maps that distinguish incorporated areas) to an orange or peach color:

[1ec5]

#617 fills in urbanized areas at zoom levels 4–6 based on Natural Earth data. We can keep this issue open to track an urbanized area fill at higher zoom levels as well.