Читается сложнее, но если не держать в голове схему - то l;s;sr;rp не читается вообще.
Более того: перечисление через точку с запятой в текущем применении обозначает (насколько я понял) не последовательное, а одновременное применение. И вот с этим directions идет в разнос по-полной. Представим что мы объединили два куска с разными directions в JOSM: автомат нам такую кашу смешает, что мне страшно.
Я там может чуть не правильно нарисовал… сама развязка - это выезда на М2 с МКАД.
В любой из схем эта развязка рисуется довольно просто — скорее, это задача для рендерера.
Логично: переделал все точки с запятой на запятые.
По крайней мере, это даёт стимул найти описание тега, а не придумывать объяснение ему из головы, как варианты с lanes:*, напоминающие об обычных lanes и lanes:psv.
Ну схема-то при этом не должна допустить двоякого толкования. Просто пока я не понял чем в схемах будут отличаться развязка из предыдущего моего поста и эта?
Можно продлить полосу съезда направо за перекрёсток, тогда будет более понятно.
А можно по предлагаемой схеме замапить на реальную дорогу? А то так не понятно вообще. Вот само место (JOSM).
Вообще-то на местности там трёхполосный участок довольно длинный, начинается от первого примыкания (2+2->3) и длится до моста и дальше, где первая полоса становится «только направо» (3->2+1). Собственно, поэтому всё тегирование — поставить lanes:turnright=1 на последнем отрезке.
А как навигатор(или рендер) поймёт, что это не дополнительная полоса, а правая полоса от предыдущего участка. Ибо по незнанию, многие едут по правой полосе, а она ведёт совсем не туда, куда бы хотелось.
И как он поймёт, что переход из 2 полос в 3 осуществляется примыканием слева одной полосы?
Собственно, это и означает тег lanes:turnright=1 — что правая полоса только для поворота направо. Если были все прямо, а затем появился этот тег, то это самый логичный вывод.
Опять же, на усмотрение навигационной программы. 2+2->3 более логично, чем 2+2->(2)->3. Но в реальности зависит от программистов, конечно: схема тегирования здесь ни при чём, это только подсказка.
Внезапно! А если воткнуть lanes:::position= вместо directions?
По схеме http://forum.openstreetmap.org/viewtopic.php?pid=194599#p194599
(да, меня раздражает кодированный синтаксис с запятыми)
Еще, кстати, было бы неплохо добавить lanes:::width. Без типа будет для всех\по умолчанию, с типом - для конкретных (если реверсивная шире остальных, хотя это меня уже несет, обычно должно хватать lanes:width)
Также можно описывать момент возникновения lanes:::width:from lanes:::width:to.
В принципе при ручном редактировании ширины будут работать достаточно хреново, но если на них заложиться, то можно будет в итоге и плагин написать (аналогично плагину для релейшна), и решить вопрос “а где у нас добавилась полоса”, и (для маньяков) сделать рендер с полосами.
Мне больше нравиться схема вида
lanes=6
lane:forward:1=turneright,psv
lane:forward:2=turneright
lane:forward:3=forward
lane:forward:4=turneleft
lane:backward:1=turneright
lane:backward:2=forward
Ну или вариации на эту тему
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 релейшна). И вот это, на мой взгляд, уже совсем плохо.
По результатам обсуждения со Scondo lanes:directions выпилен.
Вместо него — lanes:X:location, указывающий расположение группы полос для X:
- left — слева по ходу движения;
- right — справа;
- sides — поровну слева и справа (например, когда полосы разгона одновременно там и там);
- <число> — номер первой полосы из группы.
Пример: lanes:merge:location=left — полоса разгона примыкает слева.
А если вот такая форма записи предлагаемого вами синтаксиса:
lanes
[ :(forward | backward) ]
[ [ [ :(through | turnright | turnleft | turnback) ] | [ :(merge | psv | bus | hgv) ] ]
[ :location ] ]
Все параметры тега 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?
Во-первых маневр и тип это одно и то же.
Если полоса сливается - поворот с нее всегда будет на соседнюю. Если полоса для автобусов - движение определяется маршрутом автобуса и дополнительных ограничений не надо.
Во-вторых направление является суффиксом исторически. http://irc.latlon.org/logs/osm-ru/%23osm-ru.2011-10-10.log.html#t2011-10-10T15:40:41
В-третьих проблема введения руками решается за счет копирования в отличие от “упакованных” форматов, которые очень сложны для неподготовленного пользователя и очень плохо читаются глазами. Помните: пока это не будет рендериться Вася Пупкин должен уметь прочитать тег объекта чтобы поправить или хотя бы понять что это и зачем.
И в четвертых: я надеюсь что рано или поздно плагин появится. А вот проблема читаемости будет постоянно (это же все еще надо будет куда-то вытаскивать и программист тоже должен легко понимать о чем идет речь)
Формат vvk000 ещё позавчера был частью моего пропозала, в виде тега lanes:directions. Он вызвал огромное количество нареканий с разных сторон, и в итоге был убран.
Порядок частей в теге продиктован существующими практиками записи: forward/backward — всегда суффикс, этого ожидают, например, редакторы, автоматически меняя суффикс при развороте линии. Да, это не очень понятно при чтении, но сотни уже присутствующих в базе lanes:psv:forward и подобных не позволяют сделать иначе. Как я уже объяснял Scondo, части тегов не образуют дерева, хотя и делают вид.
Причин разделять turn* и спецполосы я не вижу: алгоритм считает, что они совмещены, и позволяет при необходимости разделить. Inner и outer часто непонятны обывателям, да и мне при использовании этих терминов в пропозале каждый раз приходилось вспоминать, слева это или справа, а потом ещё и исправлять вызванные этим ошибки.
Что касается ввода руками, для абсолютного большинства дорог и развязок рисование полос поворота сведётся к добавлению одного-двух тегов из двух слов, lanes:turnleft/lanes:turnright. Только за вчерашний день в базе появилось более сотни таких тегов. Количество полос, скорее, является аргументом против некоторых других пропозалов, предлагающих создавать отношение на каждую полосу или их группу.
На мой взгляд не совсем так, поэтому добавил между ними “или”: т.е. после направления либо маневр для полос, либо их тип (автобусные, звездолетные и т.п.).
И еще. Наверняка существуют способы оптом заменить lanes:psv:forward на lanes:forward:psv ну и поправить страничку описания.
Вон в Белоруссии недели две назад тысячам дорог, не имеющим ref, было присвоено unclassified одним махом и ничего, выжили и приняли новые правила их тегирования. Зато порядку и логики стало больше.
Все наши шоры - дело привычки и нежелания их менять. И есть ли сегодня хоть одна программа с серьезным покрытием СНГ, использующая psv? Думаю, пока еще можно изменить. Будет только польза.
Вообще, тип — эквивалент запрета «прямо для несоответствующих т/с нельзя», всё остальное такое же. Другими словами, это такой же вид «turn restriction per lane», как и полосы поворота.
Такие действия — отличный способ попасть на костёр. Вон, в Европе даже абсолютно бессмысленный created_by не рискуют выпиливать. Если другой программист со своей навигационной системой через полгода предложит снова сделать lanes:psv:forward, что тогда?
Изменение принятых тегов — крайне сложный процесс, требующий времени, сил и нервов. Я пробовал, и больше не хочу. Начинается процесс с пропозала. Добавлять страницы в вики может каждый, попробуйте.