Полосы

Вообще-то на местности там трёхполосный участок довольно длинный, начинается от первого примыкания (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, что тогда?

Изменение принятых тегов — крайне сложный процесс, требующий времени, сил и нервов. Я пробовал, и больше не хочу. Начинается процесс с пропозала. Добавлять страницы в вики может каждый, попробуйте.

Сдается мне, что во многих случаях, где этого можно бы было избежать в предложении vvk000, придется дробить отрезки между перекрестками на отдельные части, иначе иногда невозможно будет разобраться относится ли описание полос к началу отрезка или к его концу. И, если в случае изменения числа полос перед перекрестком такое дробление оправдано, то в случае, если их число не меняется, еще одна излишняя операция.
У vvk000 это реализовывалось с помощью begin/end. Сейчас оценить это сложно, возможно, издержки и не большие. Покажет практика.

Каждый, кто более-менее свободно владеет английским. К сожалению, рядовая советская школа и советский ВУЗ таких навыков не давали. Мы, видно, хотели, чтоб они все читали по-русски, ан-нет, они не захотели. Наш язык для них слишком богат и ясно выразить мысль на нем не получается. Имеено поэтому у них no smoking, а у нас - курение запрещено, курение строго запрещено, курение категорически запрещено и т.д. и т.п. и пр. др. Кстати, видимо, именно в силу бедности их языка они и законы по 200 лет не меняют, а принятые вчера не переписывают на следующий день, потому, что, как оказалось, сказали не то, что хотели. И никак у них не получается по одной и той же статье за пару миллиардов дать два года условно, а за мешок картошки впаять семь лет. Да здравствует великий и могучий во веки веков.
(Это были сетования по поводу собственной необразованности, сори).

Т.о., попытка постичь ангельские буквы привела к такому алгоритму:
**lanes [[[ | [:type]] ] [:direction]] = ***, где
*lanes = number
maneuver<through | turnright | turnleft | turnback> = number
type<merge | psv | bus | hgv> = number
location = right | left | sides | number
direction<forward | backward> = **

Звездочка в данном случае означает любое допустимое значение для используемых тегов, а number - количество полос соотвествующего типа. Верно?
И все равно, хоть убейте, но описание
lanes:forward:bus:location = right
мне нравится больше, чем
lanes:bus:location:forward = right
Первое более лигично, ибо использует общепринятый принцип описания составного объекта: “от общего - к частному”. Т.е. составляющие объекты описываются по принципу все более подробного уточнения их свойств (характеристик). Да и логика хромает, хоть с точки зрения синтаксиса разговорного языка, хоть с позиции программирования. Вот что локейшн может быть справа, это я понимаю, а вот что форвард, это еще осмыслить надо.

Проверил здесь. Тег lanes:psv на картах России (эвропейская часть), Украины и Белоруссии вместе взятых применен всего 1 (!!!) раз, еще 34 раза применен тег lanes:bus. Так что это не революция и не бунт.

Scondo недавно вполне резонно указал, что многие не читают tagging@ и не следят за страницами в вики. И не читают штосм Поэтому намекаю, что голосование по пропозалу полос съезда/разгона началось (неделю назад). Странным образом после его запуска у многих начали появляться осмысленные вопросы, поэтому я составил FAQ, правда, на английском. Если голосование будет успешно, на страницах тегов попробую описать систему более понятно – за всё это время я её понял гораздо лучше

Zverik
Перевод на русский будет?

Перевёл

Сам пропозал буду переводить после голосования. Кратко он описан на штосме, обсуждение велось в этой теме на нескольких страницах. Кроме того, есть мои черновики на русском (в некотором уже неактуальные).

Вот пример:
http://wiki.openstreetmap.org/wiki/File:Buslaneex.jpg

Вот теги:
lanes=4
lanes:psv=1
lanes:turnright=1
lanes:turnright:location=1

lanes:through не задан, используем формулу:
lanes:through = lanes - Ʃ(lanes:*)

Чему равен lanes:through?

lanes:through = lanes - lanes:turnleft - lanes:turnright = 3
Если бы поворота не было бы было бы 4. автобусные полосы не влияют на полосы направлений.

Антон, формула там для понимания механики. Она не является точной, а лишь даёт понять, что lanes:through почти всегда можно вывести из остальных тегов.