I’m thinking about expanding the administrative boundaries in my area, and from what I’ve found in my research, the most effective approach involves creating a relation and specifying roles like ‘outer,’ ‘admin_center,’ and ‘label’ as detailed on the wiki page:
However, I’m a bit unsure about where to add name tags. Should I exclusively add them on the label node, only on the relation, or on both the label and relation?
Looking at examples from around the world, it seems that name tags are often found on both entities but aren’t consistently synchronized, which could lead to inconsistencies.
Where should name tags be added on administrative boundaries ?
only on label node
only on relation
on both relation + label node with identical name
on relation with prefixed/suffixed name (e.g. Doi Saket District) + label node without suffix (e.g. Doi Saket)
It depends on the nature of the administrative boundary you’re mapping.
Some kinds of administrative areas completely partition a larger administrative area. For example, many countries are completely partitioned by provinces, leaving no territory that lies outside of any province. Typically in this case, each subdivision is normally represented as an area (a boundary relation in OSM’s data model). To the extent that the subdivision can be represented as a point, that point would be located at either the area’s centroid (the label member) or perhaps the seat of government (the admin_centre member).
But technically the centroid doesn’t need to be mapped, because a data consumer can automatically determine the centroid. The are multiple algorithms for doing so with different results, and a particularly sophisticated renderer could even shift these automatically generated labels away from the centroid to avoid collisions. So the manually mapped place node with the label role exists only as a compatibility shim.
On the other hand, some administrative areas exist to surround a populated place (human settlement) and aren’t intended to completely partition a larger administrative area. This is normal in some countries like the United States but completely unheard of in other countries like China. In this case, the label member is also a place node and also represents the administrative area as a point geometry. However, this node has semantic meaning that a data consumer can’t generate automatically. For example, if a city started on a riverbank and grew away from the river, its label node would typically be close to where the city began, rather than at the centroid. So this node is not merely a compatibility shim.
I say all this to point out that there isn’t a single right answer as to whether the boundary relation or the place node is the more “important” or “correct” representation of a place. Another complicating factor is that sometimes the boundary relation is named after the government, which has a different, more formal name than the populated place. Locally, there may be an expectation that a label at the city center has the name of the populated place, whereas edge labels along the boundary have the name of the city authority as tagged on the boundary relation.
Given all this, a data consumer probably needs to rely on mappers to synchronize the names across both features when appropriate. Depending on its needs, a data consumer can also use the relation membership or matching wikidata tags to determine fallback values for the various localized names on either feature.
I understand that the label node might not always be necessary for large administrative areas. But if it’s there, do we really need name tags on the place node too?
All the large administrative nodes/relation I’m looking at worldwide seems to have duplicated name tags, which are often out of sync. Can’t the renderers just fetch the name tags from the relation and place them directly on the label node?
Could it be that the reason for the some of the “* Province” suffix on place nodes is because they’re used for geocoding and routing purposes, whereas the area is solely for rendering, hence no prefix/suffix is needed?