lanes=6
lanes:forward=3
lanes:forward:turnleft=1
lanes:backward:turnleft=1-3 (или даже 1;2;3 - ближе к принятым схемам тегирования)
Просто вариант с количеством слишком опирается на “умолчания” из-за чего плохо воспринимается и постоянно остается желание вкрутить directions, который, в силу сокращений, тоже не эталон красоты - все эти буквы надо держать в голове, а они ведь, по сути, дублируют те же полосы.
Минусы “переворота” по сравнению с lanes:x - нельзя навешать “чего хочу” на каждую полосу.
С другой стороны можно оставить непосредственно движение на lanes::=
а все расширенное (ширина там, рельсы, можно вообще все из вэйпартов) выкинуть в lane:x:
Два тега - два подхода. Один лучше поддерживается ПО, второй - больше позволяет. При желании прожевывается роботом в любом направлении.
В этой схеме меня смущают итоги вида: lanes=3, lanes:turnleft=3. Путаются количество с номерами, очень неочевидно для новичков, не видевших соответствующей вики-страницы.
Точно. Поэтому еще раз предлагаю посмотреть в сторону turnleft_only/turnright_only (для исключения крайних левых/правых полос из движения прямо) как варианта однозначного обозначения движения по полосам для Прогорода. Имхо, lanes:directions надо убирать, не ложится он в эту схему…
Ну да. Но с одной стороны эта проблема, с другой стороны lanes:forward:bus=1 при использовании по числу нам сообщает достаточно только то, что есть полоса для автобуса. Ее положение мы можем определить либо опираясь на ряд допущений, либо на directions.
Так… а если оставить lanes как в пропозале, а directions пропозала заменить на lane:x: ?
Вылезают проблемы с перечислением в названии… черт. Главное что меня смущает в пропозале: мы либо угадываем либо смотрим в directions, который использует синтаксический код вместо описательных тегов…
Тут дело в том, что 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 релейшна). И вот это, на мой взгляд, уже совсем плохо.