создание карт для Magellan eXplorist 310, 510, 610, 710,

Чёрт побери! А ведь вы правы. Проанализировал таблички по парочке карт. Точно! Если длина суб-файла выражена нечётным числом, то добавляется пустой байт.
Вот табличка. http://sendfile.su/1077003

Ушёл доделывать программу.

Гм. Странно. В известной карте Украины http://www.hllab.dp.ua/Tour/triton/UA100000.zip
Первая странная последовательность из 32 байт между таблицей с содержанием и началом первого суб-файла отсутствует напрочь. Сразу идут данные.
А вместо второй странной последовательности из 11 байт в конце файла идут два байта с непонятным содержимым.

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

Кстати, выяснил, чем отличаются "базовая карта", "детальная карта" и "оверлейная карта". (С точки зрения программы IMI_tools, естественно )
Всего лишь одним параметром в суб-файле cvg_map.msf. Соотв.:
MAP_TYPE=TNDB_BASE_MAP - базовая (.mgi)
MAP_TYPE = TNDB_DETAILED_MAP - детальная (.imi)
MAP_TYPE = TNDB_POI_MAP - оверлейная (.poi)

MAP_TYPE=TNDB_LIGHT_MAP - х.з. шо за тип, но это прописано в .tpo картах
MAP_TYPE = TNDB_RASTER_MAP - растровые карты (.rmp)

Так, вроде проясняется....
По поводу первой "волшебной" строчки вроде всё ясно. Два байта контрольной суммы считаются так:


По поводу второй строчки пока неясно.
Казалось бы расчёт аналогичен, но непонятно:
- нужно ли учитывать таблицу TOC или только сами данные?
- нужно ли учитывать вставленные для выравнивания файлов нечётной длины байты?
- зачем и в каких случаях добавляется ещё один байт в строку перед двумя байтами контрольной суммы?

http://wiki.openstreetmap.org/wiki/OSM_ ... mi_archive

Гм. Немножко проясняется...
По первой "волшебной" строчке. Там, где она есть, она составляется так, как я выше описал. Проверил по парочке карт. Всё чётко!

А вот со второй "волшебной" строчкой пока проблемы.

По второй "волшебной" строчке и её контрольной сумме:
1) если все суб-файлы внутри файла карты выровнены по принципу " если суб-файл имеет нечётную длину, то после него добавляем нолик", то в таком случае вторая "волшебная" строчка выглядит как слово MAGELLAN и сразу за ним два байта контрольной суммы.
2) в картах от maps4me.net перед словом MAGELLAN добавлен пробел, а после слова MAGELLAN вставлен нолик для выравнивания, а потом идёт контрольная сумма
3) в некоторых картах слово MAGELLAN в конце файла отсутствует, а просто сразу идёт контрольная сумма, перед которой если нужно вставляется нолик для выравнивания.

Короче, я буду в своей программе делать так, как в первом варианте, ибо в так сделано в официальных магеллановских картах.

Кстати, всё-таки подтвердился алгоритм вычисления контрольной суммы в конце файла. Просто ксорим последовательно все байты на нечётных позициях и получаем первый байт контрольной суммы, потом ксорим все байты на чётных позициях и получаем второй байт контрольной суммы. Естественно, те последние два байта, где хранится сама контрольная сумма, не трогаем.

В общем, осталось только добавить в мою программу блок для расчёта контрольной суммы - и программа для разборки/сборки магеллановских карт будет готова. Только я пока не придумал как это сделать "красиво". Ибо считывать из файла по два байта за раз - это очень долго

А сколько обычно "субфайлов" содержится в магеллановском imi-файле? Ну просто интересно. И чем (какими программами) Вы собираетесь генерировать эти самые субфайлы, чтобы из них собрать imi-файл?

А про "считывание из файла по два байта за раз" - это сильно! Физически windows обменивается с дисковыми устройствами даже не секторами (обычно 512 байт в секторе), а кластерами (минимум 1 сектор, обычно несколько секторов). Конечно, прикладные средства (функции языка программирования) позволяют работать с дисками и отдельными байтами (для универсальности операций ввода/вывода), но Вы то должны понимать, что вызов такой функции все равно трансформируется в чтение кластера...

Ничего, если на некоем С-подобном псевдокоде?



собственно вот и все.
Читаем блоками по 16К (впрочем, размер блока может быть любым), потом обрабатываем блок в памяти.

_________________
//Cheers, Victor
//Magellan eXplorist 310, Transystem TripMate 852, Columbus V-990, Transystem PersonalMate 860Lite, Garmin Nuvi 50

По разному.
Зависит от кол-ва слоёв в карте, от наличия информации о рельефе, мета-данных и др.
Обычно от полсотни до примерно 250. К примеру, базовая карта мира из комплекта к ВантажПоинт содержит 56 суб-файлов, а карта Украины, которая лежит у Паганеля на сайте, 167 субфайлов. В карте Альп с мапс4ми.нет больше чем 259 суб-файлов. Размер суб-файлов тоже очень разный. От нескольких байт до десятков мегабайт. Больше всего "весят" файлы *.blx с рельефом.


А я не буду создавать карту "с нуля". Моя программа нужна будет только для того, чтобы распаковать imi-файл, подправить там вручную чего надо (добавить рельеф, мета-данные, подкрутить стиль отрисовки линий, возможно, "склеить" из двух карт одну и т.д.) и запаковать обратно.

Вы правы. Тормозилово ещё то!
Сейчас у меня программа читает-пишет файлы кусками по 131072 байт (это 32*4096, где 4096 - это обычный размер кластера на NTFS, если я ничего не путаю). Только таблица TOC пишется-читается маленькими кусочками по 4 байта. Но это из-за особенности структуры этой таблицы. Да и объём у той таблицы небольшой.
Victor Pomortseff спасибо. Примерно так я и делаю. Только я считаю контрольную сумму ещё в процессе создания нового imi-файла по принципу "записали кусок из буфера в файл - посчитали контрольную сумму по буферу", а не прогоняю процесс подсчёта суммы после того как файл уже создан. Ну, чтобы как говорится "два раза не вставать"
Правда, пока что-то оно неправильно считается. Разобрал одну карту, собрал обратно, сравнил побайтно в ТоталКоммандере. Совпало всё кроме этой чёртовой контрольной суммы файла.
Впрочем, вчера оно вообще считаться не хотело, вешалось. Только сегодня утром допетрил, что переменную i надо было объявлять как LongInt, а не как Word, а то ведь размер буфера у меня больше, чем максимально допустимое число типа Word.

Кстати, если интересно, у меня тут валяются шароновские исходники POICreator'а на дельфях. Оно глюковатое, надо переписывать, но там можно выдернуть процедуры создания базы poi в том виде, в каком они создаются ММО 1.0

_________________
//Cheers, Victor
//Magellan eXplorist 310, Transystem TripMate 852, Columbus V-990, Transystem PersonalMate 860Lite, Garmin Nuvi 50

Скажу честно, вектор для пеших походов меня слабо интересует. Но ПОИ нужны. Тулз для создания пустой или простой карты с набором ПОИ был бы очень полезен. Самому писать лень. Видно еще не так сильно нужны ПОИ.

IMHO, попробуйте предложить это камраду Бенно https://github.com/bennoschoen/mm.gen
Может, он сможет понять алгоритм и добавить в свой картогенератор.
Кстати, а в чём заключается глюкавость?

Всё. Закончил свою программку. Можете качать. Исходники и инструкция внутри.

http://sendfile.su/1082989

Программа умеет распаковывать магеллановские карты (.imi, .mgi, .poi, .rmp и т.д.) в суб-файлы в папочку и упаковывать папку с суб-файлами в один файл.

Возможно, вам будет интересно: POI, входящие в состав карты OpenStreetMap, можно скачивать в виде файла GPX, выбрав определённую категорию и определённый район. Мне об этом писал один знакомый. Скопирую сюда его письмо.

"overpass - онлайн-надстройка над осм, сервер запросов выборки объектов в осм.
проще всего зайти на http://wiki.openstreetmap.org/wiki/RU:T ... ral=spring там справа в Инструментах ссылка на поиск родников в оверпас-турбо. переходим по ней, получаем форму запроса, удаляем из него
way["natural"="spring"]({{bbox}});
relation["natural"="spring"]({{bbox}});
ибо это излишне. в левом верхнем углу карты жамкаем кнопку "выбрать прямоугольник вручную", выбираем нужную область.
жмем кнопку "Старт" для запуска поискового запроса, получаем набор наглядных точек в выбранной области. после чего жмем "Экспорт" там выбираем GPX (забыл что можно в gpx экспортировать).
получаем красивую gpx-выборку с именами, мультиязычными описаниями и т.д.
почитав описание запросов можно получить практически любую выборку из ОСМ."

_________________
Карти для GPS-навігаторів: де їх брати? https://encyclopedia-mandriv.blogspot.com/2013/06/karty-dlya-gps-navigatorov.html

Спасибо, но это совсем другое. ПОИ в картах интересны категориями, поиском и т.п. нужны не сами точки, а технологии использовпния ПОИ в навигаторах. Уверен, что у каждого туриста емть десятки или сотни своих точек. А работать с ними сейчас не так удобно. Раньше была возможность включать/отключать отдельные файлы с данными. Теперь только импорт/экспорт. Не писк при наличии сотен точек разбитых по категориям. На ПК проблема решается каталогам. На приборах каталогов нет.

Я пытался пользоваться более поздней версией этой программы с шароновского сайта. Точно где глючила уже не помню. По-моему, то ли зависала, то ли вылетала при загрузке файла с точками. То ли еще что-то было (может как-то криво грузила их). Но пользоваться ей было нереально. Хотя очень хотелось иметь отдельный инструмент для создания слоев POI чтобы не заморачиваться связкой ММО 1.0 (для создания POI) и ММО 2.7 (для сборки карты), а обходится только ММО 2.7

Это какая-то более ранняя версия, тут еще статические массивы точек и категорий с ограниченным их количеством. Поэтому думалось выдернуть оттуда ту часть, что собственно создает POI слой и приписать к нему нормальный интерфейс.

А вкупе с вашими наработками можно было бы создать инструмент для создания .poi карт (если я правильно понял идеологию, это должна быть оверлейная карта, содержащяя только POI слой). Это было бы интересно т.к. такого инструмента я не нашел нигде, а это было бы весьма полезно для использования как с векторными, так и с растровыми картами.

Сам я разочаровался в создании вектора - мороки очень много, а результат весьма посредственный. До тех пор, пока нет нормального инструмента для создания этих карт.

_________________
//Cheers, Victor
//Magellan eXplorist 310, Transystem TripMate 852, Columbus V-990, Transystem PersonalMate 860Lite, Garmin Nuvi 50