О растре в GPS (записки для памяти)

Продолжение к вот этой записи, на тему современных веяний:

  1. Современные тулзы (свежая версия map2jnx - обязательно, SAS.Planet - опционально) генерируют JNX v4, который в относительно свежих прошивках (я развлекался с 3.90) поддерживается нормально.
  2. Для свежих прошивок нужен свежий патчер. Берут отсюда.
  3. Рекомендованная в предыдущей записи jnxscale (для установки масштаба) с JNX v4 нормально не работает (получается карта, которую прибор не видит), надо пользоваться JNX Customizer (берут, как и jnxscale, с gpsunderground).

    К сожалению, JNX Customizer не правит существующий файл, а записывает новый. Т.е. быстро поправить масштаб прямо на приборе - нельзя. Неудобно, да. Еще неудобно то, что 3-значные ProductID показываются в 2-значном окошке.

  4. Многослойные и многотомные файлы, генерируемые SAS.Planet - технически работают нормально. Масштаб им тоже можно править (каждому слою отдельно), для многотомных - я правил во всех томах (поправить только в одном - не пробовал).
  5. Большие многотомные-многослойные файлы на приборе (Garmin GPSmap 62s) тормозят. Сильно тормозят. Почти такие же многотомные и однослойные - тормозят меньше. Они и рекомендуются к использованию. Естественно, им полезно ставить разные ProductID, чтобы независимо включать-выключать.
  6. Других проблем с генерацией JNX-ов SAS-планетой не обнаружено. Да, оно генерирует медленно, но стандартный путь (склейка в ecw, конвертация проекции в GlobalMapper, сохранение в GeoTiff, конверсия map2jnx) - еще гораздо медленнее.

    Ну то есть хотелось бы, конечно, ProductID для снимков ставить по своей системе, но и предлагаемый выбор 0-9 вполне удовлетворяет на практике.

  7. 32-гиговая карточка в приборе - прекрасно работает.
  8. 20 гигов карт (преимущественно снимков, конечно) - прибор медленно стартует. Может и жрет больше, не знаю.
  9. Правильный набор растров (при наличии комплектов карт):
    • Обзорный снимок (масштаба z11 или z12)
    • Набор карт от 5(10)-километровки до 500-метровки. Можно и крупнее, наверное, но на планируемый район у меня 25-тысячной нет, сказать не могу.
    • Снимки z16 или (если есть) z17, детальнее, по всей видимости, нужны редко (а места жрут мешок). Более детальные снимки - только на индивидуальные тонкие места.
  10. Если засунуть в map2jnx очень большой растр, то он делает не многотомный JNX (как SAS-Планета), а JNX с большими тайлами (512x512 в моем случае). Делает оно это НЕОБЫЧАЙНО медленно. Я ни разу не дождался, быстрее порезать этот растр на куски и сделать отдельные JNX.

Comments

> Ну то есть хотелось бы, конечно, ProductID для снимков ставить по своей системе, но и предлагаемый выбор 0-9 вполне удовлетворяет на практике. на самом деле это нифига не хорошо карты с одинаковым ProductID в менюхе находятся на одной позиции ну и соответственно разом включаются/выключаются соответственно 10 уникальных наборов карт всего, если выбирать штатные цифры НО я вот взял и просто начал вбивать в это поле свои цифирки - и оно взялось!!! так что всё путём имеем все карты уникальные, каждая на своей строчке меню буковки туда тоже записываются ;)

О блин. Поди догадайся еще.

Но меня 0-9 вполне устраивало - по единичке на уровень зума, а растр я все едино делаю map2jnx и там нумерация со 100.

И, да, все карты одного источника и одного масштаба - лежат в одной группе, мне это кажется удобным.

слил вроде как последнюю версию планеты, а такого экспорта нету. как получить??

Карты тормозят больше по причине объемов оглавлений и числа определенных структур в них, которые грузятся в память при старте.
Трансформация тайлов и чтение JPEG, которым сжат каждый из них, возложены целиком на встроенные функции процессора (это все же multimedia SoС). Конструкции формата не выглядят сильно оптимальными вообще - у того же Магеллан еще в стародавние времена образ карты включал в себя базу Raima DB, правда, когда они у себя внедряли растровые карты, тоже родили ужас в стиле JNX, складывать тайлы в базу не осилили.

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

А сам формат - прекрасный. Он простой как пробка, его легко генерировать, есть много софта, который это делает. Великолепно же. Закладывание в базу и т.п. - ускорило бы работу, но усложнило бы генерацию карт.

Поразмышляв, можно назвать еще кое-какие минусы (формата и софта, с ним работающего) - например, необходимость перегенерации всей карты, если возникла необходимость что-то поправить. Но это логично - Garmin это не для пользовательских, а для коммерческих карт разрабатывал.
А так - да, в общем, все вполне положительно.

Если вдруг слухи не дошли..
GlobalMapper 14 beta (доступный в соответствующей ветке на форуме поддержки) научился писать и читать Garmin JNX.

Ура!

А если он еще большие карты делает за приемлемое время (не так и важно - с большими тайлами или многофайловые), то вообще лафа. Потому что map2jnx конвертирует не влезающее в 50к тайлов 256х256 просто невероятно медленно. У меня ни разу не получилось дождаться :)

Пока сведений на этот предмет не имею. Вообще GM не был замечен в особенной скорости работы с тайловыми форматами - поток там один, но разработчики там крайне отзывчивые и при внятной формулировке feature request'ов есть шанс достаточно быстро получить улучшение. К слову - GM имеет для длительных операций счетчик ожидаемого времени окончания, так что просто ждать у моря погоды не придется :)

У map2jnx что-то вроде счетчика тоже есть, только толку нет - оно буквально не кончается в разумное время (проще/быстрее понаделать несколько карт из меньшего числа листов каждую).

Поскольку у меня гарминовских приемников нет, мне немного лень с этим экспериментировать (экспериментами помогал когда формат драконили), так что надежных сведений о скорости не имею. Единственное - GM все же 64-битный есть, а map2jnx вроде как нет. И в map2jnx все очень неоптимально, судя по тому, во сколько раз автору многопоточной коммерческой версии MapTiler удалось его ускорить - а потроха там все те же - GDAL.

Сейчас мечта другая - научить какой-нибудь букридер на электронных чернилах карты показывать (Leaflet/OpenLayers в browser'е с geolocation API и gps-приемник через SDIO).

Ну а у меня потребность сезонная, на большую площадь карты раньше лета не понадобятся.
Поэтому я тоже до мая пешком постою.

В общем, я все равно жду, пока выйдет 14й не beta, а там - посмотрим, на сколько он хороший.

Add new comment