geoTIFF to RMP

tothehood2 · **Добавлено:** 23.03.2012 13:56

Написал конвертор из geoTIFF в RMP. Созданные им карты должны открываться и на эксплористах и на тритонах.

Скачать: http://antalos.com/gps/geoTIFFtoRMP0.9.zip
Координаты в исходном geoTIFF должны быть в WGS84.

Статья, описывающая конвертацию карт из Ozi в geoTIFF с использованием Global Mapper: http://antalos.com/gps/ozi-to-geotiff.php

Был бы благодарен за тесты, пожелания, отзывы.

UrikEEE · **Добавлено:** 23.03.2012 14:20

Спасибо, на выходных протестирую.

Пара слов про конвертацию карт в geoTIFF с использованием Global Mapper. GlobalMapper дает возможность исполнять скрипты, написанные на своем скриптовом языке. Так вот, обрезка карт, изменение проекции/системы координат и экспорт в растровый файл (включая GeoTIFF) прекрасно реализуется скриптом. Причем исходные карты не обязательно должны быть с привязкой к ozi (не только map-файлы). Это удобно при обработке большого количества файлов. Набросал в одну папку файлы - источники, запустил скрипт, который будет последовательно файл за файлом брать из папки-источника, обрезать/преобразовывать проекцию/экспортировать в GeoTIFF файл в папку-приемник, и пошел заниматься своими делами.

tothehood2 · **Добавлено:** 23.03.2012 14:37

Спасибо за информацию, посмотрю в сторону пользовательских скриптов Global Mapper'а.

Paganel · **Добавлено:** 23.03.2012 14:46

Первая проверка.
1. Программа работает. И это уже хорошо.
2. Программа понимает только Geographic, а есть еще Equirectangular, который тоже годится и даже лучше для Magellan. На нем она вылетает с ошибкой.
3. Карта получается со сдвигом метров на 30, что для крупномасштабных карт неприемлемо. И я даже догадываюсь почему.

**** Вдогонку ****

Сдвиг оказывается дает GlobalMapper. Импортированная из geotiff в ози карта оказалась так же сдвинутой ровно на такое же расстояние. Это уже вопрос к знатокам ГМ.

Зундер · **Добавлено:** 23.03.2012 15:12

UrikEEE писал(а):

Спасибо, на выходных протестирую.

Пара слов про конвертацию карт в geoTIFF с использованием Global Mapper. GlobalMapper дает возможность исполнять скрипты, написанные на своем скриптовом языке. Так вот, обрезка карт, изменение проекции/системы координат и экспорт в растровый файл (включая GeoTIFF) прекрасно реализуется скриптом. Причем исходные карты не обязательно должны быть с привязкой к ozi (не только map-файлы). Это удобно при обработке большого количества файлов. Набросал в одну папку файлы - источники, запустил скрипт, который будет последовательно файл за файлом брать из папки-источника, обрезать/преобразовывать проекцию/экспортировать в GeoTIFF файл в папку-приемник, и пошел заниматься своими делами.

Ещё есть "batch convert/reproject", делает всё сам, без макросов.

UrikEEE · **Добавлено:** 23.03.2012 15:24

Зундер писал(а):

Ещё есть "batch convert/reproject", делает всё сам, без макросов.

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

Зундер · **Добавлено:** 23.03.2012 15:50

Ну да, я так конвертировал ECW из SAS.Planet в GeoTIFF, там по определению нет полей.
:facepalm:

сорри, ввёл в заблуждение.

vituser · **Добавлено:** 23.03.2012 15:56

Зундер писал(а):

Ну да, я так конвертировал ECW из SAS.Planet в GeoTIFF, там по определению нет полей.
:facepalm:

сорри, ввёл в заблуждение.

Поля - бордюры на листах ГШ?

tothehood2 · **Добавлено:** 23.03.2012 16:00

Paganel писал(а):

Первая проверка.
1. Программа работает. И это уже хорошо.
2. Программа понимает только Geographic, а есть еще Equirectangular, который тоже годится и даже лучше для Magellan. На нем она вылетает с ошибкой.
3. Карта получается со сдвигом метров на 30, что для крупномасштабных карт неприемлемо. И я даже догадываюсь почему.

**** Вдогонку ****

Сдвиг оказывается дает GlobalMapper. Импортированная из geotiff в ози карта оказалась так же сдвинутой ровно на такое же расстояние. Это уже вопрос к знатокам ГМ.

Проверял по своим трекам в Vantage Point, ложились хорошо.
Но я не конверчу карты из Ozi в Global Mapper, а прямо в ГМ их вяжу.

А почему Equirectangular лучше для магелланов?

Paganel · **Добавлено:** 23.03.2012 16:51

tothehood2 писал(а):

Проверял по своим трекам в Vantage Point, ложились хорошо.
Но я не конверчу карты из Ozi в Global Mapper, а прямо в ГМ их вяжу.

А почему Equirectangular лучше для магелланов?

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

По поводу ошибки GM. Вот что я накопал:

Берем координаты в Пулково 48°00'00.00" 34°00'00.00"
Преобразуем в WGS 84
OziExplorer - 47°59'59.2" 33°59'54.0"
PointPaste - 47°59'59.22" 33°59'54.05"
Magellan eXplorist 310 - 47°59'59.2" 33°59'54.1"

Все три программы используют трехпараметрическое преобразование Молоденского с коэффициентами dX,dY,dZ (Defense Mapping Agency Technical Report, Department of Defense World Geodetic System 1984, DMA TR 8350.2 Second Edition, 1 September 1991): +28 -130 -95

Шестипараметрическое преобразование по широко известной таблице SK42toWGS84.xls
дает координаты - 47°59'59.46" 33°59'54.31"

GlobalMapper 12.1 из датума S-42(PULKOVO 1942) - 48°00'00.0748" 33°59'53.1663"

Если считать 6-параметрическое преобразование верным, то 3-параметрическое в OziExplorer и PointPaste отличается от него на 9.3 метра. Именно такое отличие и предсказывает XLS-таблица.

Отличие GlobalMapper от 6-параметрического 30.4 метра, от 3-параметрического 32.1 метра.

Получается все неправы и только один ГМ прав? Хотя по большому счету нас для туристских нужд интересует не столько абсолютная точность, сколько совпадение преобразования с наиболее распространенными программами и навигаторами.

Интересно какой метод и с какими коэффициентами использует GM?

Victor Pomortseff · **Добавлено:** 26.03.2012 08:23

Paganel писал(а):

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

По поводу ошибки GM. Вот что я накопал:

Берем координаты в Пулково 48°00'00.00" 34°00'00.00"
Преобразуем в WGS 84
OziExplorer - 47°59'59.2" 33°59'54.0"
PointPaste - 47°59'59.22" 33°59'54.05"
Magellan eXplorist 310 - 47°59'59.2" 33°59'54.1"

Все три программы используют трехпараметрическое преобразование Молоденского с коэффициентами dX,dY,dZ (Defense Mapping Agency Technical Report, Department of Defense World Geodetic System 1984, DMA TR 8350.2 Second Edition, 1 September 1991): +28 -130 -95

Шестипараметрическое преобразование по широко известной таблице SK42toWGS84.xls
дает координаты - 47°59'59.46" 33°59'54.31"

GlobalMapper 12.1 из датума S-42(PULKOVO 1942) - 48°00'00.0748" 33°59'53.1663"

Если считать 6-параметрическое преобразование верным, то 3-параметрическое в OziExplorer и PointPaste отличается от него на 9.3 метра. Именно такое отличие и предсказывает XLS-таблица.

Отличие GlobalMapper от 6-параметрического 30.4 метра, от 3-параметрического 32.1 метра.

Получается все неправы и только один ГМ прав? Хотя по большому счету нас для туристских нужд интересует не столько абсолютная точность, сколько совпадение преобразования с наиболее распространенными программами и навигаторами.

Интересно какой метод и с какими коэффициентами использует GM?

1. Если отключить опцию "создавать квадратные пиксели" в GM, то образ карты создается без искажений (искажения видны только на экране GM).

2. Нужный масштаб в градусах на пиксел легко считается программой RMPCalc (http://forum.gpsinfo.ru/viewtopic.php?f=40&p=94027#p93940).

3. Коэффициенты преобразования не есть величина постоянная. Эти коэффициенты (в силу особенности СК-42) сильно зависят от местности. Почитать про это можно тут: http://www.geoprofi.ru/technology/Article_1573_10.htm или тут: http://geodesist.ru/forum/topic.php?forum=27&topic=283

4. GM использует семипараметрическое перобразование. Вот пример:

Есть такая программка GeoCalc.

Она предлагает использовать (по умолчанию, в соответствии с ГОСТ Р51794-2001 http://protect.gost.ru/document.aspx?control=7&id=130767 ) следующие значения коэффициентов:

dX 23.92
dY -141.27
dZ -80.9
wX 0
wY -0.35
wZ -0.82
M (*0.000001) -0.12

Вводим в нее координаты в СК-42 57N 57E и переводим их в WGS-84. Получаем:

57° 00' 01.324547" N
56° 59' 54.624783" E

GM дает результат:

57° 00' 01.7249" N
56° 59' 53.9217" E

Paganel · **Добавлено:** 26.03.2012 09:30

GM может использовать и семипараметрическое Бурса Вольфа и 3-х Молоденского. Но коэффициенты этих преобразований не взаимозаменяемы.
Я сегодня проверю. Они вполне могли всандалить коэффициенты Молоденского (28 -130 -95) в Бурса Вольфа или первые три из семи из ГОСТ в трехпараметрическое Молоденского. Я такое видел не раз в разных программах.

Victor Pomortseff · **Добавлено:** 26.03.2012 09:46

Paganel писал(а):

GM может использовать и семипараметрическое Бурса Вольфа и 3-х Молоденского. Но коэффициенты этих преобразований не взаимозаменяемы.
Я сегодня проверю. Они вполне могли всандалить коэффициенты Молоденского (28 -130 -95) в Бурса Вольфа или первые три из семи из ГОСТ в трехпараметрическое Молоденского. Я такое видел не раз в разных программах.

По некоторым признакам смею предположить, что используют они PROJLib со всеми вытекающими...

UrikEEE · **Добавлено:** 26.03.2012 10:42

tothehood2 писал(а):

Был бы благодарен за тесты, пожелания, отзывы.

На домашнем компе под Windows 7 Ultimate (x32) у меня не получилось создать rmp-файл. После выбора tiff-файла этот файл появлялся в списке файлов, но в колонке Status отображалось err, а в колонке Msg была надпись, что rmp-файл уже существует и указан полный путь к выбранному tiff-файлу. Путь к файлу отображался немного странный. Вот пример:
c:\maptiles\out\\m37-001-A-a.tif
Странность пути заключается в наличии двух обратных слэшей исключительно на месте последнего слэша. Никакого rmp-файла создано не было.

Попробую на рабочем компе с Windows XP. Отпишусь позже.

UrikEEE · **Добавлено:** 26.03.2012 10:45

Сразу еще парочка пожеланий:

1) Я не увидел экранной кнопки типа "Create rmp-file". Не понятно, когда именно начнется процесс создания rmp-файла. Мне непонятно, поскольку пока не получилось создать этот файл. Но если процесс создания rmp-файла начинается сразу после выбора tif-файла(ов), то лучше добавить отдельную кнопку - тогда можно открыть нужное количество tif-файлов из разных подкаталогов и запустить процесс создания rmp-файла;

2) хотелось бы иметь возможность видеть графически взаимное расположение выбранных tif-файлов (наподобие Overview Maps в TritonRMP).

tothehood2 · **Добавлено:** 26.03.2012 11:13

По поводу двух слэшей - они не на что не влияют. Проблема в том, что там должно было быть что-то типа "c:\maptiles\out\\m37-001-A-a.rmp", то есть идет проверка на то, чтобы не перезаписать существующий RMP-файл. Но программа некорректно сгенерировала название создаваемого rmp файла и оно совпадает с исходным tif, поэтому процесс конвертации запущен не был. Возможно дело в регистре имени исходного файла, в программе не было проверки.

Насчет кнопки create RMP - да, стоит добавить. Сейчас процесс создания запускается сразу после выбора tif файлов. В новой версии добавлю.

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

UrikEEE · **Добавлено:** 26.03.2012 12:07

Протестировал в обед на рабочем компе под Windows XP. Все нормально отработало, rmp-файл создается сразу после выбора tif-файла(ов).

tothehood2 писал(а):

Возможно дело в регистре имени исходного файла, в программе не было проверки.

Имя файла я никак не могу поменять в утилите. Путь и имя файла в колонке msg дублируется из выбранного tif-файла. Возможно, дело в системной кодировке, принятой в ОС. В Win 7 используется кодировка в юникодах (два байта на символ), а в Win XP - обычная однобайтовая кодировка. У меня в папке с tif-файлами не было ни одного rmp-файла.

Paganel · **Добавлено:** 26.03.2012 12:47

tothehood2 писал(а):

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

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

У меня все получилось с первого раза. К карте претензий нет. Что GM дал, то программа и сформировала.

Интересно чем отличается Geotiff в Equirectangular. Его не только твоя программа не ест, но и OziExplorer. Твоя ругается на ошибку, а Озик получает невменяемые координаты.

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

UrikEEE · **Добавлено:** 26.03.2012 13:23

Paganel писал(а):

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

Я именно это имел ввиду. В TritonRMP при Overview Maps как раз так реализован обзор карт - в виде заштрихованных прямоугольников. Удобно зрительно проверить перед созданием rmp-файла, те ли карты загружены.

tothehood2 · **Добавлено:** 28.03.2012 11:50

Залил новую версию: http://antalos.com/gps/geoTIFFtoRMP0.93.zip

Добавил управление списком загруженных TIFF, визуализацию карт.

Баг с именем RMP файла которое совпадает с tif и потому не запускается процесс конвертации наверное исправил.

Посмотрел геотиффы в Equirectangular - отличие там в том, что все координаты и размеры пикселей указаны в метрах, в то время как программа ожидает координаты и размеры в градусах (Ozi возможно тоже). Поэтому все и слетает.

UrikEEE · **Добавлено:** 28.03.2012 12:25

tothehood2 писал(а):

Залил новую версию: http://antalos.com/gps/geoTIFFtoRMP0.93.zip

Ага, спасибо, вечером протестирую.

Paganel · **Добавлено:** 28.03.2012 14:25

Проверил стыковку карт. У TritonRMP получались черные полосы до 30 метров.
Сделал 4 листа 250-метровки ГГЦ отдельными тифами. В один файл склеились нормально. Почти встык.
Четыре одновременно открытых файла в разные RMP сформировались похожего на реальный размера, но в VP показывается только один - последний. Остальные открываются не нигде и никак не отображаются.
Четыре файла сформированные по одному (открыть - сформировать - очистить - загрузить следующий) получились. Нестыковка листов около 3 метров, что на порядок лучше чем у TritonRMP.

Что делать со странными файлами, которые не показываются? Выложить куда то или поищешь так? Могу дать 4 тифака для тестирования.

Замечания по интерфейсу пока отложим. Единственное - если формируется один RMP из нескольких TIFF надо спрашивать имя выходного файла.

tothehood2 · **Добавлено:** 28.03.2012 14:55

Залей куда-нибудь тифки, скачаю - посмотрю в чем там дело может быть.

Paganel · **Добавлено:** 28.03.2012 17:22

http://us.ua/688866/

Выделил все 4 файла, открыл и сформировал 4 RMP. Первые три не отображаются. По отдельности все нормально.

tothehood2 · **Добавлено:** 28.03.2012 20:43

http://antalos.com/gps/geoTIFFtoRMP0.95.zip

Да, был баг при создании отдельных RMP для каждого тиффа, поправил

+ добавил диалог выбора имени RMP файла при создании атласа
+ поправил ошибку в визуализации расположения

Paganel · **Добавлено:** 29.03.2012 09:12

Отличненько. Программу уже можно считать рабочей.

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

UrikEEE · **Добавлено:** 29.03.2012 11:53

Протестировал программу. Получилось так, что вчера вечером тестировал версию 0.93, а сегодня в обед уже версию 0.95. Спасибо автору, в последней версии все работает.

С версией 0.93 у меня был такой баг: я формирую один rmp-атлас из 120-ти tiff-файлов (96 файлов масштаба 1:25000 и 24 файла масштаба 1:50000 на тот же район), причем суммарное разрешение картинки составляет 42564 х 30616 точек (привет MobAC и TritonRMP)), но когда начинаю просматривать этот атлас в Vantage Point 2.19, обязательно обнаруживаю черные фрагменты на картах масштаба 1:25000. Я формировал атлас 3 раза (и на компе с Win 7 (x32) и на компе с Win XP), черные фрагменты были каждый раз (почему-то один фрагмент на атлас), но каждый раз в разных местах (!!) атласа. Формой фрагмент напоминал прямоугольник, точнее 2 стороны всегда шли по границам какого-то одного tiff-файла (одна по вертикальной и одна по горизонтальной), а затем уже граница черного фрагмента в виде ломаной линии из вертикальных/горизонтальных отрезков внутри этого файла.

Сегодня обновил Vantage Point до версии 2.26 и сформировал еще раз rmp-атлас из тех же 120-ти tiff-файлов уже программой версии 0.95. Результат обрадовал - ни одного черного фрагмента при просмотре в Vantage Point я не нашел!

Paganel · **Добавлено:** 29.03.2012 12:21

Это не проблема атласа. Это глюк VantagePoint. Такое бывало и после TritonRMP. На навигаторе этого не будет в любом случае.

UrikEEE · **Добавлено:** 29.03.2012 12:38

Paganel писал(а):

Это не проблема атласа. Это глюк VantagePoint. Такое бывало и после TritonRMP. На навигаторе этого не будет в любом случае.

До навигатора пока дело не дошло - просто не хватило времени.

Но сейчас в целом получилась весьма полезная программа. Фактически теперь для получения rmp-файлов из исходных растровых материалов достаточно GlobalMapper и этой программы. Время будет экономиться.

Насчет сдвигов после экспорта в GeoTiff в GlobalMapper ничего сказать не могу. Я тестировал работу этой программы с картами ГГЦ России, сравнивал полученный при помощи этой программы rmp-файл с rmp-файлом, полученным при помощи MobAC из локального кэша тайлов (локальный кэш сформирован тем же самым GlobalMapper). Rmp-файлы практически идентичны, разница заметна только при переключении карт в VP и проявляется в разной степени замыленности надписей, все ориентиры остаются на своих местах. Но смещение все равно есть, у меня карта сдвинута на север-север-запад (относительно путевых точек) метров на 30. Может, это относится ко всем картам ГГЦ? Для меня эта погрешность приемлема, тем более к этой программе отношения никакого не имеет.

Paganel, а у Вас смещение наблюдалось только на картах ГГЦ или на других тоже оно есть?

UrikEEE · **Добавлено:** 29.03.2012 12:49

Кстати, может кому-то пригодится вот этот скрипт для GlobalMapper (для карт с gmw-файлами привязки - это карты ГГЦ России):

Код:

GLOBAL_MAPPER_SCRIPT VERSION=1.00 

// вместо C:\Tiles\IN\ надо прописать путь к папке с исходными файлами с gmw-файлами привязки (карты ГГЦ России):
DEFINE_VAR NAME="SOURCE_DIR" VALUE="C:\Tiles\IN\"

// вместо C:\Tiles\OUT\ надо прописать путь к папке с tiff-файлами, которые сформирует этот скрипт:
DEFINE_VAR NAME="DEST_DIR" VALUE="C:\Tiles\OUT\"

UNLOAD_ALL 

DEFINE_PROJ PROJ_NAME="GEO_WGS84" 
    Projection GEOGRAPHIC 
    Datum WGS84 
    Zunits NO 
    Units DD 
    Xshift 0.000000 
    Yshift 0.000000 
    Parameters 
    0 0 0.000 
END_DEFINE_PROJ 

DIR_LOOP_START DIRECTORY="%SOURCE_DIR%" FILENAME_MASKS="*.GMW" RECURSE_DIR=NO 

    EMBED_SCRIPT FILENAME="%FNAME_W_DIR%"
    LOAD_PROJECTION PROJ_NAME="GEO_WGS84" 
    EXPORT_RASTER FILENAME="%DEST_DIR%%FNAME_WO_EXT%.TIF" TYPE=GEOTIFF FORCE_SQUARE_PIXELS=NO GEN_WORLD_FILE=NO GEN_PRJ_FILE=NO
    UNLOAD_ALL 

DIR_LOOP_END

Скопировать содержимое скрипта в текстовый файл с расширением gms (например, как "FromGMWtoTIFF.gms"), подправить значения переменных SOURCE_DIR и DEST_DIR, указав в них пути к реальным папкам, затем поместить в папку, на которую ссылается SOURCE_DIR, исходные файлы с gmw-файлами привязки и уже в GlobalMapper запустить на выполнение этот скрипт.

tothehood2 · **Добавлено:** 29.03.2012 12:54

Paganel писал(а):

Это не проблема атласа. Это глюк VantagePoint. Такое бывало и после TritonRMP. На навигаторе этого не будет в любом случае.

Не, там был косяк в Delphi при работе с графикой в потоке и иногда некоторые тайлы получались полностью черные. В 0,95 по идее это должно быть исправлено.

tothehood2 · **Добавлено:** 29.03.2012 23:02

Paganel писал(а):

Отличненько. Программу уже можно считать рабочей.

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

Не вижу смысла, картинка из GlobalMapper получается лучше, если подгонять под нужные масштабы используя RMP Calculator.
Пример с увеличением:
http://dl.dropbox.com/u/2591913/map/gs-500-cmp.png

Пример с уменьшением:
http://dl.dropbox.com/u/2591913/map/gs-1000-cmp.png

Видно что после GlobalMapper артефактов изображения меньше и в целом картинка лучше.

В будущем планирую встроить в geoTiff кнопку для автоматического расчета размеров пикселя для global Mapper

challenger · **Добавлено:** 30.03.2012 03:27

UrikEEE писал(а):

Фактически теперь для получения rmp-файлов из исходных растровых материалов достаточно GlobalMapper и этой программы. Время будет экономиться.

Как я понимаю, если использовать эту программу, отпадает надобность в 2-х этапах создания карт:
1. Ози (импорт DRG карты и создание map файла)
2. Шароновский RMP maker тоже получается не нужен

Цитата:

Насчет сдвигов после экспорта в GeoTiff в GlobalMapper ничего сказать не могу. Я тестировал работу этой программы с картами ГГЦ России, сравнивал полученный при помощи этой программы rmp-файл с rmp-файлом, полученным при помощи MobAC из локального кэша тайлов (локальный кэш сформирован тем же самым GlobalMapper). Rmp-файлы практически идентичны, разница заметна только при переключении карт в VP и проявляется в разной степени замыленности надписей, все ориентиры остаются на своих местах. Но смещение все равно есть, у меня карта сдвинута на север-север-запад (относительно путевых точек) метров на 30. Может, это относится ко всем картам ГГЦ? Для меня эта погрешность приемлема, тем более к этой программе отношения никакого не имеет.

Paganel, а у Вас смещение наблюдалось только на картах ГГЦ или на других тоже оно есть?

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

UrikEEE · **Добавлено:** 30.03.2012 07:20

challenger писал(а):

Как я понимаю, если использовать эту программу, отпадает надобность в 2-х этапах создания карт:
1. Ози (импорт DRG карты и создание map файла)
2. Шароновский RMP maker тоже получается не нужен

Абсолютно верно. А если у Вас Magellan eXplorist, то отпадает необходимость в использовании "RMP Tools".

Фактически алгоритм сейчас я вижу такой:
1. При помощи Global Mapper имеющиеся растровые карты с файлами привязки преобразуете к проекции/системе координат Geographic/WGS84 (если требуется, предварительно в том же GM обрезаете лишние поля, это касается прежде всего карт Генштаба) и затем экспортируете в GeoTiff-файлы;
2. При помощи этой программы из GeoTiff-файлов получаете готовые rmp-файлы.

Мне в этой программе понравилось малое время создания rmp-файла (по сравнению с TritonRMP), возможность получения карт большого размера (MobAC не дает получить rmp-атлас разрешением более 18000х18000 точек, TritonRMP при попытке получить rmp-атлас большого разрешения выкидывает ошибку о нехватке памяти) и возможность задать Provider и Group (используется в Эксплористах).

challenger писал(а):

Если это смещение действительно то, о чём я упомянул, рекомендации по нейтрализации есть

А можно поподробней, что это за рекомендации?

challenger · **Добавлено:** 30.03.2012 09:24

UrikEEE писал(а):

А можно поподробней, что это за рекомендации?

Вот, публикую с разрешения автора ответ:

Цитата:

По поводу смещения.
Paganel-ю я лично недавно дал ссылку здесь http://www.gps-forum.ru/cgi-bin/forum/s ... apsed&sb=5
последний пост.
В общем там всё сказано. Есть пара картинок от меня.
Этого достаточно, чтобы задуматься.
Проблема не имеет отношения к ГГЦ или ещё каким картам. Это проблема GM. И заключается она в том, что прошитый в GM "S-42 (Pulkovo 1942)" дает результат не соответствующий прописанным в нём цифрам.
А именно этот датум автоматом подхватывается в GM при импорте привязки из MAP OZI.
Не надо путать" S-42 (Pulkovo 1942)" c "S-42 RUSSIA".
Первый трех параметрический, второй семи параметрический.

Ещё раз для полного понимания: если прописать вручную цифры датума "S-42 (Pulkovo 1942)", то результат будет отличный от вшитого.
Отсюда совет общего плана:
Вообще не пользоваться в GM прошитыми в программу датумами Пулково. Нет доверия.
Прописать три цифры ручками дело нескольких секунд. Заодно можно по экспериментировать.
Ну есть же у туристов треки? Почему не поэкспериментировать c датумом прямо в GM.
Тем более, GM позволяет подкачивать DG снимки прямо в проект.

И уж точно это надо сделать прежде чем начать гадать, типа так:

BS> Я тестировал работу этой программы с картами ГГЦ России,
BS> сравнивал полученный при помощи этой программы rmp-файл с
BS> rmp-файлом, полученным при помощи MobAC из локального кэша тайлов
BS> (локальный кэш сформирован тем же самым GlobalMapper)

Я не против, если ты используешь этот текст по своему усмотрению как угодно, вплоть до цитирования в вашем форуме.

Paganel · **Добавлено:** 30.03.2012 09:28

Существует две формулы персчета датумов:
Полная (Бурса-Вольфа) 7 параметров. Используется в геодезии. Коэффициенты приведены в ГОСТ 51794-2001.
Упрощенное - Молоденского 3 параметра. Используется в навигаторах, Ози и других. Коэффициенты EPSG 1254.
Разница между ними от 2 до 10 метров.
Наиболее частая ошибка разработчиков - брать первые три коэффициента из ГОСТ и использовать в формуле Молоденского или наоборот. В результате получается ошибка 30-50 метров. Скорее всего это и есть в датуме SK-42(PULKOVO) в GM. На досуге проверю оба варианта ошибки.

Выход и в Ози и в ГМ ввести пользовательский датум для СК42 с одинаковыми коэффициентами EPSG 1254 и работать в нем.

Victor Pomortseff · **Добавлено:** 30.03.2012 09:52

О каком смещении речь? Вот:

Это карта ГГЦ 250м сконвертированная через GM. Да, трек ложится не идеально. Но кто сможет точно сказать откуда погрешность - с карты или с исходных данных? Да и не 30 метров тут точно. А в пределах 10м погрешность определения координат в реальных условиях - норма.

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

tothehood2 · **Добавлено:** 30.03.2012 09:59

Paganel писал(а):

Существует две формулы персчета датумов:
Полная (Бурса-Вольфа) 7 параметров. Используется в геодезии. Коэффициенты приведены в ГОСТ 51794-2001.
Упрощенное - Молоденского 3 параметра. Используется в навигаторах, Ози и других. Коэффициенты EPSG 1254.
Разница между ними от 2 до 10 метров.
Наиболее частая ошибка разработчиков - брать первые три коэффициента из ГОСТ и использовать в формуле Молоденского или наоборот. В результате получается ошибка 30-50 метров. Скорее всего это и есть в датуме SK-42(PULKOVO) в GM. На досуге проверю оба варианта ошибки.

Выход и в Ози и в ГМ ввести пользовательский датум для СК42 с одинаковыми коэффициентами EPSG 1254 и работать в нем.

Коэффициенты из GM v13.00 для датума S-42:
TOWGS84[28,-130,-95,0,0,0,0]

Вроде как совпадают с EPSG 1254

challenger · **Добавлено:** 30.03.2012 11:17

Victor Pomortseff писал(а):

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

Всё верно, для разных территорий разные параметры датума. Задача облегчалась тем, что у цитируемого мной автора интересы связывались не с необъятной территорией, типа на пол или всю Россию, а ограничивались севером и частично центром европ. части бывшего СССР, поэтому подобрать параметры под эти территории в плане временных трудозатрат было вполне реально. Выкладываю для наглядности здесь файлик с пользовательскими датуми, для желающих опробовать (у самого с осени такой прописан в ГМ). Ну и будем ждать от Paganel результатов его проверки

Paganel · **Добавлено:** 30.03.2012 11:43

У нас на Украине смещение в GM больше. В принципе проблема решена, а выяснение где в ГМ нахомутали не так важно. Проверю на досуге. Сейчас нужно срочно выдать замечания магелланам, пока согласны выслушать.

challenger · **Добавлено:** 30.03.2012 11:58

Paganel писал(а):

У нас на Украине смещение в GM больше.

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

Цитата:

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

Вот это правильно. Магеллановцы ребята не очень адекватные, нужно пользоваться моментом, когда есть такая возможность

Зундер · **Добавлено:** 30.03.2012 12:22

Перепишу статью недельки через 2, после соревнований.

Paganel · **Добавлено:** 30.03.2012 13:07

А все таки можно сделать? Если открывается TIFF без геотегов выдавать окошко ввода границ карты. Ну очень хочется. Получится полная замена Шароновскому конвертеру.

Victor Pomortseff · **Добавлено:** 30.03.2012 13:14

Paganel писал(а):

А все таки можно сделать? Если открывается TIFF без геотегов выдавать окошко ввода границ карты. Ну очень хочется. Получится полная замена Шароновскому конвертеру.

Тут сразу возникает вопрос - а зачем делать полный аналог уже существующего?

UrikEEE · **Добавлено:** 30.03.2012 13:43

Victor Pomortseff писал(а):

Тут сразу возникает вопрос - а зачем делать полный аналог уже существующего?

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

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

Если логически интерполировать вашу мысль, то нам надо ездить на Руссо-Балте, ибо нынешние авто являются его заменой.

Paganel · **Добавлено:** 30.03.2012 16:09

Когда не загружена ни одна карта кнопка Visualise должна быть заблокирована. Вылетает сообщение об ошибке.
После удаления карты или карт панель визуализации должна обновляться сама. На ней остается изображение удаленной карты.

Victor Pomortseff · **Добавлено:** 01.04.2012 11:04

UrikEEE писал(а):

Victor Pomortseff писал(а):

Тут сразу возникает вопрос - а зачем делать полный аналог уже существующего?

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

Возможно, вы правы.

Пи всем уважении к Шаронову, его программы написаны весьма так себе. Слишком там много шероховатостей, а то и откровенных глюков.

А что касается черных полос на стыках карт, то, мне кажется, размер карты нужно нормировать на 256 (размер тайла 256х256 пикселей) равно как нужно нормировать размер матрицы blx на 128 (там размер тайла 128х128 пикселей).

Paganel · **Добавлено:** 01.04.2012 11:52

Размер картинки для RMP не критичен. Насколько я слышал там координаты округлялись до сотых долей минуты, а Шаронов их не очень корректно подгонял. Пусть автор меня поправит, если я не прав.

Victor Pomortseff · **Добавлено:** 01.04.2012 12:12

Paganel писал(а):

Размер картинки для RMP не критичен. Насколько я слышал там координаты округлялись до сотых долей минуты, а Шаронов их не очень корректно подгонял. Пусть автор меня поправит, если я не прав.

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

Paganel · **Добавлено:** 01.04.2012 14:29

Насколько мне известно 0.01 минуты. Почему так решили в Магеллане, не знаю.
Есть два варианта:
- Округлять привязку до ближайшего значения - страдает точность и черную полосу все равно можно получить, если округляемые значения не совпадут.
- Обрезать карту до ближайшего значения. Это будет точнее, но будет полоса шириной 18 метров.
Как делает Шаронов не знаю. С одной стороны он обрезает, с другой добавляет, а полосы бывают и по 30 метров, чего по идее быть не должно.

Хотелось бы послушать по этому поводу уважаемого tothehood2.

Victor Pomortseff · **Добавлено:** 01.04.2012 14:34

Paganel писал(а):

Насколько мне известно 0.01 минуты. Почему так решили в Магеллане, не знаю.
Есть два варианта:
- Округлять привязку до ближайшего значения - страдает точность и черную полосу все равно можно получить, если округляемые значения не совпадут.
- Обрезать карту до ближайшего значения. Это будет точнее, но будет полоса шириной 18 метров.
Как делает Шаронов не знаю. С одной стороны он обрезает, с другой добавляет, а полосы бывают и по 30 метров, чего по идее быть не должно.

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

Paganel · **Добавлено:** 01.04.2012 16:34

... но хотелось бы знать как это реализовано в geoTIFFtoRMP

Victor Pomortseff · **Добавлено:** 01.04.2012 17:54

Paganel писал(а):

... но хотелось бы знать как это реализовано в geoTIFFtoRMP

Судя по всему, точно также как и в TritonRMP - расширением карты черными полями до размеров, кратных 0.01 минуты. Возьми rmptools, разбери файл на тайлы и посмотри их - сразу увидишь что все граничные тайлы имеют черные поля:

верхний левый тайл карты, созданной geoTIFFtoRMP

Paganel · **Добавлено:** 01.04.2012 20:48

Я бы лучше обгрызал все изображения до кратного значения. 18 метров это немного и под картой всегда есть менее подробная, которая замажет стык. Хуже когда изображение перекрывается черной полосой. Добавит к одной 18 метров, к другой 18 и получится 40 метров черной полосы. Уж лучше 30 метров дырки.
Но мне кажется, что округление координат без изменения растра все таки предпочтительнее. Дырки и полосы не будет совсем, а максимальная ошибка на краю листа 18 метров к середине сойдет на нет, да и для туризма это совсем не принципиально.
Да и что мы тут обсуждаем. Автор все равно сделает так, как посчитает нужным. Спасибо, если скажет как именно сделал.

tothehood2 · **Добавлено:** 01.04.2012 22:39

По поводу черных полос. Не знаю как делал Шаронов, я делал так.
В RMP весь мир образно порезан на тайлы 256х256 пикселей. Получается картина вроде такой:
http://www.georeference.org/doc/latitud ... ection.htm

Координаты углов тайлов зависят от разрешения растра в градусах на пиксель.
Для того, чтобы ПО магеллана корректно работало с созданным RMP координаты углов тайла, на который мы режем растр должны совпадать с теоретически рассчитанными. Другими словами сетка тайлов уже существует, и перед нами стоит задача вписать нашу в эту сетку.

Это мы делаем так, зная координаты верхнего левого угла карты mapx, mapy и размеры тайла в градусах, находим координаты тайла tilex, tiley, в который попадет этот угол.

Зная эти координаты рассчитываем difx, dify. Теперь, зная разрешение растра в градусах на пиксель, считаем на сколько пикселей нам надо сдвинуть левый верхний угол карты, чтобы она вписалась в проекцию тайлов RMP. Оставшиеся бордюры заливаем черным.

PS Если сумбурно описал - извините

Victor Pomortseff · **Добавлено:** 02.04.2012 06:24

Paganel писал(а):

Я бы лучше обгрызал все изображения до кратного значения.

Это неправильно т.к. ведет к сознательной потере данных.

Paganel писал(а):

18 метров это немного и под картой всегда есть менее подробная

Уверен, что всегда? Я вот не уверен...

Paganel писал(а):

Уж лучше 30 метров дырки.

Абсолютно равнозначно на мой взгляд.

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

Victor Pomortseff · **Добавлено:** 02.04.2012 09:40

Victor Pomortseff писал(а):

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

Если нужно, я могу ввести соответствующую опцию (расчет координат обрезки) в RMPCalc - невелика проблема округлить координаты границ до 0.01'

Victor Pomortseff · **Добавлено:** 02.04.2012 10:44

tothehood2 писал(а):

Для того, чтобы ПО магеллана корректно работало с созданным RMP координаты углов тайла, на который мы режем растр должны совпадать с теоретически рассчитанными. Другими словами сетка тайлов уже существует, и перед нами стоит задача вписать нашу в эту сетку.

Каким образом считается эта сетка?

tothehood2 · **Добавлено:** 02.04.2012 11:27

Victor Pomortseff писал(а):

tothehood2 писал(а):

Для того, чтобы ПО магеллана корректно работало с созданным RMP координаты углов тайла, на который мы режем растр должны совпадать с теоретически рассчитанными. Другими словами сетка тайлов уже существует, и перед нами стоит задача вписать нашу в эту сетку.

Каким образом считается эта сетка?

Расчет координат узлов сетки тайлов:
Точка 1 = 90N 180W
Точка 2 = 90N (180 - $pixx)W
Точка 3 = 90N (180 - 2 * $pixx)W
Точка 4 = (90 - $pixy) N 180W
Точка 5 = (90 - $pixy)N (180 - $pixx)W
Точка 6 = (90 - $pixy)N (180 - 2 * $pixx)W

$pixx - разрешение растра в градусах на пиксель по долготе
$pixy - разрешение растра в градусах на пиксель по широте

Victor Pomortseff · **Добавлено:** 02.04.2012 11:33

tothehood2 писал(а):

Victor Pomortseff писал(а):

tothehood2 писал(а):

Для того, чтобы ПО магеллана корректно работало с созданным RMP координаты углов тайла, на который мы режем растр должны совпадать с теоретически рассчитанными. Другими словами сетка тайлов уже существует, и перед нами стоит задача вписать нашу в эту сетку.

Каким образом считается эта сетка?

Расчет координат узлов сетки тайлов:
Точка 1 = 90N 180W
Точка 2 = 90N (180 - $pixx)W
Точка 3 = 90N (180 - 2 * $pixx)W
Точка 4 = (90 - $pixy) N 180W
Точка 5 = (90 - $pixy)N (180 - $pixx)W
Точка 6 = (90 - $pixy)N (180 - 2 * $pixx)W

$pixx - разрешение растра в градусах на пиксель по долготе
$pixy - разрешение растра в градусах на пиксель по широте

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

Надо подумать крепко на эту тему.

P.S. Что-то кажется, что тут вообще не может быть решения, удовлетворяющего обеим условиям - и чтобы карта точно на сетку легла (без полей) и чтобы размер ее в пикселях был кратен 256...

tothehood2 · **Добавлено:** 02.04.2012 11:44

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

Victor Pomortseff · **Добавлено:** 02.04.2012 11:46

tothehood2 писал(а):

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

Проблема в том, что черные линии могут возникать на стыке двух карт...

tothehood2 · **Добавлено:** 02.04.2012 11:50

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

UrikEEE · **Добавлено:** 02.04.2012 14:57

Victor Pomortseff писал(а):

Проблема в том, что черные линии могут возникать на стыке двух карт...

Виктор, прощу прощения, что вмешиваюсь, но я тоже выскажу свое мнение о "черных полосах на стыках карт в TritonRMP". У меня такие стыки получались не между отдельными rmp-атласами, а в самом rmp-атласе, когда я в TritonRMP подсовывал несколько смежных исходных карт с высоким зумом (например, спутниковые снимки Яндекса с зумом 17 или 18, выгруженные из SASPlanet). То есть, когда я открываю полученный при помощи TritonRMP rmp-атлас и начинаю его просматривать в VP или в навигаторе, то на стыке исходных смежных карт наблюдаю эти самые черные полосы. Шириной десятки метров, особенно вертикальные полосы.

При этом исходные смежные файлы (ecw или уже преобразованные в tiff) при просмотре в GlobalMapper выглядят одной бесшовной картой. То есть, налицо глюк именно TritonRmp.

Victor Pomortseff · **Добавлено:** 02.04.2012 15:06

UrikEEE писал(а):

Victor Pomortseff писал(а):

Проблема в том, что черные линии могут возникать на стыке двух карт...

Виктор, прощу прощения, что вмешиваюсь, но я тоже выскажу свое мнение о "черных полосах на стыках карт в TritonRMP". У меня такие стыки получались не между отдельными rmp-атласами, а в самом rmp-атласе, когда я в TritonRMP подсовывал несколько смежных исходных карт с высоким зумом (например, спутниковые снимки Яндекса с зумом 17 или 18, выгруженные из SASPlanet). То есть, когда я открываю полученный при помощи TritonRMP rmp-атлас и начинаю его просматривать в VP или в навигаторе, то на стыке исходных смежных карт наблюдаю эти самые черные полосы. Шириной десятки метров, особенно вертикальные полосы.

При этом исходные смежные файлы (ecw или уже преобразованные в tiff) при просмотре в GlobalMapper выглядят одной бесшовной картой. То есть, налицо глюк именно TritonRmp.

Я достаточно много карт ГГЦ и ГШ прогнал через GM и далее TritonRMP и ни разу не наблюдал черных полос внутри карты. Правда, SAS'ом я не пользовался ни разу.

Сшивал до 16-ти листов в один в GM и нигде полос не было...

Правда, тут такой момент - я никогда не давал TritonRMP несколько листов одного уровня. Если требовалась сшивка слоя, то сшивал всегда в GM, а в TritonRMP только объединял несколько разномасштабных слоев по одному целому листу на слой.

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

UrikEEE · **Добавлено:** 02.04.2012 15:28

Проводил такие эксперименты с TritonRMP - один и тот же район прогонял через него и одним большим файлом (разрешением, близким к максимально съедобному для TritonRMP), и смежными файлами-кусками разрешением примерно 4000х4000 точек и смежными файлами-кусками разрешением примерно 2000х3000 точек. Все исходные карты получались экспортом из SASPlanet в ecw-файлы и дальнейшей перегонкой из ecw в tiff в GlobalMapper.

Скажу сразу - наилучшие по точности результаты получались из мелких кусочков. Сдвижка минимальная (десятки метров) и время формирования в TritonRMP тоже минимальное. Но минус - черные полосы на стыках смежных карт.

На rmp-атласах, полученных их кусков разрешением 4000х4000 и выше, появлялась большая сдвижка (уже под сотню и более метров). Ну и черные полосы на стыках смежных карт.

Повторюсь, черные полосы заметны именно на больших зумах (17 и 18-й зум в SASPlanet, что примерно соответствует масштаб 1:10000 и даже крупнее), на картах ГГЦ и тем более Генштаба масштабы куда мельче.

tothehood2 · **Добавлено:** 02.04.2012 22:53

http://antalos.com/gps/RMPCreator04.zip

Программу переименовал в RMP Creator. Изменения:
- добавлена поддержка ozi map файлов (привязка должна быть в WGS84)
- для растровых изображений без геотегов показывается окно, где надо ввести координаты верхней левой и нижней правой точек (опять же WGS84)
- добавлен аналог RMP Calculator - "geoTIFF export scale" - выбираем модель навигатора, вводим нужный масштаб. Теперь открываем в GM окно экспорта в geoTiff и жмем F9 - рассчитанные настройки должны автоматом прописаться в окне.
- добавлена возможность задавать provider/group/rmpfile для каждого загруженного файла в отдельности - для этого надо дважды кликнуть на соответствующем поле в таблице и внести нужные изменения

Кто-нибудь точно знает разрешение экрана и размер его сторон в дюймах для эксплористов 510/610 и 710, а то в инете какие-то противоречивые сведения.

vituser · **Добавлено:** 03.04.2012 00:39

tothehood2 писал(а):

http://antalos.com/gps/RMPCreator04.zip

Программу переименовал в RMP Creator. Изменения:
- добавлена поддержка ozi map файлов (привязка должна быть в WGS84).

Вот оно счастье. Спасибо.

Зундер · **Добавлено:** 03.04.2012 01:13

Ещё закачку тайлов карт из интернета/локального кэша добавить, и вот оно, совершенство! :eek:

tothehood2, примите мои искренние восхищения!

vituser · **Добавлено:** 03.04.2012 05:54

А какой максимальный размер файла может быть? Или общий файлов?

tothehood2 · **Добавлено:** 03.04.2012 08:38

vituser писал(а):

А какой максимальный размер файла может быть? Или общий файлов?

Тут сложно сказать, видимо зависит от системных ресурсов. На JPEG размерами 30000x30000 пикселей падает.
Планирую для больших изображений добавить использование внешней утилиты для нарезки на тайлы (gdal_translate), тогда по идее ограничений на макс размеры исходников не будет, но неизвестно как это будет по скорости.

vituser · **Добавлено:** 03.04.2012 09:01

Было бы здорово. На скорость чихать, хоть на неделю. Запустил и курить.

Paganel · **Добавлено:** 03.04.2012 09:54

Зундер писал(а):

Ещё закачку тайлов карт из интернета/локального кэша добавить, и вот оно, совершенство! :eek:

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

Зундер · **Добавлено:** 03.04.2012 11:02

Paganel писал(а):

Зундер писал(а):

Ещё закачку тайлов карт из интернета/локального кэша добавить, и вот оно, совершенство! :eek:

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

Значит переписывать всего-то 20% статьи, а не заменять её инструкцией к RMPCreator.

Цитата:

Тут сложно сказать, видимо зависит от системных ресурсов. На JPEG размерами 30000x30000 пикселей падает.

Оперативки хватает? Такой jpeg всю память сожрёт ещё и файл подкачки по швам пойдёт, может потому и валится? У меня для работы с графикой есть х64 с 16Гб.
Учитывайте, что работаем в FAT32, максимально возможный размер файла для FAT32 <= 4 294 967 295 байт, этот момент тоже надо проверять при создании файла.

Victor Pomortseff · **Добавлено:** 03.04.2012 11:13

Зундер писал(а):

Учитывайте, что работаем в FAT32, максимально возможный размер файла для FAT32 <= 4 294 967 295 байт, этот момент тоже надо проверять при создании файла.

А что, кто-то еще с FAT32 работает? Сколько себя помню, как с Win98 слез, сразу на NTFS перешел...

Victor Pomortseff · **Добавлено:** 03.04.2012 11:14

tothehood2 писал(а):

http://antalos.com/gps/RMPCreator04.zip

- добавлен аналог RMP Calculator - "geoTIFF export scale" - выбираем модель навигатора, вводим нужный масштаб. Теперь открываем в GM окно экспорта в geoTiff и жмем F9 - рассчитанные настройки должны автоматом прописаться в окне.

Тут бы еще поподробнее как это должно работать...

Зундер · **Добавлено:** 03.04.2012 11:18

Victor Pomortseff писал(а):

Зундер писал(а):

Учитывайте, что работаем в FAT32, максимально возможный размер файла для FAT32 <= 4 294 967 295 байт, этот момент тоже надо проверять при создании файла.

А что, кто-то еще с FAT32 работает? Сколько себя помню, как с Win98 слез, сразу на NTFS перешел...

Карточка в приборе.

Victor Pomortseff · **Добавлено:** 03.04.2012 11:22

Зундер писал(а):

Victor Pomortseff писал(а):

Зундер писал(а):

Учитывайте, что работаем в FAT32, максимально возможный размер файла для FAT32 <= 4 294 967 295 байт, этот момент тоже надо проверять при создании файла.

А что, кто-то еще с FAT32 работает? Сколько себя помню, как с Win98 слез, сразу на NTFS перешел...

Карточка в приборе.

Точно, не подумал про это :-)

Хотя тут явно нет смысла городить такие гигантские карты при том, что в растре прибор сам умеет переключаться с карты на карту.

Paganel · **Добавлено:** 03.04.2012 11:32

Victor Pomortseff писал(а):

Хотя тут явно нет смысла городить такие гигантские карты при том, что в растре прибор сам умеет переключаться с карты на карту.

Мало того, он прекрасно стыкует листы одного масштаба. Поэтому я никогда не делаю многослойных карт, чтобы иметь возможность отключить слой, и не делаю карт больше 16-36 номенклатурных листов (больше 100 мегабайт), чтобы можно было не пихать в навигатор весь мир, а взять только то, что нужно.
Вы же не перегружаете весь холодильник в рюкзак, а берете столько сколько сможете съесть в данном походе.
Кроме того, я не пью столько, чтобы утром проснуться там, где у меня нет карты.

tothehood2 · **Добавлено:** 03.04.2012 11:38

Зундер писал(а):

Оперативки хватает? Такой jpeg всю память сожрёт ещё и файл подкачки по швам пойдёт, может потому и валится? У меня для работы с графикой есть х64 с 16Гб.
Учитывайте, что работаем в FAT32, максимально возможный размер файла для FAT32 <= 4 294 967 295 байт, этот момент тоже надо проверять при создании файла.

Тесты я проводил на полностью залитым одним цветом изображении. Однотонный JPEG 20000x20000 пикслей занимает 12Mb. На нем уже падало.

tothehood2 · **Добавлено:** 03.04.2012 11:44

Victor Pomortseff писал(а):

tothehood2 писал(а):

http://antalos.com/gps/RMPCreator04.zip

- добавлен аналог RMP Calculator - "geoTIFF export scale" - выбираем модель навигатора, вводим нужный масштаб. Теперь открываем в GM окно экспорта в geoTiff и жмем F9 - рассчитанные настройки должны автоматом прописаться в окне.

Тут бы еще поподробнее как это должно работать...

Математика полностью совпадает с вашим RMP Calculator.
1. Выбираем модель устройства, вводим нужный масштаб в метрах.
2. Переходим в окно GM, там выбираем File -> Export to raster
3. Выбираем geoTiff, жмем Ok
4. В открывшемся окне с настройками экспорта жмем F9 - если все прошло ок, то в настройках X-axis / Y-axis Sample Spacing/Scale автоматом появятся новые рассчитанные значения.

Тестировал я на GM 13. Возможно на других версиях работать не будет.

Результаты тестов по масштабу. Плюсиком отмечены уровни зума, на которых отображалась карта.

Victor Pomortseff · **Добавлено:** 03.04.2012 11:56

tothehood2 писал(а):

Victor Pomortseff писал(а):

tothehood2 писал(а):

http://antalos.com/gps/RMPCreator04.zip

- добавлен аналог RMP Calculator - "geoTIFF export scale" - выбираем модель навигатора, вводим нужный масштаб. Теперь открываем в GM окно экспорта в geoTiff и жмем F9 - рассчитанные настройки должны автоматом прописаться в окне.

Тут бы еще поподробнее как это должно работать...

Математика полностью совпадает с вашим RMP Calculator.
1. Выбираем модель устройства, вводим нужный масштаб в метрах.
2. Переходим в окно GM, там выбираем File -> Export to raster
3. Выбираем geoTiff, жмем Ok
4. В открывшемся окне с настройками экспорта жмем F9 - если все прошло ок, то в настройках X-axis / Y-axis Sample Spacing/Scale автоматом появятся новые рассчитанные значения.

Тестировал я на GM 13. Возможно на других версиях работать не будет.

GM13 Rus. Не работает.

P.S. Я Вам писал, что это не так просто :-)

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

Строго говоря, нужно сначала переключиться на вкладку "Экспорт границ". Там выставить радиобаттон "Global projection", потом взять из соответсвующих полей значения. Потом переключиться на вкладку "Настройки GeoTIFF", убедиться что незакрыжен чекбокс про квадратные пиксели, потом уже вставить значения в нужные поля. И при этом, искать окно, как минимум, нужно независимо от его заголовка (чтобы не зависеть от языка)...

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

Ей богу, проще самому отресамплитиь картинку :-)

tothehood2 · **Добавлено:** 03.04.2012 12:01

Victor Pomortseff писал(а):

GM13 Rus. Не работает.

P.S. Я Вам писал, что это не так просто :-)

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

Строго говоря, нужно сначала переключиться на вкладку "Экспорт границ". Там выставить радиобаттон "Global projection", потом взять из соответсвующих полей значения. Потом переключиться на вкладку "Настройки GeoTIFF", убедиться что незакрыжен чекбокс про квадратные пиксели, потом уже вставить значения в нужные поля. И при этом, искать окно, как минимум, нужно независимо от его заголовка (чтобы не зависеть от языка)...

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

Ей богу, проще самому отресамплитиь картинку :-)

На самом деле все не так сложно, пяток вызовов winAPI и все. Затык в языке, так как у меня ищет окна по заголовку. Скиньте как у вас называются подчеркнутые опции:

Victor Pomortseff · **Добавлено:** 03.04.2012 12:07

Victor Pomortseff · **Добавлено:** 03.04.2012 12:28

А вот попробуйте-ка новый RMPCalc http://depositfiles.com/files/h7slsdttl
На тех картах, что я тестировал удалось добиться такого расчета коэффициентов, при котором карта ложится ровно на узлы сетки, без черных полей :-)

tothehood2 · **Добавлено:** 03.04.2012 13:18

RMP Creator 0.5: http://antalos.com/gps/RMPCreator05.zip

- Исправлена ошибка с картами у которых верхний левый угол совпадал с узлом сетки тайлов
- Добавлена поддержка gdal_translate для нарезки на тайлы больших изображений. Внешняя программа используется если ширина или высота изображения больше настроек "If image width/height >" или стоит галка "always". Работает намного медленнее, нарезка 4772х6757 тиффа внутренними ресурсами проходит за 10 секунд, а при использовании внешней - за минуту двадцать секунд. Но для больших изображений выбора особо нет.
- Добавил поддержку русского GM 13 (не проверял) для установки масштаба

Victor Pomortseff · **Добавлено:** 03.04.2012 13:24

tothehood2 писал(а):

Добавил поддержку русского GM 13 (не проверял) для установки масштаба

Работает, но только если руками снимешь галку "всегда создавать квадратные пиксели". А должна провертяь и при необходимости сама снимать... А также устанавливать Global projection... в границах экспорта...

tothehood2 · **Добавлено:** 03.04.2012 13:32

Victor Pomortseff писал(а):

tothehood2 писал(а):

Добавил поддержку русского GM 13 (не проверял) для установки масштаба

Работает, но только если руками снимешь галку "всегда создавать квадратные пиксели". А должна провертяь и при необходимости сама снимать... А также устанавливать Global projection... в границах экспорта...

Global Projection у меня само автоматом устанавливается. И настройки устанавливает даже при стоящей галке.

Victor Pomortseff · **Добавлено:** 03.04.2012 13:45

tothehood2 писал(а):

Victor Pomortseff писал(а):

tothehood2 писал(а):

Добавил поддержку русского GM 13 (не проверял) для установки масштаба

Работает, но только если руками снимешь галку "всегда создавать квадратные пиксели". А должна провертяь и при необходимости сама снимать... А также устанавливать Global projection... в границах экспорта...

Global Projection у меня само автоматом устанавливается. И настройки устанавливает даже при стоящей галке.

Не устанавливается. И настройки при стоящей галке не ставятся.

Victor Pomortseff · **Добавлено:** 04.04.2012 07:07

tothehood2 писал(а):

Victor Pomortseff писал(а):

На самом деле все не так сложно, пяток вызовов winAPI и все. Затык в языке, так как у меня ищет окна по заголовку. Скиньте как у вас называются подчеркнутые опции:

А можно выложить скриншот вкладки Export Bounds?

tothehood2 · **Добавлено:** 04.04.2012 08:52

Victor Pomortseff · **Добавлено:** 04.04.2012 08:53

Спасибо

Victor Pomortseff · **Добавлено:** 04.04.2012 13:21

Вот вам новая версия RMPCalc - http://depositfiles.com/files/yey82huzn

Все делает сама :-)

Запускаем GM, загружаем карту, делаем что надо, выбираем Экспорт растра, выбираем GeoTIFF. Как только появилось окно GeoTIFF Export Options, запускаем RMPCalc и жмем на кнопку "Получить данные из GM". Если все нормально, то, GM сам должен переключиться на вкладку "Экспорт границ", там должен выбраться пункт "Global Projection..." и поля Север-Юг-Запад-Восток в RMPCalc должны заполниться соответствующими значениями.

Теперь нажимаем кнопку "Считать" - в полях X-ось и Y-ось должны появиться значения коэффициентов. После этого нажимаем "Передать данные в GM" - там автоматически произойдет переключение на вкладку "GeoTIFF настройки", автоматически будет выбран формат "8-бит палитра", автоматически снята галка "Всегда создавать квадратные пиксели" и поля с коэффициентами заполнятся нужными значениями - останется только нажать OK.

Опция "Выравнивать по сетке тейлов" корректироует коэффициенты таким образом, чтобы углы карты ложились ровно в узлы сетки тейлов (см. http://xt.ht/phpbb/viewtopic.php?f=118&t=62113&start=45#p694639 и http://xt.ht/phpbb/viewtopic.php?f=118&t=62113&start=45#p694925)

Victor Pomortseff · **Добавлено:** 05.04.2012 07:41

Окончательная версия RMPCalc http://depositfiles.com/files/ei570f85m

Добавил выбор модели устройства.

На этом, видимо, все - болше не знаю чего туда еще можно прикрутить :-)

Victor Pomortseff · **Добавлено:** 05.04.2012 09:05

Ошибочка вышла... У 710-го экран не такой как у 510/610.
И еще одну ошибку нашел...

Поправил - http://depositfiles.com/files/vdeovwm3w

tothehood2 · **Добавлено:** 06.04.2012 18:33

http://antalos.com/gps/RMPCreator055.zip
- поправил калькулятор масштабов (ставит галку для проекции, снимает для Square Pixels)
- добавил экспы 510/610/710

tothehood2 · **Добавлено:** 11.04.2012 16:23

Набросал небольшой мануал:
http://antalos.com/gps/rmp-creator.php

Vyacheslav · **Добавлено:** 06.05.2012 00:21

Просмотрел вроде всю тему, но ничего подобного не нашел. У меня при нажатии на кнопку "Create RMP" программа вылетает с ошибкой:

OS: Windows7 x64

Paganel · **Добавлено:** 06.05.2012 20:35

У меня тоже вылетало при каких то определенных действиях. Но я не помню когда. Кажется при конвертировании файлов Ozi.

vituser · **Добавлено:** 08.05.2012 03:24

Я просто добавил что он просит и всё. Еще несколько подобных просил.

Paganel · **Добавлено:** 28.05.2012 16:04

А что он просил и где это взять?
У меня он просил LYBEAY32.DLL

vituser · **Добавлено:** 30.05.2012 04:39

Да гуглом нашел. Библиотеки из С++ похоже. Он ещё просил несколько, там же отыскал.

Paganel · **Добавлено:** 30.05.2012 08:54

Я тоже нашел, но у меня не находит 110 вход в какой то библиотеке. Было бы неплохо собрать архивчик со всем нужным.

Проект заглох или нет? Мне так и не удалось нормально пользоваться программой. Во многих случаях брешет с координатами. Надо еще серьезно тестировать.

vituser · **Добавлено:** 31.05.2012 02:09

После неоднократной попытки прогнать файл размером 250-300 Мбайт, мне стало неинтересно.
Зависает наглухо. Меньше - нет проблем.

UrikEEE · **Добавлено:** 31.05.2012 07:27

Я использую geoTIFFtoRMP (версия 0.95). Полет нормальный. Я этой утилитой обрабатывал (в один rmp-файл) вплоть до 256 tiff-файлов (каждый размерами около 4000х4000 точек). Полученный rmp-файл имеет размеры 550-700 мегабайт (на самом деле я формировал несколько rmp-файлов для разных районов) и нормально работает на 510-м эксплористе.

Пожалуй, мне сейчас достаточно 3 программ: Global Mapper, geoTIFFtoRMP ну еще иногда MobAC (когда надо на скорую руку по быстрому получить небольшой rmp-атлас).

Калиныч · **Добавлено:** 31.05.2012 15:16

UrikEEE писал(а):

Я использую geoTIFFtoRMP (версия 0.95). Полет нормальный.

Файл rmp получается почти в два раза меньше по размеру чем в MOBAC. В нескольких случаях исходный геотифф не хотел конвертироваться, хотя MOBAC его кушал. Если бы добавить в программу комментарии-трассер, что она в данный момент делает, было бы замечательно. Еще не нашел зависимость, почему некоторые полученные файлы rmp не хотят исполняться, и в VP высвечиваются контуром, но не показывается растр при уменьшении зума или вообще не высвечивается даже контур.

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

ILLi4 · **Добавлено:** 13.07.2012 11:41

есть проблемы:
1. загружаю в ГМ шесть 500-метровок. обрезаю как написано в http://antalos.com/gps/ozi-to-geotiff.php, но восток и запад режет нормально, а вот север и юх обрезает не правильно.
2. ошибка при сохранении в РМПкриейтор "не найден файл libeay32.dll"
что делаю не правильно?

zmiys · **Добавлено:** 31.07.2012 12:02

Добрый день. Уважаемый Victor Pomortseff при попытке получить данные из GM( 13 RUS ) возвращает ошибку '65.3439932557661' is not a valid floating point value.
Версия RMP Calculator последняя из Вашего поста от 05.04.2012 09:05.
С уважением В.Змиевский.

Victor Pomortseff · **Добавлено:** 31.07.2012 12:55

zmiys писал(а):

Добрый день. Уважаемый Victor Pomortseff при попытке получить данные из GM( 13 RUS ) возвращает ошибку '65.3439932557661' is not a valid floating point value.

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

zmiys · **Добавлено:** 31.07.2012 13:27

Большое спасибо.
С уважением В.Змиевский.

demid-v · **Добавлено:** 29.08.2012 22:00

Вопрос к tothehood2: при создании атласа из одинаковых по масштабу карт вылетает ошибка: "ERR while crafting a00/tlm files".
Файлы закачаны SAS планетой и обработаны Global Mapper 13 для получения геотиффов размером ~ 5800*5500 пикселей (слой Z18). Создавал атласы из 4-х квадратов, причем некоторые атласы RMP creator отработал без ошибок, а другие квадраты ни в какую не хочет - в чём может быть причина?
Программа Шаронова обрабатывает все квадраты нормально, но меня не устраивают черные полосы на стыках.
Может, кто сталкивался с такой проблемой?

tothehood2 · **Добавлено:** 23.09.2012 19:08

demid-v писал(а):

Вопрос к tothehood2: при создании атласа из одинаковых по масштабу карт вылетает ошибка: "ERR while crafting a00/tlm files".
Файлы закачаны SAS планетой и обработаны Global Mapper 13 для получения геотиффов размером ~ 5800*5500 пикселей (слой Z18). Создавал атласы из 4-х квадратов, причем некоторые атласы RMP creator отработал без ошибок, а другие квадраты ни в какую не хочет - в чём может быть причина?
Программа Шаронова обрабатывает все квадраты нормально, но меня не устраивают черные полосы на стыках.
Может, кто сталкивался с такой проблемой?

залейте куда-нибудь тиффки, на которых вылетает - посмотрю в чем может быть причина

demid-v · **Добавлено:** 24.09.2012 23:36

tothehood2 писал(а):

залейте куда-нибудь тиффки, на которых вылетает - посмотрю в чем может быть причина

Как ни странно, но сейчас всё работает без сбоев

Скорее всего, была проблема с библиотеками (libeay32.dll и другие). В установочном пакете их нет, пришлось искать что-то подобное в интернете, но нормальной работы я не добился. Тогда написал в этот форум - тоже ответа не было... Опять стал копать в интернете, скачал несколько архивов. Методом научного тыка пробовал разные версии, и вроде бы нашел нужную, т.к. сейчас при склейке в атлас 4-х кусков с результирующим размером более 10000*10000 ошибка не возникает (большие куски не пробовал, поскольку незачем, но наверное, тоже будет работать).
Попутно хотелось узнать: будут ли новые версии этой замечательной программы - хотелось, чтобы она была не только в оконном режиме, но и в полноэкранном, чтобы было видно имена файлов (сейчас "хвосты" уходят на правый обрез окна) :dance:

Paganel · **Добавлено:** 25.09.2012 08:41

Кстати не стоит ли выложить полный проверенный набор необходимых библиотек?

tothehood2 · **Добавлено:** 26.09.2012 02:43

Если у кого-нибудь есть - выложите пожалуйста, потому что уменя под win7 x64 тоже не заработало.

demid-v · **Добавлено:** 26.09.2012 21:37

Под Семеркой не пробовал, работает под ХР сервиспак 3. НО: при копировании папки с программой в другое место - там она отказывается работать (т.е. выдаёт ту же ошибку err while crafting a00/tlm files) :mad:

Paganel · **Добавлено:** 27.09.2012 08:17

А где же все таки пакет DLL-ек?

tothehood2 · **Добавлено:** 27.09.2012 20:57

Я буду собирать из билдов GDAL, как соберу - залью и отпишусь здесь.

Paganel · **Добавлено:** 03.10.2012 12:56

Народ жалуется. Ссылка со страницы http://antalos.com/en/gps/rmp-creator.php на скачивание программы
ведет на 404. На русской странице все нормально.

tothehood2 · **Добавлено:** 08.10.2012 23:27

http://antalos.com/bin/RMPCreator056.zip

- добавил все необходимые библиотеки (надеюсь все, протестировал на win7x64, win xp)
- изменяемый размер окна

demid-v · **Добавлено:** 09.10.2012 00:19

Спасибо огромное! Всё работает отлично!

Один только нюанс - при расширении окна вниз "градусник" (прогресс бар) остается на месте и в конце концов пропадает из поля видимости. Но это, конечно, мелочи, главное - в ширину раздвигается без проблем!

Paganel · **Добавлено:** 09.10.2012 09:24

Будешь ставить прогрессбар на место, заодно выровняй левый край таблицы, бар и кнопки Remove Clear с отступом от края окна как справа и как у кнопки Open. Это на функциональность не виляет, но создает впечатление некоторой доморощенности программы.

tothehood2 · **Добавлено:** 25.11.2012 23:58

http://antalos.com/gps/rmp-creator.php - выложил версию 0.9

Основные изменения:
- исправлены утечка памяти в нарезке тайлов и при генерации tlm. Теперь большой растр я собираю в RMP, не используя внешний нарезчик тайлов. Из GM экспортирую растр кусками размером 10000х10000 пикселей (добавил этот пункт в инструкцию - http://antalos.com/gps/ozi-to-geotiff.php), а затем их собираю в один RMP файл, используя встроенный нарезчик. Так получается намного быстрее, чем с использованием внешнего

- Добавлена настройка уровня качества JPEG, который создается для RMP. Может быть числом от 1 до 100. Выше 80 смысла поднимать особо нету, размер файла растет сильно, а качество - почти нет. Я использую 75, раньше стояло жестко заданный уровень качества 90, что давало на выходе большие файлы.

- Рассчитанные в градусах размеры для экспорта geoTiff теперь пишутся еще и в текстовом виде - можно будет задать их руками.

- Выложил исходники - https://github.com/antalos/RMPCreator

demid-v · **Добавлено:** 26.11.2012 20:27

Отлично! Спасибо!!

Paganel · **Добавлено:** 27.11.2012 09:39

tothehood2 писал(а):

- Рассчитанные в градусах размеры для экспорта geoTiff теперь пишутся еще и в текстовом виде - можно будет задать их руками.

В таком случае их проще задать прямо в метрах на пиксел в самом ГМ, что я обычно и делаю не мороча себе голову градусами.

Калиныч · **Добавлено:** 28.11.2012 10:35

tothehood2 писал(а):

выложил версию 0.9 ...

При конвертации Geotif в rmp происходит ошибка "[err] while tiling image". При этом MOBAC файл конвертирует. В чем дело? Большой размер, 50 Mb? Меньшего размера конвертирует без проблем.

be2611 · **Добавлено:** 28.11.2012 15:32

Калиныч писал(а):

tothehood2 писал(а):

выложил версию 0.9 ...

При конвертации Geotif в rmp происходит ошибка "[err] while tiling image". При этом MOBAC файл конвертирует. В чем дело? Большой размер, 50 Mb? Меньшего размера конвертирует без проблем.

Была такая проблема, когда запускал RMP Creator из Program Files. Вероятно, дело в пробеле в имени папки, перенёс в папку с именем пути без пробелов - всё пошло. Хорошо бы этот момент подкорректировать

tothehood2 · **Добавлено:** 28.11.2012 18:34

Калиныч писал(а):

Меньшего размера конвертирует без проблем.

Пришлите ссылку на geoTiff - посмотрю.

tothehood2 · **Добавлено:** 28.11.2012 18:35

be2611 писал(а):

Калиныч писал(а):

tothehood2 писал(а):

выложил версию 0.9 ...

При конвертации Geotif в rmp происходит ошибка "[err] while tiling image". При этом MOBAC файл конвертирует. В чем дело? Большой размер, 50 Mb? Меньшего размера конвертирует без проблем.

Была такая проблема, когда запускал RMP Creator из Program Files. Вероятно, дело в пробеле в имени папки, перенёс в папку с именем пути без пробелов - всё пошло. Хорошо бы этот момент подкорректировать

Спасибо, гляну. Исправил, новая версия - http://antalos.com/bin/RMPCreator091.zip

be2611 · **Добавлено:** 28.11.2012 23:03

Можно ещё маленькую хотелку? По окончании создания .rmp во временной папочке остаются подпапочки с именами "forrmp" и "tiles". Можно подправить, чтобы они удалялись по окончании процесса?
И ещё вопрос по поводу настройки уровня качества jpeg. Пробую при сборке атласа из 3-х GeoTIFF менять настройки качества от 50 до 100. При этом выходные .rmp получаются одинаковыми, проверял бинарным сравнением. Отличия только во времени создания атласа, которое прописывается в информационном блоке внутри файла. В чём тут дело? Кроме того, настройка качества не сохраняется в .ini, если не очистить список файлов кнопочкой Clear и попытаться создать атлас из уже имеющегося списка файлов с другой настройкой качества.

tothehood2 · **Добавлено:** 29.11.2012 11:48

be2611 писал(а):

Можно ещё маленькую хотелку? По окончании создания .rmp во временной папочке остаются подпапочки с именами "forrmp" и "tiles". Можно подправить, чтобы они удалялись по окончании процесса?
И ещё вопрос по поводу настройки уровня качества jpeg. Пробую при сборке атласа из 3-х GeoTIFF менять настройки качества от 50 до 100. При этом выходные .rmp получаются одинаковыми, проверял бинарным сравнением. Отличия только во времени создания атласа, которое прописывается в информационном блоке внутри файла. В чём тут дело? Кроме того, настройка качества не сохраняется в .ini, если не очистить список файлов кнопочкой Clear и попытаться создать атлас из уже имеющегося списка файлов с другой настройкой качества.

http://antalos.com/bin/RMPCreator092.zip
- настройка JPEG quality теперь корректно работает и сохраняется
- временные файлы удаляются после генерации RMP

be2611 · **Добавлено:** 29.11.2012 13:53

tothehood2 писал(а):

- настройка JPEG quality теперь корректно работает и сохраняется
- временные файлы удаляются после генерации RMP

Благодарю, заработало, как надо. Остался совсем мелкий нюанс по второму пункту, удаляется содержимое временных папок, а сами папки нет.

Калиныч · **Добавлено:** 30.11.2012 09:53

Пересоздал файл из Ози в Геотиф, со всеми рекомендациями по тайлам, использовал кнопку set под магеллан 310. В новой версии 092 объединенный файл rmp создался, но в Vantage Point его не видно, даже контура нет. Попробую еще варианты.

tothehood2 · **Добавлено:** 30.11.2012 10:17

Калиныч писал(а):

Пересоздал файл из Ози в Геотиф, со всеми рекомендациями по тайлам, использовал кнопку set под магеллан 310. В новой версии 092 объединенный файл rmp создался, но в Vantage Point его не видно, даже контура нет. Попробую еще варианты.

Киньте файл ози для проверки

Калиныч · **Добавлено:** 30.11.2012 11:52

на рабочем месте не получится, ресурсы заблокированы, вечером или в выходные выложу.

Калиныч · **Добавлено:** 03.12.2012 06:59

Калиныч писал(а):

на рабочем месте не получится, ресурсы заблокированы, вечером или в выходные выложу.

Домашний интернет в нашей деревне по USB модему был никакой, даже сообщение не ушло на форум. Через день-два меняю работодателя, может ситуация по безопасности изменится. На домашнем нетбуке под win_хр файл rmp создался нормально, тех же размеров, что и на рабочем компе под win7, и в Vantage Point показывается контуром и включается на нужном зуме. Видимо проблемы с win7. Не резанный цельный Геотиф с библиотекой gdal не конвертируется, по рекомендации добавлю библиотек от C++.

Alhimik · **Добавлено:** 14.01.2013 16:40

Скачал сегодня "RMP Creator 0.92".
1.Внизу нет кнопок Remove, Clear,Visualise. Это только у меня?(win7x64)
2.При попытке конвертировать тайлы >10000 pix программа вылетает.
3. Что делать с папкой gdal?
3. Из формата ozi не конвертирует - вылетает. Хотя TritonRMP справляется.

Подскажите пожалуйста, в чем дело?

demid-v · **Добавлено:** 14.01.2013 20:12

1. На Семерке не пробовал, а на ХР все кнопки на месте.
2. Иногда, бывает, что вылетает с ошибкой err while tiling ... закономерности пока не понял,но в целом с большими картинками работает нормально. ТОлько я не вижу смысла создавать такие большие rmp, во-первых, долго конвертится, во-вторых, магеллану пофиг - одна большая карта или десять маленьких. Может, стоит попробовать склеивать карты в самом RMP Creatore?

tothehood2 · **Добавлено:** 17.01.2013 01:02

Alhimik писал(а):

Скачал сегодня "RMP Creator 0.92".
1.Внизу нет кнопок Remove, Clear,Visualise. Это только у меня?(win7x64)
2.При попытке конвертировать тайлы >10000 pix программа вылетает.
3. Что делать с папкой gdal?
3. Из формата ozi не конвертирует - вылетает. Хотя TritonRMP справляется.

Подскажите пожалуйста, в чем дело?

1. у меня на win7x64 все ок
2. покажите карту
3. это служебные утилиты, которые используются при конвертации карт
4. покажите карту

vituser · **Добавлено:** 17.01.2013 10:51

Alhimik писал(а):

Скачал сегодня "RMP Creator 0.92".
1.Внизу нет кнопок Remove, Clear,Visualise. Это только у меня?(win7x64)
Подскажите пожалуйста, в чем дело?

Ноутбук? У меня в буке 15" так же.

Alhimik · **Добавлено:** 17.01.2013 12:17

tothehood2 писал(а):

1. у меня на win7x64 все ок
2. покажите карту
3. это служебные утилиты, которые используются при конвертации карт
4. покажите карту

1. Да, у меня ноут, разрешение 900х1600 и кнопок внизу нет. И прогресс-бар справа не появляется, когда должен. Приходится программу закрывать-открывать, чтобы удалить карты.

2. Вот карта ози https://dl.dropbox.com/u/49886834/east_crimea.rar Уже разобрался, что там по одной стороне 11300 пикселей, ставлю в программе вместо 10000 12000 и все конвертит. НО!!! получается неверная привязка, ошибка до 600м. А в ози ошибка до 30м. При конвертировании через GeoTiff привязка нормальная получается. попробовал RMP Creator 0.93 проблема с ошибкой привязки при конвертации Ози-файлов осталась. Через GeoTiff нормально.

3. Папку gdal нужно оставить в папке где программа RMP Creator 0.92? Файлы из неё нужно вытаскивать? Или лучше эти библиотеки в Windows/system32 поместить?

tothehood2 · **Добавлено:** 17.01.2013 14:58

1. Покажите скрин
2. Возможно GM сам как-то правит растр при экспорте в Tiff. При конвертации из .map у меня тоже ошибка наблюдается. Как будет время - посмотрю.
3. Нет, ничего никуда переносить не надо

Alhimik · **Добавлено:** 17.01.2013 16:08

tothehood2 писал(а):

1. Покажите скрин

Вот скрин https://dl.dropbox.com/u/49886834/screen.rar

tothehood2 · **Добавлено:** 17.01.2013 19:22

RMP Creator 0.94
В новой версии форма должна корректно отображаться при увеличенном системном шрифте

Alhimik · **Добавлено:** 17.01.2013 20:03

Все кнопки есть! Спасибо! За такую программу и подробный мануал и заплатить не жалко!

demid-v · **Добавлено:** 17.01.2013 22:06

Экспериментировал с созданием RMP-файла и заметил такую интересную особенность.
В GM собрал большую карту размером намного больше, чем 10000х10000.
Преобразовал карту в GeoTIFF: в первом случае в 8-битной палитре, а во втором - в 24-битной.
RMPcreator 8-битную конвертировал, а 24-битную - выплюнул!
Проверил на разных картах - результат тот же...

be2611 · **Добавлено:** 17.01.2013 22:06

Совершенно случайно выявилась ещё одна ошибочка:
"[err] while tiling image" в случаях, если в пути к месту расположения программы
и/или в пути и имени исходного .tif файла присутствуют русские символы.
Ошибка имеет место при использовании внешнего обработчика gdal_translate

Видимо, при формировании .bat надо использовать 866 таблицу, а не 1251.

tothehood2 · **Добавлено:** 18.01.2013 21:25

demid-v, be2611, спасибо за сообщения об ошибках.
Скачать RMP Creator 0.95
- исправлена работа с кириллическими символами в путях
- внешняя нарезка (gdal) на тайлы теперь поддерживает 24-битные tiff, png c альфа-каналом
- исправлена ошибка, возникающая при нарезании на тайлы с помощью gdal, если получился тайл с высотой 1 пиксель
- переделан вызов gdal, что ускорило нарезку на тайлы при его использовании

Alhimik · **Добавлено:** 20.01.2013 13:54

У меня не работает рассчёт масштаба при экспорте в geotiff. Вроде все делаю как в мануале: GM13-экспорт растра-геотифф-в RMP Creator 0.95 ставлю модель и масштаб, жму set или F9, сразу переключается на вкладку настроек экспорта, но там ничего не меняется, задаю другой масштаб-нет изменений. В окне RMP Creator, где должны появиться рассчитанные масштабы, пусто, или нули.
На всякий случай скрин https://dl.dropbox.com/u/49886834/screen2.jpg

Paganel · **Добавлено:** 20.01.2013 18:34

Я вообще не понимаю зачем это. В ГМ в окне экспорта можно вводить разрешение в метрах на пиксел. 4-5 рассчитанных значений я помню наизусть, да и точно соблюдать их не обязательно.

Alhimik · **Добавлено:** 20.01.2013 19:05

Да удобно ведь, более наглядно получается с этим калькулятором. И многие не знают, как в окне экспорта метры на пиксель ставить. Тогда нужно это в мануал дописать, и значения для разных масштабов указать. Но лучше доделать калькулятор, так меньше вариантов наделать ошибок. Смотришь модель навигатора, масштаб на карте и всё! А так нужно узнать сначала сколько метров на пиксел соответствуют твоему навигатору и карте, потом вызвать дополнительное окно в GM, там переставить метры, ввести их 2 раза...

Paganel · **Добавлено:** 20.01.2013 21:55

Я не спорю, но у меня то версия ГМ то версия конвертера и в результате масштаб так ни разу передать и не удалось.

Я и плюнул.
А еще полезно смотреть, какой масштаб получился из карты и стоит ли его менять чтобы из 6 метров на пиксел сделать 4. По моему лучше оставить то, что было.

tothehood2 · **Добавлено:** 21.01.2013 21:19

Alhimik писал(а):

У меня не работает рассчёт масштаба при экспорте в geotiff. Вроде все делаю как в мануале: GM13-экспорт растра-геотифф-в RMP Creator 0.95 ставлю модель и масштаб, жму set или F9, сразу переключается на вкладку настроек экспорта, но там ничего не меняется, задаю другой масштаб-нет изменений. В окне RMP Creator, где должны появиться рассчитанные масштабы, пусто, или нули.
На всякий случай скрин https://dl.dropbox.com/u/49886834/screen2.jpg

http://antalos.com/gps/rmp-creator.php - залил 0.51, процесс обмена данными между GM и RMP Creator изменен. Думаю теперь заработает.

Alhimik · **Добавлено:** 21.01.2013 22:13

Данные передаются! Спасибо!

tothehood2 · **Добавлено:** 29.01.2013 01:23

RMP Creator 0.96
- если встроенному нарезчику тайлов не хватает памяти, то внешний будет запускаться автоматически
- в статус-баре показывается немного дополнительной информации
- прогресс бар теперь корректно отображает прогресс при работе с большими файлами
- исправлена ошибка при открытии .map файла с абсолютным путем к растровому файлу

demid-v · **Добавлено:** 29.01.2013 22:43

tothehood2 писал(а):

RMP Creator 0.96
...
- прогресс бар теперь корректно отображает прогресс при работе с большими файлами
...

Странно, но у меня прогресс-бар так и не появился :sad:

Появляется лишь окно MSDOS, где виден процесс создания тайлов, но в заголовке самой программы написано: RMP Creator v0.96 (Не отвечает)
Так что понять, когда закончится процесс затруднительно...
А во всём остальном - отлично, пока еще ни разу не вылетал с ошибкой! Один только маленький нюанс - если имя файла rmp будет совпадать с уже созданным файлом, то появляется сообщение об ошибке, хотя логичнее ожидать здесь диалогового окна с предложением о перезаписи файла.
Спасибо за такую классную программу!

Tramp · **Добавлено:** 29.01.2013 23:08

Точнее ответит разработчик, но окно доса похоже на запуск внешнего нарезчика тайтлов. В этом случае прогресс-бара в программе не будет.

tothehood2 · **Добавлено:** 30.01.2013 10:34

demid-v писал(а):

Странно, но у меня прогресс-бар так и не появился :sad:

Появляется лишь окно MSDOS, где виден процесс создания тайлов, но в заголовке самой программы написано: RMP Creator v0.96 (Не отвечает)
Так что понять, когда закончится процесс затруднительно...

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

Paganel · **Добавлено:** 30.01.2013 16:22

Alhimik писал(а):

Да удобно ведь, более наглядно получается с этим калькулятором. И многие не знают, как в окне экспорта метры на пиксель ставить. Тогда нужно это в мануал дописать, и значения для разных масштабов указать. Но лучше доделать калькулятор, так меньше вариантов наделать ошибок. Смотришь модель навигатора, масштаб на карте и всё! А так нужно узнать сначала сколько метров на пиксел соответствуют твоему навигатору и карте, потом вызвать дополнительное окно в GM, там переставить метры, ввести их 2 раза...

Я тут уже два дня спорю с Поморцевым (http://forum.gpsinfo.ru/viewtopic.php?f ... &start=153) и вырисовывается не очень корректная картина:
1. Он упрямо считает, что карты в Магелланах отображаются в географической проекции с постоянными градусами на пиксел. Но магеллан не растягивает карты северных районов. Он отображает постоянные метры на пиксел согласно линейке и по горизонтали и по вертикали. Мы снимаем галочку "Квадратные пиксели" и тем самым превращаем Geographic в подобие Equirectangoular.
2. Метры на пиксель не зависят от положения карты относительно экватора, а только от ее масштаба. Градусы в калькуляторе считаются видимо для среднепотолочной широты. Южные карты сдавлены, северные растянуты, но это компенсируется дополнительным ресамплингом навигатором, что не способствует качеству.
3. В калькуляторе написано Scale in meters, но почему то надо указывать абсолютный масштаб карты 100000 для километровки, для которой масштабом в метрах принято считать 1000 метров в одном сантиметре. Вообще то там надо указывать не масштаб карты, а градацию увеличения навигатора 1200 или 800 для километровки и среднюю широту карты. Если конечно при нарезке на тайлы ее опять не самплят на квадратные пиксели на градус.

Тут явно, что то не так.

tothehood2 · **Добавлено:** 30.01.2013 22:06

Paganel писал(а):

Тут явно, что то не так.

Пока времени разбираться нету, отписал там о формате представления данных, используемом в RMP. Может поможет придти к истине.

Victor Pomortseff · **Добавлено:** 31.01.2013 08:28

Paganel писал(а):

Я тут уже два дня спорю с Поморцевым (http://forum.gpsinfo.ru/viewtopic.php?f ... &start=153) и вырисовывается не очень корректная картина:
1. Он упрямо считает, что карты в Магелланах отображаются в географической проекции с постоянными градусами на пиксел.

То ли я не умею объяснять, то ли вы не хотите слушать.

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

Я говорил лишь о том, что в тех картах, которые мы подсовываем конвертеру, единицами измерения являются градусы. Это "медицинский факт", явно видимый в заголовке файла. И в настройках GM при переходе от исходной проекции карты к WGS84 Lat/Lon.

Ничего кроме этого я не утверждал.

Дальше в навигаторе единицы измерения уже могут пересчитываться как угодно. Как именно - покажите мне код и вам скажу.

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

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

Victor Pomortseff · **Добавлено:** 31.01.2013 12:31

tothehood2 писал(а):

RMP Creator 0.96
- в статус-баре показывается немного дополнительной информации
- прогресс бар теперь корректно отображает прогресс при работе с большими файлами

Небольшая погрешность.

Загружаю два файла 1.tif и 2.tif. Нажимаю "Создать RMP" (указано "каждый tif в отдельный rmp).

В статус баре отображается 1.tif и 1/1. И так висит все время. И когда 1.tif обрабатывается и когда 2.tif обрабатывается.

Хотя, как я понимаю, в момент обработки 1.tif там должно быть

1.tif 1/2

а в момент обработки 2.tif

2.tif 2/2

Правильно?

tothehood2 · **Добавлено:** 31.01.2013 12:36

Victor Pomortseff писал(а):

tothehood2 писал(а):

RMP Creator 0.96
- в статус-баре показывается немного дополнительной информации
- прогресс бар теперь корректно отображает прогресс при работе с большими файлами

Небольшая погрешность.

Загружаю два файла 1.tif и 2.tif. Нажимаю "Создать RMP" (указано "каждый tif в отдельный rmp).

В статус баре отображается 1.tif и 1/1. И так висит все время. И когда 1.tif обрабатывается и когда 2.tif обрабатывается.

Хотя, как я понимаю, в момент обработки 1.tif там должно быть

1.tif 1/2

а в момент обработки 2.tif

2.tif 2/2

Правильно?

Да, это занесено на исправление - в режиме атласа все ок, в режиме каждый в отдельный файл - неверно показывает

Paganel · **Добавлено:** 31.01.2013 13:32

Victor Pomortseff писал(а):

Я не знаю как карта отображается в навигаторе. Я не видел кода его программы, поэтому сказать ничего не могу. А гадать не хочу (есть ряд предположений, но оставлю их при себе т.к. это мои личные предположенния, основанные на том, как решал бы эту задачу я сам).
...
Я говорил лишь о том, что в тех картах, которые мы подсовываем конвертеру, единицами измерения являются градусы. Это "медицинский факт", явно видимый в заголовке файла. И в настройках GM при переходе от исходной проекции карты к WGS84 Lat/Lon.
...
В своем калькуляторе (RMPCalc) я считаю коэффициенты ресамплинга в тех единицах, которые требуются для GM. А именно в градусах на пиксель. И точное значение коэффициентов зависит от модели навигатора (разрешение экрана и его физические размеры), масштаба карты и "положения листа на глобусе". Последнее тоже важно т.е. пересчет идет через метры - расстояние между границами карты на местности (тут используются алгоритмы из ProjLib - кому надо, может сам найти).

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

Проводим эксперимент. Берем карту посевернее. Я взял пятикилометровку R-36-1,2 по всем правилам откалибровал ее в ГМ.

Первую карту я сохранил с разрешением указанным в метрах по моей табличке - 68.57 mpp, что соответствует масштабу навигатора 4.8 км. Размер изображения уменьшился на 10% и карта сохранила исходные пропорции:

Вторая карта сделана в полном соответствии с описанием RMPCreator с использованием встроенного калькулятора, где был указан масштаб карты 500000 и передан в ГМ. Галка "квадратные пиксели" в обоих случаях была снята.
Изображение уменьшилось по ширине в полтора раза, а по высоте в три. Карта выглядит сильно сдавленной по вертикали. Масштаб карты карты получился по горизонтали 104.18 mpp, а по вертикали 180.62, что где то в районе десятикилометровки.

Все это было бы фигней, если бы не разница в конечном результате.

Карта с масштабом в метрах:

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

Немного более лучшего результата можно добиться, если сохранять карту в исходном разрешении и уменьшать в Photoshop.

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

Что делать с калькулятором, решайте сами.

Я бы доработал RMPCreator, чтобы он мог принимать Geotiff в проекции Rectangular, которая является правильной для навигаторов Магеллан, как впрочем и Гармин. Я не строил предположений. Я просто спросил у разработчиков.

Glock · **Добавлено:** 01.02.2013 10:15

Во истину в споре рождается истина. Благодаря Вам ребята а не каким то разработчикам из фирм производителей навигационного оборудования, данные навигаторы становятся наиболее популярны.

tothehood2 · **Добавлено:** 01.02.2013 11:11

В свете последних тестов одинаковых карт (с одинаковым м/пиксель) на GC/610 выяснилось, что DPI прибора вообще не влияет на уровни зума, на которых отображается карта. Карты с одинаковым разрешением показываются на одинаковых уровнях в разных приборах.

То есть видимо софт, исходя из разрешения карты как-то сам оценивает на каких уровнях ее показывать, не учитывая DPI

Paganel · **Добавлено:** 01.02.2013 18:50

Софт мыслит в пикселях, а на разницу в размерах экранов ему наплевать. Линейка, что в 310, что в 710 длиной 70 пикселей и на ней указываются одинаковые значения масштабов. То есть он учитывает метры на пиксел.

Victor Pomortseff · **Добавлено:** 04.02.2013 09:23

Paganel писал(а):

Софт мыслит в пикселях, а на разницу в размерах экранов ему наплевать. Линейка, что в 310, что в 710 длиной 70 пикселей и на ней указываются одинаковые значения масштабов. То есть он учитывает метры на пиксел.

Э-э-э... А при чем тут длина линейки в пискселях?

Я приводил уже пример:

Одна и та же карта. Один и тот же масштаб отображения. Разница в том, что в первом случае карта без ресамплинга ("неправильное" разрешение оригинала), во втором - с ресамплингом ("правильное" разрешение).

Что характерно, качество картинки в "неправильном" разрешении выше. Что, если подумать, вполне логично.

Разница тут исключительно в том, в каком интервале масштабов будет отображаться данная карта. только и всего.

Собственно говоря, можно и карту с разрешением 1 метр на пиксель и карты с разрешением 100 метров на пиксель рисовать в одном и том же масштабе отображения. Разница будет исключительно в коэффициентах масштабирования. И степени искажений - растр масштабируется в достаточно узком диапазоне значения коэффициента масштабирования. Дальше начинаются слишком большие искажения. Именно из этих соображений и выбирается диапазон масштабов отображения карты. Исходной точкой является коэффициент 1. Т.е. попиксельный вывод карты на экран без масштабирования. Ну и от него плюс-минус две ступени масштаба в сторону увеличения и уменьшения. Дальше уже сильно страдает читаемость карты.

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

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

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

Paganel · **Добавлено:** 05.02.2013 20:22

А как бы добавить пару кнопочек в окно ввода координат при ручной привязке и брать по ним координаты из буфера обмена в любом удобном тебе формате:
хочешь в таком - 47.999783 33.998346
а можно и в таком - 47 59.9870 33 59.9008

Уже очень надо.

Paganel · **Добавлено:** 06.02.2013 10:27

Victor Pomortseff писал(а):

Одна и та же карта. Один и тот же масштаб отображения. Разница в том, что в первом случае карта без ресамплинга ("неправильное" разрешение оригинала), во втором - с ресамплингом ("правильное" разрешение).
Что характерно, качество картинки в "неправильном" разрешении выше. Что, если подумать, вполне логично.
Разница тут исключительно в том, в каком интервале масштабов будет отображаться данная карта. только и всего.

Естественно уменьшенная картинка смотрится лучше чем увеличенная. Это и ежу понятно. Кроме того скриншот экрана 180 дпи увеличенный на компьютерном экране 75 дпи почти в три раза смотрится еще хуже. Но я, например, покупал навигатор не картинки рассматривать.
Есть понимание разумной достаточности. Вдвое большее разрешение - в четыре раза больший файл. В eX 310 память не резиновая, а я делал карты и для Triton 300. Там вообще 20 мегабайт на все.
Потом, предположим, просканированная 400 дпи километровка фактически превращается в 500-метровку. При уменьшении до километровки она будет смотреться лучше, но другой конец зума становится почти бесполезным. Там будет один символ кустика на весь экран.

Если хотите - попробуйте идею:
В гармине уровень зума (масштаб с которого начинается отображение) задается отдельным параметром и может не соответствовать реальному разрешению карты.
В Магеллане этот параметр тоже есть. RMPCreator его просто тупо переписывает из заголовка GeoTiff. Так вот попробуйте взять карту с реальным разрешением для 400м, а масштаб в заголовок прописать как для 800м (увеличить вдвое). По моему получится именно то, что ты хочешь. Диапазон зумов должен переехать с центром на 800 и качество карты заметно улучшиться.

Если да, то можно сделать RMPCustomizer по аналогии с JNX, для просмотра и правки параметров карт.

Victor Pomortseff · **Добавлено:** 06.02.2013 11:31

Paganel писал(а):

Естественно уменьшенная картинка смотрится лучше чем увеличенная. Это и ежу понятно. Кроме того скриншот экрана 180 дпи увеличенный на компьютерном экране 75 дпи почти в три раза смотрится еще хуже. Но я, например, покупал навигатор не картинки рассматривать.
Есть понимание разумной достаточности. Вдвое большее разрешение - в четыре раза больший файл. В eX 310 память не резиновая, а я делал карты и для Triton 300. Там вообще 20 мегабайт на все.
Потом, предположим, просканированная 400 дпи километровка фактически превращается в 500-метровку. При уменьшении до километровки она будет смотреться лучше, но другой конец зума становится почти бесполезным. Там будет один символ кустика на весь экран.

Если хотите - попробуйте идею:
В гармине уровень зума (масштаб с которого начинается отображение) задается отдельным параметром и может не соответствовать реальному разрешению карты.
В Магеллане этот параметр тоже есть. RMPCreator его просто тупо переписывает из заголовка GeoTiff. Так вот попробуйте взять карту с реальным разрешением для 400м, а масштаб в заголовок прописать как для 800м (увеличить вдвое). По моему получится именно то, что ты хочешь. Диапазон зумов должен переехать с центром на 800 и качество карты заметно улучшиться.

Если да, то можно сделать RMPCustomizer по аналогии с JNX, для просмотра и правки параметров карт.

Основная моя мысль в том (попробую ее сформулировать явно), что

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

2. Ресамплинг - есть попытка обмануть прибор, уведя диапазон масштабов за границы оптимального диапазона. При этом уйти от искажений не удастся ибо большой разницы между масштабированием в приборе и ресамплингом в ГМ я не вижу. Можно поиграться с ресамплингом в мощных графических редакторах, где реализованы различные более продвинутые алгоритмы, но это потребует перепривязки карты. Хотя может и дать чуть лучший результат.

Исходя из вышесказанного я пытаюсь подвести к тому, что ресамплинг необходим в крайних случаях. Но далеко не всегда. Лично я не вижу смысла в ресаплинге ради того, чтобы сместить диапазон отображаемых масштабов на одну ступень (что имеет место быть в случае с картами ГГЦ, который я приводил в качестве примера. Собственно, вот ссылка на сообщение с полным набором скриншотов карты 500м ГГЦ, на которых видно что и без ресамплинга карта отлично читается и является информативной во всем диапазоне масштабов отображения: http://forum.gpsinfo.ru/viewtopic.php?f=13&t=10017&st=0&sk=t&sd=a&start=150#p96203.

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

Можно, конечно, попробовать поиграться с заголовком (речь идет о поле PixelSize, если правильно понимаю?) Но не уверен что это надо.

Калиныч · **Добавлено:** 31.05.2013 13:53

tothehood2 писал(а):

RMP Creator 0.96
- если встроенному нарезчику тайлов не хватает памяти, то внешний будет запускаться автоматически
- в статус-баре показывается немного дополнительной информации
- прогресс бар теперь корректно отображает прогресс при работе с большими файлами
- исправлена ошибка при открытии .map файла с абсолютным путем к растровому файлу

Спасибо разработчику. С выходом этой версии, все rmp файлы готовлю только в ней, про MOBAC забыл. Работает устойчиво и под Win7 и XP.

FamilyMan · **Добавлено:** 29.06.2013 13:46

UrikEEE писал(а):

Кстати, может кому-то пригодится вот этот скрипт для GlobalMapper (для карт с gmw-файлами привязки - это карты ГГЦ России):
...
Скопировать содержимое скрипта в текстовый файл с расширением gms (например, как "FromGMWtoTIFF.gms"), подправить значения переменных SOURCE_DIR и DEST_DIR, указав в них пути к реальным папкам, затем поместить в папку, на которую ссылается SOURCE_DIR, исходные файлы с gmw-файлами привязки и уже в GlobalMapper запустить на выполнение этот скрипт.

Я нашел похожий скрипт для конвертации png с привязкой в MAP в TIFF.

Код:

GLOBAL_MAPPER_SCRIPT VERSION=1.00

UNLOAD_ALL

DEFINE_PROJ PROJ_NAME="GEO_WGS84"
Projection GEOGRAPHIC
Datum WGS84
Zunits NO
Units DD
Xshift 0.000000
Yshift 0.000000
Parameters
0 0 0.000
END_DEFINE_PROJ

DIR_LOOP_START DIRECTORY="C:\Tiles\IN\" FILENAME_MASKS="*.MAP" RECURSE_DIR=NO

IMPORT FILENAME="%FNAME_W_DIR%"
LOAD_PROJECTION PROJ_NAME="GEO_WGS84"
EXPORT_RASTER FILENAME="C:\Tiles\OUT\%FNAME_WO_EXT%.TIF" TYPE=GEOTIFF FORCE_SQUARE_PIXELS=NO 
UNLOAD_ALL

DIR_LOOP_END

Вроде все работает только один вопрос - как в скрипте установить чтобы рассчитывался масштаб экспорта GeoTIFF (как в RMPCreator). Например для фрагмента из САСПланета зум x14 я хочу иметь тоже что в RMPCreator рассчитывает через GM для scale in meters = 40000 для Explorist 310. И для x15 - для 20000.

На тек. момент я имею на выходе:
- для x14 - карта видна на масштабе от 1200 до 400 (должно быть от 800 и ниже)
- для x15 - карта видна на масштабе от 800 до 150 (должно быть от 400 и ниже)

Не подскажете как это сделать?

UrikEEE · **Добавлено:** 01.07.2013 11:05

FamilyMan писал(а):

Не подскажете как это сделать?

Вы хотели бы сделать разные коэффициенты для разных зумов при выполнении скрипта в Global Mapper?

Немного странно это спрашивать в ветке про "geoTIFF to RMP", но тем не менее отвечу.

Если Вы хотите сделать скрипт "на все случаи жизни" (который сам бы вычислял "на лету" необходимые коэффициенты), то вынужден Вас огорчить - скриптовый язык GM очень скудный и не позволит вольностей даже типа "a = 2 + 2". Описание этого языка можно почитать здесь. Единственная зацепка - это возможность во время выполнения скрипта запускать другие приложения и вложенные скрипты (читайте RUN_COMMAND и EMBED_SCRIPT в описании языка).

Идея какая: в теле цикла скрипта GM вместо EXPORT_RASTER вставить вызов RUN_COMMAND, запускающий бы некое приложение с параметрами (имя текущего map-файла и т.п.), чтобы это приложение само подобрало требуемые коэффициенты для текущего map-файла и, самое главное, в итоге сформировало текстовый файл - вложенный скрипт с единственной командой EXPORT_RASTER (с правильно заполненными параметрами, в т.ч. SPATIAL_RES). И после вызова RUN_COMMAND вставить вызов EMBED_SCRIPT, указав в качестве файла скрипта тот текстовый файл, который сгенерит внешнее приложение, вызванное RUN_COMMAND.

Я подобный финт ушами делал для обрезки карт генштаба по координатам из map-файла. У меня RUN_COMMAND запускал простенький vbs-скрипт, который шерстил строки текущего map-файла (путь к текущему map-файлу передавался в виде параметра), находил пограничные координаты и генерировал текстовый файл с командой EXPORT_RASTER с параметрами обрезки по найденным координатам, а следом за RUN_COMMAND шел вызов EMBED_SCRIPT со ссылкой на только что сгенерированный скрипт с командой EXPORT_RASTER...

UrikEEE · **Добавлено:** 01.07.2013 11:11

... а если Вы не хотите сделать скрипт "на все случаи жизни", а хотите пару - тройку скриптов для фиксированных зумов - так поэкспериментируйте с настройками X-asics и Y-asics в "Geotiff Export Optins" GM и вбейте их в виде значений параметра SPATIAL_RES в команде EXPORT_RASTER. Ну в смысле сделайте несколько скриптов (для каждого зума свой) с конкретными значениями параметра SPATIAL_RES для каждого зума.

FamilyMan · **Добавлено:** 02.07.2013 15:54

Спасибо. Все получилось.

Paganel · **Добавлено:** 20.09.2013 21:34

Вот сегодня на американском форуме опубликовали такое сообщение - http://www.magellaninsiders.com/viewtop ... 3&start=16

======================
Great software, working great !
BTW,
compared MSDK and RMP Creator,
used same 3.5Gb input files (sat images - lvl 19,17,15,13 ) and create RMP's, first with MSDK and then with RMP Creator.
http://postimg.org/image/dfz94dmrd/
Both made workable RMP's, only the MSDK create 850Mb file and RMP Creator create 3.8Gb file.
It' seems that Magellan using some sort of on-the-fly compression since the RMP file is cca 4 times smaller.

Nevertheless, RMP Creator is still the best free tool for rasters for eXplorists.
===================================

Мелочь, а приятно!

Deathnemo · **Добавлено:** 11.02.2014 02:00

Здравствуйте...помогите пожалуйста определить, что не так делаю при создании RMP.

Порядок действий:
1.Скачал и склеил карту в SAS Планета в формате jpg с привязкой
2.Открыл в GM поменял проекцию на Geografic...далее экспортировал в GeoTIFF

3.Потом использовал RMP Creator v 0.96
В итоге получились битые карты (тоесть часть тайлов есть а многие не выжили). Пример отображения в VP...ну и соответственно так оно выглядит и в навигаторе

хотя при открытии tiff например в фотошопе - карта отображается отлично без косяков

На всякий случай привожу размеры файлов

Вопрос: что я не так сделал?

Paganel · **Добавлено:** 11.02.2014 09:53

У VP есть глюк по недорисовыванию некоторых тайлов в совершенно нормальной карте. В навигаторе все тайлы, если они есть, прорисовываются нормально.
У меня еще ни разу не было, чтобы изображение, которое есть в тифе, не попало в RMP.

Deathnemo · **Добавлено:** 11.02.2014 10:39

Paganel писал(а):

У VP есть глюк по недорисовыванию некоторых тайлов в совершенно нормальной карте. В навигаторе все тайлы, если они есть, прорисовываются нормально.
У меня еще ни разу не было, чтобы изображение, которое есть в тифе, не попало в RMP.

Я изначально тоже сослался на глюк в VP. Но в итоге когда скомпилированный RMP смотрел на эксплористе...картина вырисовалась не очень обнадёживающая...там где VP зафиксировал отсутствие тайлов...они отсутствовали и в навигаторе. Ради чистоты эксперимента залил нормальный tiff http://www.ex.ua/430703756108 - если будет желание заморочиться то попробуйте сделать rmp и посмотреть что выйдет!

Д. Засядько · **Добавлено:** 11.02.2014 15:08

Странно, но ваш "тифф" у меня в ГлобалМаппере выглядит некрасиво. Местами какие-то белые квадратики вместо серого фона, обозначающего застройку, и ещё артефакты типа "посыпали белым песочком" вдоль дорог.
Я так понимаю, это данные из OpenStreetMap. С какого сервера качали?

Deathnemo · **Добавлено:** 11.02.2014 17:13

Д. Засядько писал(а):

Странно, но ваш "тифф" у меня в ГлобалМаппере выглядит некрасиво. Местами какие-то белые квадратики вместо серого фона, обозначающего застройку, и ещё артефакты типа "посыпали белым песочком" вдоль дорог.
Я так понимаю, это данные из OpenStreetMap. С какого сервера качали?

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

Качал с OpenSteetMap Mapnik - сервер в SAS указан - http://a.tile.openstreetmap.org (если правильно понял)

Андрей Лунячек · **Добавлено:** 12.02.2014 01:25

Надо же! Я по такой же методике (SAS Планета - Global Mapper - RMPCreator) сделал целый ряд городов (Харьков, Донецк, Полтава, Львов, Ивано-Франковск), используя OpenStreetMap Mapnik. И никогда проблем не было. Может, это сам Киев виноват?

Д. Засядько · **Добавлено:** 12.02.2014 14:01

Подозреваю, что некоторые тайлы просто не докачались до конца или скачались с ошибками. Ну и плюс к этому, вероятно, что-то напортачили с настройками сжатия JPEG.

Deathnemo · **Добавлено:** 12.02.2014 15:17

Андрей Лунячек писал(а):

Может, это сам Киев виноват?

Такие подозрения были!))

Deathnemo · **Добавлено:** 12.02.2014 15:29

Д. Засядько писал(а):

Подозреваю, что некоторые тайлы просто не докачались до конца или скачались с ошибками. Ну и плюс к этому, вероятно, что-то напортачили с настройками сжатия JPEG.

Артефакты убрались после того как начал конвертацию не в 8 бит а в 24 (но конечно размер выходит неприлично большой после такой конвертации)
По поводу недогруженных тайлов - исключено, ибо в tiff они все видны.
Единственное что заметил: В программе RMP Creator - после компиляции rmp, корректное отображение в VP происходит только если я использую не geotiff исходник, а jpeg + map привязка...но в этом случае по времени обработки jpeg файла с разрешением порядка 40000х40000 пикс времени уходит мягко говоря дофига!(

Зундер · **Добавлено:** 12.02.2014 16:40

Попробуйте карту клеить не JPEG, а ECW, он лучше подходит для больших рисунков и умеет хранить в себе геодата. Global Mapper понимает этот формат даже без *.map файла.

Андрей Лунячек · **Добавлено:** 12.02.2014 22:52

Deathnemo писал(а):

по времени обработки jpeg файла с разрешением порядка 40000х40000 пикс времени уходит мягко говоря дофига!(

Я делаю так: когда экспортирую фрагмент из SAS Планеты (формат .jpg + .map), то сразу же включаю разбивку его на фрагменты менее 10000 пикселей по каждой из сторон. Потом полученные файлы обрабатываю Глобал Маппером, потом загоняю в RMPCreator и собираю в один RMP-файл. Качество то же самое, что и при экспорте одного файла без разбивки, но мелкие файлы обрабатываются гораздо шустрее.

Deathnemo · **Добавлено:** 13.02.2014 00:05

Андрей Лунячек писал(а):

Deathnemo писал(а):

по времени обработки jpeg файла с разрешением порядка 40000х40000 пикс времени уходит мягко говоря дофига!(

Я делаю так: когда экспортирую фрагмент из SAS Планеты (формат .jpg + .map), то сразу же включаю разбивку его на фрагменты менее 10000 пикселей по каждой из сторон. Потом полученные файлы обрабатываю Глобал Маппером, потом загоняю в RMPCreator и собираю в один RMP-файл. Качество то же самое, что и при экспорте одного файла без разбивки, но мелкие файлы обрабатываются гораздо шустрее.

Андрей, спасибо за совет...сам как-то не додумался...буду пробовать...ибо на данный момент, что бы я не пробовал склеивать в формате ecw jpeg png...даже уже пробовал через mobile atlas creator...файлы создаются нормальные (при просмотре) а вот после RMP - фейспалм!

Андрей Лунячек · **Добавлено:** 13.02.2014 00:26

Deathnemo, вы Киев делаете? Если хотите, могу сделать для вас, если подождёте 2-3 дня (в зависимости от наличия у меня свободного времени). Если же хотите подолбаться самостоятельно, дам совет: хорошо смотрятся карты городов, сделанные из двух слоёв (16 и 18 в SAS Планете, что соответствует 15 и 17 в других программах).

Deathnemo · **Добавлено:** 13.02.2014 01:54

Андрей Лунячек писал(а):

Deathnemo, вы Киев делаете? Если хотите, могу сделать для вас, если подождёте 2-3 дня (в зависимости от наличия у меня свободного времени). Если же хотите подолбаться самостоятельно, дам совет: хорошо смотрятся карты городов, сделанные из двух слоёв (16 и 18 в SAS Планете, что соответствует 15 и 17 в других программах).

Спасибо за помощь...ваш совет по поводу разбивки файлов - помог, удалось наконец-то сделать карту - сейчас Киев в масштабе 18 выглядит замечательно!))
А вот можно немного подробнее многослойных карт...насколько я понимаю, здесь необходимо использовать функцию "Сформировать" в SAS?!

Андрей Лунячек · **Добавлено:** 13.02.2014 02:03

Нет, это вы что-то лишнее придумали. Экспортируете слой 16 и слой 18. Можно сделать каждый из них отдельным RMP-файлом, а можно при конвертации при помощи RMPCreator слепить их в один файл.

Paganel · **Добавлено:** 13.02.2014 14:12

Вы меня простите. Я понимаю желание сделать одну единственную карту под называнием "Украина", где есть ВСЕЕЕЕЕЕЕЕЕЕЕ, но я никак не могу понять смысл этого.
Эксперименты и на Тритонах и на Эксплористах показали, что карты показываются совершенно одинаково и по отображению и по скорости, если:
- 546 листов километровок Украины лежат в навигаторе 546-ю файлами RMP
- все 546 отдельных избражений карт лежат в одном RMP-файле
- карты склеены в изображения большего размера (по 36 карт) и лежат в 17 файлах RMP.

RMP-файл магелланов, в отличие от JNX Гарминов, это просто контейнер, в котором может лежать все что угодно - любые изображения любых участков местности любого масштаба в любых сочетаниях. Никакой многослойности в RMP нет. Просто если вы положили туда карты одного масштаба или космоснимки одного зума - получается одна карта одном слоем. И Магеллану совершенно пофиг будет там одна картинка 10000*10000 или четыре по 5000*5000. На экране будет одно и то же.
А если у вас там карты разных масштабов, то вы увидите как бы несколько слоев. Но, если вы карты одного масштаба положите в один RMP, а другого в другой, вы увидите на экране абсолютно то же самое.

Все дело в управлении картами, которое Гарминам и не снилось.
Если у вас все слои (все карты разных масштабов слиты в один RMP) то это все и будет одним куском. Если у вас зум 16 и зум 18 в отдельных RMP, то вы можете, например, выключить отображение 16-го зума и включить вместо него показ чего то другого прямо в меню навигатора, а не дома за компом сделать другую карту. А в эксплористах есть еще и управление группами карт (тег Provider). Это вообще класс! Можно накидывать в навигатор кучу разных карт отдельными листами под конкретный поход, а в походе включать и выключать сразу все листы карт одного типа одним кликом, прямо в навигаторе формируя тот многослойный пирог карт, который хочется видеть в данный момент.

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

Deathnemo · **Добавлено:** 13.02.2014 15:24

Желания абсолютно нет...наоборот с вами полностью согласен - наличие отдельных файлов - даёт больше гибкости в настройках отображения и разгрузке навигатора от ненужных слоёв

Андрей Лунячек · **Добавлено:** 13.02.2014 21:03

Paganel писал(а):

Вы меня простите. Я понимаю желание сделать одну единственную карту под называнием "Украина", где есть ВСЕЕЕЕЕЕЕЕЕЕЕ...

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

Дмитрий, при всём к вам уважении: я просмотрел все предыдущие комментарии на этой странице и в упор не пойму, где вы увидели желание сделать "монстрообразный файл Украины или всего мира". Речь шла всего лишь о карте Киева. Поэтому ваш комментарий не очень стыкуется с тем, что написано выше. Как будто вы сами с собой разговариваете.

Paganel · **Добавлено:** 13.02.2014 21:32

Тогда объясните мне:
- в чем смысл многослойности, о которой спрашивают почти все пользователи, начинающие делать карты, и здесь спрашивали в том числе?
- почему самая частая проблема - превышение размера экспортированного изображения в 10000*10000 точек и более?
- почему у меня никогда не было необходимости делать ни того ни другого? Я вроде как тоже не только вокруг дома хожу. Может я как то не так навигатором пользуюсь или чего то не понимаю?

Если делать многослойные карты на какую то местность, то надо было покупать Гармин. Там это делается лучше.

Андрей Лунячек · **Добавлено:** 14.02.2014 00:11

Paganel писал(а):

Тогда объясните мне:
- в чем смысл многослойности, о которой спрашивают почти все пользователи, начинающие делать карты, и здесь спрашивали в том числе?
- почему самая частая проблема - превышение размера экспортированного изображения в 10000*10000 точек и более?
- почему у меня никогда не было необходимости делать ни того ни другого? Я вроде как тоже не только вокруг дома хожу. Может я как то не так навигатором пользуюсь или чего то не понимаю?

Если делать многослойные карты на какую то местность, то надо было покупать Гармин. Там это делается лучше.

Насчёт размера изображения. Не знаю у кого как, но у меня при превышении 10000 пикселей RMPCreator запускает внешний нарезчик тайлов, который работает ужас как медленно. Но для меня это не проблема, так как я просто разбиваю изображение на несколько более мелких. Или вы что-то другое имели в виду?

Насчёт многослойных карт. Я вовсе не утверждал, что это отличная идея - слепить в один RMP-файл несколько карт разных масштабов. А вот сделать каждую из них отдельным файлом - пожалуйста. Поскольку выше речь шла о карте города на основе OSM Mapnik, я подсказал, что на экране навигатора будет хорошо смотреться комбинация из двух карт, сделанных из зумов 16 и 18 SAS Планеты, что соответствует зумам 15 и 17 MOBAC, Global Mapper и других программ. Сочетание этих двух зумов я установил опытным путём, сделав несколько карт из зумов 15, 16, 17, 18 и поочерёдно включая-отключая их в навигаторе. Или, опять-таки, в своём вопросе вы что-то другое имели в виду?

Д. Засядько · **Добавлено:** 14.02.2014 08:33

По моему скромному мнению, вот как раз для онлайновых карт вроде OSM Mapnik и прочих производных от OSM, а также гугля, яндекса и т.д. есть какой-то смысл в создании многослойных карт. Один источник - один файл с несколькими уровнями зума (масштабом). Это хотя бы логично.
А если лепить в один файл космоснимки, генштаб, РККА и т.д., то таки да, получится неудобная в использовании фигня.

По поводу размера файла: с тех пор как придумали нарезать картинку на тайлы, размер файла картинки перестал быть важным. Лишь бы на карточку памяти поместился. А подгрузить и показать картинку 256х256 пикселей сможет даже самый древний навигатор

Андрей Лунячек · **Добавлено:** 15.02.2014 00:55

Д. Засядько писал(а):

По моему скромному мнению, вот как раз для онлайновых карт вроде OSM Mapnik и прочих производных от OSM, а также гугля, яндекса и т.д. есть какой-то смысл в создании многослойных карт. Один источник - один файл с несколькими уровнями зума (масштабом). Это хотя бы логично.
А если лепить в один файл космоснимки, генштаб, РККА и т.д., то таки да, получится неудобная в использовании фигня.

При изготовлении RMP-карт из онлайновых карт не нужно делать все масштабы подряд (т.е., например, 12, 13, 14, 15, 16 и т.д.). Дело в том, что они не совпадают с масштабами Магеллана (1,6 км, 1,2 км, 800 м, 400 м, 240 м и т.д.). Поэтому будут мешать друг другу. Например, карта с онлайн-масштабом 17 будет прекрасно отображаться в Магеллане на масштабе "60 м". Если же одновременно с ней использовать карту масштаба 18, то вместо прекрасной 17-й на масштабе "60 м" появится уменьшенная (и хуже читаемая) 18-я. Поэтому самый простой выход - использовать не все масштабы, а через один (т.е., например, 13, 15, 17).

Летом друзья просили сделать карты городов Грузии. Я сначала сделал город в виде четырёх RMP-файлов на основе масштабов 15, 16, 17, 18. Загрузил в навигатор, включил все. А потом начал по одной отключать и смотреть, что получится. Пытался найти оптимальную комбинацию масштабов. В итоге остановился на сочетании двух - 15 и 17.

Что касается вашего "а если лепить в один файл космоснимки, генштаб, РККА и т.д., то таки да, получится неудобная в использовании фигня". Позволю не согласиться. Всё получается удобно, если правильно организовать и разнести их по разным уровням зума. Вот что у меня было в походе по Крыму (перечисляю в порядке укрупнения масштаба):
Километровка Генштаба
500-метровка Союзкарты
OSM Mapnik из 16 зума
Космоснимок от Гугла из 18 зума

Всё вместе работало весьма удобно. Правда, в моём случае это были отдельные файлы, и я мог, при желании, отключить 500-метровку Союзкарты и включить вместо неё 500-метровку Генштаба. Или отключить OSM (z16) и включить аэрофотоснимки Державного Земельного Кадастра Украины (тоже z16).

Д. Засядько · **Добавлено:** 15.02.2014 11:06

Может, написать об этом на форуме MOBAC? Пусть подправят соответствие уровней зума карты в Мобаке, чтобы совпадало с навигатором.
http://sourceforge.net/apps/phpbb/mobac/

Новости	Форум	Контакты
Отчеты	Барахолка	Реклама
Статьи	Календарь	Скидки ХТ


Страница 1 из 1 [ Сообщений: 267 ]