[patch] Check for name not equal to any name:*

[skela]

In multilingual areas, some mappers seem to use “name:*” for “foreign” languages and only “name” for their native language. It would be more consistent to use name:* for each language.

I think that the validator plugin should complain when there are “name:*” attributes defined on an object and the “name” attribute does not match any of the “name:*”. Please consider applying the attached patch.

[skela]

Patch to implement the “name != any of name:*” check

[stoecker]

I other areas it is "name=name:1 - name:2" (in bilingual areas like Belgium). You should change your code to support that case also. And please change the wording to something more descriptive.

[anonymous]

Why should only redundant name-tagging be valid?
I would expect Helsinki to be tagged:

name=Helsinki
name:se=Helsingfors
name:fa=هلسینکی
...(more *localized* names)

...as if any application needs a localized name and can't find it should fallback to the default name tag. If I understood the proposal that's the base for this patch correctly you would consider this invalid and rather enforce:

name=Helsinki
name:de=Helsinki
name:fi=Helsinki
name:en=Helsinki
name:fr=Helsinki
name:se=Helsingfors
name:fa=هلسینکی
...(more *localized* names)

What's the advantage? I vote for not including this validator check.

[skela]

Replying to anonymous:

If I understood the proposal that's the base for this patch correctly you would consider this invalid and rather enforce:

name=Helsinki
name:de=Helsinki
name:fi=Helsinki

…
Not really. My proposal is that when there are localized names, one of them should be the default name. Or to follow Dirk Stöcker’s suggestion, the default name could alternatively be a composition of (some) localized names, such as name=Brussels-Bruxelles (the name need not necessarily include name:de=Brüssels, name:fi=Brysseli, etc.).

What's the advantage? I vote for not including this validator check.

The advantage would be that the language of the default name would be tagged. It could be useful in spell checks (think of misspelled “street”, “alley”, “lane” embedded in a name) or in consistency checks, when comparing the address data to other databases.

Identifying the language could also be useful in text-to-speech applications (spoken driving directions from navigators). If the language is known, the name can be pronounced correctly. Think of name=Vantaa, name:fi=Vantaa, name:sv=Vanda. Germans would hear “Vantaa” with the name:fi Finnish pronounciation. If it were tagged name:de=Vantaa, the V would be pronounced as F, which few locals would recognize.

Suggestions for a better description of this check are welcome.

[skela]

Revised patch, to check if name equals any of name:* or is a composition of some name:*

[skela]

Replying to stoecker:

I other areas it is "name=name:1 - name:2" (in bilingual areas like Belgium). You should change your code to support that case also. And please change the wording to something more descriptive.

The revised patch attempts to address this. I tested it ​near Brussels. Currently, the only supported separator is " - ".

I was thinking of supporting something like "\s*\(-\|–\)\s*", but it could lead to false splits that would have to dealt with. For example, name="Avenue de la Toison d'Or - Gulden-Vlieslaan" would be split into "Gulden" and "Vlieslaan" while name:nl="Gulden-Vlieslaan".

Those mappers who dislike this check could always disable the check in JOSM configuration, right?

[skela]

Fix a NullPointerException and use Map.Entry to avoid map lookups in the name:* iteration.

[skela]

I would like to emphasize that this check only affects map primitives for which there are name:* keys defined. In monolingual areas, nodes, ways and relations may carry name tags but rarely any name:en, name:fr, name:de and so on. This check kicks in only when a map primitive carries one or more name:* tag.

[stoecker]

Ok, the revised version seems to be better. Can you checkin yourself? You know how to build new .jar also? First checkin, then svn up, then ant and the checkin new jar in dist-dir (When you forget svn up the version is wrong).

[skela]

Replying to stoecker:

Ok, the revised version seems to be better. Can you checkin yourself? You know how to build new .jar also? First checkin, then svn up, then ant and the checkin new jar in dist-dir (When you forget svn up the version is wrong).

Thanks, I will, later tonight. I did not check in the .jar for #3669 last night, because I thought other changes could soon follow. I will do that for this fix.

[skela]

Committed in r18512 and r18513.