Валентин, я тебе присылал файл status, обрати внимание, что для рабочего поиска сокращение “ул.” вместо “улица” нужно делать в ТРЕХ местах: 1. highway=* & name 2. addr:street 3. mkgmap:street
То есть “Имя улицы” должно до буквенно совпадать с addr:street указанной на доме и совпадать в момент производства карты с внутренней переменной mkgmap:street при создании индекса.
А иначе поиск работать не будет. Пример твоя уже вчерашняя карта: город Нарва, улица Александра Пушкина, дом 17 на твоей карте не ищется, потому что, в тегах имени улицы есть name:ru=улица Александра Пушкина, а в тегах дома 17 прописано addr:street=Aleksander Puškini, возможно пример не корректный так как в тегах дома 17 прописано еще addr:city=Narva, но поверь, что даже без тега addr:city=Narva поиск все равно работать не будет, так как name:ru и addr:street не совпадают.
Теперь разложим твою строку: Если страна Россия и внутренняя переменная mkgmap:street ничему не равна и highway любой, то установить addr:street=‘без названия’. И сразу вопрос, а куда или кому/чему установить addr:street=‘без названия’.
Ведь нам надо чтобы этот тег был установлен на здании, а highway в данном населенном пункте получил имя ‘без названия’ иначе совпадения не будет и поиск не сработает.
https://www.openstreetmap.org/query?lat=56.36886&lon=38.14211 вот тут хоть и стоит тег на здании addr:place=Скоропусковский и вроде можно его скопировать в addr:street=Скоропусковский, но как проездам, улицам и дорогам прописать name=Скоропусковский я не знаю, мой стиль подставляет не всем этим проездам и т.д. только в этом нас. пункте имя улицы А-108 и поиск работает по ней. Скоропусковский, А-108, дом 2, 3, 6 только три дома. Но это в этом, а в других? Позже проверю как на туристическом приборе, а на Nuvi из этой ситуации выхожу просто: Искать адрес → Город → Прибор просит ввести улицу, а ничего не ввожу и нажимаю “Готово” → получаю список улиц в этом населенном пункте (даже притянутые) Выбираю → Просит ввести №дома, опять готово и выбираю из того что есть (Но не все дома получают притянутый адрес), да и хочется решить эту проблему тоже.
Сокращения нужны только для повышения читабельности надписей на экранах с невысоким разрешением. Для целей организации поиска нужно просто наладить разделение слов в названиях (компиляция с ключем –split-name-index) и отделение их от префиксов и суффиксов (улица, бульвар, шоссе и др.). Для этого в конфигах есть специальный файл, где оно настраивается - roadNameConfig.txt
# russian
prefix1:ru = "улица", "переулок", "проспект", "проезд", "разъезд", "тракт", "площадь", "бульвар", "шоссе", "дорога", "тупик", "микрорайон", "аллея", "линия", "набережная"
prefix2:ru = "им.", "имени"
suffix:ru = "улица", "переулок", "проспект", "проезд", "разъезд", "тракт", "площадь", "бульвар", "шоссе", "дорога", "тупик", "микрорайон", "аллея", "линия", "набережная"
lang:RUS = ru
Ну хоть через 4 месяца ответил, спасибо.
Сокращения я использую на туристических приборах как ты и говоришь для повышения читабельности. Пользователи автомобильных приборов попросили без сокращений, так как злая тетка плохо понимает сокращения и получается забавное произношение улиц. А перенос префиксов в конец имени (то есть делая из них суффиксы) я делал что бы получить однообразие отображения улиц при поиске. Все это я делал до введения в mkgmap функции roadNameConfig.
Два дня бился с проблемой. Оказывается TYPViewer работая под Windows 10 портит тхт-файл исходника, сволочь! Причем как изощренно это происходит - он перемешивает картинки POI с кодом какой-нибудь другой. В итоге смотришь на карту и офигеваешь, не понимая, что происходит. И никак это побороть не получилось. 
В итоге вернул обратно старый SSD с Windows 7 и все опять нормально заработало. Ахренеть.
Так. Вроде начинает все немного проясняться.
Сегодня вернулся к разбору описанной выше проблемы более подробно. TYPViewer под Windows 7 сохраняет коды точек в таком виде:
[_point]
Type=0x11711
А вот в Windows 10 ровно тот же TYPViewer уже пишет вот так:
Type=0x117
SubType=0x11
И это Mkgmap уже отказывается корректно транслировать. Если открыть готовый TYP-файл, то мы увидим следующее:
Type=0x001
SubType=0x11
При этом коды линий и полигонов остаются в прежнем виде, когда одной строчкой описывается и тип, и подтип. Корежит только блок с точками. Завтра попробую связаться с разработчиком TYPViewer.
Такие дела… 
Победил, блин. Бессмысленно и беспощадно “с умом” потрачена куча времени. Кто бы мог подумать, что сие находится в настройках самого TYPViewer. 
А у меня давно оказывается так, только вместо французского - русский
Немного иначе, но получилось!
Для того, что бы заработала эта логика нужно ввести свою собственную переменную при компиляции карты. В моем случае она выглядит так:
--style-option=code-page=1250
или
--style-option=code-page=1251
И вот тогда уже можно сделать переключение разных настроек в зависимости от языка:
if (mkgmap:option:code-page=1251) then
include "inc/name-ru";
end
if (mkgmap:option:code-page=1250) then
include "inc/name-en";
end
Я вынес в отдельные файлы все, что касается переводов и имен по умолчанию.
Единственный момент - при внедрении такого переключения в файл настроек линий, при компиляции все они просто пропадали. Природа этого явления мне пока не понятна. Так что пришлось сделать два логических блока if-then внутри файла lines отвечающих за языковое разделение, без ссылки на внешние файлы.
Прорыв года, практически, блин. Я нашел способ, как отображать в моем ущербном Nuvi-1490 некоторые важные точки! Например светофоры и броды. До этого я безуспешно пытался подобрать какой-то из пригодных для этого типов poi но без особых результатов. И вот я-таки нащупал логику. Смысл в том, что у точки должно быть имя. И только с ним навигатор считает нужным такую точку показать на экране. Пускай в typ-файле отображение названия отключено, но в данных оно быть должно. В своем файле настроек русскоязычных названий я это сделал вот так:
(highway=traffic_signals | crossing=traffic_signals) & name!=* {set name='светофор'}
(highway=ford | ford=yes) & name!=* {set name='брод'}
Но еще есть Nuvi-2797LMT, который точки показывает вообще от балды, по-моему. Как к его логике найти подход, вот вопрос.
Такая же логика и у моего Garmin-Asus M10e. Также при конвертации пришлось давать имена многим объектам и отключать отображение в typ-файле :).
Граждане. А как обрабатывать значение у ключа, которое содержит в себе точку с запятой?
Пример:
whitewater=put_in;egress
; - перечисление
т.е whitewater=put_in;egress равноцено одновременному присутствию на объекте и whitewater=put_in и whitewater=egress
Нет. И Overpass это недвусмысленно подтверждает.
; - перечисление
Но оно не приветствуется и не всеми и не везде поддерживается.
Это я знаю, но хотелось бы придумать способ прикладного применения в случае обсуждаемого конвертера.
не мапьте под рендер. автор оверпаса мог вполне решить что не будет поддерживать “;” 
но применения в данном случае такое, что на объекте два тега, как я и написал.
Как раз все строго наоборот: whitewater=put_in;egress находится. А вот whitewater=put_in & whitewater=egress - нет. Что вовсе не удивительно по причине отсутствия такой связки тегов в базе, ибо нет технической возможности иметь на одном объекте два ключа с одинаковым названием.
значит я вас не правильно понял.
потому и ввели перечисление. к примеру в shop очень часто попадаются.
Получилось через применение регулярного выражения.
whitewater ~ 'put_in\p{Punct}egress' [0x6516 resolution 24]
Умные люди подсказали еще боле простое и изящное решение - просто забрать значение ключа в одинарные кавычки. 
whitewater='put_in;egress' [0x6516 resolution 24]