Duplicated keys in SpecialPhrases are lost about osmand

[stefanb]

Please note that HashMap.put(K,V) documentation says:
If the map previously contained a mapping for the key, the old value is replaced.

[vshcherb]

We don't use now more than 1 value. So this is an issue for now

[stefanb]

Actually there is legitimate need for duplicate keys for supporting common aliases. This intent by developers can be observed in specialphrases_en.txt, which contains 82 duplicated keys, eg:

gym,Fitness Centre
gym,Fitness Center
gym,Gym

to accomodate for various aliases that are used in the POI list to make it prettier (show "Some Fitness Center" instead of "Gym Some Fitness Center"), but still show it with POI type if some alias is not included in the name already ("Gym Some").

[sanderd17]

The duplicate keys are included in the text file, for when it's needed to have a map in the reverse order (phrase -> key). This can be useful for full-text search, or for the thing you says.

But as natural text search isn't implemented yet, I didn't include code to create that map, as it would most likely appear to be useless anyway.

For your advantage, I don't know if it's needed. I just filtered the text so it wouldn't repeat itself (as the comment in the code says, "backery backery the Corner" looks very silly), but I don't see a problem with synonyms. To me, "Gym Quality Fitness Centre" looks fine.

Of course, if you don't agree, you have the code, so you can make a map in the other direction to solve your issue.

[stefanb]

I just wanted to see some consensus before starting to fix it.

My proposals:

• OsmAndFormatter.getPoiStringWithoutType() should look for included string case insensitive (english commonly uses capitalized all words in names, while in other languages only the first letter of the first word in the name, to avoid "Bakery Some bakery")
• key in specialphrases should be composed of both type and subtype (to address weird current "yes" -> "Building" mapping and expand it with "building.yes" -> "Building", "office.yes"->"Office", "bridge.yes" -> "Bridge", "tunnel.yes"-> "Tunnel"), with fallback on just subtype (so we don't need to fix all specialphrase files)
• Change HashMap in SpecialPhrases from m = new HashMap<String, String>(); to m = new HashMap<String, List<String>>(); to support a variable number of aliases and use them accordingly. For the previously mentioned full text search the same specialphrases files will need to be read into different structure to provide effective reverse mapping alias -> [type.]subtype.

Opinions, objections, other ideas, better proposals?

[ruzenkadev]

What do you mean by "and use them accordingly", how will you choose wich alias to use?

[sanderd17]

• I agree with the capitalisation issue, but that's not related to this
• Take a look at this script: https://github.com/osmandapp/Osmand/blob/master/OsmAnd/scripts/generate.sh it parses the wiki pages to make those txt files. So you can include the key too if you want. I just don't immediately see how you can solve that building issue. But I don't know what you want to do exactly. OsmAnd is defining the type from the value, and those *=yes things are not indexed as far as I know.
• Changing the hashmap is indeed a trivial change, and won't break anything as the hashmap is never accessed directly outside that class.

[stefanb]

What do you mean by "and use them accordingly", how will you choose wich alias to use?

Show the first one (aliases.get(0)) unless any alias from the list of aliases is already included (case insensitively) in the name.
For backward compatibility adding to the list should be always done at the beginning aliases.add(0, alias) , so that the last mentioned alias in file will be used.