For some reason, I was of the understanding that place=* worked in one of two ways:
place=* tagged on the type=boundary relation to indicate that the centroid should be usedtype=boundary relation contains a node member with role label and that node has place=*, to indicate a specific spot to render the labelI suspect I will only be upset if I try to verify this understanding against actual mapping and actual opinions.
As I’ve been explained… somewhere… Nominatim output should not be regarded as an address, but simply as a “chain of containers” of place and administrative boundaries that contain the object.
For Nominatim, the tag seems to be needed on the boundary relation if it’s present on the node for the same municipality. Otherwise Nominatim wont be able to match the two. (municipalities’ admin_level isn’t as standardized as the one of place=country ).
If a boundary relation and a place point represent essentially the same feature, add the place point to the boundary relation and give it the role label. (Don’t think too hard about the name of that role.) Nominatim will have no problem associating the two elements. Otherwise, tagging both elements with matching place=* creates a conundrum for renderers.
I think any English-language documentation about place=municipality should avoid drawing a strong connection between the name of the value and what English-speaking countries call municipalities in the real world. The tag has apparently been useful for certain things that other countries call municipalities (even in English), but many English-speaking countries follow a different model that treats municipality as a catch-all word for types of places that we already have better-supported tags for. We don’t want mappers mistakenly retagging place=city/town/village as place=municipality after they come across this documentation.
In the long term, we should decouple place=* from political geography so it can focus on human geography, that is, describing centers of population and commerce. border_type=* combined with admin_level=* is so much more effective at describing political geography. Look no further than the functionally synonymous place=state and place=province tags. If for consistency we try to set place=* to the generic or legal title of more local administrative areas, we’d have to juggle hundreds of extra place=* values, all with inconsistent meanings, causing more headaches for renderers and geocoders. place=municipality is probably the first value I’d discourage, given the potential for confusion.
I changed to this, but it broke the previous fix. Maybe if I give the problem a thumbsdown it will go away (or people wont notice it’s there).
Can you elaborate on the problem you’re trying to fix, to make sure we’re talking about the same issue? If you use Nominatim through the website, it can sometimes be difficult to tell what’s coming from Nominatim itself versus the website’s Nominatim integration code.
There is this municipality with ca. 200 inhabitants and it appears in Nominatim here in nearby municipality Uetendorf.
Previously it was here and at other places in nearby Thun, another municipality with 45000 inhabitants.
You corrected the role to label only an hour ago. It was admin_centre for a couple days before that. Maybe you’re seeing the result of your previous change?
Such label changes do not trigger an update of all addresses the node was included in. Things will only fix itself with time.
Should municipality really be a place tag? The more I read here and in the wiki is that it does not really belong in the human-centred place hierarchy.
However, sometimes we are where we are (landuse vs landcover 
).
The second most used place value is defined as ”A named place that has no population” in Taginfo. What human-centred hierarchy? 
Or if we ignore that part of how place is used, what makes municipality less human-centred than county?
county, state, country, these are all commonly defined by administrative boundaries, the idea to represent them with a node is due to the limitations we had historically (for the renderer), I don’t think we would introduce these today. Municipalities are of this kind. locality is for the other toponyms, that are neither those aforementioned nor settlements or their parts for which we have established tags (squares, …), but are human centred, usually not referring to natural features (but also used some time as a catch all, because it is rendered, and people mostly refrain from introducing new tags, so if a natural feature is not in the list of established natural feature types, people will often tag it as locality).
In general, OSM Carto automatically labels the centroid of an administrative boundary in purple italic text. It’s intended to serve a similar purpose as the municipality labels in the National Land Survey maps. Renderers are capable of positioning such labels automatically, as on any kind of area feature, so I tend to think we shouldn’t make mappers do it manually just for boundary relations.
The label appears at different zoom levels depending on the admin_level=* and total area. Sometimes the label fails to appear because the relation covers too small an area or some other label collides it out. It has nothing to do with whether the relation has a place point as a member or whether that point’s name matches. In principle, omitting the point representation gives the renderer more flexibility to position the label elsewhere in case of any collision.
Slightly off-topic: could you please stop adding sub-areas to boundary relations, including adding made up admin level 9 boundaries.
I appreciate this general notion, and I absolutely do not want to spend my time with tags that don’t serve a practical purpose.
That said, the area of Pöytyä (same link as before) is quite large and empty (at least by southern Finland standards). Carto is rendering names of bogs, farms, hamlets… but not the actual name of the place.
I can accept that rural Finland wasn’t at the top of Carto devs minds when they wrote their rendering rules. I can accept that Carto specifically will never change. But what do I do next? It does seem that adding a node as a label with place=municipality isn’t the solution I was hoping for either, as that’s apparently been tried too (link to Akaa, a more urban municipality with more well-known towns).
I’m not dead-set on any particular key or value, but municipality is the term official Finnish sources consistently use in English for the basic administrative areas of Finland. Division into administrative areas (vector) | National Land Survey of Finland This link conveniently demonstrates the term, the admin area hierarchy and shows a map with Akaa in the centre
This basic admin level is ground-verifiable (large signs on the sides of major roads crossing the border) and the names are widely used and meaningful, i.e. this is not just some bureaucratic nonsense.
A ”working” rendering solution seems to have been used in Vehmaa where the mapper has intentionally misnamed the obscure town of Vinkkilä as Vehmaa (name of the municipality). Vinkkilä is mapped as a suburb (while in reality it’s the name of the entire town). Obviously this isn’t ideal either, and similar attempts haven’t been accepted with towns other mappers actually care about.
I couldn’t find that either. If this is defined by placenames.mss, it seems to need some factors that make it important enough. For the sample I mentioned above (and that isn’t rendered either), it doesn’t matter, as the two parts of the name each refer to a place with its name being displayed. It would actually be suboptimal if it was displayed too. Maybe @Minh_Nguyen refers to some other map rendering.
(note to moderators: I think this question is still on topic as it discusses place=municipality, given the title of the thread and initial post).
The kind of label I’m referring to complements the place labels in the stylesheet:
For example, we’ve modeled Robertson County, Kentucky, as a boundary relation whose label member is a place=county point. OSM Carto ignores the latter in favor of generating a label about a mile to the west. (Multiple centroid algorithms exist; they sometimes result in very different placement, depending on the shape.)
If I’m not mistaken, these labels were originally introduced to ensure labels on U.S. counties and similar administrative areas. Once this functionality became commonplace, we stopped paying any attention to place=county points, hence the lack of tags on Robertson County’s point. We should probably delete them all at this point. Hardly anything uses them, and nothing should.
OSM Carto has similar rules for other admin_level=* values, though ironically not for level 7, which would correspond to most of the places in the U.S. that would be eligible for place=municipality.
I think I have seen that working quite well for admin_level=6, but most municipalities have admin_level=8.
Many municipalities I encounter just have an admin_center and that usually has place=town or place=village, both values that are hardcoded in the project.mml which may explain why they are rendered.
Interestingly Nominatim has:
which might explain why both appear there.
(note to moderators tasked with removing off-topic posts: I think this question is still on topic as it discusses place=municipality, given the title of the thread and initial post).
Stepping away from specific rendering behavior for a moment, a number of national communities have historically assigned admin_level=8 to their most local administrative unit (other than things like quarters and arrondissements that represent parts of a settlement). This comes from an idea that we would somehow harmonize analogous administrative levels across countries (unfortunately confusing political geography with human geography).
Based on this tendency, some renderers and geocoders have come to assume that admin_level=8 is a kind of synonym for place=city/town/village for certain purposes. Such a boundary wouldn’t be a good candidate for the boundary centroid label I described earlier, since it would typically be redundant to the populated place label based on the place=city/town/village point.
These assumptions break in any region that completely partitions territory into a most-local level of “space-filling” administrative areas, especially if the administrative areas don’t correspond one-to-one with urbanized areas. These are the very areas that seem to warrant place=municipality. On top of that, some countries don’t have formal boundaries for the settlement within the most-local administrative area.
This is all very complicated if you just want labels that reflect how the territory is broken down locally in your region, without worrying about the very different administrative model in other parts of the world.
The U.S. is a microcosm of all these issues. admin_level=8 covers New England and Puerto Rico completely, regardless of urbanization, but it’s sparse everywhere else. Additionally, we have more than 50 different parallel systems of administrative area types, often using the same words with conflicting meanings. As a result, there’s a lot of unhappiness with the historical global tagging schemes. A soft consensus has emerged about how we’d reform these tagging schemes if we had our druthers (a big if):
label for “is a” relationships and admin_centre for “is the capital city of” relationships.admin_level=* values across legal systems. Only skip odd values to maintain a distinction between major and minor administrative levels within a single legal system.place=* points for populated places and parts thereof. Deprecate place=municipality/county/state.place=* points based on some measure of importance rather than anything official. (This is hard.)place=* on boundary relations. Instead, rely on admin_level=* to nest a boundary inside another boundary and border_type=* to indicate the legal title or generic word.Some of these things are uncontroversial and largely implemented already, while other things would be a radical departure from historical global practice, possibly conflicting with user expectations in some parts of the world that are organized differently. Both the boundary and place tagging schemes would be more elegant because they’d be trying to accomplish less: boundary tags only for political geography, harmonized only within a single legal system; place tags only for human geography, with an attempt at global consistency. But some data consumers would be unhappy about losing the ability to compare two completely unrelated administrative areas.
In the meantime, place=municipality is really an oddball. It only exists because some countries were almost able to conflate political and human geography in their national tagging practices, except for one niggling detail. It doesn’t fit into any globally harmonized place model.