Тут дело в том, что lanes:psv:* используется уже примерно полгода. При этом используется умолчание, что эта полоса — первая от внешней стороны. Другими словами, я просто расширил эту схему на полосы поворота, соответствующим образом усложнив умолчания.
Проблема с lanes:directions несомненна, но заменять этот тег на ещё N тегов, похожих на lanes:: — не очень хорошо: двойная работа, либо непонятки для непосвящённых. Можно попытаться раскрыть его, но я опасаюсь другой пропасти: программистского синтаксиса, как в украинском пропозале. lanes:directions=turnleft;through;through,turnright;turnright,psv читается, на мой взгляд, куда сложнее lanes:directions=l;s;sr;rp.
Dimuzz, тег directions снимает неоднозначность не столько с количеством полос для движения прямо, сколько с расположением и взаимоотношением поворотных и ограниченных полос: например, где находится полоса для общественного транспорта, можно ли с неё поворачивать.
Да, ещё не забудьте, пожалуйста как учесть “переходящие полосы”. Т.е. как в этом формате описать такую развязку, что бы было однозначное представление вот такой развязки, т.е. что бы было понятно, что правая полоса становится “только направо”, а левая “вырастает” из второстепенной дороги.
А не трактовалось, что второстепенная дорога вклинивается в главную, а на главной потом появляется правая полоса для поворота.
Читается сложнее, но если не держать в голове схему - то l;s;sr;rp не читается вообще.
Более того: перечисление через точку с запятой в текущем применении обозначает (насколько я понял) не последовательное, а одновременное применение. И вот с этим directions идет в разнос по-полной. Представим что мы объединили два куска с разными directions в JOSM: автомат нам такую кашу смешает, что мне страшно.
Логично: переделал все точки с запятой на запятые.
По крайней мере, это даёт стимул найти описание тега, а не придумывать объяснение ему из головы, как варианты с lanes:*, напоминающие об обычных lanes и lanes:psv.
Ну схема-то при этом не должна допустить двоякого толкования. Просто пока я не понял чем в схемах будут отличаться развязка из предыдущего моего поста и эта?
Вообще-то на местности там трёхполосный участок довольно длинный, начинается от первого примыкания (2+2->3) и длится до моста и дальше, где первая полоса становится «только направо» (3->2+1). Собственно, поэтому всё тегирование — поставить lanes:turnright=1 на последнем отрезке.
А как навигатор(или рендер) поймёт, что это не дополнительная полоса, а правая полоса от предыдущего участка. Ибо по незнанию, многие едут по правой полосе, а она ведёт совсем не туда, куда бы хотелось.
И как он поймёт, что переход из 2 полос в 3 осуществляется примыканием слева одной полосы?
Собственно, это и означает тег lanes:turnright=1 — что правая полоса только для поворота направо. Если были все прямо, а затем появился этот тег, то это самый логичный вывод.
Опять же, на усмотрение навигационной программы. 2+2->3 более логично, чем 2+2->(2)->3. Но в реальности зависит от программистов, конечно: схема тегирования здесь ни при чём, это только подсказка.
Еще, кстати, было бы неплохо добавить lanes:::width. Без типа будет для всех\по умолчанию, с типом - для конкретных (если реверсивная шире остальных, хотя это меня уже несет, обычно должно хватать lanes:width)
Также можно описывать момент возникновения lanes:::width:from lanes:::width:to.
В принципе при ручном редактировании ширины будут работать достаточно хреново, но если на них заложиться, то можно будет в итоге и плагин написать (аналогично плагину для релейшна), и решить вопрос “а где у нас добавилась полоса”, и (для маньяков) сделать рендер с полосами.
Ну или вариации на эту тему
lane:forward1=turneright,psv
или
lane:forward:1=turneright
lane:forward:1=psv
Писанины конечно больше, но схема расширяема. Уж если мы описываем полосу как отдельный объект, так и давайте тегировать ее как отдельный объект а не диапазонами. Ну а потом уж если хочется можно надобавлять:
lane:forward:1:offset=расстояние в метрах от осевой линии
lane:forward:1:width
lane:forward:1:maxspeed
lane:forward:1:maxspeedpractical
lane:forward:1:smoothnes
Ну и так далее
Писанины хоть и много но схема очень проста для понимания, легко читается, меньше шансов накосячить внося правки для одной полосы.
Scondo, у меня предубеждение против тегов с тремя и более двоеточиями. В обсуждении пропозала Фредерик недоволен даже двумя. Синтаксис с запятыми мне тоже кажется кривым, но, похоже, «в лоб» его не решить, нужно рассматривать проблемы, вызываемые таким синтаксисом, выделять самые важные и решать только их. Для этого, первым делом, нужно собрать примеров, когда без lanes:directions не обойтись (пока есть только два — с l,s,sr и p,s,s aka m,s).
Думаю, отдельные объекты стоит оставить на далёкое будущее с радугой, единорогами и highway=lane (есть замечательный пропозал на этот счёт). Для примера того, как оно сейчас, предложенная схема воплощает принципы работы прогорода (lanes:directions) и гармина (lane_restriction). Схема с параметрическими ролями крайне неудобна в обработке: вместо проверки на наличие/отсутствие тегов придётся сделать аналитический движок ещё сложнее, чем при обработке списка полос через запятую.
Это потому, что вы смотрите на набор тегов как на плоскую таблицу. А я смотрю на нее еще и как на дерево.
И в этом аспекте логичнее указывать позиции полос, которые ты только что посчитал, чем лезть на уровень выше и брать оттуда карту этих полос.
Относительно необходимости directions и вообще:
Дело в том, что если теги будет ставить человек, не проникнувшийся системой полос, то ему проще поставить конкретику для полос (даже если оно дублирует умолчания) чем три раза думать “а стандартный у меня случай или нет”. Также при вытаскивании конкретики на уровень выше возможны случаи когда люди вообще будут пропускать ее расстановку, даже если расположение полос не попадает в умолчания.
Опять же, если смотреть со стороны получается “а зачем тогда вообще считать полосы, если есть directions”.
Также не следует забывать что сочетания счета с конкретикой дает нам переопределенную задачу. Которая, опять же, значительно сложнее контролируется при разнесении по разнотипным тегам.
lanes:directions=“ls,s,s,s,r”
lanes:through=3
UPD:
Кстати, еще один жесткий аргумент за position= вместо directions
Если использовать отношения в нестандартной конфигурации, то у тебя получается одна и та же вещь (положение полосы) описана двумя разными способами (в запакованной кодировке directions и нумерацией в lane/lane:to релейшна). И вот это, на мой взгляд, уже совсем плохо.
Все параметры тега lanes опциональные (о чем говорят квадратные скобки, т.е. параметр может быть или не быть)
Только обратите внимание на то, что одновременно я предлагаю первым опциональным параметром указывать direction (forward | backward), если это требуется логикой описания, а затем уже движение по полосам, тип полосы или группы полос и уточнение их положения. Направление (прямое|обратное) в моем представлении является более общим объектом, чем полоса, т.к. направление в свою очередь сосоит из полос, а не наоборот. В свою очередь тип это характеристика той или иной полосы, а локейшн - обстоятельство места для нее.
Другими словами так:
**lanes [:direction] [[[] | [:type]] []] = ***, где lanes = number
direction<forward | backward>
maneuver<through | turnright | turnleft | turnback> = number
type<merge | psv | bus | hgv> = number
location = right | left | sides | number
Предлагаемый вами синтаксис логичен, строг, но уж больно многословен, представляю как придется вводить это все руками. А ведь полос и перекрестков на карте больше чем дорог…
Не попытаться ли как-то приблизить синтаксис к варианту, предложенному vvk000?
Во-первых маневр и тип это одно и то же.
Если полоса сливается - поворот с нее всегда будет на соседнюю. Если полоса для автобусов - движение определяется маршрутом автобуса и дополнительных ограничений не надо.
В-третьих проблема введения руками решается за счет копирования в отличие от “упакованных” форматов, которые очень сложны для неподготовленного пользователя и очень плохо читаются глазами. Помните: пока это не будет рендериться Вася Пупкин должен уметь прочитать тег объекта чтобы поправить или хотя бы понять что это и зачем.
И в четвертых: я надеюсь что рано или поздно плагин появится. А вот проблема читаемости будет постоянно (это же все еще надо будет куда-то вытаскивать и программист тоже должен легко понимать о чем идет речь)
Формат vvk000 ещё позавчера был частью моего пропозала, в виде тега lanes:directions. Он вызвал огромное количество нареканий с разных сторон, и в итоге был убран.
Порядок частей в теге продиктован существующими практиками записи: forward/backward — всегда суффикс, этого ожидают, например, редакторы, автоматически меняя суффикс при развороте линии. Да, это не очень понятно при чтении, но сотни уже присутствующих в базе lanes:psv:forward и подобных не позволяют сделать иначе. Как я уже объяснял Scondo, части тегов не образуют дерева, хотя и делают вид.
Причин разделять turn* и спецполосы я не вижу: алгоритм считает, что они совмещены, и позволяет при необходимости разделить. Inner и outer часто непонятны обывателям, да и мне при использовании этих терминов в пропозале каждый раз приходилось вспоминать, слева это или справа, а потом ещё и исправлять вызванные этим ошибки.
Что касается ввода руками, для абсолютного большинства дорог и развязок рисование полос поворота сведётся к добавлению одного-двух тегов из двух слов, lanes:turnleft/lanes:turnright. Только за вчерашний день в базе появилось более сотни таких тегов. Количество полос, скорее, является аргументом против некоторых других пропозалов, предлагающих создавать отношение на каждую полосу или их группу.