Я не против, например расставить подсказки для рендера на точках: smooth, corner и на прямой (сглаживать/не сглаживать).Но при этом обклацывая снимок, хотелось бы быть уверненным что вне зависимости от возможностей софта и точности аппроксимации сплайна, я не получу грубых ошибок в геометрии (самопересечений для поликов или пересечений русел рек иберегов и т.п.)
+1
Просто, эффективно, реализуется уже имеющимися средствами, не требует введения нового типа геометрии. Если я правильно понимаю, первопричиной беседы про сплайны послужили угловатые дороги, русла рек, водоемов и пр. Дело за рендерами.
Рендерер не может правильно сгладить полилинию без подсказок.
Ilis
Поставить подсказки, как предложил dkiselev, проще, чем вводить новый тип геометрии. Этот метод используется во всех 3D-рендерах без исключения, т.е. на vertex ставятся флажки сглаживать-не сглаживать. Я не знаток Java-программирования, но думаю ввести поддержку таких тегов в JOSM большого труда не составит (т.е. чтобы JOSM правильно отображал сглаженные линии).
Есть многое на свете…
Сплайн живьем и чертежи, его использующие:
http://pages.cs.wisc.edu/~deboor/draftspline.html
В то время как вы два года чертили на начерталке непоймичто, корпорация Boeing сплайнами чертила самолеты 
Кроме того, я видел советских еще времен чертежи турбинных лопаток - там 3D профиль (примерно догадываетесь о его сложности?) был задан как длинная такая таблица чисел.
Как однозначно воспроизвести сплайн любым картографом? Ну вот, например:
http://en.wikipedia.org/wiki/File:Bezier_3_big.gif
А как вы будете определять пересечение при наличии таких подсказок? И то, и другое невозможно без серьезного допиливания внутренностей самого postgis. Но речь изначально шла про OSM?
Всё понятно. Ждем реализации сплайнов в ОСМ и их поддержки нав.софтом. “Странно” только почему миллиардная индустрия 3D-рендеринга делает ровно наоборот - переводит NURBS в треугольники и только потом рендерит.
PS: интересно, сколько среди осмеров инженеров боинга… 
(added)
А если серьезно, имхо предложение dkiselev - это самый реалистичный сценарий, при котором в зависимости от навороченности софта из одних и тех же данных может изображаться как ломаная, так и сглаженная линия.
Я буду использовать подсказки только для рендера. Пресловутое, “Рендерер не может правильно сгладить полилинию без подсказок” - вот и будут ему подсказки. А для определения пересечений - и т.д. старые добрые ломанные. При этом я буду уверен в результате как в рендере поддерживающем сплайны так и в по которое их игнорит. Я буду уверен что у меня дороги со зданиями не пересекуться вне зависимости от натроек шага интерполяции по.
Кстати про коллизей. Вот вполне себе возможный пример. Допустим красненькое, в центре - коллизей, черненькое - дорога вокруг. Без сглаживания или с недостаточным сглаживанием - дорога пересекается со зданием:
Со сплайнами Безье - только хуже будет, т.к. они не обязаны проходить через точки.
И да, это не мое предложение, в начальном посте Марека такой вариант упоминается как один из возможных. Скромный я
Бойтесь потлачеров рисующих сплайнами!
Не будет! Кривая Безье - строго определенный объект (можно жестко зафиксировать его определение). Если при рисовании по этому определению Колизей и дорожки не пересекались, то при воспроизведении (рендеринге, расчете) по этому же определению они и не будут пересекаться.
А вот ваша картинка - отличнейший пример почему нельзя оставлять сглаживание на откуп рендеру, пусть даже с подсказками. Один рендер ваши “подсказки” поймет одним способом - и получит левую картинку, другой другим способом - и получит похожую на правую. И обе будут легитимными!
Они делают в точности моим путем. Модель хранится сплайном. Для нужд рендеринга приближается полигонами. Приближается каждый раз по разному, в зависимости от требуемого качества.
Википедия - http://ru.wikipedia.org/wiki/%D0%91%D1%80%D0%B8%D1%82%D0%B2%D0%B0_%D0%9E%D0%BA%D0%BA%D0%B0%D0%BC%D0%B0
согласно этой бритве проект OSM давно пора закрыть Нафиг эта лишняя сущность нужна
Почему лишняя? Я, может быть, чего-то не понимаю, но скажите мне: 1)в каком другом проекте я могу получить все то, что я получаю от OSM и 2)что в OSM я не могу сделать существующими инструментами из того, что я сделаю с помощью сплайнов?
Mir76, любой из сплайнов - строго определенный объект. Это кривая описываемая полиномом какой то там степени или что то типа того. Я не математик точного определения не помню. Я бы нарисовал пример с кривыми Безье только не знаю какой именно вариант вы подразумеваете, но попробую угадать.
Вот вам опорная, сглаженная Безье сплайном кривая и апроксимация. В результате пересекаем или нет домик опять же зависит от шага апроксимации. Проблема та же. Просто кривые безъе еще менее обратно совместимы с текущим положением.
Вы наверное скажете что это дескать несовершенство софта, надо просто шаг интерполяции уменьшить. Ок. Рассотрим реальную ситуацию. Вы обрезаете планету по границам России. В границу входят сплайны (в прочем это не принципиально.) Как вы будете выбирать шаг интерполяции? Слишком маленький = слишком много точек = осмосис сжирает всю память и умирает. Слишком большой = граница кривая = то что я описал в примере. Как адекватно поддерживать эти кривые. Ведь их будут использовать и для рек по несколько километров между опорными точками и для горных серпантинов по 5-6 метров между опорными точками. Как это интерполировать чтобы адекватно считать пересечения? Отвечу сам себе Чтобы не выбирать шаг интерполяции вам надо уравнение кривой пересчитать для геоида и для разных проекций, тогда задача поиска пересечений будет решаться аналитически.
Ну и пару слов о 3d. Не забываем про lo poly и mesh model тоесть в серьезных проектах пересчет из nurbs кривых в треугольники не отдают на откуп по и железке, это делают заранее после чего модельку еще доводят ручками. Ну и допустим сделали вы nurbs ландшафт и nurbs модели персонажей (всеравно ведь в треугольники заранее пересчитаете под контролем дизайнера) допустим что у вы таки пересчитываете nurbs модель в треугольники на лету. Соударения вы тоже будете в nurbs кривых считать?
это типа шутка была. Хотя готовую карту можно взять в гугле и яндексе, порисовать в свое удовольствие можно в НЯКе, а без сплайнов вы не сможете нарисовать красивую гладкую дугу тремя-четырьмя точками.
Задача-то какая? Поиск пересечения с точностью метр? Тогда шаг интерполяции достаточен такой, чтобы расстояние от сплайна до вписанной в него ломаной было не больше метра - вычисляется, скажем, через кривизну (или вторую конечную разность). И если домик не пересек эту ломаную, то не будет большой погрешностью считать, что он и сплайн не пересек. Если размер сллайна 10 метров, а точность требуется километр, то его вполне можно приблизить парой отрезков, никто не заметит.
А что, мапник тайлы уже на лету генерит? Аналогия не уместна. Правильно такая - модель в nurbs, всегда ей и остается, чтобы можно было править ее редактором (это типа база OSM). Для использования в критичных приложениях без редактирования модели она пересчитывается в треугольники (это типа мапник тайлы нарендерил). Потом треугольники руками подправили (и тайлы можно, и часто хочется в paint-e подправить). И эти треугольники используются для постоянных расчетов соударения (тайлы постоянно отображаются тысячам пользователей). Но исходная модель - в сплайнах.
Вот здесь кроется ошибка. При рисовании карты не нужно, чтобы оно как-то «выглядело» (там где задача стоит «чтобы выглядело» сплайны как раз используются и весьма успешно). Оно должно с некоторой точностью приближать то, что есть. Эта задача решается и без сплайнов. Чтобы заставить сплайн лежать в нужном коридоре отклонений от действительности также придётся натыкивать энное число точек, пусть и несколько реже, чем в случае ломаной.
В случае прямых задача о пересечении решается аналитически в несколько умножений и одно деление. В случае конических сечений аналитическое решение усложняется лишь на извлечение квадратного корня. А что в случае сплайнов? Численные методы с кучей итераций и хитрозамороченной обработкой пограничных случаев (и результатом, зависящим от реализации)?
/me никак не увидит профита в сплайнах…