Конвертер OSM -> MP

Конечный конвертер похоже понимает оба формата. Адреса на первый взгляд не теряются. Вес конечного файла практически не отличается. Спасибо, суть понятна.

Подскажите ещё по какому принципу объекты слоями ложатся. Кто выше, кто ниже (не уровни масштабирования). Берем нулевой уровень детализации в нем два разных полигона в одних координатах. Условно газон и спортивная площадка. Кто то оказывается выше, кто то под ним - ниже. Закономерности уследить не удается.
От чего это зависит? Может быть от последовательности конвертации - типа кто первый тот ниже, кто последний ложится выше. В том же GPSMapEdit отображение по какому признаку распределяет объекты? И как то не получается поменять местами - вынуть на верх, опустить вниз.
Другими словами есть *.mp файл. Что в файле отвечает за позицию практически одинаковых полигонов (это не мост и не платформа подземного метро - обычные поверхностные объекты).
Не уверен понятно ли изложил, думаю понять суть можно. :slight_smile: Спасибо.

Каждая программа навигации сама отвечает за расположение полигонов. Например, в гармин все определяется typ-файлом, где заданы приоритеты для каждого типа данных. В “7 дорог” приоритет отображения зависит от размера полигона.

Теплилась надежда услышать другое. Хотя иного быть не может. Спасибо.

Всем привет!
Кто скажет в чём проблема?
Не могу собрать одну область (пока все остальные собираются без проблем).
Что это означает и что делать?

Объясните пожалуйста, что происходит при добавлении этих опций в строку запуска osm2mp?

Спасибо.

Ну, наверное, нужно заглянуть в osm2mp.pl и посмотреть что в строке 535 делается.

Как это понял я. Программа понимает что в name используется язык указанный в --default-lang=, так же старается везде использовать значения из name:en для значения ключа–target-lang=en. Если следом указать ключ для Я. Переводчика то буде переводить с одного языка на другой. Но это в теории, на практике всё несколько иначе.

А как на практике? :slight_smile:
Попробовал с вместе с --lt-yatr-key=…, выдает ошибку

malformed JSON string, neither array, object, number, string or atom, at character offset 0 (before "(end of string)") at LangTransform/YaTranslate.pm line 68.

и похоже ничего не переводит…

пример рабочих ключей для yatr

-tl=en -dl=uk --lt-yatr-key=@/path/yatr.key --lt-yatr-cache-dir /path/cache/yatr --lt-priority yatr_ru_en=3 --lt-priority yatr_uk_en=2 --codepage=1252 --textfilter Unidecode 

Спасибо. Еще бы для каждого ключа объяснение - было бы совсем чудесно.

В 2017 году была похожая ситуация - https://forum.openstreetmap.org/viewtopic.php?pid=650811#p650811
Ошибка то появлялась, то исчезала - в зависимости от порядка написания ключей.
Параллельно выяснилось - перевода нет ни на одном устройстве (с разными ОС). Что и подвигло написать в Яндекс. Они что то сделали и перевод восстановился - https://forum.openstreetmap.org/viewtopic.php?pid=651603#p651603

Рабочий вариант ключей:

# desired map language  
target_lang: ru

# source language for default tags
default_lang: ka
--lt-yatr-key @мой.key --lt-yatr-cache-dir osm2mp/cachedir --lt-priority yatr_ka_ru=4 --lt-priority yatr_en_ru=3 

т.е. сначала ищется name:ru, если нет - name:ka и переводится на русский, если нет - name:en и переводится, дальше как масть ляжет - скажем name:de. Последний в приоритете по практике оказывается чистый ‘name’.

 --target-lang             desired map language                      
 --default-lang            source language for default tags          

 --lt-priority <id>=<val>  set tranformer priority                   
 --lt-yatr-key <key>       api key or @keyfile                       
 --lt-yatr-cache-dir <dir> directory to store cache                  

Спасибо всем, буду пробовать.

А подскажите пожалуйста, как сделать так, чтобы числа не расписывались словами? А то так получается:

; NodeID = 996081360
; natural = peak
[POI]
Data0=(43.1383648,42.6790505)
EndLevel=1
Type=0x6616
Label=Чатынтау~(Четыре тысячи четыреста одиннадцать)
[END]

К названию прилепляется высота (ele) - а переводчик ее расписывает… Это лишнее.

И еще иногда появляются такие строчки в логе:

All cache engines failed; data will not be saved! at LangTransform/YaTranslate.pm line 175.

Хотя папка кеша задана, но в ней ничего не появляется…

А еще выяснилось, что addr:housnumber Я.переводчик тоже расписывает словами. такая фигня получается…

Я было начал править словарь переводчика. Фиг вам. Не правится.
Остаётся только у себя на ПК править непосредственно фай базы данных *.sqlite той или иной пары языков. Но это не подъёмный труд. Стоит оно того или нет решает каждый сам. По крайней мере номера от 1 до ххх наверное можно.
Ещё можно в Exsel создать простую последовательность чисел в столбик. Скопировать во второй столбик. И импортировать в базу sqlite. На первый взгляд должно получиться. Но придется искать все числовые ранее внесенные пары и удалять. Тоже можно наверное автоматизировать по фильтру. Однако телефонные номера - это цифры в разнобой. Так что будет трудно.
Можно экспортировать имеющуюся базу в Exsel. Отсортировать цифровые данные. Во второй столбик скопировать первый, заменив тем самым в столбце перевода буквы на цифры. И обратным движением импортировать данные в базу.

Как вам такая перспектива. :slight_smile: Я пока не сподвигся. Так по чуть чуть правлю когда замечания получаю и не более того.

Да, пока вы не начали и база пустая, можно импортировать цифры из Exsel. А потом уже начать использовать. Переведенные ручным образом цифры останутся цифрами. В остальном база начнет наполняться. Сначала перевод берется из базы, и только если такого перевода нет, то в переводчике. Можно вообще создать свою базу. Или оставить карту на арабском! :smiley:

Я состроил такую строку:

и после использования у меня нет .sqlite.
Я сделал что-то не так?
И кстати, это что, у всех кто пользуется я.переводчиком, числа расписываются словами? и я первый кто на это обратил внимание?

–lt-yatr-cache-dir=yatr - дерриктория где следует искать sqlite. Возможно вы не корректно прописали путь и тогда файлы базы пишутся в корень папки osm2mp (не помню точно).

  1. Возможно у вас не работает накопление базы - так как путь прописан не корректно.
  2. Но скорее всего вы не установили модуль (драйвер) для базы данных sqlite3 - в разных ОС несколько разные по названию libdbd-sqlite3-perl (скажем как то так).
  3. По этой причине у вас непременно идет перерасход бесплатного трафика переводчика - и перевод быстро отключается до следующих суток. На следующий день восстанавливается, но не на долго. По мере накопления базы запросов на перевод должно становиться всё меньше и меньше. И со временем дневного трафика становится вполне достаточно. А пока вы можете попасть и под отключение от переводчика за выработкой даже лимита месячного.
  4. Проблемы с цифрами обсуждались и в этой теме. Просто надо поискать.