|
Hi everyone. The context for this question is that I'd like to improve the multilingual names for the states of the US. I'm using iD. When I search for a state name, the main result is the Administrative Boundary relation and it has all the name:xx tags. But inside the state there is also a node with place=state that is role=label. This node has a completely separate set of name:xx tags! I have noticed some states where the relation's name and the node's name have slight differences. So to localize every state I have to do it twice each. My understanding is that some places are sometimes mapped as center nodes because their boundaries aren't clearly defined, but for states I wouldn't think that's a problem. Doesn't this practice violate the "one feature one element"? What are some reasons for mapping label nodes inside the relation? Should I fix the name:xx for both each? Thank you. Edit: I would like to note that, at least for OSM's renderer and within iD, the state's name appears roughly centered over the area, and not where the role=label node is. So I'm not seeing what the label node provides. |
|
I would say no. A bigger issue is double-tagging |
|
Firstly, about the task you are describing: Please only ever add name tags for languages that you know. Do not blindly copy names in languages you are unfamiliar with from places like Wikipedia - it doesn't improve the quality of OSM one bit. Especially so if the name you enter for a certain language is identical to the English name of the place. See this thread on talk-us https://lists.openstreetmap.org/pipermail/talk-us/2020-December/020769.html and maybe discuss your ideas there before continuing. As for your second question, I think that the place nodes are mostly left over from olden times when we did not have administrative boundaries. At some point the rendering has switched from using the place nodes to using the names of admin boundaries, but not every renderer necessarily does that and if someone just wants to know where in the world approximately Nevada is, maybe these nodes are useful. Nominatim, at least, will under certain circumstances merge names from a place node and its surrounding admin boundary. You are right in saying these nodes violate the idea of "one feature, one object", unless of course you want to argue that "a state" and "the administrative boundary of a state" are two different things. Personally I wouldn't add a place node if I added a new state boundary, but I wouldn't remove an existing one either. 1
Yes, thank you for the caution about blind copying. I have confidence that my change would be a good one, but I'll use separate talk threads for that. I did not consider that state boundaries were added later, so that makes sense as to why they exist. I wouldn't dare remove the nodes but I hope one day it can happen so we don't have to duplicate everything. So it sounds like I should do the names on both then, since different renderers might be using them both. The reason I started this is because I noticed the inconsistency within OsmAnd, which I now believe is pulling the names from the nodes, not the relations. Thanks again.
(28 Dec '20, 00:19)
traditionals...
It should be noted that boundary relations support a "label" role that can reference a node for placement of the label :-). If this references such a place node applications can in principle could de-duplication of the objects.
(29 Dec '20, 10:30)
SimonPoole ♦
|
