Для шейдеров, насколько я знаю, намного быстрее будет сделать 1D текстуру реализующую эту функцию, чем считать формулы на GPU влоб (но тут, опять таки, надо быть осторожным с точностью).
Работает всё это так: пусть есть координаты в радианах:
lat ϵ (-π/2, π/2)
lon ϵ (-π, π)
взяв
x = lon
y = mercator(lat)
получим координаты на плоскости:
x ϵ (-π, π)
y ϵ (-∞, ∞)
из-за того что y может получаться большим по модулю, входную широту обычно ограничивают до примерно (-85.05°, 85.05°). Если так сделать, на выходе будет квадрат (-π,-π) - (π, π), который уже можно нормировать как удобно, собственно его вы и видите на openstreetmap.org. Да - полюса туда не попадают, и если этот квадрат натянуть на сферу, на полюсах будут дырки.
Первое - сама математика которую я процитировал выше, второе и третье - собственно реализации проекций [lat lon высота] в [x y z], и MercatorProjection использует те самые функции из geomath.
Я непонятно написал, то что они используют geomath.h я увидел, но что из них? Просто там нет комментариев, а мои скудные знания в этой области мне не помогают=)
чем отличаются mercator и unmercator?
И что мне использовать для пересчёта из меркатора в сферические:
MercatorProjection::ProjectImpl
MercatorProjection::UnProjectImpl
SphericalProjection::ProjectImpl
SphericalProjection::UnProjectImpl ?
Вы уж извините, что я не понимаю в этом, зато может другим не придётся спрашивать, если тоже такой вопрос возникнет=)
Спасибо.
Тогда забудьте про glosm, используйте функции mercator/unmercator. Что делает первая я расписал, а вторая выполняет в точности обратное преобразование.
Вам, по идее, нужно всего лишь в текстурные координаты класть не широту и долготу, а mercator от широты и долготу.
У меня тукстурные координаты по Y задаются в диапазоне от 0 до 1 (радиус сферы равен 1).
Для быстрой проверки переписал функцию меркатор на питоне и получил результаты:
После таких результатов я даже не знаю, что туда передавать, градусы или радианы?
Сворачиваете плоскую нарисованную карту в проекции Меркатора в трубочку (цилиндр), оборачивая ею шарик.
Это центральная проекция: точка на поверхности шарика и точка на карте, свернутой в трубочку, лежат на одном и том же луче, выходящем из центра шарика.
Калькулятор с вами не сгласен. Правильный ответ: в чём принимает используемая тригонометрическая функция, то и передавать, см. доки на язык/либу.
Это не меркатор получится, меркатор равноугольный, а это — нет. Равноугольные стереографические проектируют из точки, диаметральной точке касания проекции и сферы. Это и это тут не поможет.
У Вас какой-то странный калькулятор.
Мой, например, всегда считает только в радианах.
Если у него есть дополнительная отключаемая функция по преобразованию радиан в градусы и обратно, то на общность это никак не влияет.
Распишите ряд Тейлора для любой тригонометрической функции, и убедитесь, что речь может идти исключительно о радианах.
Угловой градус - это вообще единица неестественная.
Так, не?
PS. Подумал - да, был не прав, принял написанное где-то (возможно, здесь http://livit.ru/plane-driving/bases-aviation-cartography/print:page,1,327-cilindricheskie-proekcii.html)) на веру. Собственно, масштабный коэффициент строится именно из равенства коэффициентов растяжения по обеим осям. А центральная проекция этим свойством не обладает.
Но что такое “точки, диаметральной точке касания проекции и сферы” так и не понял: проекция касается сферы по кольцу, а не в точке. Если цилиндр касающийся, а не секущий, точка, через которую проходит луч, вдоль которого проектируем, - лежит на экваторе. Но она не может там лежать в проекции Меркатора. Иначе бы не было проблем с отображением полюсов.
Градусы, радианы, грады — стандартный набор, на одном выбирается движковым переключателем, на другом кнопкой ДРГ. Если говорить о библиотечных функциях ЯП, то возможны и более экзотические варианты, как полный оборот / 256
Это в алгебре приняты радианы, точнее там вообще не приняты какие-либо единицы, там числовая функция от числа, к углам не имеющая отношения вообще. В в прочей науке и технике может быть в любых единицах. Популярные в прошлом тригонометрические таблицы (Брадиса например) и логарифмические линейки показывали исключительно в градусах. И да, считать тригонометрию тейлором это не актуально, нынче рулит кордик.
Угу, такая проекция тоже есть, только это не меркатор. (Если отталкиваться от теории, линия равноугольной проекции должна протыкать исходную и проективную поверхности под равными углами (так -/-/- или так --/-) иначе искажения углов, у тут она под прямым углом к сфере и под косым к цилиндру)
Это если на плоскость проектируем, а не на цилиндр, проще на картинке увидеть. На цилиндр наверное похожий выкрутас, но не такой
из центра сферы нельзя провести луч, который был бы не перпендикулярен поверхности сферы (точнее касательной к поверхности сферы). к цилиндру же перпендикулярны будут только лучи, лежащие в плоскости экватора. По моему тот рисунок и есть проекция меркатора.
Замена одного ряда на линейную комбинацию других с целью ускорения сходимости ни на что не влияет.
Радианы остаются радианами.
Точно!
Именно этим соображением я пользовался, когда интуитивно заключил, что центральная проекция не может быть равноугольной.
Только не сумел так красиво сформулировать словами.
Но данная иллюстрация относится как раз к проекции Меркатора.
Видать, считать Меркатора центральной проекцией - весьма распространенное заблуждение.
Жаль.
Я как раз искал такую картинку, но не нашел.
В принципе, еще со времен Евклида известно, что любое геометрическое построение достаточно несложно описывается словами (в отличие от алгебраических вычислений).
Кстати, судя по описанию, такая проекция, хотя и является, возможно, равноугольной, но не является проекцией Меркатора, т.к. у Меркатора масштаб вдоль экватора не меняется, а у указанной проекции на плоскость - меняется.
Одно другое, кстати, не исключает - FPU тоже работает по определенным алгоритмам.
Другое дело, что использование в FPU именно CORDIC мне тоже внушает некоторые сомнения.
