Place on nodes and relation

[pnorman]

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:

1. Only include points for nodes (osm-carto and osm2pgsql-themepark)
2. Only include points for polygons from polygon geometry (I don't know anyone who does this)
3. Only include points for polygons using admin_center where available
4. Include place points for nodes and points from polygon geometries (current spirit implementation of shortbread)
5. Include points for nodes and points from admin_center where available
6. 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

[1ec5]

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.

[pnorman]

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.

[1ec5]

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?

7. Include label where 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

[pnorman]

7. Include label where available; otherwise generate a point feature at the centroid.

We wouldn't dictate that its the centroid - implementations can use any label placement algorithm they want, which could include a node in the relation. The problem is what happens to place nodes? Some of them are members of relations, some aren't.

Is this a more fleshed out way of stating what you're proposing?

8. Include points for type=boundary place=* relations and place=* nodes that are not a member of a relation with role label?

[1ec5]

We wouldn't dictate that its the centroid - implementations can use any label placement algorithm they want, which could include a node in the relation.

Sure, if the renderer needs to synthesize a point feature, the location would be implementation-dependent. On the other hand, if there is already a label node, then it would just use that, because after all the location may not be arbitrary. The centroid is only the most obvious placement of the synthesized point.

Include points for type=boundary place=* relations and place=* nodes that are not a member of a relation with role label?

Not quite. For better or worse, plenty of type=boundary place=* relations have place=* nodes with the role label. For example, the Fort Pierre node is a label member of the Fort Pierre boundary relation. In that case, no point feature would be synthesized based on the boundary relation.

Conversely, plenty of type=boundary place=* relations spatially contain place=* nodes that aren’t members of the relation. For example, the Presho place point is not a member of the Presho boundary relation. In my opinion, it’s OK to render this still-common tagging error less than optimally. In this case, the renderer would synthesize a point feature based on the relation even if it’s redundant (because it would have no way of knowing).

What I’m suggesting is merely to synthesize a point feature as a fallback for when no place label point is explicitly associated with the relation.

[pnorman]

Sure, if the renderer needs to synthesize a point feature, the location would be implementation-dependent. On the other hand, if there is already a label node, then it would just use that, because after all the location may not be arbitrary.

I don't think we should dictate a particular position for a label, including dictating that it lies on a member node. Not all implementations may be able to place based on node members of a relation.

The centroid is only the most obvious placement of the synthesized point.

Not quite. For better or worse, plenty of type=boundary place=* relations have place=* nodes with the role label. For example, the Fort Pierre node is a label member of the Fort Pierre boundary relation. In that case, no point feature would be synthesized based on the boundary relation.

That's a bit of a bad example because the relevant tags are identical on the node and relation and you won't be able to tell the difference between what you suggested and what I suggested.

What do you do if you have a type=boundary boundary=administrative place=city name=foo relation with a node member with place=city name=bar?

[1ec5]

I don't think we should dictate a particular position for a label, including dictating that it lies on a member node. Not all implementations may be able to place based on node members of a relation.

The inclusion of a point feature in Shortbread tiles wouldn’t necessarily dictate anything. It’s there as an option. Again, the location of a place=city label node carries meaning: the town square, the origin of the street grid, etc. It isn’t a purely mathematical cartographic generalization. A stylesheet can choose not to label this meaningful location, just as it can choose not to label any village at a particular zoom level.

On the other hand, if a stylesheet instead wants to label boundary edge labels, Shortbread should supply a linestring feature for that purpose. If it wants to place a single label based on the overall boundary geometry (at the centroid or somewhere outside of the city limits), disregarding any city’s label point, then Shortbread should supply a point feature explicitly for that purpose. But those point features would need to be a comprehensive alternative to whatever is in place_label. I suspect very, very few maps would use them.

More concretely, I’m not suggesting to combine boundary_labels and place_labels. boundary_labels is good for labeling “space-filling” administrative areas from political geography, whereas place_labels is good for labeling populated places from human geography. An unlabeled boundary relation’s synthesized point could appear in boundary_labels to avoid confusion.

What do you do if you have a type=boundary boundary=administrative place=city name=foo relation with a node member with place=city name=bar?

With the label role? Prefer the place point I suppose. This does happen 2,726 times across all place=* values, compared to the 49,135 occurrences of the names matching. Among human settlements, it happens 1,295 times compared to 34,736 matches. Of the 4% of mismatches, most are because the local community intentionally prefers to put an official legal name in the boundary’s name=*, reflecting political geography, but a less formal name in the place point’s name=*, reflecting human geography. The latter is how a typical user would interpret a point-placed label for a city.

In some cases, the mismatch is due to a typo or other mistake. We shouldn’t let rare tagging mistakes dictate the tile schema.

[pnorman]

On the other hand, if a stylesheet instead wants to label boundary edge labels

administrative boundary edges are out of scope here - nothing here impacts any layers other than place_labels. The only reason type=boundary boundary=administrative objects come up at all is they also often get additional tags to indicate they are a place as well as an administrative boundary

In some cases, the mismatch is due to a typo or other mistake. We shouldn’t let rare tagging mistakes dictate the tile schema

Yes, but the example you had picked to show your suggestion had identical results between what you suggested and what I did. This is a better example.

Your proposal would result in no label point for a place if it had a label member but there wasn't also a node with corresponding place tags. This feels like we're trying to discourage place on area-like objects. If we want to do that it would be much simpler to only ever use nodes.

[1ec5]

Your proposal would result in no label point for a place if it had a label member but there wasn't also a node with corresponding place tags. This feels like we're trying to discourage place on area-like objects. If we want to do that it would be much simpler to only ever use nodes.

I don’t follow. A label member always carries a place=* tag, so my suggestion would be to prioritize that member over anything in the relation. I’m not suggesting to discourage mappers from adding place=* to areas or relations – that’s a completely different discussion. But you asked what to do to avoid redundant labeling, particularly in the event of a conflict between the relation and its label member. The solution seems obvious to me: pick one.

[pnorman]

I don’t follow. A label member always carries a place=* tag, so my suggestion would be to prioritize that member over anything in the relation.

But why prioritize the node over the relation instead of the relation over the node? Yes, in the common case these are the same output in the vector tile, but we need to have defined behavior in the uncommon case. There are a number of untagged nodes as members of boundary relations, e.g. https://www.openstreetmap.org/node/10598372256