How is place=municipality used correctly and are there country/state-specific rules not to use it at all?

General talk
, ,
21

The same applies for

But they all do also have boundary relations

22

From my perspective, it should certainly not be ignored. Wikipedia has a lot of conflation. Merging different entities in one article if they go by the same name or are sometimes thought to be the same. Wikidata is more like a true object database. Therefore, a village and a municipality should always be two distinct entities. In Wikipedia, the information on the village will sit somewhere in the article on the municipality making it sometimes hard to distinguish which piece information is on which entity.

2 Likes
23

For our example of Bezau have a look at GeoNames. They also distinguish:

24

I’ve updated this one here: Changeset: 161000930 | OpenStreetMap

But in the end I agree with:

The same information is already available at the boundary relation and the only purpose is the simple rendering of maps.
The Wikidata item for the municipality goes into the relation and the Wikidata item for the village goes to the place=village node.

I would argue in favour of removing the municipality nodes and transferring the information to the relation. Especially since Carto does not use or display it at all.

1 Like
25

I’m completely fine with this. I would only recommend that the documentation on the usage of place=municipality and boundary relations on municipalities will be improved. As said before, based on this discussion, I think that we highly likely never need a node with place=municipality in Germany and Austria. Both are well mapped countries where we should have a boundary relation for each municipality. Even if the municipality has a name that is different from the name of its municipality seat, a renderer would take the name from the boundary relation anyway.

3 Likes
26

I feel this pain and I’d agree, except that a substantial portion of the Cebuano-linked items do represent real places and parks. Anecdotally, the conflation issue represents probably about 1 in 20 items that I’ve encountered, which is spectacularly awful, but I’ve also seen people overcorrect by falsely merging Cebuano-linked items based on the name alone. That kind of conflation can be tricky to untangle, especially if it spreads to OSM.

As the saying goes, even a broken clock is right twice a day.

27

It also happend to me that I overmerged items. The Cebuoano-Bot items often do not have the correct local name, but some dashes and blanks in between, where the German native language term typically concatenates the word elements (e.g. for the mountain “Karhorn” and not “Kar Horn” or “Kar-Horn”). So if you work on a topic and come across ceb items, you typically do not take too much time to decide. Luckily, there is also an option to revert.

28

I have updated the German wikipage on place=municipality: DE:Tag:place=municipality - OpenStreetMap Wiki

I wrote that neither for Austria, nor for Germany, a separate node is needed and instead all information should go to the boundary relation (which is also roughly covered in the wikipage). Renderers would expect the information there anyway. I did not delete how to map a node with place=municipality. I added that it might be needed for other world regions, e.g. in areas where boundary relations for municipalities do not exist.

I hope this will be useful to avoid future confusion on municipality mapping.

29

Here is another one:

it does not add a second point with the same name, it is just the municipality (I agree representing this with a single node in the middle of nowhere is not the best mapping, a municipality is an administrative entity so adding the place=municipality tag to the boundary seems fine if you think suggesting a label position is not the task of a geodatabase

30

I bet there are dozens of them worldwide, what do you think?

31

Just another DACH-centric viewpoint: in Switzerland place=municipality is rarely used as we have complete municipality borders for the country and from a search/geocoding pov things tend to just work for them.

There is a potential use case though for municipalities that don’t contain a place with the municipality name. Most of the time this is simply due to the municipality name being geographical qualified and in that case we typically simply use the non-qualified name for the admin-centre object. But there are some cases with municipalities that have a composite or completely different name than any of the enclosed places, for which it could be used. The problem is that this is a direct route to the rabbit hole of if admin entities are/can/should be places or not.

32

place=municipality on a node is a highly established mapping in Germany that has been part of many forum discussions over the last years. Please do not modify the German Wiki-page substantially without an appropriate discussion with the German community.

33

As I mentioned in the very beginning, I thought OpenStreetMap is a worldmap. Not a German or Austrian map. Therefore, the same mapping practices should apply worldwide as far as country-specific circumstances allow for it.

Here, we are not talking about Germany, but about: Is a separate node to propose a labeling position of a municipality required at all, if a boundary relation for the municipality exists anyway. The outcome of the discussion was: No. Creating rendering hints should not be part of mapping considerations.

So if a place=municipality node is no added value at all, why is it of value for Germany and needs to be discussed in the German community? Maybe other people having created such nodes were misguided by the German language documentation as well.

I would further assume that the German language documentation is not only considered by Germans, but e.g. Austrians and Swiss as well. Or do they also have their own AT and CH OSM wiki so they can make their country-specific rules to do mapping differently but anywhere else in the world?

3 Likes
34

These municipalities exist. There are even municipalities that have a name that is completely independent of settlement names. E.g. Argenbühl in Germany, where the municipality seat is called Eisenharz (Relation: ‪Argenbühl‬ (‪2806737‬) | OpenStreetMap).

But it was explained that even in this case, we do not need a separate node. The name of the municipality is tagged in the boundary relation and renderers should refer to this relation:

35

That’s a highly idealistic position that doesn’t really represent what happens in practice. (Whether it even should be what happens in practice is a whole other question).

There is nobody who can enforce worldwide tagging practices, so in reality many communities develop their own approaches. It’s not easy to draw a clear line between “country-specific circumstances that require specific mapping approaches” and “cultural or linguistic differences or accidents of past mapping history that have led to differences that are difficult to undo at this point”.

I know from living and mapping in two European countries that perfectly common mapping practices in Country A would be immediately reverted if I tried them in Country B. Sometimes these differences go back to the approaches taken by a small number of active mappers in the very early days of OSM. If anyone felt strongly enough to want to change them, it would require a lot more than modifying a wiki tagging page.

I think you are making a big leap from a discussion between a handful of people on a narrow topic. Many people wouldn’t read a post that appears to be specifically about place=municipality. But the “label” role is much more general and is used more than 160 thousand times globally, so clearly significant numbers of mappers feel it does have a purpose.

Also, the discussion was not just about whether the “label” node should exist, but also about whether it should include tags such as wikidata.

Have you asked the German community? Note that if current practice is to use these nodes then that practice should be described on the wiki, regardless of whether it seems a good idea or not (although it does seem here the wiki may not have sufficiently reflected other approaches, and as you imply there may have been a bit of confusion between German the language and Germany the country).

It’s common enough for countries to have their own pages on the wiki documenting specific mapping practices. I’m not so familiar with the German-language wiki, but just for illustration, the page Directrices de etiquetado españolas lists guidelines for mapping in Spain (that is, the country Spain, not the Spanish-speaking world). That’s not merely theoretical. For example in the mapping effort responding to the floods near Valencia, it came to light that many non-Spanish mappers had a different interpretation of when to tag highway=track versus highway=unclassified compared to practice in Spain. (I’ve drifted a long way off topic here, but I think it’s important to be aware of this kind of context).

2 Likes
36

It is not a common practice. In some areas of Germany, such tags are used, but in other areas such tags are not used. It was said that, in this regard, Germany is an outlier anyway. So if, from a general point of view these nodes do not make sense, why should they still be promoted only due to a country-specific habit?

37

Just to be clear, I was referring to a growing consensus among U.S. mappers about how we might want to evolve the tagging standards going forward. We started discussing that because someone noticed an inconsistency from state to state that didn’t seem to be justifiable based on real-world differences. I don’t think there has been adequate discussion among the broader OSM community and software ecosystem to say it’s a done deal yet, but the more that local communities get on board with this viewpoint, the stronger the momentum for a global change. Think of it as a kind of informal federalism.

I was also pointing out that there’s a difference between a label member / place=* point that represents a settlement’s commonly accepted central location, which cannot be computed, and one that merely represents a centroid, which can be computed mathematically. place=municipality happens to be a place classification that’s mostly only used on centroids, but even so it might still have an enduring utility in countries where boundary data is difficult to obtain.

38

It was I who used the word “outlier”. I merely said that based on a few other countries I thought Germany might be an outlier. But I didn’t look thoroughly at the use in all other countries. Maybe there there are one or more other countries that have well-developed systematic approaches that require these nodes. If I was going to change the wiki page on the subject, I would look at that kind of thing in more detail.

And also, I was referring only to place=municipality, not stating a general principle about label nodes for boundaries in general.

39

from my understanding, the German wiki documentation is documenting the use of tags in German language. Country specific information should be marked specifically and indicate to which countries or areas it refers (regardless of the language in which it is written, we could have paragraphs about specific tagging conventions in France in the “German” wiki). But this is the theory, in practise, you can find a lot of information specifically referring to Germany in the German wiki, and it is not always clearly marked as country spedific or Germany related.

2 Likes
40

actually, it could be criticized for all place-tags which are replicating an administrative entity type already given inambiguously in the admin_level and typically with its boundary, e.g. level 2 and place=country, or level 8 and municipality, but also place=state and level 4 (e.g. how much sense does it have to represent a state with a node? Node: ‪Arkansas‬ (‪316942960‬) | OpenStreetMap ), or place=county and level 6.