Отвечу, процитировав свой старый пост в гарминовской теме:
http://forum.openstreetmap.org/viewtopic.php?pid=342499#p342499
Что мешает конвертить самому с теми конфигами, которые нравятся? Не будет никаких двойных дорог.
Ставить конвертер с нуля то ещё удовольствие:)
Но да, если у вас, Renord, всё настолько серьёзно, то это лучший выход.
Поставил.
С теми конфигами, что во установочном пакете (SVN), результат желает быть лучше 
Много объектов не обрабатывается воще (забор, ворота, мультиполигон реки ( http://www.openstreetmap.org/relation/5356411 -возможно из-за того, что он очень большой и не попадает в скачанную область целиком? ) - что пока заметил). Множество ошибок “дорога пересекает сама себя в узле”, “Дорога имеет тупик без узла” (это, например, просека http://www.openstreetmap.org/way/116925200 )
Но и дубликаты дорог там отсутствуют.
Ничего удивительного, вытаскиваются только те объекты, которые указаны в конфигах. В дефолтном наборе только некий универсальный типов объектов, поддерживаемый большинством навигационных программ. Заборы и ворота - нестандартные гарминовские типы, потому их нет.
Тут два варианта - либо дописать дефолтные конфиги (которые у вас сейчас) либо взять гарминовские (что логичнее, не находите?), перепилить файлы ways-roads-… под себя или заменить их более ранними, начала 2013 года. Конвертер тогда был тоже более ранней версии, но нынешний должен работать со старыми конфигами. Если я не прав, liosha меня поправит.
Полигон реки скорее всего неполный, потому не сконвертировался. Просто отслеживайте целостность мультиполигонов в исходном osm-файле.
На ошибки, что находит мапэдит не обращайте внимания, критичны только те, в которые утыкается cgpsmapper. Избегайте редактирования mp-файла мапэдитом, даже просто пересохранив созданный конвертером mp, рискуете словить кучу критических ошибок cgpsmapper’ом. GPSMapEdit сильно огрубляет координаты, отсюда разные самопересечения, дубликаты узлов и прочее.
Лучше всего вносить изменения не в mp, a в исходный osm-файл.
Второй вариант (тот, который “либо взять гарминовские”) гораздо более, вопрос где их взять.
Полигон реки точно неполный - Автор ухитрился протянуть его через Приморский край в Хабаровский на тысячу километров. Однако в той mp-шке, что выкладывается на гис-лаб, он отображен, хотя там обрезано по границе края. Как там сделано?
Про МапЭдит я уже сказал - необходимость заставляет прибегать к его услугам. Например, требуется отображение рельефа, который в ОСМ не поддерживается в принципе, В некоторых местах требуются данные, которые возможно получить только из недопустимых в ОСМ источников (генштабовские карты, например).
Самопересечения большей частию заложены в исходнике - типо разворотных колец: http://www.openstreetmap.org/way/229367084 , почему-то конвертором не обработано, и таких набегает много. Это точно не от МапЭдита.
Проблем от огрубления координат им я не имел (по крайней мере в массовом количестве). Они возникают в-основном при копировании - вставке объектов с разных карт - получаются нестыковки, почти незаметные, но дороги автоматом не срастаются.
Несколькими постами выше liosha давал ссылку.
Для обрезки карты по заданным границам есть ключ --bpoly. Читайте документацию на вики по osm2mp.
Вам не приходило в голову, что в большой стране каких только ошибок на карте нет, а ведь она собирается регулярно, и никто эмпешки вручную не правит.
Проблема может и не в огрублении координат (всё равно cgpsmapper расставляет все точки по той же 24-битной сетке) а в том, что мапэдит их тупо округляет, местами плодя недопустимые элементы (напр., слишком короткие дороги из одного ребра). Дело-то ваше, конечно, раз нравиться вам раз за разом делать бесполезную работу, никто вас не будет отговаривать.
Допустим, данные не чисты лицензионно, но незаменимы - ну так сливайте их с основным массивом ещё до osm2mp - второй раз вам говорю - только не заливайте их в общую базу. Насчёт рельефа, зачем его вообще каждый раз сливать с остальными данными, нужно скомпилировать для него отдельную карту, хранить её и при необходимости включать в мапсет для mapsource или прибора.
Покажите место в Приморье, где нет открытых данных, по которым можно нарисовать и добавить в osm дорогу, мне просто интересно.
Дубликаты дорог и в гарминовском mp отсутствуют, это именно вы их создаёте своими неквалифицированными действиями посредством мапэдита.
Да, некоторые дороги представлены невидимой полилинией “дорога без покрытия”, включенной в роутинг и видимой полилинией типа, поддерживающего роутинг, но не включённого в него.
Почему нельзя было сделать видимые линии нероутинговыми типами? В разных приборах дефолтный стиль дорог общего пользования очень разный, на мой взгляд, довольно удачный в большинстве случаев, и к тому же масштабируемый. Если я возьму произвольный тип линии и нарисую ему стиль, то он может соответствовать только стилю дороги на каком-то одном зуме определённого типа навигатора. Перерисовать стили всех дорог, как это сделано у Валентина или Максима - плохая идея. У них сборки под определённые типы навигаторов, у нас универсальная. В целом результат будет хуже. К тому же для десятка типов дорог придётся найти полсотни свободных типов полилиний, с ними в гармине напряг.
Почему вообще не отказаться от удвоения дорог, вернуть, как было 3 года назад? Ну тогда роутинг будет менее адекватный или же будут ситуации, когда какая-нибудь асфальтированная tertiary будет иметь на своём протяжении участки с типом “тропа” или “дорога без покрытия”, обычные же деревенские улицы все подряд будут тропами и грунтовками.
Последнее слово за Лёшей, но я лично против такой переделки.
Может вы, поковырявшись в конфигах, найдёте лучшее решение, и мы им воспользуемся.
[чуть-чуть off topic]А гарминовские векторные карты вообще как-то развиваются? Или там достигнут «предел мечтаний» по мнению экспертов? Ведь всякие выкрутасы требуются из-за несовершенства формата или ещё чего-то, я правильно понимаю?[/чуть-чуть off topic]
Гарминовские векторные карты давным-давно развились в новый, более защищённый формат. Насколько я знаю, прогресс по его вскрытию околонулевой.
А вскрытый формат, с которым все сторонние (не-гарминовские) конвертеры работают, да, так и застыл в том убогом состоянии…
Видимо я что-то не так установил? Например ворота в конфигах есть
- condition:
- barrier = gate
action:
- action: write_poi
type: 0x3315
, однако POI в mp не появляется. Хотя точка установки ворот на дороге маршрутизируется как непроезжабельная.
Точно так же есть описание забора:
- condition:
- or:
- barrier = fence|hedge
- fenced = yes
action:
- action: write_line
type: 0x010f12
name:
-не рисуется линия и всё тут. С лестницей то же самое.
Может со структурой папок чего не так, с именами файлов? Или еще чего?
Главный конфиг по-умолчанию дефолтный используется, а не гарминовский. Нужно явно указывать --config garmin-ru.cfg
Дефолтный конфиг default.cfg не знает о файлах nodes-garmin-custom-univ.yml и ways-lines-garmin-custom-univ.yml и поэтому их игнорирует, как и остальные со словом garmin в имени.
Мне кажется, это мало кому надо. Какие там преимущества? 26-битная точность координат, псевдо-3D здания и развязки, больше контактной информации у POI - как-то это неуникально. Кому это нужно - юзают что-то другое.
Меня старый гарминовский в целом формат устраивает и возможности cgpsmappera бы устраивали, если б он не сдох. Пусть бы и не развивался, но лишь бы техподдержка была и найденные баги правились.
Да, хотелось бы более гибких настроек стиля карты, как в джосме или маперитиве, но такого в гарминовском формате можно не ждать.
Вот что реально могли бы решить с кастомными стилями - масштабирование полилиний (а может и POI) с изменением зума, задаваемый порядок отрисовки полилиний. А то сейчас дороги понад усе, а остальное - хрен поймёшь как, никакой системы. Чтобы число цветов полилинии и полигона не ограничивалось двумя, а то иногда приходится вместо одного полигона рисовать два, а то и три один поверх другого. Чтобы можно было задавать обводку полигонов, аналогично линиям.
Ну так… Предупреждать же надо было!!!
Всё заработало. Теперь буду пробовать разбираться дальше.
…действительно, “удовольствие то ещё”… Три попытки установки разных версий PERLа - пока получилась работающая. Потом экспериментальный подбор размера скачиваемой области, не приводящий к out of memory, Установка PITHON для реализации докачки недоскачанных мультиполигонов. Собственно разбирательство с устройством конфигов…
Но теперь имею хотя бы общее представление как это работает.
Попутно выяснилось, что наравне с “natural”,“landuse” и “waterway” недокачанным может оказаться и например полигон “place = city” - а это еще хуже: не поддается докачке скриптом, так как не мульти, а без него поломается очень много чего, завязанного на “condition: inside_city” - например, лестница за городом маршрутизируется, а в городе - нет (так и не понял зачем так сделано).
Да и собственно в данном случае докачка , как я понимаю, не помогла бы - это было бы “махать руками после драки”, то есть пристроить полигон туда, где уже все посчитано без его участия.
Как сделано дублирование дорог разобрался, но необходимость в этом понять так и не могу.
Проблема невидимости какого-либо типа прекрасно решается TYP-файлом, тем более что практически всегда он с картой применяется. А иначе даже зданий не видно.
Можно принять это как попытку разрешить заложенное в OSM противоречие между ролью дороги (primary, secondary…) и ее физическим состоянием (шоссе, грунтовка…) - то есть, изображать согласно роли, но маршрутизировать согласно состоянию. Ну не знаю…
Насчет автоматической постройки графа в МапЭдите - соглашаюсь, что это плохая идея. Можно получить множество неожиданностей, и даже не узнать об них.
Вот.
Надо вам было новое сообщение создавать, а не редактировать предыдущее. Я сразу и не увидел.
Недокачанный полигон place - это странно. Если вы вырезаете .osm точно по границам, таких быть вовсе не должно. Если с запасом - ну да и пусть, они всё за пределами целевой территории.
Пеший и вело-роутинг внутри нп убит по двум причинам: 1) из-за кучи тротуаров вдоль дорог плохо джипиэсмапперу (много близких узлов) и вообще из-за обилия пешеходных дорожек и троп пухнет дорожный граф, ограничивая тем самым размеры покрытой одной картой области; 2) велика вероятность, что гармин заведёт в определённых обстоятельствах на тротуар или лестницу автомобиль, даже если на этих отрезках имеются все ограничения. Как я говорю по этому поводу, в гарминовском роутинге есть правило: “если нельзя, но очень хочется, то можно”
В альтернативных сборках эти проблемы не так критичны. Сборка осуществляется программой mkgmap, а целевая аудитория - туристы и велосипедисты.
Про двойные линии дорог - гадать тут нечего, я уже всё подробно описал, повторяться не хочу. Если считаете, что есть решение лучше - предлагайте что-то конкретное, желательно, подкрепляя предложение исправленным кодом.
Если выкачать квадрат, из которого потом можно было бы вырезать например Хабаровский край по границе - у меня гарантированно получается out of memory при дальнейшей обработке (не супер же компъютер ).
А при более мелких квадратах запросто может отрезаться кусок города (цепочка квадратиков вдоль Амура от Хабаровска через Комсомольск до Николаевска). Ну следить, конечно, надо…
Понятно, но режьте же по границам районов, у нас многие регионы и страны так и собираются.
Я скачал сегодня osm2mp (https://code.google.com/archive/p/osm2mp/source/default/source). Запустил с параметром --config=c:\Perl\site\osm2mp\cfg-navitel\navitel-ru.cfg
Программа ругается:
Loading configuration…
YAML Error: Stream does not end with newline character
Методом тыка выяснил, что в файл \osm2mp\cfg-navitel\polish-mp\nodes-navitel.yml нужно добавить пустую строчку в конце файла.
И ещё вопрос:
В программе упоминается список типов данных garmin-custom. Я так понял, что это дополнение к стандартному тайпсету Гармина. Где взять его описание?