Сворачиваете плоскую нарисованную карту в проекции Меркатора в трубочку (цилиндр), оборачивая ею шарик.
Это центральная проекция: точка на поверхности шарика и точка на карте, свернутой в трубочку, лежат на одном и том же луче, выходящем из центра шарика.
Вопрос какой-то странный.
На вход тригонометрических функций всегда подают радианы.
На выходе получаем масштабирующий коэффициент.
Калькулятор с вами не сгласен. Правильный ответ: в чём принимает используемая тригонометрическая функция, то и передавать, см. доки на язык/либу.
Это не меркатор получится, меркатор равноугольный, а это — нет. Равноугольные стереографические проектируют из точки, диаметральной точке касания проекции и сферы. Это и это тут не поможет.
У Вас какой-то странный калькулятор.
Мой, например, всегда считает только в радианах.
Если у него есть дополнительная отключаемая функция по преобразованию радиан в градусы и обратно, то на общность это никак не влияет.
Распишите ряд Тейлора для любой тригонометрической функции, и убедитесь, что речь может идти исключительно о радианах.
Угловой градус - это вообще единица неестественная.
Так, не?
PS. Подумал - да, был не прав, принял написанное где-то (возможно, здесь http://livit.ru/plane-driving/bases-aviation-cartography/print:page,1,327-cilindricheskie-proekcii.html)) на веру. Собственно, масштабный коэффициент строится именно из равенства коэффициентов растяжения по обеим осям. А центральная проекция этим свойством не обладает.
Но что такое “точки, диаметральной точке касания проекции и сферы” так и не понял: проекция касается сферы по кольцу, а не в точке. Если цилиндр касающийся, а не секущий, точка, через которую проходит луч, вдоль которого проектируем, - лежит на экваторе. Но она не может там лежать в проекции Меркатора. Иначе бы не было проблем с отображением полюсов.
Градусы, радианы, грады — стандартный набор, на одном выбирается движковым переключателем, на другом кнопкой ДРГ. Если говорить о библиотечных функциях ЯП, то возможны и более экзотические варианты, как полный оборот / 256 
Это в алгебре приняты радианы, точнее там вообще не приняты какие-либо единицы, там числовая функция от числа, к углам не имеющая отношения вообще. В в прочей науке и технике может быть в любых единицах. Популярные в прошлом тригонометрические таблицы (Брадиса например) и логарифмические линейки показывали исключительно в градусах. И да, считать тригонометрию тейлором это не актуально, нынче рулит кордик.
Угу, такая проекция тоже есть, только это не меркатор. (Если отталкиваться от теории, линия равноугольной проекции должна протыкать исходную и проективную поверхности под равными углами (так -/-/- или так --/-) иначе искажения углов, у тут она под прямым углом к сфере и под косым к цилиндру)
Это если на плоскость проектируем, а не на цилиндр, проще на картинке увидеть. На цилиндр наверное похожий выкрутас, но не такой
из центра сферы нельзя провести луч, который был бы не перпендикулярен поверхности сферы (точнее касательной к поверхности сферы). к цилиндру же перпендикулярны будут только лучи, лежащие в плоскости экватора. По моему тот рисунок и есть проекция меркатора.
Замена одного ряда на линейную комбинацию других с целью ускорения сходимости ни на что не влияет.
Радианы остаются радианами.
Точно!
Именно этим соображением я пользовался, когда интуитивно заключил, что центральная проекция не может быть равноугольной.
Только не сумел так красиво сформулировать словами.
Но данная иллюстрация относится как раз к проекции Меркатора.
Видать, считать Меркатора центральной проекцией - весьма распространенное заблуждение.
Жаль.
Я как раз искал такую картинку, но не нашел.
В принципе, еще со времен Евклида известно, что любое геометрическое построение достаточно несложно описывается словами (в отличие от алгебраических вычислений).
Кстати, судя по описанию, такая проекция, хотя и является, возможно, равноугольной, но не является проекцией Меркатора, т.к. у Меркатора масштаб вдоль экватора не меняется, а у указанной проекции на плоскость - меняется.
Сдается мне, что рулит прежде всего сопроцессор. А лучше кордика - LUT
Одно другое, кстати, не исключает - FPU тоже работает по определенным алгоритмам.
Другое дело, что использование в FPU именно CORDIC мне тоже внушает некоторые сомнения.
Но можно проводить не из центра
Кордик, к слову, считает не ряд а произведения матриц. Какие исходные матрицы задашь, такая и будет и функция и единицы измерения.
Сопроцессор, если только это не обросший наследием предков х86, тригонометрию сам не считает. А LUT сдуется на 20-30-м разряде точности :).
Да-да, он самый, это я по старинке этот кусок процессора сопроцессором обозвал. Я так понимаю, что на таких обсчитывается процентов 95 из обсуждаемых на этом форуме вычислений. А то и больше.
Разнообразные ARM-ы в навигаторах, думаю, больше 5% геовычислений занимают А там хорошо если fpu складывать и умножать умеет. А большая часть вообще без него.
А там в принципе есть хоть что-то напоминающее fpu?
А то примерно в 50 раз более низкая производительность (по сравнению с х86) в вычислениях с плавающей точкой заставляет думать, что fpu там нет в принципе.
А нафига им fpu, если, например, в том же Гармине все уже поделено на уровни и переведено в доли дуги, а проекция вида - это Equirectangular с опорной параллелью в центре экрана?
Ну да.
Придется вспоминать уже подзабытые из-за включения fpu внутрь x86 процессоров числа с фиксированной точкой. 
Добавлю, что новомодные операции с растрами в тайловой форме опираются на аппаратные возможности SoC, на которых построены навигаторы, включая декодирование и простые геометрические преобразования jpeg-файлов. Так что все возможности идут от платформы.