Полосы

Точно. Поэтому еще раз предлагаю посмотреть в сторону 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: автомат нам такую кашу смешает, что мне страшно.

Я там может чуть не правильно нарисовал… сама развязка - это выезда на М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?