GPS с растром.

[Bushman]

Если объяснять на пальцах, то:

Трансформированный растр - это тот, которому для того, чтобы "лечь" на свое место достаточно всего двух точек привязки по противоположным углам и информации о том, в какой проекции он находится. В таком формате привязка хранится в GeoTIFF, ECW/JPEG2000, MrSID, TAB-файлах Mapinfo и в комплекте world-file + prj-file в ArcView. И это правильно не только по факту стандартности такого подхода для всех промышленных продуктов, но и по той причине, что софт не обязан тратить машинное время на то, чтобы трансформировать кривой растр каждый раз, если это можно сделать однажды.

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

Что касается OZF - его появлению мы обязаны тому, что автор OZI не удосужился почитать, что было уже придумано до него. А до него уже существовало несколько стандартных промышленных форматов (в т.ч. документированных и с доступными бесплатными исходниками для чтения/записи) с абсолютно теми же возможностями, без изобретения велосипеда. Я говорю о суб-формате tiled TIFF, где данные хранятся фрагментами (тайлами). Кроме того, товарищ сделал все свои самостийные форматы закрытыми, не документировав их.

"Стандарт де-факто" - не значит что-то хорошее. Просто очень много людей по незнанию и отсутствию желания знать, пошли по тому же пути, что и автор программы - схватились за первое попавшееся, вместо того, чтобы подумать. Хуже того, до появления недавно сторонних утилит, способных декодировать ozf, ozf2, ozfx (еще одно чудо мысли), область применения карт, привязанных и выложенных в таких форматах искусственно ограничивалась продуктами семейства OZI (согласитесь, не очень красиво и логично в свете идеи о свободном обмене данными и т.п.). Пойдя дальше, можно вспомнить, что продукты OZI работают только на windows-платформах, а т.к. данные не документированы, это затрудняет их перенос (теперь, к счастью, нет, но не благодаря, а вопреки автору) на другие платформы и в другие программные продукты.

[Propretor]

В ответе чуствуется профессионализм оратора. Спасибо за науку. Буду иметь ввиду, хотя не смотря на сказанное выше позитивного отношения к озику в общем то не меньше.

Garmin eTrex, eTrex Legend, GPSMAP 60Cx, HP iPAQ RX1950.

[Bushman]

Да просто сто раз уже тут приходилось это объяснять уже (а так - я инженер, так что профессионалом в убеждении не являюсь). Никому не пытаюсь навязать отказ от OZI, но считаю, что люди должны чётко представлять себе, что есть что, и что чего реально стоит в смысле возможностей и т.п. Для расширения кругозора рекомендую посмотреть на http://www.esri.com/software/arcgis/arc ... tures.html (коммерческое, исключительно стандартное и профессиональное) Ну и QGIS с собратьями (для linux-девайсов) никто не отменял...

[_olegus_]

Как и обещал, ссылка на программу: http://webfile.ru/1723026 (73Мб) Программа открывает только карты с расширением .tpo Спасибо Bushman за проделанную работу. И вопрос: "Есть ли надежда?"

[Bushman]

Ну вот что еще могу сказать:
1) между форматом rmp, который оно отдает в прибор, и форматом tpq (в котором хранятся данные в папке USMaps) много общего в смысле хранения данных - там тоже JPEG-тайлы (в остальном они различаются).
2) как экспортить данные в rmp-файл не имея навигатора, я не понял (при попытке экспортировать карту, софтина хочет коннектится к gps-девайсу), что несколько осложняет ситуацию, т.к. разных примеров (например, вырожденный файл, содержащий только 1 или 2 тайла) нагенерировать не могу.
3) Хорошая новость состоит в том, что среди библиотек есть TPQ2RMP - судя по всему, в ней и сосредоточены функции кодирования RMP-формата.
4) Более пристальное изучение RMP-файла привело меня к след. подозрениям:
- начало состоит из оглавления с именами файлов (rmp.ini topo1.tlm topo1.a00 bmp2bit.ics bmp4bit.ics, очевидно - со смещениями) заканчивающимся на MAGELLAN
- rmp.ini - это то, что следует потом, там какая-то фигня типа имени карты.
- topo1.tlm - это (судя по всему) описание мозаики тайлов (возможно - смещения и координаты, в какой СК- не ясно, но в самом TOPO! регион вырезается не параллельно линиям градусной сетки, так что это может оказаться вовсе и не градусы, в файлах программы есть упоминания NAD83)
- topo1.a00 - это сами тайлы в JPEG (без изменений в формате)
- bmp2bit.ics, bmp4bit.ics - битмапы из соответствующих икон-файлов, которые идут в поставке TOPO!
- ну и тот же маркер "MAGELLAN" в конце.
- везде где входит строка "topo1" - это не жесткое определение, а название карты, заданное при экспорте.
Так что формат сравнительно прост, уважаемые мастера hex-редакторов - welcome, так сказать.

Заранее предупреждаю - я не программист и не спец по взлому и т.п. фокусам, так что сам ничего не обещаю (просто посмотрю, что еще можно выяснить). Но как сам RMP-формат (в плане того, возможно ли в нем разобраться и написать кодер) так и сама эта софтина (в плане возможного добавления в нее "левых" карт в формате tpq) представляются вполне перспективными.

[Bushman]

Проверил адреса - да, совершенно точно самое начало - это оглавление. В приведенном тут файле карты есть, например, содержимое bmp4bit.ics, сам файл начинается с адреса 00 5C 50 C2, а в начале файла после строки "bmp4bit ics" (имя в формате 8+3) идет четыре нулевых символа и C2 50 5c 00. Так что это есть действительно примитивное оглавление.

[Bushman]

Как и думал - magsendtool, написанный MagUser'ом c gpsinfo.ru справляется с показом оглавления и извлечением суб-файлов из образа карты.
На сегодня пока всё. Далее надо копать tlm-файл из тех, что извлекаются.

[nikaanor]

Коллега Bushman очень убедительно все разъяснил. Но хотелось бы обратить внимание на пару моментов: OZI поддерживает формат ECW. Так что если не нравится OZF, пожалуйста промышленный стандарт. :)
И самое большое преимущество OZI - легкость и простота освоения. Именно из-за этого (на мой поверхностный взгляд) он стал фактически стандартом.
Я не в курсе, подскажите что еще на КПК с растром можно использовать?

[_ys05_]

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

Грубо говоря, если загрузить привязанный "кривой" растр, то OZI его отобразит также криво. И если по этому "искривленному" пространству пройти прямо, то трек на экране искривится вместе с пространством, и в итоге отобразится примерно там, где надо на растре.

[Bushman]

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