создание карт для Magellan Triton

Могу (хочу) написать расширенный FAQ по созданию карт Тритон/Эксплорист от "0".
Надеюсь, Муза соизволит почтить меня своим вниманием после НГ.

_________________
Штурман, нада дёрнуть!

Да, переименовать.
Проще взять готовые карты у Paganel, тогда при распаковке имена не будут совпадать. Раскладывать по разным папкам необходимо исключительно ради сохранности rmp.ini, чтобы скопировать список из каждого в итоговый rmp.ini
При упаковке программа затребует BMP2BIT.ICS BMP4BIT.ICS, можно переименовать chunk.ics 2 раза, работает.
Кстати, для Тритона я так большие карты не создавал, только для Эксплориста, смогу проверить на Тритоне завтра-послезавтра.
Может подождёте инструкцию? А то скомкано получается, больше вопросов, чем ответов.

_________________
Штурман, нада дёрнуть!

О!.. За инструкцию буду очень благодарен! Думаю, не только я. Чтобы переключить одну карту, ставить-снимать 40 галочек очень скучно... А какой-то ощутимой разницы в энергопотреблении и качестве работы в зависимости от объёма подключенных карт я в Тритоне 500 не заметил.

в общем, решил я тоже попробовать сделать большие карты при помощи rmptools.jar
кое-что получилось, правда не с первого раза, и не могу сказать, является ли мой путь самым легким
1. надо поместить каждый из файлов первоначальной карты в отдельную папку
2. при помощи rmptools.jar распаковываем карту. в результате в папке появляется еще фалы: unnamed0.a00, unnamed1.a00, unnamed2.a00, unnamed0.tlm, unnamed1.tlm, unnamed2.tlm (нам нужны будут только они), а также bmp2bit.ics, bmp4bit.ics и rmp.ini (последние три файла нужны только в единичном экземпляре, то есть можно оставить их только в первой папке, остальные можно удалить)
распаковывание проводится следующим образом: RMP - Unpack
те же самые действия проделываем с каждой папкой, где есть первоначальная карта
3. в новую папку помещаем все файлы с первой папки: unnamed0.a00, unnamed1.a00, unnamed2.a00, unnamed0.tlm, unnamed1.tlm, unnamed2.tlm, а также bmp2bit.ics, bmp4bit.ics и rmp.ini
с остальных же папок только файлы unnamed0.a00, unnamed1.a00, unnamed2.a00, unnamed0.tlm, unnamed1.tlm, unnamed2.tlm (причем переименовываем их соответственно в unnamed3.a00, unnamed4.a00, unnamed5.a00, unnamed3.tlm, unnamed4.tlm, unnamed5.tlm и так далее...)
4. вносим изменения в файл rmp.ini
раньше он имел вид

теперь будет
и далее, сколько файлов
5. "собираем" файл назад: RMP - Рack и указываем новый rmp.ini

Если у кого есть более «простой» путь – поделитесь

Первоначально у меня было 20 файлов по 20 метров каждый, которые надо было "сшить" в один большой
Карты создавались при помощи Mobile Atlas Creator 1.9.3, содержали несколько слоев
В один все же не получилось, точнее файл в 450 метров я то создал, но в VantagePoint отображались не все места на карте – кое-где вообще не было изображения, кое-где только «верхние» слои
Поэтому объединил в четыре файла по 100 метров
На 400 Тритоне они «пошли», все нормально

_________________
сайт о пеших походах по области

nikalexey и Зундер, Спасибо за толковые советы! Всё получилось. Объединил 18 rmp-карт в одну весом 1.5 Гига, VP и Тритон 500 работают с ней без проблем! Разница с nikalexey только в том, что исходные карты были однослойными, сделаны в RMPmaker, и при распаковке не было файлов bmp2bit.ics, bmp4bit.ics, их я вставил готовые. С переименовкой chunk.ics 2 раза не экспериментировал. И файлы .a00, .a00 у меня назывались TOPO

Немного не понял.
Я не делаю многослойных карт. Мне нужно склеить один слой (одного масштаба из нескольких кусков). Они не составляют полного квадрата и хотелось бы получить прозрачными отсутствующие места.
Распаковал две карты
Указал оба 0 уровень - L-37-141C и 141BD. Получил карту суммарного объема, но отображается только одна. Границы показываются тоже только одной карты.
Указал первую 0, вторую 1. Показываются обе и пустой участок прозрачный, чего и хотелось. Но в некоторых местах вторая карта с дырками, которые уменьшаются с увеличением масштаба.

все равно файлы нумеруются по порядку: 0,1,2, и т.д.
если честно, не ставил перед собой такой задачи
надо пробовать варианты

_________________
сайт о пеших походах по области

Итак сегодня проковырялся полдня с картами.
1. Склеил L-37-141 части C и BD обоими способами - явовским тулсом и TritonRMP. Результат идентичный. Они делают одно и то же.
2. В обоих случаях в VantagePoint при некоторых масштабах по краю карты пропадает часть квадратов. При увеличении они появляются. Заметил и на других картах, состоящих из одного изображения. На Эксплористе отображается нормально. Видимо, это глюк вантажа.
3. Карта с точностью до 5 метров (толщины линий 250-ки) соответствует карте в Ози.
4. Границы карты не соответсвуют исходному оригиналу. Где то карта обрезана (обычно сверху и слева), где то зеленая граница лежит за картой и тогда появляется черная полоса.
5. Координаты границ карты округлены до сотых долей минуты. Но округление не до ближайшего значения. Разница между зеленой полосой и действительной границей карты составляет от 0,012 до 0,028 минуты (то есть больше чем 0,01). В результате обгрызка карты или черная полоса может достигать 50 метров на местности.
Или Шаронов намудрил или это тонкости формата RMP.

А нельзя ли как-то Подсунуть МОБАК-у карты из локальной папки на компьютере, подготовленные соответствующим образом?

Может, кто-нибудь пытался или знает, как создать растровую карту для Магеллана без абсолютно не контролируемого TritonRMP? Из космоснимков делают с помощью Mobile Atlas Creator, может, её как-то можно применить? Наверняка у программистов Магеллана есть специальное ПО для этого. По векторным картам вижу, такое ПО у них уже стырили. А по растровым??? Я бы за такое ПО даже заплатил. Просто жутко жалко тратить кучу времени на эти танцы с бубном... Особенно когда твой бубен не подействовал...

Почему же нельзя? Очень даже можно! Я об этом писал на этой странице ветки "Mobile Atlas Creator для создания карт для Magellan" (см.мои посты, начиная с поста от "13.01.2012 14:59").

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

Есть следующие причины, пока мешающие мне сделать непрерывный локальный тайловый кэш большого размера (и в дальнейшем его бесшовно пополнять):
1) Global Mapper на моем компе с трудом переваривает более-менее приличное рабочее пространство, которое можно за раз выгрузить в локальный кэш. Например, я ради интереса попытался в GM открыть рабочее пространство сразу из 2304 png-файлов (целиком лист M37 из карт масштаба 250 метров, если на листе вмещаются 144 километровых карты, то карт масштаба 250 метров больше уже в 16 раз!) - GM просто отказался открывать такое количество! Но я тоже упертый В общем, открыл новую для себя возможность GM - он умеет работать с "каталогом карт". Загнал я эти 2304 png-файла в каталог карт в GM и открыл-таки рабочее пространство, после чего запустил "Экспорт вэб...". GM начал создание локального кеша тайлов, но предполагаемое время его создания составляло более суток... Прервал я этот эксперимент, не только время меня остановило, а еще и нерешенная пока проблема слияния (частично) пустых тайлов (об этом см.далее);
2) имеющиеся у нас растровые карты в основном в системе координат "Пулково", из-за этого границы карт генштаба и ГГЦ не совпадают с границами тайлов. Поэтому даже экспорт одной карты в локальный кэш приводит к появлению по краям карты частично заполненных тайлов. Если сделать экспорт соседнего листа карты, то смежная граница выгружается также в виде частично заполненных тайлов в тех же самых файлах. Встает задача "умного копирования/слияния" тайлов - о ней я напишу дальше;
3) как я расковырял, в скриптах в GM на сегодняшний день не реализован "экспорт в вэб..." (в отличие от "экспорт растра..."), поэтому полностью автоматизировать процесс переноса растровых карт в локальный кэш не получится.

Тырить промышленное ПО?
Я на месте Магеллана научил бы VantagePoint карты делать из растра (идея Paganel, я поддерживаю), это было бы круто с учётом DG-спутниковых карт! А Garmin и DeLorme потеряли бы часть рынка.
Есть софтинка, я с ней особо не разбирался и потому не описывал, под руку попалась перед самой экспедицией, вот и лежала без дела.
Требует она Java непременно последних версий, а серверная часть лежит в интернете, т.е. обработка происходит не на компе пользователя, а на сервере Picosun. Я эту программу не проверял совсем!
Всё, что Вы делаете, Вы делаете на свой страх и риск и на радость Picosun Я так понимаю, копии карт у него остаются

_________________
Штурман, нада дёрнуть!

UrikEEE, чуть позже допишу по Global Mapper, меня пугает тот объём статьи, который надо описать понятным языком.
Итак уже пишу пошаговую инструкцию к действию без подробного описания процессов.

_________________
Штурман, нада дёрнуть!

Теперь пару слов о нерешенной пока задаче "умного копирования/слияния" тайлов.

GM при экспорте в вэб создает в папке ну скажем "Z15" тайловую структуру (внутри нее каталоги с координатами по y, а в каждом таком каталоге файлы-тайлы с координатами по x). Чтобы Mobac такую папку принял, достаточно просто переименовать "Z15" в "15".

Но, как я писал выше, все равно придется локальный кэш наращивать поэтапно - так как GM на обычных компах не способен за разумное время переварить сразу все ваши карты.

Плюс к этому каждый раз пограничные тайлы будут заполнены неполностью. К слову говоря, если GM создает тайлы в виде png-файлов, то эти файлы создаются с альфа-каналом, то есть с битом прозрачности, и для частично заполненных тайлов незадействованная пустая точка помечена как прозрачная.

Поэтому возникает вот какая задача:
Надо переместить все подкаталоги/файлы из папки-источника (Z15) в папку-приемник (15). Но перемещать не бездумно. Если текущий файл-тайл из папки-источника отсутствует в папке-приемнике, то его просто перемещаем, а если такой файл уже есть в папке-приемнике, то скорее всего, это уже ранее частично заполненный тайл, поэтому просто так переместить его нельзя, а надо на этот файл-приемник наложить файл-источник и записать. Конечно, один-два раза это можно легко сделать и в фотошопе, но когда количество частично заполненных тайлов примерно 10-15% от общего количества тайлов, то фотошоп не пройдет. Нужна автоматизация.

Я пока остановился на редакторе Gimp-2.6 Его главный козырь - он умеет работать со скриптами, и этими скриптами легко (как я надеюсь) можно описать слияние 2-х png-файлов (частично заполненных тайлов) в один. Но язык скрипта оказался потомком языка Лисп и беглое знакомство с ним пока вынесло мне мозг Необходимо время, может, на выходных проведу эксперимент.

UrikEEEОдновременно начали писать, сообщения перемешались.
Тот ещё кусок работы - открыть одновременно пограничные тайлы в GM и нарезать заново. Не факт, что получится. Кстати и в Gimp тоже - не факт, что тайлы совпадут.

_________________
Штурман, нада дёрнуть!