Atlantic Ocean: repeated name removal

General talk
62

A redirect takes you to the main name=* page where int_name=* is described in the table as:

International name. Consider using language specific names instead; e.g., name:en=… International does not (necessarily) mean English. It is used to give the name transliterated to Latin script in Belarus, Bulgaria, Greece, Kazakhstan and Northern Macedonia

Though I would note that usage does seem to vary wildly. For example, the most widely used value is clearly not an “international name”. “Aparato Individual de Bombeo” (used exclusively in Argentina) is just Spanish for Individual Pumping Apparatus.

63

Fortunately, this just appears to be one mapper’s misunderstanding that they’ve copied all over the place. (They confused name with short_name for the initialism and used int_name for the spelled-out name, but both are descriptions rather than actual names.)

To your broader point, there have been many questions over the years as to the source of an int_name. For example, if a tourist attraction is mostly known by a different name internationally than locally, but the attraction is virtually unknown to English speakers, should int_name really be in English?

It’s an interesting question, but I don’t think we need to solve it as part of naming the oceans. Even if we decide that the English name isn’t the most obvious international name for the Atlantic Ocean, it still has a strong claim to being the official_name, which often holds the legal name of a feature. But I think name and int_name would be a better place for this information, because official_name insinuates that the other names are somehow less legitimate.

64

Just want to chime in to support the notion that name=* should be dropped from the Atlantic Ocean. My reasoning is as follows:

  1. It should not be within the scope of OSM to provide default/fallback name values. This is a political and dirty business, it will eventually generate lots of conflicts, and it will leave the DWG with tons of extra work in resolving said conflicts.

  2. It adds yet another meaning to the name tag, which makes using said tag harder for new mappers. We should strive to keep such central tags as unambiguous and simple in meaning as possible.

  3. The problem of objects having lots of names in different languages, but no clear universal default to fall back to is not a fringe case at all. It is very common, and I’ll elaborate on this below. As such, OSM should help and encourage data consumers to handle these cases properly, whatever that would imply for the individual consumer. We don’t do this by trying to camouflage the problem though providing unfounded fallback names. I’d argue that putting makeup on this turd actually diminishes the quality of OSM data, as it encourages mistakes on the the data consumer’s end.

    This problem occurs in every area of the world where no single language has dominance, of which there are lots:

  • Along every linguistic boundary. These sometimes coincide with national boundaries and sometimes not. A case I recently encountered was when mapping along the Norwegian - Russian border. I held my nose and tagged using name=<Norwegian name> - <Russian name>, or the other way around, just to achieve a sensible rendering in carto, but I still feel bad about it many months later.
  • Areas with multiple official languages:
    • Belgium would be the prime example that springs to my mind.
    • In Norway, where I come from, the indigenous Sami languages are recognized as official, on par with Norwegian. In areas with both Norweigan and Sami settlements, objects often have two equally weighted official toponyms and no clear way to prioritize one over the other. I don’t want to put a name tag on these objects, but I still want one or both official names rendered by data consumers.
  1. Although one could argue that removing name from such objects is breaking with data consumers’ assumptions, and thus is breaking backwards compatibility, I still tink it is preferrable to remove said tag. Any data consumer that is relying on name for fallback in ambiguous cases are by definition displaying incorrect and messy data, as there are no universally agreed upon strategy for how one should determine these fallback values. If we drop the name tag for these objects we are actually increasing the quality of their product, as it is better to not display a name than to display an incorrect name, IMO.

For what it’s worth I like @ZeLonewolf’s suggestion of a noname=multiple_languages tag and I hope it is adopted.

2 Likes
65

Given that many data consumers already treat the name tag as the default/fallback name, how would you suggest changing the status quo? Replacing the name tag entirely and always using language qualified name:* tags instead would be both more explicit and more neutral, but given current usage patterns that seems unlikely to happen any time soon.

https://taginfo.openstreetmap.org/keys/name#overview
https://taginfo.openstreetmap.org/search?q=Name%3A#keys

66

I suggest simply removing the name tag in the cases where a name tag can’t be reasonably justified, such as in this case with the Atlantic Ocean, or in the other cases I describe. If the value of the name tag is an actual name in some language, the value can be moved to the appropriate name:lang key. Adding the noname=multiple_languages tag is probably also a good idea.

Said data consumers will then be robbed of their default/fallback values, but that’s fine as they are unreliable data that shouldn’t be relied upon by any sensible service anyway. If this results in the consumer loosing naming they desire, it will hopefully spur them to do a better job at name handling. Naming is intrinsically complicated and consumers must relate to this. OSM can provide suggestions for how to navigate this space, but in the end the consumer should be responsible for choosing a path.

Note that I’m not proposing removing all name tags. I only suggest doing so in cases where no single language can lay claim to the name tag. I want to reserve the name tag for cases where there is a single indisputable name that outranks all others in officially/usage.

3 Likes
67

Sorry, but there is none.

Even if everybody on Earth agrees that it’s the Atlantic Ocean (& should that be North Atlantic & South Atlantic? :thinking:), what version of it do you use?

I’d think that name:lang=* is really the only way to go, & for the Atlantic, I’d start with English, French, Spanish & Portugese as the 4 majors, with a host of “smaller” contenders.

1 Like
68

That’s what @harahu saying… there is no ONE name for it, so there should be no name. But there might be other objects having only ONE name and then can have a name.

Totally agree, it should not be up to us mapper, what is labelled on the map. We mapper can assist in making the situation clear by something like noname=multiple_languages and if applicable also something like default_language=no;ru

69

There are 96.6 million uses of the name tag. Meanwhile the most used name:lang tag is name:en at 5.9 million. Most language specific name tags have usage under 1 million. I don’t see how removing name from a small number of contentious objects would get data consumers to stop relying on it. It will still be there on the other 96 million!

3 Likes
70

Well put. This is more or less what I’m saying. I suspect we are in agreement, @Fizzie41; but I might not have expressed myself clearly enough.

A slight nuance is that I don’t want to require an object to truly only have ONE name for the name tag to be used. My requirement is just that it has a single dominant name, more important than any other.

As an example; Sognefjorden has names in multiple languages, e.g name:de=Sognefjord, but it also has name=Sognefjorden, which is fine, because this is the indisputably most important (and official) name name for the feature.

To be clear: I have nothing against data consumers relying on and making use of the name tag. It can be very useful, as expressed above. And its usage is probably correct in the vast majority of its uses. I just take issue with data consumers relying solely on the name tag for their name rendering, expecting there to always be a name for significant objects. Doing so is a terrible practice, IMO.

Even though the cases where objects have a justifiable name tag outnumber the contentious cases we’re discussing, some of these contentious cases are pretty significant. If what I’m proposing goes though, lazy data consumers would loose the rendering of all the world’s major oceans, Antartica, and, the de facto European capital of Brussels. In addition to a host of other significant objects. That is, until they realize that name isn’t the only source of name data for objects that they should be leveraging.

I can’t be certain, but I’m imagining that the loss of these high-value names will be enough for these lazy data consumers to wake up. And if they don’t, I still think it’s a good thing that they aren’t displaying nonsense names anymore.

For the rest of data consumers, who already handle names with a bit more care, removing these contentious names will have a strictly positive effect, in that their own (thought through) fallback logic is allowed to come into effect.

1 Like
71

I agree with removing the name tag for reasons already mentioned. int_name can IMO be used in cases where we can back it up with documentation that says a specific language is preferred for communication between people who speak different languages. I don’t think we should spend any time inventing our own rules for which name applies the most in multilingual spaces.

72

If I understand your comment correctly, int_name should not be copied into name in the absence of a more applicable name – what about other name keys?

73

De wiki about names says:

name: The common default name. Notes:

  • For disputed areas, please use the name as displayed on, e.g., street signs for the name tag
  • Put all alternatives into either localized name tags (e.g., name:tr/name:el) or the variants (e.g., loc_name/old_name/alt_name)

This wiki does not mention the case discussed in this topic, where there is no default common name. We seem to converge to the notion that name should hold the undisputed common name, if there is one, even when there are no name signs on the ground. Then this case shoud at least be mentioned as a special case/exception.

I also think the term “default” is not right. It’s not a name used when all other names are missing, it is the verifiable name. If other variants exist, it is up to the renderers/data users to determine the rules and priorities for the use case of their particular application. Defaulting is a processing rule, not an attribute.
Maybe “undisputed common name”? With absence of ground truth as a special case.

74

Having read a bit here, so curious. Met someone from southern Iran today, it seemed he stressed “Persian” more than gulf, he showed me the google maps, I asked to look at openstreetmap - there was no Persian gulf there and no Arabian gulf - he could read all the scripts no matter which side, nothing! Just now looked it up back behind the keyboard, Nominatim has a hit for Persian Gulf - takes ages to load that beast. Nominatim also finds “Arabian Gulf” does it have two name:en? (Update: Yes, alt_name:en)

75

At least for me when logged out, Google Maps labels the gulf as “Persian Gulf” and “Persian Gulf (Arabian Gulf)” if you zoom in a little further. I’m seeing this regardless of language when appending &hl=LANGUAGE_CODE to the URL. However, reputedly, the priority switches depending on IP geolocation, so you might see something else in every language. In order to facilitate something like that in OSM-based data consumers, the relation would need to be tagged with all manner of name:*-IR, name:*-SA, name:*-UE, etc.

Incidentally, the name is the Arabic for “Arabian Gulf” as of changeset 138,526,663. The comments in that changeset explain the choice of name.

76

I did comment on the CS, I just felt like that. Curiously, in the group, there was a woman from Hungary that never ever heard of the Persian Gulf yet decidedly said to know the Arabian Gulf (she meant the Red Sea.) So, which name is name:* and which is alt_name:* may also be locally decided?

PS: The man from Southern Iran consulted google in the German locale and “Arabian” was in put in parentheses below “Persian”.

PPS: Interestingly, in historic times, the Red Sea was indeed called “Arabian Gulf” (source Wikipedia.)

1 Like
77

@imagico has written about the problem of multiple names on his blog and did some interesting tests how to build a label from different parts.
If you haven’t yet, it’s very much worth reading.

78

For completeness, there’s also this massive thread on the same topic:

79

As far as I can see, since July it has not been tagged with noname=yes, yet it is still not being rendered.

name=* is still missing however (whether correctly or not), so it seems just this condition alone prevents rendering?

If so, this seems like an issue with OpenMapTiles to me. The name:XX tags overrule no name tag (just as they would if there were indeed a name tag). If there is no name:XX for a user’s language tagged, then omit the rendering.

(Purely out of interest, I wonder what would happen if we set the name value to a white space…presumably it’d then render?)

80

Correct, it’s the lack of name that prevents it from rendering. noname is only relevant to this discussion because some mappers, probably acting on the advice of a validator warning, add noname=yes to affirm that they don’t think the feature should have a name.

This is the cruxt of the issue. name is defined as a feature’s primary name(s). But do we say that a massively multilingual feature, such as an ocean, has many primary names, a primary name that is null (meaning the ocean is unmentionable?), or a primary name that nonetheless we would feel comfortable replacing with a localized name when presenting to a user?

To me, name:* without name is just as awkward as *_name without name. We don’t omit name from this reservoir just because the state and federal authorities have competing reg_name and nat_name for the same lake, or from this river because each of the countries along it speaks a different language. Hardly anyone knows the name of this islet, but that doesn’t mean it should be tagged alt_name without name.

81

It has no primary name but it has (already-tagged) localised names which can, and should, be rendered.

My opinion (for various reasons) is that English is good enough as a fall back and I would be fine with that being used for name (but I am from the UK, so I’m not entirely unbiased in this).

However, in some ways, that is a separate topic. OpenMapTiles does read in localised names. The omission of name shouldn’t prevent it (or any other renderers) rendering name:XX as appropriate (the exception being if the appropriate localised name isn’t tagged).