Mkgmap

Буквально только что наконец-то одержал маленькую победу над этой программулиной, разобравшись, как добиться русских символов, которые она никак не хотела отображать при преобразовании mp->img.

При этом преобразование osm->img замечательно работает. После некоторых экспериментов дело оказалось в том, что mkgmap ожидает увидеть в файлах данных UTF-8, как в файлах *.osm . Файлы же *.mp обычно идут в виндовой кодировке 1251, с отметкой об этом в заголовке CodePage=1251. Ходил вокруг да около этих кодировок, но получалась фигня. Codepage=UTF-8 или utf8 не берет, хочет число. Нагуглил cp65001, попробовал в винде - да, оно. Codepage=65001, как оказалось, тоже mkgmap’у не нравится.

В общем, решение такое: перекодируем файл mp в UTF-8 и комментируем внутри строку с codepage. Решение обходное, временное, но рабочее.

А зачем вообще эти mp нужны?

А затем, что osm2mp выдаёт заметно лучший результат, но в mp, который ещё после этого надо компилить дальше. Я хочу попробовать заменить на этом этапе cgpsmapper на mkgmap.

gps-Max, можно использовать osm2mp --nocodepage, тогда в .mp будет utf-8

Т.е. osm->mp->img получается лучше osm->img? Чем лучше?

Первое лучше лишь тем, что уже реализовано :slight_smile:

osm2mp лучше тем, что хорошо учитывает все актуальные особенности OSM и имеет быстрореагирующего автора

А, всмысле osm->mp не mkgmap’ом. Понял.

CodePage=utf8, как писал выше, вызывает ругательства:

java.nio.charset.UnsupportedCharsetException: cputf8
at java.nio.charset.Charset.forName(Unknown Source)
at uk.me.parabola.mkgmap.reader.polish.PolishMapDataSource.imgId(PolishM
apDataSource.java:623)

А так, да, всё круто, результирующий файлик вроде переваривается, несмотря на мои опасения по поводу заголовков. Там name остается в 1251, но это вроде пофиг. Спасибо за подсказку :slight_smile:

Интересное дело, mkgmap Московскую область целиком в *.osm не прожевывает, а в *.mp - вполне даже. Размеры исходных файлов разные - osm около 450 мегов, а mp около 100, видимо, из-за этого.

С измененным TreSize на старом девайсе крутится довольно шустро в итоге, а внешний вид пока на глаз особо не отличается.

Забавно, если заглянуть в конфиги (которые стили), то можно увидеть кучу всего интересного. Вот, например, аналогичная здешней борьба за unpaved:


# Flag unpaved roads.
highway=*
& (surface=cobblestone | surface=compacted | surface=dirt |
   surface=earth | surface=grass | surface=grass_paver |
   surface=gravel | surface=grit | surface=ground | surface=mud |
   surface=pebblestone | surface=sand | surface=unpaved |
   mtb:scale=* |
   tracktype ~ 'grade[2-6]' |
   smoothness ~ '.*(bad|horrible|impassable)' |
   sac_scale ~ '.*(mountain|alpine)_hiking' |
   sport=via_ferrata)
{ add mkgmap:unpaved=1 }
(highway=bridleway | highway=path | highway=track | highway=unsurfaced)
& surface!=* & tracktype!=* & smoothness!=* & sac_scale!=*
{ add mkgmap:unpaved=1 }

Пользую mkgmap для себя почти с того момента, как начал рисовать в osm. Поделюсь своими наработками. Во-первых, чтобы переваривал, нужно всегда использовать splitter.

Вот выдержки из Makefile:


STYLE?=         Ru4x4Traveller

RUSSIA?=        rus.osm
GISLAB?=        http://gis-lab.info/data/osm/russia

NORWAY?=        norway.osm
FINLAND?=       finland.osm
SWEDEN?=        sweden.osm
GEOFAB?=        http://download.geofabrik.de/osm/europe/

#
MKGMAP?=        /usr/local/bin/java -Xmx1024m -jar /home/glebius/bin/mkgmap.jar
SPLITTER?=      /usr/local/bin/java -Xmx1024m -jar /home/glebius/bin/splitter.jar
OSMOSIS?=       /usr/local/bin/java -jar /home/glebius/bin/osmosis.jar
FETCH?=         /usr/bin/fetch
RM?=            /bin/rm -f --
MV?=            /bin/mv --
CP?=            /bin/cp --
UNZIP?=         /usr/bin/bunzip2
XAPIURL?=       http://www.informationfreeway.org/api/0.5

# new mkgmap not thread safe
#JOBS!= sysctl -n kern.smp.cpus  
JOBS=   1

fetch-bbox:
        ${FETCH} -o ${BBOX}.osm ${XAPIURL}/map?bbox=${BBOX}

fetch-russia:
.if exists(${RUSSIA}.bz2)
        ${FETCH} -i ${RUSSIA}.bz2 ${GISLAB}/${RUSSIA}.bz2
.else
        ${FETCH} ${GISLAB}/${RUSSIA}.bz2
.endif
        
fetch-scandinavia:
.if exists(${NORWAY}.bz2)
        ${FETCH} -i ${NORWAY}.bz2 ${GEOFAB}/${NORWAY}.bz2
.else
        ${FETCH} ${GEOFAB}/${NORWAY}.bz2
.endif
.if exists(${FINLAND}.bz2)
        ${FETCH} -i ${FINLAND}.bz2 ${GEOFAB}/${FINLAND}.bz2
.else
        ${FETCH} ${GEOFAB}/${FINLAND}.bz2
.endif
.if exists(${SWEDEN}.bz2)
        ${FETCH} -i ${SWEDEN}.bz2 ${GEOFAB}/${SWEDEN}.bz2
.else
        ${FETCH} ${GEOFAB}/${SWEDEN}.bz2
.endif
.endif
        ${UNZIP} ${NORWAY}.bz2
        ${UNZIP} ${FINLAND}.bz2
        ${UNZIP} ${SWEDEN}.bz2

split-russia:
        ${RM} 6324*.osm.gz
        ${SPLITTER} --description=${STYLE} ${RUSSIA}.bz2

russia: clean clean-russia
        ${MKGMAP} --max-jobs=${JOBS} \
                --route --net --remove-short-arcs \
                --description='Ru4x4' --country-name='Russia' \
                --country-abbr=RU \
                --charset=cp1251 --code-page=1251 --family-id=90 \
                --style-file=. --style=${STYLE} \
                6324*.osm.gz \
                ${STYLE}/STYLE.TYP
        ${MV} *.img *.tdb Russia/
        ${CP} ${STYLE}/STYLE.TYP Russia/
 
clean-russia:
        ${RM} Russia/*
 
clean:
        ${RM} *.img *.tdb

distclean: clean
        ${RM} *.osm
        ${RM} *.osm.gz
        ${RM} *.osm.bz2
        ${RM} areas.list template.args

То есть когда хочу сгенерировать, то пишу:

make distclean fetch-russia split-russia russia

Стилем особо хвастаться не могу, т.к. никак не могу достичь идеального баланса уровней. Чтобы и на больших масштабах не тормозила, и чтобы на средних было достаточно объектов видно. Хотелось бы посмотреть на чей-то стиль, у кого хорошо проработаны levels/resolution.

Из-за ограниченности типов в гармин, решил попробовать вписывать покрытие в имя дороги, оказалось удобно:


# 2) грейдер
highway=primary & surface=compacted
        { name 'пЁя─п╣п╧п╢п╣я─' }
        [0x12 road_class=1 road_speed=2 resolution 6]
highway=secondary & surface=compacted
        { name 'пЁя─п╣п╧п╢п╣я─' }
        [0x12 road_class=1 road_speed=2 resolution 8]
highway=tertiary & surface=compacted
        { name 'пЁя─п╣п╧п╢п╣я─' }
        [0x13 road_class=1 road_speed=2 resolution 16]
highway=unclassified & surface=compacted
        { name 'пЁя─п╣п╧п╢п╣я─' }
        [0x13 road_class=1 road_speed=2 resolution 19]
# 3) гравийка
highway=primary & surface=gravel
        { name 'пЁя─п╟п╡п╦п╧п╨п╟' }
        [0x12 road_class=1 road_speed=2 resolution 6]
highway=secondary & surface=gravel
        { name 'пЁя─п╟п╡п╦п╧п╨п╟' }
        [0x12 road_class=1 road_speed=2 resolution 8]
highway=tertiary & surface=gravel
        { name 'пЁя─п╟п╡п╦п╧п╨п╟' }
        [0x13 road_class=1 road_speed=2 resolution 16]
highway=unclassified & surface=gravel
        { name 'пЁя─п╟п╡п╦п╧п╨п╟' }
        [0x13 road_class=1 road_speed=2 resolution 19]
# 4) бетонка
highway=primary & surface=concrete
        { name 'п╠п╣я┌п╬п╫п╨п╟' }
        [0x12 road_class=1 road_speed=2 resolution 6]
highway=secondary & surface=concrete
        { name 'п╠п╣я┌п╬п╫п╨п╟' }
        [0x12 road_class=1 road_speed=2 resolution 8]
highway=tertiary & surface=concrete
        { name 'п╠п╣я┌п╬п╫п╨п╟' }
        [0x13 road_class=1 road_speed=2 resolution 16]
highway=unclassified & surface=concrete
        { name 'п╠п╣я┌п╬п╫п╨п╟' }
        [0x13 road_class=1 road_speed=2 resolution 19]

Типичный программистский баг: взял номер кодировки из параметра, приклеил спереди ‘cp’ и попытался результат использовать :slight_smile:
Пинайте автора :slight_smile:

Это нестрашный баг, легко обходится. Однако юникодная cp65001 тоже не работает, это хуже.

Первое: интересно, зачем и откуда такая извращённая кодировка?
Второе: не понимаю смысла замены имени, а не добавления уточнения к нему. Конструкция типа { name ‘${name} (грунтовка)’} вполне работает и встречается где-то в дефолтах.

Пока что в mkgmap выявились следующие отличия, по сравнению с osm2mp:

  • Нет возможности сформировать точку из полигона
  • Похоже, нет поддержки адресации точек
  • Нет некоторых дополнительных условий типа inside_city
  • Чуть менее тонкие настройки роутинга
  • Объекты можно привязать как к уровню карты (level=[0…8]), так и к уровню прибора (resolution=[~10…24]).

А так, по большому счёту, всё то же самое, только занимаемая при работе память раза в три меньше и время выполнения раз в двадцать быстрее.

Про роутинг пока можно сказать, что он, по крайней мере, работает.

Отдельно нужно сказать про очень сильную генерализацию линий mkgmap’ом на средних уровнях. В крайних масштабах всё нормально, а в средних заметны большие ступеньки. Причём, это не зависит от входных данных и не регулируется параметрами.

Вообще-то это одно и то же, только разными словами. Или я что-то не понимаю

Долго не знал, чего написать, очень уж ты вопрос хороший поднял. Я уже более полугода экспериментирую с настройками уровней, пытаясь найти баланс, однако проблема в том, что он будет разным для разных ситуаций.

В идеале, хотелось бы иметь отключаемые слои, чтобы быстро убрать ненужное и сосредоточиться на нужном типе объектов. Однако, в гармине такого даже близко нет, увы. На данный момент наиболее интересная мысль - это точки убирать в отдельные дополнительные карты, которые можно включать/выключать в навигаторе. Кстати, файлы gpi для этого хуже - их нельзя отключать, в отличие от прозрачных карт с точками.

Level - категория карты, а resolution - категория железки. Если в заголовке карты поменять настройки levels, то придётся везде по конфигам править/подгонять значения. Если же привязать объекты к resolution, то число и разрешение уровней карты можно менять без последствий. Очень удобно для экспериментов, да и вообще полезно.