Прямой экспорт тайлов SAS Планеты в RMP (Magellan)

[Draude]

Рано или поздно SAS планете это произойдет, поэтому тему открою и наработки буду подкидывать.
Экспорт в формат навигаторов Magellan (.rmp)
Хотелка
В Хотелке вопрос :
> 1. Чем вас не устраивает текущий вариант экспорта?
Прямой экспорт всегда предпочтительный по самому определению "прямой экспорт".
Ну и кто сказал что для Magellana нужны карты только в географической проекции LatLong (далее LL)?
Да это просто более продвинутые пользователи по удобному алгоритму из растра в проекции LL научились собирать RMP.
А на самом то деле сам девайс (навигатор) этот растр обратно его коверкает, чтоб изобразить на своем экране картинку в равенстве по высоте и ширине в пересчете метров на пиксель. Этот факт сегодня уже признают что ни на есть магеллан-гуру.
С другой стороны даже самые отъявленные магеллано-центристы не оспаривают первенство изобретения навигатора Магелан перед появлением самих карт. И для удобства с некоторых пор эти растровые карты навигаторы Магеллан (как впрочем GPS других производителей) их поддерживает, а масштаб там (как на картах так и на экране Магеллана) указан отнюдь не в градусном представлении. Поэтому мне лично видится что в общем случае по растру Магеллан заточен отнюдь не исключительно под карты в проекции LL.

Но вернемся к второму пункту из Хотелки.
Моя задача реализуемая и имеет не единственное решение и к тому же разными способами. Проверено на широтах 50° , 7,5° и 69°
Самый удобный - прямое вычисление. Более замороченный - итерация.
Простой и понятный вариант следующий:
Допустим выделенная область 5тайлов в высоту 4 в ширину уровня z15. На данный момент имеем следующее.
область выделения:

30 тайлов (при выделенных 5х4=20), из которых верхний левый выкроен так :

и соответственно
Number of tiles in first block: 30
Width of tile in degree: 0,0219727
Height of tiles in degree: 0,0141654


И по "
2. Для произвольно взятой точки с координатами ALon, ALat и для "мира", разрешение тайлов которого равно ATileWidthDegree и ATileHeightDegree координаты тайлов считаются вот так:

AX := (ALon + 180) / ATileWidthDegree;
AY := (-ALat + 90) / ATileHeightDegree;"

то , скажем если привязываться к середине области выделения, для координаты ALat оригинальных тайлов меркатор из середины области выделения в данной выделенки получается что AY := 2823,843873 (при Height of tiles in degree:0,0141654).
Округляем результат до ближайшего целого (тут 2824) и обратным вычислением находим ATileHeightDegree_New, при котором нарезка совпадет с существующим меркатором. ATileHeightDegree_New := (-ALat + 90) / 2824 => ATileHeightDegree_New :=0,014164617
На этом можна было б и остановится.
Но у нас в выделенной области 5 тайлов в высоту, и лучший результат будет если для каждого ряда тайлов определится своя ATileHeightDegree_New, а конечный результат как среднее арифметическое этих ATileHeightDegree_New.
Сам результат довольно таки хорош и для сравнения с результатом, полученным итерациею с условиями допуска расхождения 1 пиксель на 16 тайлов, представлен на картинке.

[zed]

По поводу поддерживаемой проекции в Магеллане, хороший комментарий был вот тут: http://travel.org.ua/forums/viewtopic.p ... 60#p733644

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

и сейчас именно такая равноугольная проекция и создаётся при экспорте, если установлена галка "Не трансформировать...".

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

Как бы ни так! В Меркаторе каждый пиксель тайла (не говоря уже о самом тайле) имеет разное разрешение в градусах. И то изначальное значение (0,0141654) есть усреднённое разрешение всех тайлов. Полученное вами усреднённое значение весьма близко к исходному и единственный эффект, который можно получить - небольшой сдвиг сетки до границы верхнего левого тайла. Но это севершенно не значит, что теперь тайл целиком, без изменений, можно записать в RMP. Теперь тайл нужно привести к этому вычисленному усреднённому разрешению. И вот этого приведения разрешения никак не избежать. Его можно только минимизировать, если делать экспорт строкой в один тайл (как предполагалось изначально).

[Draude]

...
Как бы ни так! В Меркаторе каждый пиксель тайла (не говоря уже о самом тайле) имеет разное разрешение в градусах." И то изначальное значение (0,0141654) есть усреднённое разрешение всех тайлов. Полученное вами усреднённое значение весьма близко к исходному и единственный эффект, который можно получить - небольшой сдвиг сетки до границы верхнего левого тайла*. Но это севершенно не значит, что теперь тайл целиком, без изменений, можно записать в RMP**. Теперь тайл нужно привести к этому вычисленному усреднённому разрешению. И вот этого приведения разрешения никак не избежать. Его можно только минимизировать, если делать экспорт строкой в один тайл (как предполагалось изначально).

* -Но почему же небольшой сдвиг? Расчетный номер тайла в моем примере 2824, это на порядок больше количества пикселов в тайле. То есть пока у нас в тайле произойдут изменения, которые затронут один пиксел (1/256), как ни парадоксально, мы фактически можем сдвинуть сетку более чем на 10 тайлов (2824/256) , а это не есть небольшой сдвиг.
** - Вот тайлы из кеша SAS, у каждого из них есть внутренняя красная рамка, такой себе удобный, визуальный маркер границ оригинальных тайлов:

9_1.7z

(291.4 КБ) 315 скачиваний

9_2.7z

(262.88 КБ) 273 скачивания

Вот RMP файл по схеме SAS => склейка-меркатор => GlobalMapper => GeoTiFF c разсчетным средним ATileHeightDegree_New => RMPCreator => RMP:

z15_geoTiff5x4_5_0141646184847.tif.7z

(353.18 КБ) 340 скачиваний

и на всякий случай разобраный на тайлы он же:

z15_geoTiff5x4_5_0141646184847Tils.7z

(352.02 КБ) 309 скачиваний

На мой взгляд в этом примере без всяких дополнительных операций тайлы из кеша SAS "безболезненно" можно записать в RMP.

[zed]

Расчетный номер тайла в моем примере 2824

Не понял, при чём тут номер тайла?

у каждого из них есть внутренняя красная рамка

Надеюсь она в 1 пиксель? И чтобы рамка не сливалась на стыке тайлов, нижнюю и правую стороны раскрасьте в другой цвет (например, синий), тогда будет очень просто определить где начался первый тайл и где закончился второй.

склейка-меркатор => GlobalMapper => GeoTiFF c разсчетным средним ATileHeightDegree_New => RMPCreator

А вы из этой схемы уберите трансформацию растра и пересчитайте вручную координаты нижней границы снимка в файле привязки:

Код: Выделить всё

ABottom_New := ATop - (ATileHeightDegree_New / 256) * AImageHeight;

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

И да, для тестов возьмите район Мурманска, z8-z10, тайлов 10 и более в высоту, чтоб аж до Питера достать. В ширину можно ограничиться одним тайлом.

[Draude]

Ну я ,вообще то, на первом этапе только хотел показать один из простых способов нахождения нужного ATileHeightDegree (ATileHeightDegree_New), да-бы вписать группу тайлов (оптимальную по вертикали) без перенарезки для Меркатора.
Если этот момент уже не принципиальный, то будем двигаться дальше.
Так, к разговору про проекцию Equirectangular, то вот прочитал область использования

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

> И да, для тестов возьмите район Мурманска, z8-z10, тайлов 10 и более в высоту, чтоб аж до Питера достать. В ширину можно ограничиться одним тайлом.

Ну точность с уровней SAS z8-z10 как то не актуальна для туристических навигаторов но несмотря на то , что предварительно и не оценивал район Мурманска в этих зумах (только z15 и то по высоте 5 тайлов, как раз в Мурманске на широте 69° ), обязательно как то "тестану", но вот бы заиметь скрины карт с девайса, с мечеными тайлами район Мурманска.
По оценкам числовым,градусным, пиксельным, визуальным и др., да я только последнее время ими и занимаюсь, начиная с момента внедрения вами в SAS экспорта в формат RMP...
На основе числовой оценки погрешности итерацией получаю более лучшее нужное значение ATileHeightDegree, вот только вся та цепочка с єтим лучшим значением к RMP + разборка+ подкидка кукушат-тайлов из кеша SAS и обратная сборка в RMP, все ручками и занимает время...

>Надеюсь она в 1 пиксель?...
Делал по разному, в этом случае уже не помню. Но уже очередные границы тайлов раскрасил в разные цвета.

[zed]

только хотел показать один из простых способов нахождения нужного ATileHeightDegree

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

Так, к разговору про проекцию Equirectangular, то вот прочитал область использования

Обратите внимание, что такая "проекция" используется прямо сейчас, если стоит известная галка. На сколько я понимаю, по сути, вы хотите получить похожий результат, что даёт RMPCreator при экспорте в Меркаторе. Только вот по слухам, даже такой экспорт практически бесполезен и нужно сильно извратиться, чтобы получить более-менее удобоваримую точность привязки (это я про опыт lunyachek с нарезкой по 10 км). Вы же, получите ещё худший вариант, из-за того, что ATileHeightDegree подбирается вручную. Т.е. если вам нужна не просто красивая картинка, а вы собрались использовать её для навигации, то игра не стоит свеч.

Ну точность с уровней SAS z8-z10 как то не актуальна для туристических навигаторов

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

[Draude]

Сначала о Мурманске в z9
Выделенка 10 тайлов

Результаты, картинка расчетов с оценками

Уже на начальном этапе теста ясно, что для z9 для 10-ть тайлов в высоту на широте Мурманска дела "повна торба"( в смысле дрянь).
Но если очень нужно(хотя для этих масштабов для навигатора хватает векторных карт), то по одному тайлу в полоске всегда пожалуйста....или задействовать один из двух ныне существующих вариантов экспорта.
Вообще вопрос точности как то должны пересекаться с моментами целесообразности, при выполнения заказа у вас же было предложение-вопрос а не убрать ли возможность экспорта из слоев там числом ниже 7.
С другой стороны заказчик остановился на фиксированном к-стве тайлов в высоту 128, и я вот сейчас не помню на z14, или z13 меня лично точность в двух местах тестовой карты в 128 тайлов в высоту не устраивала.

только хотел показать один из простых способов нахождения нужного ATileHeightDegree

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

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

.


Далее, в SAS (вы писали) сейчас ATileHeightDegree берется как усредненное разрешение всех тайлов (простое), но я не уверен, что функция есть линейная, ибо если вы (скажем из моего примера) выделите три тайла, с тем же центральным, то получите несколько иное ATileHeightDegree (чем в предыдущей выделенке пять тайлов с центральными теми тремя тайлами). 0,0141654 против 0,0141657

[Draude]

И если

для Меркатора нету какой-то постоянной сетки - она постоянно смещается из-за изменения разрешения мира.

то:
1. В общем случае принципиальной разницы нет между ATileHeightDegree = 0,0141654 и ATileHeightDegree_New = 0,014164617.

При вычислении ATileHeightDegree_New (удобного) даже не меняется нумерация тайлов сетки от ATileHeightDegree. А вот точность с ATileHeightDegree_New повышается по определению.

скрытый текст: показать

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

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

2. Точность с ATileHeightDegree_New будет лучше чем с ATileHeightDegree.

Когда мы выделяем область в меркаторе, для экспорта в растрформат

скрытый текст: показать

кстати

"... чтоб изобразить на своем экране (девайса) картинку в равенстве по высоте и ширине в пересчете метров на пиксель."

и если в какойто области карты разрешение м/пиксель по высоте не будет соответствовать разрешению м/пиксель по ширене то магелан в лучшем случае будет обратно трансформировать растр а вхудшем вообще "лажать"

мерная линейка 3.2 км вписалась в сетку 2км

то почему мы должны брать среднее (по градусах) разрешение всех тайлов? Мы же выделяем меркатор. А широта середины(по вертикали) выделенной области этого меркатора в общем случае никак не совпадает с средним значением широты (то есть с серединой в проекции LL) этой же выделенной области.

скрытый текст: показать

В приведеном выше примере (уровень z15, 5 тайлов...) разница между средним значением широты выделенной области (49,9920265
) и широтой середины высоты (49,992039) этой области меркатор составляет 0,0000125000 градуса (или 0,226пиксела)

Если задаться вопросом, а если взять и выделить чуть, чуть иначе область.
Давайте попробуем перевыделить область так, чтоб "попасть" в мое "удобное" значение ATileHeightDegree_new.
Простое вычисление в моем примере дает следующий результат.
Для того, чтобы ATileHeightDegree от SAS (изначально оно 0,0141654000) совпало с моим удобным ATileHeightDegree_New (0,0141646185) мы должны верх выделенной области(50,02744 град) сместить вниз на 0,000003908°. Или же поднять нижнюю границу выделенной области на те же 0,000003908°.
Что такое 0,000003908° для тайла уровня z15 на широте 50°?
Это всего то 0,07 пиксела !

3.То есть изначальная выделенная область (с ATileHeightDegree от SAS 0,0141654000) и новая область ( с моим удобным ATileHeightDegree_new 0,0141646185) пиксельно равны.

То что же нам мешает? Привязка ATileHeightDegree к усредненному арифметическому разрешению всех выделенных тайлов? (допишу мысли потом, спешу на работу)

[Draude]

В зависимости от того, что же в конечном итоге нужно (или лучше) для Магеллана в растровой карте, разрешение в градусах (°/pixl) или разрешение в m/pixl , то можно собирать rmp с этим учетом.
По какому критерию идет автоматическое отображение/ не отображение растра (от какого то значения в °/pixl или от какого-то значения в m/pixl) единодушного мнения у продвинутых пользователей магелланов нет.
Постоянное по сути и вот собственно последнее утверждение от Paganel

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

Более подробно об отличиях алгоритмов отображения и управления картами мы тут уже говорили (или может в тревеле). Но если надо, я повторю.

Последнее же утверждение Лунячека (заказчика фишки экспорта RMP в SAS Планете)

У Магеллана за всё отвечает единственный параметр - разрешение карты в метрах на пиксель.

В случае Paganel при достаточно длинном по вертикале одноуровневом rmp (а это сей час в SAS непроблема, слой до 128 тайлов под одно градусное разрешение ) растр на дисплее девайса не должен пропадать на одном масштабе вдоль всего rmp ( что как то не вяжется, ибо сам масштаб отображения Магеллана отнюдь не в °/pixl)

В случае Лунячека вроде более логично, но тогда при достаточно длинном вертикальном слое с постоянным ATileHeightDegree при просмотре на одном масштабе прибора мы должны наблюдать пропадание изображения растра . (скажем z15 от г. Нижний-Новгород и вниз до г. Холм, а смотреть в приборе на 800м).

скрытый текст: показать

Я это наблюдаю в VP на ПК. Тоесть разобраться как бы не проблема и давно пора бы уже.

4.Как бы там не было, для коректного отображения растра в масштабах прибора (м, км, мили, футы и т.д ) следует иметь с достаточной точностю одинаковое по горизонтале и вертикали разрешение в m/pixl на всех частях карты.
Разрешение вверху карты обязательно будет отличаться от разрешения того что в низу, но в каждом месте карты горизонтальное разрешение должно быть равно вертикальному. А это достигается разбивкой растра на соответствующие блоки, каждый из которых будет иметь свое ATileHeightDegree_new (или пусть тоже ATileHeightDegree) поблочно. Тоесть разбивка по блокам штука хорошая.

5. Максимальное количество тайлов по высоте вообщем зависит от уровня z SAS и таки да в случае предлагаемого прямого экспорта дополнительно ограничено.
Но все решаемо, и для наиболее востребованных уровней z14,z15…z18 составляет от 5 до 60 тайлов в высоту. Мало это или много? Ну скажем можна посмотреть там лист генштаба 50k на средней широте в сколько тайлов z15 он помещается...

[zed]

уровней z14,z15…z18 составляет от 5 до 60 тайлов в высоту. Мало это или много?

Уже ж вроде выяснили, что на таком количестве тайлов оно глючит. И даже на 128 глюк иногда возможен.

Все свои теоретические выкладки вы можете проверить на реально сгенерированных файлах. Я уже описал алгоритм выше. Для Мурманска вы даже на этапе расчётов получили плохой результат, ну так возьмите какой-нибудь реальный юзер-кейс на z14-z18 и сделайте экспорт по своей методологии. Посмотрите как будет меняться сетка на стыке слоёв и как вообще отреагирует на это навигатор. А то много букв, да толку ноль. В теории, вон, экспорт строками в 1 тайл выглядел идеально, а на практике вышло швах. Тут же даже теория так себе...