Dukarav Dec 29 2020 at 14:41

Об эффективном использовании памяти при отображении картографических данных

9 min

2.5K

Programming*Image processing*Geoinformation services*CGI*Astronautics

Comments 9

sshikov Dec 29 2020 at 14:55

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

Dukarav Dec 29 2020 at 15:15

Вы имеете ввиду формат JPEG 256х256 как в maps.google.com? К сожалению, моделировать необходимо не только вид в надир. В примере виден горизонт. Представляете, сколько клеток 256х256 нужно загрузить до горизонта? Да и с предсказуемостью следующих клеток не всегда хорошо — модель должна крутиться (т.е. показывать вид при разной ориентации). И «листать» пользователь может куда угодно, задавая будущее или уже прошедшее время при моделировании.

sshikov Dec 29 2020 at 15:27

>Вы имеете ввиду формат JPEG 256х256 как в maps.google.com?
Ну, не обязательно прямо такой, там же все-таки веб, вы бы не были ограничены именно jpeg, и конкретным размером, но в целом да, мелкие куски, из которых динамически собирается карта. Причем возможно динамического размера, потому что детализация ближе к горизонту очевидно может быть менее точной.

На самом деле веб карты не грузят тайлы одного размера (в километрах или градусах). Там размер тайла зависит от текущего масштаба.

Насчет предсказуемости я просто недопонял, думал что это вид прямо «под нами», а не произвольный.

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

GCU Dec 29 2020 at 16:50

А почему отказались от сжатого дерева квадрантов?

Dukarav Dec 29 2020 at 17:42

а зачем, если вся карта лезет в память или она разбивается лишь на 10-20 частей

GCU Dec 29 2020 at 19:11

Просто PCX это построчное одномерное сжатие RLE, а квадродерево позволит сжать сразу однородные двумерные блоки, да и массив реперных точек не нужен.
P.S. Формулировка "целиком загружается в память" слегка сбивает с толку, почему бы не написать "отображается в память", при таких размерах файлы же не читаются от и до, а только в тех местах, где надо.

Dukarav Dec 29 2020 at 20:38

Файлы один раз целиком читаются в память и затем вся работа идет в памяти. Примерно 20 Гбайт для «среднего» масштаба. Тогда скорости для прокрутки хватает. А то, что построчное (самое примитивное) сжатие — так ведь все равно каждый пиксель на экране считается и достается отдельно. Рисуется ведь не «плоская» карта, а перспектива. то есть точки «плоской» карты отображаются в модели иллюминатора не подряд.

GCU Dec 29 2020 at 21:59

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

N-Cube Dec 29 2020 at 16:51

Изобретенная во времена СССР индексная структура для растровых карт (квадродерево) была успешно использована японцами в 1990-х при создании реалтайм систем навигации для автомобилей на ДВД дисках (данных на диске много, и скорость автомобиля может превышать 50м/с). А вот, например, как современными средствами можно визуализировать различные виды данных на глобусе на ноутбуке (хоть десятилетней давности): HOWTO: Visualization on The Globe
Можно наложить эпицентры землетрясений, вектора смещений земной коры, магнитные и гравитационные аномалии и так далее.