You are right. From a more abstract point of view, this subject is not about a way of mapping that is adapted to the specifics of a country or that only applies to municipalities. It is about the technical question if an additional node is needed for an administrative territorial entity, if it is already represented by a boundary.
As a parallel, in the very beginning of my life as an OSM mapper, I was told: Do not add a name tag to the area of a settlement if there is already a named place node and vice versa.
There was no note in the German wiki that the information only applies to Germany. I also do not get the point why mapping of a municipality should follow different principles in Germany and Austria at all. From a mapping point of view, I do not see a difference in municipalities in both countries.
Since you’re familiar with Wikidata’s ontology, I’d put it this way: ideally, we’d only use a place=* node to represent a human settlement (Q486972), whether or not it happens to correspond to an administrative territorial entity (Q56061). As you’re probably aware, more often than not, Wikidata conflates the two concepts into a single item. Sometimes this is merely a bug caused by Wikipedia’s editorial policies; however, in the real world, a settlement is often conflated with an administrative territorial entity on purpose. Whenever this is the case, the place=* node represents both and its name should indeed match the boundary relation’s name.
The prevalence of non-settlement place=* points is partly due to the limited capabilities of early renderers and the dearth of boundary data in the project’s early days. If we were to delete all the place=country nodes in OSM overnight, it would become an urgent compatibility issue with some major renderers, but I think it would be a good goal to work towards eventually. Regardless of language, the wiki needs to accurately describe the current situation even as it points to future possibilities.
By the way, another project I contribute to, OpenHistoricalMap, tracks changes to boundaries over time, maintaining a separate boundary relation for each change to its membership or geometry. The distinction between settlements and administrative territorial entities is of particular interest, since we map many places that predate fixed boundaries. Due to this extra complexity, we prefer to limit the label role to settlements. We’re actively deletingplace=county and other centroid points, now that the official vector tile generator computes them automatically from boundary relations.
(Also, it goes without saying that OHM disfavors the subarea role, despite its popularity in OSM. Imagine having to create a new United States any time a city anywhere in the country decides to annex another house, or another Austria any time a boundary stream changes course.)
From my perspective, there are two reasons for conflation in Wikidata. The root cause is that different logical entities related to a certain topic are conflated in Wikipedia articles and therefore, they were imported into Wikidata in this way. The second cause is that, supported by the root cause, many people seemingly do not understand that Wikidata is not intended to have conflation like Wikipedia.
I recently had a long discussion with another user who claimed that I was completely wrong separating the central town as well as the urban municipality from an independent city of Germany (which is on the same administrative level as a district) into three different items. Giving examples of other conflated independent cities, he insisted that putting everything into one item is the desired state.
From my perspective, conflation of a settlement and administrative territorial entities, it is located in, is mostly driven by the reuse of the same name for two or more entities having different administrative levels or even different boundaries (the boundaries of the main settlement are typically smaller than those of the municipality and there are also further named settlements). In case that the higher level entities use a different name, almost anybody get the point that they are different.
are you sure the place-node (of a city, town, village, …) “represents both”? From my understanding, place=<settlement type> should represent a settlement, but not fields, forests and such other natural areas that aren’t built up. Administrative entities are covering the whole land, for settlements this often means their administrative boundaries include a significant share of natural areas, but from the meaning of “settlement” I would not expect these areas to be generally included in the settlement (I would also not state the opposite, that they are never included, I could see some situations where the locals see some of the areas as parts of the settlement).
Here I agree, it would be nice if we could come to the same conclusion for OSM: discourage/deprecate the concept of explicitly stating subareas.
All I’m saying is that it depends. Depending on the region, the real-world meaning of a named “city”, “town”, etc. can be a purely administrative construct, a purely demographic construct, or some combination of the two. An administrative city can be a boundary alone, and a demographic city can be a place=* point alone, but when the two concepts have merged in reality, then it gets murkier and depends on local expectations.
For example, about half of the territory of New Orleans is sparsely inhabited swampland (not counting the water area). No administrative boundary corresponds to the settlement, either in OSM or in real life. The overall boundary exists because of the settlement. For all intents and purposes, the place node centered closer to the central business district represents both the core settlement and any outlying areas, both officially and for all anyone cares. No one distinguishes between the two in practice. Even if we were to map centroid points comprehensively, we would not map one for New Orleans, because the existing place node is a more meaningful label.
However, the important context here is that New Orleans is a type of administrative entity that generally does not completely subdivide its parent boundary. Normally, any substantial settlement in Louisiana, such as nearby Slidell, has its own administrative entity that has a boundary shaped vaguely like the settlement. The fact that New Orleans extends into the wilderness is a peculiar exception that recently led the local community on a hundred-message-long journey through 19th-century laws and present-day traffic signs. Thus the distinction between New Orleans as a settlement and New Orleans as an administrative territorial entity is more obscure than it would be in another state where local boundaries normally do not conform to settlements.[1] Another consequence is that place=municipality is completely unused in Louisiana, because nothing officially exists that would require it.
In other words, it isn’t enough that the settlement and administrative entity share the same name: in order for the label role to be appropriate, the two would at least need to be considered two representations of the same thing administratively. Even so, if Wikidata happens to split the two into separate items for its own reasons, then this would theoretically force the boundary relation and its label member to have different wikidata=* tags.
You can tell from the Englisch Wiki-page of place=municipality that the German page is far from a mere translation. With regards to more complex mapping features such as places, highways and boundaries, many mapping practices are highly country-specific. (That is a feature, not a bug.) As others said before, the line between general and country-specific guidance is often not drawn clearly. And yes, the Wiki is not always clean in the sense that country-specific regulations occassionally clash with general guidelines on the English page (which they shouldn’t).
As I said before, place=municipality for nodes has been discussed quite intensively in various German forum threads. So, any attempt to de-facto deprecate this feature, must be discussed with the German community. (This does not mean that I am personally strictly against it.) In general, the quality and acceptance of the Wiki suffers from edits of this kind, as they support the already widespread approach “No need to follow the Wiki, since people can change it at any time.”
Region-specific mapping practices for e.g., Germany, Austria, Switzerland or even on the level of states are not always documented. Certainly, this is also due to the much larger and more active osm-community in Germany. If needed, any general mapping guideline on a German Wiki-page can of course be restricted to Germany with details how the situation in other German-speaking regions is different.
Note that there are 745 place=municipality-nodes in Germany, but only 5 (!) in Austria.