Mkgmap

Сокращения нужны только для повышения читабельности надписей на экранах с невысоким разрешением. Для целей организации поиска нужно просто наладить разделение слов в названиях (компиляция с ключем –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] 

Доброго всем дня.
Пытаюсь создать этот файл по описанию, но выдает ошибку что не может скачать bounds.zip и sea.zip.
Подскажите так же если мне нужна объединенная карта Могилёвской области и Смоленской области то мне нужно скачивать карту России и Беларусь или карту всего мира.

Этот инструмент сейчас не работает, есть ли альтернатива?