shortbread-tiles
Place on nodes and relation
A long-standing issue with OSM cartography has been handling place=* on both nodes and relations. The issue has generated hundreds of comments on osm-carto including the attempt at fixing it which didn't develop any kind of agreement.
Holds label points for populated places. Features are sorted by population in descending order.
The place_labels documentation is silent on what exactly is included, except that everything is a point. Obviously implementations can differ in some aspects, but do we want to narrow down what's allowed? I can see the following options:
- Only include points for nodes (osm-carto and osm2pgsql-themepark)
- Only include points for polygons from polygon geometry (I don't know anyone who does this)
- Only include points for polygons using admin_center where available
- Include place points for nodes and points from polygon geometries (current spirit implementation of shortbread)
- Include points for nodes and points from admin_center where available
- Include points for nodes that aren't an admin_center member of a relation, and points from polygons, using admin_center where available
1 and 4 are reasonably common ways to implement places
admin_centre is for an administrative center, that is, a capital city or other seat of government. It should be irrelevant to the issue of duplicated places. label is the role representing the place point associated with the administrative area. If Shortbread is using admin_centre for this purpose, that will yield a lot of unexpected behavior.
In OpenHistoricalMap/issues#701, OpenHistoricalMap’s vector tile generator takes a different approach than the ones listed here: it exposes place=* nodes as point features and also synthesizes a centroid point feature for each administrative boundary that lacks an explicit label member. In other words, the label member overrides centroid calculation. Unfortunately, this won’t yield perfect results in OSM until we clean up misuse of admin_centre.
About a decade ago @gravitystorm said
It's entirely the wrong concept to put a "label" node in the database, and I'll not be using it for rendering.
The geodatabase is for geodata. Rendering decisions are made by the renderer. If the renderer isn't sufficiently advanced to place a label to your desire, then lets improve the renderer.
I still agree with this. If we extend the earlier list to include both admin_center and label and rule out use of admin_center, we're left with options 1, 2, or 4.
A decade ago, there was considerably more confusion about what label and admin_centre mean. As things stand today, label is just a misnomer for the logical/commercial/cultural center of a populated place associated with the boundary. This is a meaningful real-world location that can’t be inferred from the boundary’s geometry. It is not a renderer hint overriding a calculated centroid for aesthetic purposes, as described in the quote above.
Meanwhile, admin_centre is for, say, a province’s provincial capital city. It does not represent the same place as the boundary. At most this information could boost the capital city’s prominence, but we’re already getting feedback about how using capital=* like that leads to counterintuitive results.
This is all written into our documentation, but we’re still struggling with residual mistagging. Shortbread would likely worsen the situation by choosing any option that uses admin_centre for anything or requires place=* on a boundary relation. Would an option 7 be feasible?
- Include
labelwhere available; otherwise generate a point feature at the centroid.
Related discussions:
- https://community.openstreetmap.org/t/use-of-admin-level-on-capital-s/130318
- https://community.openstreetmap.org/t/how-is-place-municipality-used-correctly-and-are-there-country-state-specific-rules-not-to-use-it-at-all/123842
- https://community.openstreetmap.org/t/label-and-admin-centre-nodes-for-boundaries/122944
- https://community.openstreetmap.org/t/some-places-have-both-a-node-and-a-way/114220