О дорожных знаках

А есть ли практический смысл рисовать на карте знаки? Это скорее для навиков надо, чем для рендера

По поводу смены номеров знаков в новой редакции ПДД - вариант возможен (так на вскидку, они только добавляются, правда, но тем не менее), возможно, изменить формат на sign:RU:[YYYY[MM[DD]]] (ну или другая дата, при отсутствии считается текущая, при наличии других - самое позднее значение)=значение.
Почему road_ а не traffic_ - т.к. все “дорожные” знаки, а не только те, которые к движению по проезжей части относятся.
Почему я сразу упираю на РУ, потому что не надо повторять мантру “международный проект давайте делать в международном формате и т.д.”, суть этого отношения - вспомогательная, в конечном итоге оно может быть и перерастёт в некое “по всему миру”, но оно сейчас должно отображать именно “как в ПДД РФ (РБ,Украины, Франции, Германии и т.д.)”, т.е. именно для конкретной страны, не пытаясь пересечь (в смысле - найти аналоги) их с другими. Знаки у всех разные, “дефолтные” ограничения тоже.
Смысл именно в том, что бы дать возможность маперам региона нанести знаки. Уже потом, заведя новые теги можно всегда знаки перевести в эти теги, одним махом, пройдясь ботом. Точно так же, если вдруг у нас введут в городе ограничение 50, то взяв maxspeed:source=RU:urban можно спокойно все соответсвующие maxspeed’ы поменять с 60 на 50, сделав это быстро и в автомате (а не вечные “руки не дошли”, мы же боремся за актуализацию данных).

Теперь, небольшое дополнение по отношению.
Во первых, на него можно вешать “стандартные теги”, т.е. тот же максспид можно прописать в отношении (а не на отдельных участках дорог, что, имхо, удобнее),
во-вторых необходимо будет добавить 2 роли для веев:
роли sign:begin (всё ж begin, а не start) и sign:end, потому что есть такие вещи, как “конец зоны”.
Если указан просто sign, то под ним подразумевается sign:begin

Кстати, пешеходные переходы (площадные) тоже сюда вполне вписываются.
Ещё раз, про цель отношения - его цель актуализация данных (тегов) на основе первичных источников (знаков), при этом оно вполне допускает конвертирование в рамках каких-то конвертеров и отображение некими рендерами. Но на выходе, всё же, должны быть конкретные значения тегов скорости/количества полос/запретов поворота/обгона (вытекающее, в т.ч. из “опасного поворота” или “моста”, который, напомню в ОСМ мапится только тем местом где “пролёт”, а ПДД запрещают обгонять уже на этапе “подъезда к ОСМ-мосту”) и т.д. Это некое “вспомогательное отношение”, которое содержит “как оно есть на дороге”, и дающее возможность “замапить все знаки”, нежели попытка все теги (запрет поворота, ограничение скорости, ширины, высоты и т.д.) соединить в единую схему (что только зло).

Кажется, что свалены в одну кучу дорожные знаки и ограничения, которые они налагают.
Знак - табличка на столбе, пусть на node и висит, кому надо - тот отрисует.
А ограничение (максимальная скорость), которое он налагает в зоне своего действия - совсем другой тег (maxspeed).

Давайте определимся, что предлагается - дополнить метод мапить знаки или совершенно новая система обозначения ограничений взамен существующей?

Знаки. Только не ограничения, а вообще все.
Суть схемы - показать где стоит знак, что это за знак и где он действует. Пока (думаю, и потом) не предполагается описывать “как он действует” (это тегируется своими тегами, с вполне рабочей схемой их принятия).
Ну, т.е. value=* можно прописать (там макс скорость, или другое ограничение), но это не основная цель. Цель - “мапить знаки”, повторюсь, не как столб, а с зоной их действия. Для тех, кто ездил по 8 км в зоне действия “обгон запрещён” (который там ещё за ветками где-то стоит, а резметки уже года 3 как нет), думаю, не смысла объяснять зачем указывать “где стоит и где действует” (это же касается и других знаков).

Так это решает текущая схема. Пока по факту я вижу большую громоздкость, а результат пшик в виде “столба”.

Как в текущей схеме замапить “обгон запрещён”? Важно - именно с зоной действия. Или “Подача звукового сигнала запрещена”, или “Остановка запрещена”, ну и т.д.

А многие ли, не заглядывая в вики (я честно не смотрел), сейчас смогут ответить, куда нужно направлять direction знака — в сторону, куда он действует, или в сторону, куда обращена его лицевая сторона?

Если маппим знак, то логичнее второе. А если использовать первое, то вероятен коктейль разнородных данных.

Многие знаки действуют до перекрестка. На перекрестках будет каша из всех, кто там заканчивает действие

overtaking=* 
parking:lane:right=no_stopping, parking:lane:left=no_stopping, parking:lane:both=no_stopping (в зависимости от расположения знаков) 

http://wiki.openstreetmap.org/wiki/RU:%D0%94%D0%BE%D1%80%D0%BE%D0%B6%D0%BD%D1%8B%D0%B5_%D0%B7%D0%BD%D0%B0%D0%BA%D0%B8_%D0%A0%D0%BE%D1%81%D1%81%D0%B8%D0%B8/%D0%97%D0%B0%D0%BF%D1%80%D0%B5%D1%89%D0%B0%D1%8E%D1%89%D0%B8%D0%B5_%D0%B7%D0%BD%D0%B0%D0%BA%D0%B8

Нашел такое, но не про то, что надо:
http://wiki.openstreetmap.org/wiki/Key:traffic_signals:sound

Ещё вброшу на повестку.

Как обозначать несколько знаков на одном столбе?
а) Несколько нод рядом (уныло и неправда);
б) Пустая нода с пачкой отношений (уже лучше, но громоздко);
в) Точки с запятой! (да ну их нафиг).

Предлагаем ещё варианты.

Именно! Поэтому direction - атавизм, который необходимо убирать, только указывать нужно именно на том месте, где он действует (для этого-то и отношение).
Далее,
По поводу “действуют до перекрёстка” - не все (лишь часть запрещающих) и не всегда (иногда - до границы НП, иногда - до окончания НП).
В третьих - видимо, повторю ещё раз 100, я не предлагаю сделать замену существующих схем, предлагаю “мапить на будущее”, т.е. обозначать как стоят знаки, обозначать как они действуют, по мере разработки новых тегов (например “клаксон=запрещено”) оперативно поднимать отношение с sign:RU[:дата последних изменений]=3.26 и дополнять отношение (можно и веи из него, но смысл?) и дописать в него ещё один тег “клаксон=нельзя”. Всё. Ни какой лишней работы, только ботом пройтись раз - всё сделано и подготовлено до, в процессе внесения знаков, и главное, мы знаем по какой причине нельзя (стоит знак), а не потому что тут дворовая территория, скажем.
Кстати, есть ещё комбинации запрещено /разрешено по чётным/нечётным. И чем мапить parking:lane:right=no_stopping:odd+parking:lane:left=no_stopping:even+parking:lane:right=no_parking:even+parking:lane:left=no_parking:odd
Можно спокойно завести отношения для каждого из знаков, указать у них отдельно opening_hours (а в Москве, как Вы знаете, бывают ещё исключения по выходным и праздникам, которые в чёт/нечет не укладываются, но спокойно ложатся в opening_hours) и не париться с супер-расширениями тегов, которые чуть что - надо всё переделывать и отследить ещё, что бы все веи на дороге были переделаны и не дай бог ни один не забыть.

Если это отдельные знаки - то на каждый своё отношение, если это знак+табличка к нему - то табличку либо в “расширение” (sign_extend, см 1-й пост), либо (если это временные интервалы) в opening_hours.

Вот не надо этого, пожалуйста - “одним махом, пройдясь ботом”.
То, что можно сделать ботом, следует делать в конвертере (за исключением явных ошибок, типа очепяток).
Поэтому вместо “maxspeed:source=RU:urban” следует использовать “maxspeed=RU:urban” а остальное перенести в конвертер. Тогда менять нужно будет только его настройки а не базу данных курочить.

Я знал, что вы про них помяните.
Уже спокойно заведено. Аж две штуки:
http://wiki.openstreetmap.org/wiki/Conditional_restriction, причем там синтаксис точно, как в opening_hours

parking:lane:right:conditional=no_stopping @ (08:00-10:00)

http://wiki.openstreetmap.org/wiki/Key:parking:lane#Specifying_time_intervals_.28optional.29

parking:lane:right=no_stopping 
parking:lane:right:time_interval=08:00-10:00

Чтобы ни один вражеский софт не сработал

Даже если какой софт не умеет работать с нечисловыми значениями - это решается одним проходом osmosis-а. Было бы желание.

И, что мешает существующим тегам и схемам существовать?
Ещё раз - я не предлагаю заменить существующие схемы новой. Если уже есть схемы, в которых пускай и надо 150 раз повторить одно и то же “заклинание” (motor_vehicle=no+motor_vehicle:conditional=yes @ (18:30-07:30) bicycle=yes+bicycle:conditional=no @ (Sa 08:00-16:00)), кстати в примерах conditional часто меняет значение на обратное “ухудшая положение” (maxspeed=none ->120|100, при том. что none всего 2 часа в сутки, имхо, надо 100, а через conditional “повышать” до 120 и none), но это небольшой офф, то пускай существуют, их менять не предлагаю. Предлагаю отмечать знаки, как первоисточник информации, что бы можно было сказать “почему тут ограничение”, откуда оно начинается (и с какой точки на hw, и где именно стоит знак, который действует именно на этот участок дороги, потому, что какой толк от direction для “Въезд запрещён”[+“Объезд препятствия справа”], установленных между двух параллельных проезжих частей, получается, что знак сразу на обе действует, хотя понятно, что смысл сего показать, что слева встречка).

IMHO, не надо пытаться применить traffic_sign для указания ограничений. Предлагаю маппить знаки просто как знаки, с азимутом нормали лицевой стороны в качестве direction.

А уж если кому надо, то он может пытаться рассчитывать их действие при конвертации во что-нибудь. Но вообще для этого обычно есть другие теги.

Вопрос не в том, что вы сможете пройтись osmosis’ом, а в том, что другие не то, чтобы не смогут, а и не догадаются, что это надо сделать в обязательном порядке.
Скачали страну, конвертнули, приехали, и прямо в лапы полицейским.
Данные о разрешенной скорости, оказывается, были зашифрованы российскими мапперами.

Если кто-то хочет использовать тег, то обычно смотрит на статистику используемых значений, чтобы поддержать актуальные.