Is there are a way to define labels for (multipolygon) lakes?
relation/332617 in the default rendering has its name somewhere west of Thonon, hard to notice and barely within the lake.
I made an attempt in version 357 with this node, but it looked more like a mini-lake placed within a larger lake. Either the feature type for the label node should be different or the role “label” isn’t recognized within the relation.
The label role is only for boundary relations, not multipolygon relations. This may sound like an omission, but actually it’s a misnomer: the label role is for the focal point of a populated place by convention, not a geometric center of a shape by calculation.
OSM Carto has chosen a particular algorithm for placing a label within a (multi)polygon feature. The behavior on Lake Geneva is unfortunate, but a manual override is out of scope for the OSM database. After all, that would disadvantage other data consumers that are capable of more optimal point placements, such as Shortbread, or those that generate lake centerlines, such as OpenMapTiles as seen in OSM Americana.
I had noticed that it’s better in OSM Americana, but apparently it couldn’t place it either by merely computing the optimal center.
Such labels would only be tagging for the rendering if it would use tags contrary to the definition. place=municipality should also be placed in the centre and not based on some demographics.
There’s more than one correct way to label the “center” or “centroid” of a shape. Since each of these methods can be computed automatically without additional context, mappers don’t need to position it automatically. By analogy, you don’t need to manually map a hint for the label of a building. The renderer should be able to choose a good spot to put the building’s label without your intervention.
Moreover, the centroid is only a rule of thumb. Maps traditionally would take liberties with label placement, shifting them to avoid collisions. A primitive digital mapping system would rely on the mapper to manually place these hints, but OSM has too many disparate users and use cases for this approach to work. After all, your carefully placed centroid will be wrong when the user switches to another language that uses a longer name for the lake, or rotates and tilts the map, or enables an optional ferry or bathymetric layer.
The only good reason to use the (poorly named) label role is when the label’s position depends on context beyond the boundary’s geometry, such as population distribution or the layout of the urban transportation network. We relax the “one element” rule because there are essentially two features, one administrative and the other cultural. That isn’t the case with natural features such as lakes.
I notice that both the Shortbread and MapTiler styles seem to do a better job with Lake Geneva - interestingly they take two different approaches. Is there something about vector tiles that makes this easier, or is it coincidence that the two vector styles stand out from the rest here?
Largely coincidence I think. Picking one computed point is always going to work better in some cases rather than others (I don’t see why Carto’s ST_PointOnSurface should be “[less] capable of more optimal point placements”).
The more sophisticated “place along a line” approach is likely to deliver nicer results. This requires pre-computation which fits quite naturally with pre-baked vector tiles - Carto tends to compute everything on-the-fly. But OpenTopoMap is/was a raster tile style that pioneered pre-computed label positions.
Yes they can be checked in Postpass that ST_Centroid( may be seen as slightly better here
SELECT
osm_type, osm_id, tags,
ST_Collect
(
ARRAY
[
geom,
ST_MakeLine
(
ARRAY
[
ST_Centroid(geom),
ST_PointOnSurface(geom),
(MIC).center
]::geometry[]),
ST_Buffer((MIC).center,(MIC).radius)
]
)
FROM
(
SELECT
osm_type, osm_id, tags, geom,
ST_MaximumInscribedCircle(geom) AS MIC
FROM
postpass_polygon
WHERE
osm_id = 332617
)