Почему решил что она как-то привязалась, а не просто имеет одинаковые символы ?
Я говорю о том что в пределах одного города локализацированное название слов/символов из addr:street будет таким же как и локализированное название name.
И не нужно дублировать эти переводы по всем сущностям.
Ладно еще в отношениях, их немного.
Но создавать addr:street:, addr:suburb: на каждом доме - это излишество, которого можно избежать, которое полезно только для osm2mp.
Да, его можно избежать с помощью отношения street.
Не, ну ёлки-палки. Мы тут напрягаемся, специально пишем русскоязычные названия улиц в name:ru, а Лёша тут транскрипцию выдумывает.
лЭрмонтов, блин. 
Ну на то она и транскрипция 
Гугл-транслейт может лучше
ЗЫ
Повторяю, явно локализованные названия используются в первую очередь.
В таком виде это выглядит, безусловно, логично, но абсолютно не проясняет существо “хитрых способов”.
Там был еще один существенный вопрос:
И именно то него зависит множество вариантов осуществления “хитрого способа” (слово “множество” употреблено в математическом смысле).
Мне, кстати, сейчас пришли в голову некоторые идеи по сочетанию этих двух подходов.
И не должно. Хитрый способ может быть каким угодно
Честно говоря, не понимаю, на что это влияет.
Но вообще “тег” и “атрибут” - это практически синонимы
В подавляющем большинстве случаев так оно и есть.
Но не в случае частей улиц.
Если два пути (way) имеют общую точку и одинаковое название на одном из языков, совершенно не нужно релейшна, чтобы понять, что они являются частями одной сущности.
Данные должны быть заданы, а не угаданы. Даже если угадывать их несложно
Так считают люди, не имеющие опыта обработки текстовой информации.
Не все, что логично выглядит на бытовом уровне, является алгоритмически работоспособным, а тем более - надежным.
Так что привязка дома к улице по названию - наглядна, но со всех остальных точек зрения - просто чудовищна.
Ну, последняя фраза многое проясняет.
По поводу различия подходов, я уже приводил примеры:
- “Красная площадь” - пример того, что разные объекты могут на одном языке иметь идентичные наименования, а на другом - различные.
- Связывание частей одной улицы по двум признакам: общей точке и совпадающему названию.
Если исходить из “атрибут объекта”, то в первом случае брать название из другого объекта нельзя, а если из “самостоятельная сущность” - можно.
Во втором также используется “атрибут объекта”, чтобы перенести название с одной части объекта на другую.
Возможен и альтернативный подход: по ВСЕМ имеющимся данным составляется словарь соответствий и все недостающее восполняется по этому словарю. При этом у нас возможны ложные “попадания”, но зато если название улицы переведено хоть в одном города, то этот перевод появится и во всех остальных. Правда, возникает проблема неоднозначности данных: что делать, если названию на одном языке соответствует несколько - на другом. Т.е. что выбирать “Red” или “Krasnaya” для “Square”.
В принципе, мне представляется целесообразным использовать эти подходы с приоритетом: сначала делается попытка найти другие части объекта и “поживиться” у них, а в случае неудачи - обратиться к общему “словарю” соответствий. Но и в этом случае остается вопрос: что делать, если у того, что тем или иным способом идентифицируется как один объект, имеется неоднозначность.
Например, есть 3 части улицы (как мы идентифицировали ее как одну улицу - не важно): одна подписана одним именем, другая - другим, а третья - не подписана. Откуда брать имя для третьей части?
Что должно быть в идеале - понятно (тоже, кстати, слишком оптимистичное заявление: у разнгых людей разные представления, как должно быть).
По крайней мере, при всем разнообразии мнений, с тем, что ошибок не должно быть, согласятся все. (хотя не все сойдутся в том, что именно считать ошибкой, а что - правильным вариантом)
У нас есть реальная база, далеко не свободная от ошибок. И одна из основных - неполнота информации. Еще у базы есть такая вещь как избыточность, которая позволяет обнаружить и исправить часть ошибок.
Вот этому, насколько я понимаю, и посвящено настоящее обсуждение: что делать, когда все интересующие объекты имеют все нужные теги на требуемом языке - понятно. Обсуждать имеет смысл лишь способы “вытаскивания” информации, которой нет на поверхности.
Но при этом, разумеется, нельзя заюбывать о таком качестве алгоритма восстановления информации как надежность и минимальное количество ложных срабатываний (ошибочного приписывания названия).
Вот моё мнение как раз противоположное: не надо ничего “вытаскивать”, если оно не задано явно.
А обсуждать нужно не способы “вытаскивания” того, чего нет, а способы описания этих сведений с минимальными затратами и без раскорячивания данных.
В принципе позиция понятна и логична, но она не совпадает с озвученной ранее:
Так что если обсуждение “хитрых способов” нас не интересует, о чем вообще речь?
Работать все равно придется с той базой, что есть, а не с той, какую хотелось бы иметь.
Про “хитрые способы” речь шла не про поиск значений, которые не заданы, а про локализацию заданных значений.
liosha Уже же были реализованы шаблоны из GME для транслитерации. Или задумано что то более оригинальное?
Эти шаблоны сейчас применяются на вообще все надписи, а новые задаются для конкретных языков.
И кстати да, шаблоны надо бы тоже туда перенести.
Вообще-то это совершенно другая задача.
В частности, перенос названия с отношения на путь, входящий в это отношение, но не имеющий собственного названия, локализацией не является.
Ну я и говорю, что это совершенно другая задача 
В качестве ещё одного proof-of-concept сделал плагин для яндекс.переводчика
Пока без внешнего кеша, так что запускать можно только на небольших данных!
Посмотреть список доступных языков:
./osm2mp.pl --lt-dump
Попробовать:
./osm2mp.pl --lt-priority yatr_ru_uk=10 --default-lang=ru --target-lang=uk small_msk.osm -o xx.mp
UPD
Привинтил внешний кеш через DB_File.
Судя по TOS, подаствсуд начинается после 10000 запросов в сутки, так что в принципе можно пользоваться.