Default and local language name not the same: Error or False Positive?

[AnkEric]

In the Netherlands "we" use English language as default language (for OpenStreetMap). Most important if the object is relevant to foreigners, not speaking Dutch language.

So - IMO - this is correct:

• name = "European Limes Cycling Route"
• name:en = "European Limes Cycling Route"
• name:nl = "Europese Limes Fietsroute"

FIX: "Class 50601 "Default and local language name not the same" does not answer my question.

Is this (more) correct, because "Default and local language name are the same"?

• name = "Europese Limes Fietsroute"
• name:en = "European Limes Cycling Route"
• name:nl = "Europese Limes Fietsroute"

Or is this (more) correct, because because no [name:nl] is specified?

• name = "European Limes Cycling Route"
• name:en = "European Limes Cycling Route"

Is [name:nl] the default name for the Netherlands? Why? This is an European Cycling Route (icn), not a Dutch Cycling Route (lcn)...

Or does the item refers to: [name:cs = ?] ? If this is the issue than I do agree: list of "?" is both incomplete and needless. And incorrect: Rendering a name as "?" is always incorrect. Should the Renderer always verify: is my preferred language available and not ('?' or 'unknown' or 'Null') (realistic example!)?

key	value
source	5042
item	5060
class	50601
subclass	0
elems	relation8309144
lat lon	52.0853013 4.8741829
en	Default and local language name not the same
timestamp	2018-10-16 20:10:03

tags	commentPlease do NOT add any way or node to this relation. It is intended to collect all the sub-relations composing the complete itinerarydistance0icn_refLimesnameEuropean Limes Cycling Routename:cs?name:deEuropean Limes Radwegname:enEuropean Limes Cycling Routename:es?name:fi?name:fr?name:hr?name:hu?name:it?name:lt?name:nlEuropese Limes Fietsroutename:no?name:pl?name:pt?name:sl?name:sv?name:tr?networkicnrefLimesroutebicycletypesuperroutewikipediaen:Limeshttps://en.wikipedia.org/wiki/Limes	comment	Please do NOT add any way or node to this relation. It is intended to collect all the sub-relations composing the complete itinerary		distance	0		icn_ref	Limes		name	European Limes Cycling Route		name:cs	?		name:de	European Limes Radweg		name:en	European Limes Cycling Route		name:es	?		name:fi	?		name:fr	?		name:hr	?		name:hu	?		name:it	?		name:lt	?		name:nl	Europese Limes Fietsroute		name:no	?		name:pl	?		name:pt	?		name:sl	?		name:sv	?		name:tr	?		network	icn		ref	Limes		route	bicycle		type	superroute		wikipedia	en:Limes	https://en.wikipedia.org/wiki/Limes
comment	Please do NOT add any way or node to this relation. It is intended to collect all the sub-relations composing the complete itinerary
distance	0
icn_ref	Limes
name	European Limes Cycling Route
name:cs	?
name:de	European Limes Radweg
name:en	European Limes Cycling Route
name:es	?
name:fi	?
name:fr	?
name:hr	?
name:hu	?
name:it	?
name:lt	?
name:nl	Europese Limes Fietsroute
name:no	?
name:pl	?
name:pt	?
name:sl	?
name:sv	?
name:tr	?
network	icn
ref	Limes
route	bicycle
type	superroute
wikipedia	en:Limes	https://en.wikipedia.org/wiki/Limes

[frodrigo]

The default language for Netherlands is "nl" (except in Friesland): https://github.com/osm-fr/osmose-backend/blob/master/osmose_config.py#L868

I presume the is no so much objects where the primary name tag is in English. You can just mark them as false positive. The other alternative is to allow "nl" and "en" as default language, but I think is not a good solution for Netherlands.

[frodrigo]

Please reopen if required.

[majkaz]

@frodrigo I have the same issue. The presumption that every name tag has to be in local language is simply wrong for international routes (example: European cycle/hiking/road routes).

I have seen it for the relations on E55 (for example rel. 2566710). For an European road, English name is just fine, even if this part is only in Czechia. You want to keep the name "readable" by others as well. Yes, I am marking it as false positive but IMHO, this specific case (international routes) should be excluded by design.

[fgouget]

How can one identify "international routes"?

[majkaz]

Well, it shouldn't be that difficult in Europe: E55 is "European" network, network "icn" is "International Cycling Network", "iwn" is for International trekking/tourist routes.

[fgouget]

There are a ton of Exx and Exxx roads in France but nobody knows them by those names. For instance nobody knows what the E50 is is whereas everybody knows the A4, aka the "Autoroute de l'Est". Furthermore most signs are labelled as A4. So putting "E50" on the map or translating the name to "Est Highway" would make no sense.

Maybe it's different in other countries or for cycling / trekking paths but this should really be double-checked.

[majkaz]

@fgouget Are we talking about the same? If you name the road in local language, there is no problem, the check doesn't complain. If you name the relation in local language, the same. That's up to you. What is discussed here is that it isn't this way everywhere. My problem is the Exx RELATION and every one of the international relations, which are by definition international. The check doesn't make much sense here. You may have the name in local language or you may have it in English, just to keep it readable everywhere. And the check complains for each and every smallest part in the relation, because the message works like "there is some name connected with this way in different language than the local one". I would love to see this check disabled for such relations.

[fgouget]

I guess we weren't and I'm probably still a bit confused.

• As I now understand you're not proposing to change the name of the road segments.

• Changing the name of the per-Country relation for an international route to not match the local name could make sense as it depends on the local conventions. But how can a program identify those? Does it need a hardcoded list of all the international route identifiers?

• The relation that collects all the per-Country relations cannot have a name that matches the local name in each of the countries. That's true of all relations that contain objects in multiple countries. Is this what you mean?

[majkaz]

• I am speaking strictly about the Osmose test. This has nothing to do with the mapping, just with how Osmose is working.
• Yes, it would probably need a hardcoded exception. IMHO, the icr and iwr relations as whole should be excluded from beginning from this test. The only other exception seems to be the e-road network. Not that difficult to exclude, it has an extra tag network=e-road. There is no reason to check for name in local language for such relation. It might be in local language, but it might be as well in English/French/whatever "universal" language was decided. In every of these cases, there is an exact (and sufficient) identifier already available.
• Not quite. Yes, this is automatically true for every superrelation. You cannot have a superrelation crossing boarders in Europe without changing the language, except in very few cases. But often, it is true for the national part as well, see this Czech part and the part in Austria of the superrelation 21572. Neither has the name tag in local language.

[Bibi56]

@majkaz I got your point but that's rather an exception for NL. In France the French part is usually named in French (not for icn, I don't know why). So we have name:en, and name (which is the same as name:fr). Consider it rather as false positive? IMHO have name in NL and name:en in EN would make more sense but that's up to Dutch mappers.

I checked the wiki and the issue is more the wiki than Osmose:

name=* - Description the route A description should use the key description, not name.

For the mentioned E55, see your point 2: E55 is sufficient. The given name is just bad: it's the Austrian part of the E55, the E55 is not Austrian, a description:en would be Austrian part of E55.