I believe in the abilities of mathematicians from Russia. Take this part of the development in your hands. It would be an enrichment for OSM. Worldwide.
It would be great to be leading in the map develepment.
Marek, why not use a tool in josm (comand line) for creating curves (besier) with automatic approximation with simple polyline?
I think, use curves without backward compatibility is awful. It will kill mobile applications. With backward compatibility you can use line approximation for computations. But there is another problem:
For example:
You draw a river, with a straight riverbanks. Neva or something like this, they have straight concrete or granite embankment. And you draw a line for a clearway. It’s smooth in real world, and you use curve. So you must check, that curve didn’t intersects with embankment, and simple polyline didn’t cross it too. I think many peoples will forget do this checks. If you use tool that draw polyline by bezier base points with a given precision you insuared that you didn’t make a mistake.
I wonder if any 3D software renders splines. Different level of details is possible just now, using polygon simplification algorithm.
Spline on a geoid (or at least ellipsoid)? I wonder if it possible, to fit one to another.
It will make useless most of already written software. Nobody will say ok to you for this.
UPD: Marek, is i wrote below, if you really want curves, you would better adopt circular arcs, which are much more useful. Introduce additional attribute to way node/segment, so old software could just ignore it and treat it as straight line.
Ну так зачем же компромиссы? Есть кривые, которые гораздо точнее аппроксимируют дуги и проще в обсчёте: это дуги.
Для того, чтобы из прямого отрезка (хорошо, геодезической прямой) сделать дугу, надо ему добавить только один параметр… ну например, угол загиба (который автоматически равен нулю для прямой). Таким образом, если не задавать сильно большие углы, вполне можно будет работать со старым софтом, который легко научить сначала просто игнорировать дополнительный параметр, «аппроксимируя» дугу отрезком.
Или определять оную дополнительным узлом между концами, помеченым спец. флажком, и тогда старый софт, который не знает о флажке будет рисовать на её месте два последовательных отрезка.
А один отрезок с концами на расстоянии километра на самом деле что угодно, хоть спираль архимеда?
Что отрезки, что накликанные точки, что сплайны, что дуги будут всего лишь приближением, и, думаю, никто себя не тешит ложными надеждами относительно идеальных кривых.
Как раз дуги — это компромисс, а сплайны — универсальный инструмент.
Я не говорю что надо всем броситься и каждую линию переделать в сплайн. Но задуматься об этом можно и нужно уже сейчас.
Софт для начала может просто игнорировать параметры каждого узла кривой Безье. А конвертеры могут нарезать длинные кривые на более мелкие прямые сегменты. Математический аппарат для этого уже давно есть.
Про то, что новички что-то там наломают, вообще не аргумент. Давайте релейшены сначала запретим чтобы не ломали.
А остальные не скругляют разве? Просто не разу не видил что-бы где то с этим проблемы были. ТО что должно быть круглым - на карте круглое что квадтратным - то квадратное))
В каком конкретно месте она работает? В epsg:4326 (как хранится в БД), или в epsg:3857 (меркатор на шаре, как отображается в josm и в мапнике)?
А если я захочу отобразить в epsg:3395 (как на яндекс-картах), где уже не шарик, а эллипсоид?
Отобразится то отобразится только сильно по разному может отобразиться, ну и как следствие в разных координатах будет/не будет к примеру пересекаться с чем-нибудь.
Если у двух кривых есть точка пересечения (с конкретной широтой и долготой), то они должны пересечься в этой точке в любой проекции. Разве не так? Углы и прямизна/кривизна изменятся, это да, так это проблема всех проекций сферы на плоскость.
Это как раз аргумент, массовый проект должен быть в первую очередь простой и устойчивый к каким-то не очень аккуратным действиям, иначе объекты будут пребывать в поломатом состоянии.