А мне подумалось про чуть более сложные алгоритмы, типа Point Location на Trapezoidal Map. Кажется, что со сплайнами будет полный мрак.
По идее так должно быть, но очень часто программисты не обязаны знать тонкостей геодезии. Поэтому как они ищут пересечения прямых - загадка для всех.
Кстати, очень простой пример.
Рисуем две геодезические линии (по дуге большого круга на сфере или эллипсоиде, т.е. кратчайшей прямой) с азимутом отличным от 0°, параллельные, отстоящие на десяток метров. Естественно они не пересекаются.
Одну из линий делим на отрезки (также по кратчайшей прямой, т.е. дуге большого круга) через 1-10 км и ставим на ней промежуточные точки. Линии по-прежнему не пересекаются (на эллипсоиде).
Переводим массивы координат в меркатор и любуемся результатом. А ведь это типичный результат, например, для протяженных административных границ.
PS: границы с тегом source=www.eastgeology.com имеют много промежуточных точек на “прямых” участках. Неспроста 
Вы собираетесь проецировать кривые третьего порядка на геоид. Может, не надо? Одумайтесь! :3
как альтернативный вариант - может делать тегами подсказки для рендера? типа geo=smoothed или geo=arc на отрезках way’ев?
Я видимо, совсем тупой, плохо объясняю. Есть два принципиально разных способа прикрутить сплайн, пусть какую-то кривую Безье, на геоид.
Первый, который вы мне все дружно объясняете - взять контрольные точки, спроецировать в трехмерщину, потом как-то провести через них нечто в пространстве по геоиду. В зависимости от искажений проекции и способа проведения по контрольным точкам одна и та жа пара кривых может начать пересекаться в каких-то проекциях, а в каких-то нет.
Второй - кривая сначала строится в двумерной плоскости долгота-широта, а потом уже каждая точка получившейся кривой стандартно проецируется на геоид. Получается какая-то кривая на геоиде, гладкая, изгибающаяся. И вот здесь уже если точек пересечения не было, то их и не возникнет.
Это как это не пересекаются??? Вы нашли два непересекающихся больших круга на сфере?
Это называется - была векторная карта, а стала растровая 
Массовый проект должен быть простым, а сплайны/Безье это слишком сложно.
Возникает несколько ненавязчивых вопросов:
а) То есть, помимо прямого расчёта полинома 3-й степени (быстрые алгоритмы отрисовки вроде брезенхема уже ушли лесом) предлагается считать тригонометрические функции в каждой точке?
б) Что насчёт 180 меридиана?
в) Как быть с вычислением длины, площади и пр. аналитикой? Считать приближенно в лоб?
Две непересекающиеся дуги (отрезка). Я этого хлебнул по горло когда рисуешь планшеты в UTM. Это совсем нетривиальная задача.
PS: Zverik очень точно подметил про растр.
И вообще что такое сплайн в картографии и ГИС-съемке…
Отрезок я могу измерить физическими методами, проверить рулеткой. Окружность тоже измеряется. А как в поле измеряется сплайн, какой строитель, станок или прибор способен его изготовить - я не знаю. ИМХО максимум какую кривую можно поддерживать в базе - дугу окружности. Хотя даже с ней возникнут проблемы.
Не, не стала Я написал математическую абстракцию про каждую точку, чтобы понятней было. В реальности сплайн все равно заменится на ломаную (векторную!) и потом она спроецируется в нечто многозвенное на геоиде. Проектирование отрезка ломаной отторжения не вызывает?
Это уже другой вопрос - “нужны ли сплайны”. Я пока говорю про “возможны ли”
а) сплайн пересчитывается в ломаную, она уже по одному звену проецируется стандартными, работающими сейчас методами проецирования отрезков. Кроме того, тригонометрия считается сопроцессором очень быстро, быстрее полиномов на самом деле. Для совсем критичных приложений можно и предвычисленные тригтаблицы задействовать и даже целочисленную арифметику.
б) не вижу особых проблем. Гораздо страшнее полюса, от них лучше отрезаться, хотя бы по 80 градусу. И есть четкое желание ограничить область применения сплайнов объектами меньше 20 километров в диаметре. Берег озера, поворот дороги - что-нибудь такое.
в) способ из пункта а) сводит все эти задачи к уже решенным. Кроме того, в каждой конкретной задаче можно подумать над аналитическим решением, ускоряющим вычисления. Оно будет сильно зависеть от исходного определения сплайна.
А ведь здесь проблема в том, что нет четкой договоренности как именно проводить даже не сплайн - а отрезок прямой по двум концевым точкам. Даже что вообще такое - отрезок прямой на эллипсоиде. В принципе даже в меркаторе можно потребовать, чтобы отрезок соединял две точки по дуге большого круга. Тогда он выглядеть на карте будет совсем не прямым, зато с пересечениями будет более адекватно.
То есть, насколько я понимаю, приходим к следующему:
Решение не даёт преимущества, которые могли бы дать сплайны (гладкость), так как любую ломаную и так можно уже строить.
Решение создаёт дополнительные сложности в реализации.
Из сплайна можно получить ломанную с любой точностью. А из ломанной сплайн — нельзя.
Повторю свой вопрос - какими инструментами и с какой точностью можно измерить сплайн на местности.
Линейкой с любой наперёд заданной точностью, аппроксимируя его полилинией.
Встречный вопрос: зачем его измерять с какой-то неимоверной точностью?
В таком случае с задачей сглаживания может справиться рендер.
Почему же нельзя? Полно методов нахождения сплайнов по имеющемуся набору точек, и в зависимотси от количества контрольных точек так же можно получить любую точность.
И самое интересное - все это можно сделать не затрагивая OSM. Взять например все motorway и trunk на какой-нибудь местности и преобразовать их в сплайны с погрешностью скажем в полметра. И посмотреть будет ли какое-либо преимущество по занимаемой памяти и скорости обработки по сравнению с алгоритмами на основе упрощения ломаных. И уже имея такие результаты можно либо агитировать за добавление сплайнов в OSM либо признать что это будет излишним усложнением.
Эти методы находят просто хороший сплайн, а не тот, который был задуман, и после задумки которого из его точек выкинули параметры этих точек. Возьмём четыре точки, расположенные по углам квадрата. Какой сплайн мы построим? Вертикальный овал, горизонтальный овал, эллипс, круг или квадрат? Какой метод надо применить к этим точкам?
Нет, не приходим. Как сейчас рисуется поворот дороги если мы хотим, чтобы он выглядел гладко? Натыкивается много-много точек. Как это делается при помощи сплайна? Натыкивается 3 или 4 точки. Поскольку сплайн в пространстве “долгота-широта”, то во всех проекциях он пройдет ровно по тем точкам местности, которые мы видим при создании (так можно софт написать), поэтому за точки можно его подогнать к реальной дороге. Получаем гладкую кривую, что и хотели.
Так он и лежит в базе четырьмя точками. Если кому-то захочется его рендерить или считать геометрию - он приближает сплайн ломаной (по понятным формулам) - и делает свое дело. Чем глаже и точнее хочет - тем больше точек в свою ломаную добавляет.
Фактически мы перекладываем функцию “натыкивание много-много точек” с юзера на железяку, причем вполне контролируемым (в отличие от тупого сглаживания имеющихся сейчас точек) способом.
Вообще, чтобы понять ситуацию достаточно вместо страшного слова “сплайн” думать про обычную дугу окружности - с ней все те же достоинства и недостатки. И что такое “дуга на эллипсоиде” без бутылки не разобраться, и заменяет она одна кучу точек, и софт весь перепахивать надо…