Схема разбивки на тайлы

[sng]

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

[zed]

"ВЗГЛЯД ИЗ-ЗА ГУГЛА"

[PavelML]

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

[svp]

Интересная задачка.

нужен гаусс-крюгер а не меркатор.

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

Если есть здесь понимающие люди, нарисуйте примерно, как оно получится. Ну, то есть, например, на куске карты из меркаторовских тайлов нарисовать искаженные границы крюгеровских и наоборот.
Алгоритмически мне видится такое потоковое преобразование примерно так:
У нас есть две системы глобальных прямоугольных координат в растре: результирующая (x, y, zoom) и исходная F(x,y, zoom). Функция F преобразовывает пиксельные координаты из одной системы в другую.
X -- Буфер запрашиваемых (целевых) тайлов с именами (qrts) или координатами (xyz).
Xw -- Некоторое прямоугольное тайловое окно в пределах X. Размер окна подбираем эмпирически.
C - Буфер (оперативный кеш) исходных распакованных тайлов. В этот кеш попадают исходные тайлы, географически пересекающиеся с результирующими тайлами из окна Xw. Т.е. Берём тайл из окна (Xw[i]), получаем его пиксельные координаты и преобразуем функцией: F(Xw[i].x, Xw[i].y, zoom). Полученные координаты нужно снова преобразовать в тайл (просто целочисленно поделить на 256). Этот тайл и заносим в C, если его там ещё нет.

Окно нужно для удобного управления количеством требуемых потоковому конвертеру ресурсов (памяти).
Окно Xw должно сканировать область тайлов X.

По ходу сканирования тайлы окна Xw заполняются пикселями, взятыми методом интерполяции с помощью функции преобразования F(). Полностью заполненные тайлы исключаются из очереди X, а следовательно в буфере С можно уже не держать освобождённые при этом распакованные тайлы.
На питоне я бы такое написал. Вопрос в скорости ив функции F.
Ну и, чтобы убедиться сработает ли этот подход, надо посмотреть на то, как накладываются результирующие тайлы на исходные или наоборот. По сути, надо отобразить две тайловые сетки на карте: исходную и результирующую. Понятно, что одна из них будет геометрически искажена.

[PavelML]

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

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

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

Если 1000х1000, то напрашивается два разрешения - для зон низкого разрешения тайпы размером 10х10 км (10м/пиксель), для высокого 1х1 км, для сверхвысокого 100х100м. Десятичные разрешения позволят привязать имена файлов к координатам. То есть если в СК-63, скажем фигурируют значения "север" 5753000 и "восток" 105000, то тайп можно было бы именовать: 21055753.jpg где первая цифра (2) - фактор зума (1 м/пиксель).

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

Если мы берем конечный пиксель с нужной нам координатой и потом вычисляем четыре ближайших пикселя в исходной системе координат:
- легче организоать работу кэша и подкачки
- больше порядка в организации именования файлов и заполнении пространства.
Недостаток - функция пересчета координат из гаусса-крюгера (СК-63 или подобная) в меркатора (wgs-84) - итерационная. То есть - используется только одно направление пересчета - из wgs-84 в гаусса-крюгера. А обратный расчет делается итерацией методом последовательного приближения. Для получения координаты с точностью вдесятую долю миллиметра нужны обычно 6 итераций.
Другими словами - преобразование координат от конечной метрической к исходной градусной - примерно вшестеро-впятеро медленнее.

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

Какой из этих вариантов выбрать - видимо нужно экспериментально проверить - насколько серьезно система тормозит при такой трансформации. Если серьезно - второй вариант, Если нет - я бы выбрал первый, итерационный...

[PavelML]

в качестве наглядности... демонстрировать трансформированные тайпы нет смысла - мелкие квадратики будут отличаться только видимым углом наклона в зависимости от удаления от базового меридиана.
Поэтому... я вот взял территорию 300х150 км (мордовию) и всю запихал в глобал-маппер. После преобразования в местную систему СК-13, базирующуюся на гауссе-крюгере, получил вот такой "баян". Верхние углы прямоугольника размером 300х150 км ушли примерно на 8 км:

[PavelML]

Кстати... если такой "трансформатор" будет работать - ему под бок можно подложить базу описателей снимков высокого разрешения, кроме границ снимков чтобы были два значения смещения снимка относительно правильных координат. Тогда при трансформации программа будет автоматически позиционировать снимок с намного более высокой точностью
Создавать такие описатели несложно, особенно если для определения сещения использовать кадастровую карту росреестра - она выдается с высочайшей точностью на больших пространствах и может быть опорной. Там есть такие участк как "опоры" - обычные столбы сечением 20х30 см - тоже стоят на учете как участки. И эти столбы видны на снимках высокого разрешения. Значит привязать можно с очень неплохой точностью. Вместо 15-20 метрового сдвига будет 0,5-метровый на равнинной местности и 3-метровый на пересеченной или в местах с искусственно изменненным рельефом. Ну это конечно зависит от угла наклона камеры спутника при съемке. При обработке снимков математикой компенсирующая коррекция на рельеф вносится, но она не очень точна по привязке и разрешению.

Тем не менее - мне удавалось определить границы объекта по спутниковому снимку достаточно точно после такой привязки. Геодезическая съемка границ подтвердила что ошибка была не более 20-30 см.

[svp]

Спасибо, уважаемый PavelML. Теперь проблема стала гораздо понятнее для человека, не знакомого с премудростями ГИС. Складывается впречатление, что задачу проще решить несколько по-другому. Имеет смысл использовать GDI+ или OpenGL, сделать механизм того самого "описания" тайЛов и преобразовывать их (тайлы) на лету RGBA текстуру (с прозрачными пикселями). Эти текстурные "спрайты" можно успешно кешировать в оперативном кеше, а нынешние графические ускорители без труда решат проблему производительности при отрисовке, в среднем, (1280 / 256) * (1024 / 256)=20 преобразованных и, наверно, немного пересекающихся прозрачными границами тайлов, вмещающихся на экран.
Я прав?

P.S.
"Тайл" от слова tile -- плитка.

[PavelML]

Спасибо, уважаемый PavelML. Теперь проблема стала гораздо понятнее для человека, не знакомого с премудростями ГИС. Складывается впречатление, что задачу проще решить несколько по-другому. Имеет смысл использовать GDI+ или OpenGL, сделать механизм того самого "описания" тайЛов и преобразовывать их (тайлы) на лету RGBA текстуру (с прозрачными пикселями). Эти текстурные "спрайты" можно успешно кешировать в оперативном кеше, а нынешние графические ускорители без труда решат проблему производительности при отрисовке, в среднем, (1280 / 256) * (1024 / 256)=20 преобразованных и, наверно, немного пересекающихся прозрачными границами тайлов, вмещающихся на экран.
Я прав?

P.S.
"Тайл" от слова tile -- плитка.

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

[svp]

Ну это уже вопрос технологии графического программирования, это не моя тема.

Да не... Я не про GDI+ и OpenGL спрашивал, а про то, что отдельные тайлы после их преобразования превратятся в эдакие нелинейно искаженные прямоугольники. Вот если их, как бы, вырезать из фона, то как из кусочков пазла, можно же будет чисто геометрически собрать карту новой проекции?