О растре в GPS, часть 3

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

  1. О растре в GPS (HOWTO)
  2. О растре в GPS (записки для памяти)
Как нам подсказали читатели, в Global Mapper v14 есть поддержка JNX.

Действительно, есть, я ее вчера опробовал. Имею сказать

  1. Получаемые файлы, после подстройки масштаба и Product ID при помощи JNX Customizer (берут отсюда), прекрасно читается GPSMAP 62s (а других приборов с поддержкой растра у меня нет). Не тормозит и все такое.
  2. Масштаб, который ставит Global Mapper - мелковат, на мой вкус. Для километровки стандартно получается "видно с 3 км", лично я такой масштаб ставлю 200-тысячным картам. Возможно, для приборов с экраном покрупнее GM прав, для моего прибора - нет.
  3. C большими картами (которые не влезают в 50k тайлов 256x256) GM обходится нормально, делает тайлы побольше (из листа 500-метровки сделал 49k тайлов 490x512). Прибор такие карты жует нормально.
  4. Работает медленно: все тайлы сначала сохраняются в %TEMP% как файлы, даже на SSD это небыстро. Лист километровки (144 карты), который влезает в 50k тайлов 256x256 - где-то полчаса. Лист 500-метровки (~400 карт, он был неполный) - около полутора часов.
    Второй случай - сильно быстрее, чем map2jnx для больших тайлов, там я даже 1% готовности никогда не мог дождаться.
Сухой остаток: жить можно.

Update: а вот путь SAS-Планета - ECW - GlobalMapper - JNX оказался жопой. Отчего-то (неоптимальная работа с JPEG) 39к-тайловую карту (снимок) с тайлами 256x256 GlobalMapper мастурбировал почти два часа, а следующее разрешение (50k тайлов, но уже 350x450) захотел делать вовсе 4 часа.

Для снимков - прямо SAS-планетой пришлось сохранять, несмотря на то, что многотомные JNX я не люблю. 4 минуты вместо 4 часов (и понятно, оно JPEG-и не пережимает, а прямо из кэша своего и берет).

Comments

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

Ну вот судя по разнице в скорости между картой (хорошо жмется) и снимком (жмется хуже),
проблема, в числе прочего, еще и в сжатии JPEG.

Но с картографией можно работать. Тоже,могло бы быть побыстрее раз в 10, сохранять лист полтора часа стыдно (и временные файлы писать при наличии RAM - тоже стыдно), но потерпеть можно. Ну сколько этих листов надо. Ну пять. Ну десять.

На самом деле, разработчики вполне открыты для диалога. Они не только шустро фиксят баги, но и довольно оперативно добавляют нужные фичи, о которых их просят. Поддержка JNX там основана, например, на dll, которую написал отечественный гражданин, больше всего сделавший для изучения и взлома формата. Так что если к ним обратиться с конкретными мыслями - есть немалая вероятность, что учтут.
А по поводу RAM - дело в том, что GM пишется в том числе по заказу USGS, и у них могут быть свои специфические требования в духе 512Мб RAM.

Ага, жесткие требования.

Карта (в ECW-формате т.е. сильно жатая) в ~300Mb, генерируем .JNX в ~300Mb
Процесс GlobalMapper (x64) занимает в памяти 8Gb.

Вступить в диалог - да, думаю можно. Попробую

Про ECW ситуация следующая:
Сам формат - wavelet, с произвольным доступом и сжатием раз в 12, но его поддержка реализована в GM тоже через стороннюю DLL, и на сколько хорошо они там с ней договариваются - фиг знает.
По поводу диалога - рекомендую e-mail, хотя форум тоже годится.

Ну читает оно его за разумное какое-то время. Всяко не за часы, ну может за десятки секунд.

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

Я взял тестовый файлик, правда не очень удачный т.к. там "все дороги монголии с точки зрения Bing". 110M в ECW - но пожалось, понятно, очень сильно.

И попытался экспортировать его в GeoTIFF (в той проекции, которая годится для JNX: Geographical/WGS84) и в JNX. Получил такое ориентировочное время (после того как 2% работы было сделано)
GeoTIFF - 40 минут (тоже немало)
JNX - 2.5 часа.

В-общем, если в 50k тайлов 256X256 карта вписывается, то путь GeoTIFF-map2jnx должен быть сильно быстрее, map2jnx работает со стандартными тайлами вполне человеческое время, не вызывающее резко негативных эмоций.

Братья-славяне написали полезную утилиту для контроля структуры получившихся файликов:
http://www.garniak.pl/viewtopic.php?f=9&t=13355

Я запутался -- какой в результате рекомендуемый воркофлоу?
А то мне Oregon 600 приехал взамен бездарно проёбанного (вырвало из китайского крепления на руль велосипеда под колёса фуре на трамвайных рельсах) 62s и я таки озаботился битмап-картами...
Особенно в свете гор Лаоса, где ничего векторного отродясь не было.

0) Попатчить прошивку прибора

Карты:

1) Всосать в GlobalMapper (по одному масштабу за раз)
2) Убрать поля, если карты с полями
3) Export To Raster - JNX (долго!)
4) поправить масштаб и Product ID JNXCustomizer-ом

Снимки
1) Скачать SAS-планетой нужное
2) Сохранить в JNX
3) Поправить масштаб и продукт ID

Хм, а как убирать поля, если там 2K-листы, которых 100500...

Tools - Control Center - Выделить все листы (Ctrl-A) - Options - Cropping - Automatically Crop Collar

Если при этом возникнут дырки или нахлесты - значит листы неточно привязаны или сами деформированы (при сканировании или еще как)

Эх, 2K оказались далеко не везде... В смысле, 200k, двухкилометровки.

Мдааа... Дыры в пол-квадрата сетки везде... Ещё и привязывать это всё вручную, я рехнусь :(

Слушай, а ты с GM вообще понимаешь как бороться? Я вот загрузил, скажем F-47 весь в 200k (двухкилометровка). Убираю рамки -- дыры в одну рамку шириной.
Но я запускаю Image Rectifier -- и смотрю, что восточные точки из листа, скажем, F-47-01 в точности попадают на рамку (западную) листа F-47-02. Т.е. привязка очень точная, точнее не сделать. И что теперь? Почему края плохо режутся?
И если пальцем на экране "прижать" край любого листа (начало рамки) и сказать Crop, то видно, что отрезает он гораздо дальше, чем рамка, залезая внутрь листа!

Ну вот я честно - не видел проблем ни с ggc (которые, правда, исходно электрические), ни с нормально отсканированным генштабом.

А что там с F47 - не знаю, надо смотреть что там за привязка (может она просто не в той системе координат, в которой карта?)

Ну, это генштаб 59-го года, сканированный, с рутрекера (пять раздач, каталог верхнего уровня называется _map у всех, везде вотремарк поехали.нет). ggc-то только Россию покрывает.
Питер из этой же раздачи нормально (ну плюс-минус пяток пикселей) кропает.
А вот эту ЮВА -- я говорю -- точки стоят идеально, все 9 штук на лист, а при кропе он отрезает вдвое больше (в пикселях), чем надо от каждого листа -- серьёзно залезая в рисунок -- и как результат -- дыры. При этом, если включить полупрозранчость слоёв, видно, что линии рамки (внутренние края) у соседних листов совмещаются с точностью в 1-2 пикселя, т.е. если резать таки ровно по рамке, без лишнего, то всё должно совпасть идеально.

Прямо хоть пиши скрипт на перле, который физически по MAP-файлам порежет картинки и переделает MAP-файлы.

На форуме у Глобалмаппера есть тема 2007 (!) года с такой проблемой и ответом "нууу, у нас эта фича только для США-Канады-Месики, но мы подумаем об её универсализации". Не подумали?

Там, действительно, ерунда какая-то.

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

Даже не ясно, репортить ли багу, и если репортить то -- как. Правовой статус что карт в примере что моей копии глобалмэппера сомнительный :)

Ну как, global mapper - trial, карты - с веба...

На гис-лабе посоветовали сначала по рядам обрезать юг-север а потом по столбцам запад-восток, вручную задавая границы. Работает, но оооочень заморочно, особенно столбцы выбирать в списке.
И, да, там поля ввода в градусах, по 20 минут задавать тоже так себе. Но работает. Идеально всё стыкуется.

Багу все-таки стоило бы отрепортить, как мне кажется....

Во, смотри что сработало:

Control Center - Select All - Cropping
Snap to Manually Specified Degree Boundary

И для широты задал 0.33333333333333, для долготы 1.0

И все карты разом - офигачило нормально!

(для другого масштаба - надо смотреть как листы нарезаны, но смысл тот же)

Ага, я об этом, уже засыпая, сам подумал, но не успел попробовать :)

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

А у меня - работала нормально (листы на Монголию). И вот пишут выше, что на питер работает нормально. Чудеса?

слушай, а не знаешь ли ты магических мест где ещё таких листов побрать можно? А то у меня даже 200k не все, увы, вот наткнулся, что юг Вьетнама -- только 500k :(
вдруг есть места с довесками какими-то о которых я не знаю?

Самое полное что я знаю - лежит на рутрекере

Увы...

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

Да незачем.

Просто у меня automatic всегда работал, я не задумывался почему (и удивился, что на вьетнаме не сработал)

0) Сделано уже, да :)

Меня интересуют больше снимки, так как топокарт Лаоса я не нашёл в цифровой
(сканированной) форме, хотя у местных гидов видел на бумаге отличные.

Вот я и не понимаю, как понять какие уровни нужны и как именно править масштаб :) Читал-читал -- нифига не понял, сколько слоёв удобнее делать и как правильно SAS'овский масштаб в JNX'овый пересчитывать.

Чёрт, ответилось в корень.

Ну и вот я говорю SAS.Планете -- хочу вот такой прямоугольник, хочу JNX, 5 уровней зума.
И она в ответ: буду я обрабатывать 20 миллионов (!) файлов, уже сделала 500 тысяч, и молотит -- а кэш у неё не растёт. Что она обрабатывает, если ничего не качает и что я делаю не так!?

Я не понял - ты сразу экспорт, ничего не скачивая?

Да, думал оно само догадается про предыдущие шаги! Не догадалось. И ошибок не говорит!
вот ведь софтина!

Там ведь в JNX можно несколько уровней -- а качать только один. Качать по-очереди, следя за статусом?

Качать по очереди.

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

И, да, не делай многослойных JNX-карт. Делай несколько однослойных, с разным ProductID, тогда ненужные можно будет не включать - и будет меньше тормозить.

P.S. А как вообще 600-й орегон
а) жручесть
б) видность экрана
в) удобство управления тачскрином
?

a) Ничего пока не могу сказать, так как пока юзаю только как велокомп. По ощущениям -- не хуже GPSMap 62s, но точных замеров не производил, а использую по часу в день. Вот уже неделю по часу в день он живёт на Eneloop XX (без зарядки, прямо из магазина) и показывает 50% заряда.
б) Очень хорошо.
в) Неплохо. Плюс там переделали интерфейс и вот как велокомп он стал почти идеален, и работа с картой тачем приятнее, чем стрелками, и листает-зумит (векторную, из OSM, выгрузка гислаба) карту Питера он раза в два быстрее GPSMap 62s.

В общем, пока я доволен именно в роли велокомпа (сердце, каденс -- да, использую, увы, скорость с датчика он не берёт, такое вот выдавливание велосипедистов на серию Edge), а вот как туристический НАВИГАТОР я его попробую только в ноябре-декабре.

А вот сделай себе растровый снимок питера (более всего интересно z17 или z16) гигабайта на три - и расскажи, быстро ли скроллится.

Если не раздражает (62s - раздражает уже на "несколькогиговых", правда возможно что я на SD-карту пожмотился и надо купить быструю, а не абы-какую), то вот возьму и проапгрейдюсь (GPS-часть у 62s раздражает пока только в поезде/самолете, когда через окошко).

Осталось купить MicroSD на 32 гига :) Но я всё равно собираюсь. Сейчас попробую сделать z17 Питера и ближайших окрестностей.

Кстати, официально в России продают только 600t и 650t -- с картой ("Дороги России-топо", конечно), которые на $80 дороже чем без t, поэтому я заказывал с Амазона :) Хотя цены тут сейчас вполне адекватные, нет дикого разрыва, как было во времена GPSMap 60s :)

О, z17 не то что бы тоже качается. 150 файлов из 400 есть, и попытки растут быстрее, чем скачанные файлы. 270 из 500... И так далее..

В общем, на z17 в нашем Северо-Западе что-то есть примерно половина тайлов только, очень странно. И по прогнозу это ~400MiB всего, весь Питер и вокруг... Как вот так -- куда оно тайлы дело? :(

z16 тоже какой-то пустой -- уже 300 тайлов проверено, 0 скачано! Может меня в гугле забанили?!

Там если забанили - это видно (но я не помню как - и сейчас разворачивать SAS не буду)

В гугле банят, да. Причем, похоже что не по числу скачек, а по числу обращений к ошибочным тайлам.
Банится IP, где-то на сутки. Тем кто на ADSL - тем хорошо, реконнект и снова в бой.

Не, я про бан пошутил -- что-то-то качается. Но в z16/z17 скачивается 1/2-1/3 от нужного числа тайлов... Какая из этого карта выйдет -- не ясно.

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

Я качаю обычно с укрупнением масштаба, от 14-15 и дальше сколько хватит сил. В этом случае если нет нужных тайлов нужного масштаба SAS подставит более мелкие.

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

О! Забанил! :) Эх, жаль, нельзя по IPv6 качать. У меня их МНОГО.

Крепко меня забанили, до сих пор 503...

Там сутки, если правильно помню.

Разбанили. Не докачал даже z13 (~9K тайлов, успел 8K) забанили обратно :)))
Кажется, это не может работать вообще без запаса проксей или IP-адресов.

Да, я выше же писал, что мне хватало сети в 16 адресов.

Там странно, бывает банят сразу (через ~10k), а бывает что один адрес работает сутками и тянет сотни тысяч тайлов и ничего.

Мне казалось, что считаются именно ошибки (обращения к несуществующим тайлам), но доказать не могу.

Да где бы взять эти 16 адресов... Эх, умела бы Планета по IPv6...

Кстати, смотри какой рецепт разбана:

http://sasgis.ru/mantis/view.php?id=2086

Только я не могу найти как в ZMP включать куки а автор (vasketov) на форуме хамит и раглагольствует в стиле ``меньше народу больше кислороду'' и ``вам никто ничего не обещал''. Какой-то он типично-для-русских-форумов неадекватный.

А, ну оно же нынче OpenSource. "AllowUseCookie=1" и всё.
Блин, дельфи... Я бы научил его список URL'ей генерить (а потом скриптом по IPv6), но не разбираться же с Delphi для этого.

"Скриптом по IPv6" - а нельзя просто поднять локальный прокси, который по IPv4 будет получать запрос и фигачить его дальше по IPv6?

У какого такого домашнего провайдера IPv6 работает?

Да, о прокси я думал. Но не нашёл ничего готового, а прокси писать на грамм сложнее, чем скрпит.

У любого. Через туннель. Hurricane Electric даёт /48 routable за бесплатно, например. Ну да, помедленней, будет (да и так не быстро) но зато не надо раз в 2-3 часа на протяжении недели ходить и совершать шаманские пляски с бубном.

Ничего не понял :) Мне нужно 5 гигов гугловых снимков -- оно мне поможет?
И, да, с обрезкой по очень сложному контуру, иначе гигов получается не 5 а 25 (буквально).
Этот конвертер может их скачать и не нарваться на бан?

z20 на наш северо-запад -- 27 миллионов файлов с Гугла... ОЙ :) 90 дней, говорит :)

Оно там еще размер скачки пишет. Размер JNX примерно такой же, как размер этих JPEG-ов.

Ну и z20 по-моему вовсе не нужен.

Да там и файлов нет реально даже на z18. Поставил качать z18 -- он обработал 2000 файлов, скачал 3 (!). Вокруг Питера.
Сейчас попробую всё же Лаос, который нужнее, для Питера и Ленобласти меня и OSM устраивает.

Подтверждаю - z20 - это только для США и отдельных богатых стран Европы, если кому-то хочется считать машинки на стоянках.
Более чем достаточно даже 16, как правило.

Про зумы - есть в хвосте исходного HOWTO: http://blog.lexa.ru/2011/05/12/o_rastre_v_gps_howto.html