include all name variants (don't de-dup)

[matkoniecz]

I wanted to provide fallback for names - for example for a location in Japan I would want to display name:pl if it would be available, with name:en as fallback and if neither was available use name, likely to contain unreadable squiggles (true list was significantly longer but other languages were omitted for previty).

• What did you see?

Mapzen includes all language variants of the name:* values to enable full internationalization (when different from name).

https://github.com/tilezen/vector-datasource/blob/master/docs/layers.md

So as result, in Poland name:pl was removed and as result I got English names on my map in Poland (despite name:pl provided, to avoid exactly this problem).

• What did you expect to see?

name:lang are provided, even if the same as name (or there is a list of languages where name is the same as in the name tag, so one may use fallback in displaying label)

• What map location are you having problems with? City and country are helpful, as well as tile coordinates or latitude / longitude.
• Screenshot? Props for animated gifs.

See https://github.com/matkoniecz/Zazolc/commits/failed_fallback branch

https://mapzen.com/tangram/play/?#13.5000/50.0586/19.9356

This image contains more German labels than Polish ones. With addition of some English labels, that are also unwanted.

German and English names are preferable over Japan/Korean/Hebrew etc, but not over Polish names.

Is space saved by avoiding name duplication really worth making fallback for labels impossible? How much space is saved this way? Maybe deduplicate only some languages?

[nvkelso]

Here's a better link for testing:

https://mapzen.com/tangram/view/?api=506/1132#13.0622/50.0625/19.9280

I copied the YAML into a Tangram Play as a signed in user and then saved it. The map id is 506/1132.

[nvkelso]

I suspect this is related to:

    name_source: |
        function() {
            return feature['name:pl'] || feature['name:en'] || feature['name:de'] ||
                   feature['name:fr'] || feature['name:fi'] || feature['name:es'] ||
                   feature['name:ja_rm'] || feature['name:sv'] || feature['name:it'] ||
                   feature['name:sr-Latn'] || feature.name;
        }

Since OSM names in the local language for that place aren't generally tagged with (in this case) name:pl and instead rely on name, it's ambiguous as to which language the default name is in.

We are more strict in Refill and other Mapzen basemap styles, requiring a specific language code be provided so all labels are in that language, the fallback language, or the local language:

https://github.com/tangrams/refill-style/blob/3801ad27e12158159ce71711efa52875a06fccbf/refill-style.yaml#L24-L30

    ux_language: false             # l10n language code, trusting OSM in v0.10 tiles, fixed in v1.0 tiles
    ux_language_fallback: false    # l10n language code, trusting OSM in v0.10 tiles, fixed in v1.0 tiles
    ux_language_text_source: |
        function() {
            // if a ux_langauge has been defined use that, else if there is feature name in the fallback_ux_language then use that, else use the feature's default name in the local language
            return (global.ux_language && feature['name:'+global.ux_language]) || (global.ux_language_fallback && feature['name:'+global.ux_language_fallback]) || feature.name;
        }

This way the languages won't be "mixed" randomly but on a set order.

Potentially Tilezen could "guess" at what language the name property is in (spatially and algorithmically with language detection). Or the specific name tag could be added to OSM and Tilezen would pass it thru.

It's debatable if we should continue dropping "duplicates" of the local name. That may be a overly cleaver optimization that's outlived it's usefulness.

[matkoniecz]

Since OSM names in the local language for that place aren't generally tagged with (in this case) name:pl and instead rely on name, it's ambiguous as to which language the default name is in.

At least in Poland, people started tagging both name and name:pl - see for an example http://www.openstreetmap.org/node/206270454#map=19/50.06873/19.94874

Some people attempted to use the same fallback logic and worked to add missing name:pl. I also expected that by adding this logic I will find some places with missing name:pl and I will fix them.

JOSM also complains if no name:lang key has the same value as name key. There are many false negatives as sometimes equivalent of name in other languages is the same as in local, so this warning is frequently missing despite lack of both name and name:local_language_tag

[nvkelso]

Another alternative is to denote what the local language code for the default name is, in this case something like name_lang:pl. Then name would be in Polish, and since name:pl would match name, name:pl would get dropped along with all the other "translations" which are actually just the local name.

Here's the tags for that feature:

[matkoniecz]

Another alternative is to denote what the local language code for the default name is, in this case something like name_lang:pl. Then name would be in Polish, and since name:pl would match name, name:pl would get dropped along with all the other "translations" which are actually just the local name.

It would still cause problems in some situations. Let say that we want to display labels in Polish (name:pl), with English (name:en) as fallback.

Lets say that we have location outside Poland with

name=foobar
name:en=EnglishText
name:pl=foobar
name:local_language=foobar

it would end converted into

name=foobar
name:en=EnglishText
name_lang=local_language

and EnglishText would end displayed (I wanted to check is it happening anywhere or is it theoretical issue at least for Polish labels, but overpass is currently down).

Also I fear that

Potentially Tilezen could "guess" at what language the name property is in (spatially and algorithmically with language detection).

will result in poor results near borders - with some mistakes on/near borders. Also what about peaks that are exactly on a country border? In addition, I would expect that it will be obnoxiously complicated to guess local language in places where there is more than one language in a country. Finding data for that will be really troublesome - it is not helping that it is frequently a political issue. https://en.wikipedia.org/wiki/List_of_multilingual_countries_and_regions would be really scary during implementing this.

[matkoniecz]

Overall, maybe just showing all labels would be a better idea?

[nvkelso]

Yeah MVT solves this problem for us, and compressing the GeoJSON and TopoJSON does as well.