svp писал(а):PavelML писал(а):Ну это уже вопрос технологии графического программирования, это не моя тема.
Да не... Я не про GDI+ и OpenGL спрашивал, а про то, что отдельные тайлы после их преобразования превратятся в эдакие нелинейно искаженные прямоугольники. Вот если их, как бы, вырезать из фона, то как из кусочков пазла, можно же будет чисто геометрически собрать карту новой проекции?
Почему превратятся? Это если растр деформирвоать - то превратятся. Но точности не будет. Тут другой принцип - мы сопоставляем точку в прямоугольном битмапе (конечном, с правильной прямоугольной формой) - четырем ближайшим точкам (после вычисления координаты этой точки в исходной системе) - в исходном меркаторовском растре.
Что означает сопоставляем?
Это означает, что мы от вычисленной координаты WGS-84 точки, которую мы должны "заполнить" в конечной проекции гаусса-крюгера - берем расстояние по долготе и расстояние по широте до каждой из четырех ближайших к нам ИЗВЕСТНЫХ точек из исходного растра. Кроме расстояний до этих точек мы считываем цвет каждой из четырех точек, в RGB - из исходного битпмапа в меркаторе.
Таким образом, мы имеем исходную мозаику - сколько процентов какого цвета должно получиться в нужном нам месте - прямоугольной карты в проекции гаусса-крюгера. Смешиваем цвета (если разные методы - "бикубические, квадратичные, линейные" и так далее) и - присваиваем нашей точке в конечном растре - этот цвет.
Потом берем следующую точку в конечном прямоугольном растре - и все вовторяем для нее с четырьмя точками, которые окажутся в другом месте исходного растра. И так далее.
Этот метод хорош тем, что ему несоотвествия разрешений не мешают, он всегда определит наиболее правильный цвет для нужной точки.
Второй метод.
Берем исходный битмап в меркаторе и вычисляем для каждого пикселя индивидуально свою собственную координату (X-Y) в проекции гаусса-крюгера. Тут мы вынуждены организовать трехмерный массив - каждый пиксель битмапа будет иметь не тоько цвет, но и значение X и Y.
Что дальше. Рисуем (с нуля) свой прямоугольный битпап с отсчетом от скажем 102000 до 103000 по Y от 5600000 до 5601000 по X.
Изначально каждый пиксель имеет точную координату и мы должны покрасить каждый пиксель, найдя цвета четырех ближайших к этому пикселю точек из вышеполученного трехмерного массива, покрасив его по методике смешивания цветов в зависимости от близости координаты цвета к нужной координате...
Логически это даже проще. Но во как быть с поиском ближайших точек в масссиве... тут индексация нужна и все равно медленно...