Люди не хотят “использовать тег”. Они ходят использовать софт. А что он использует вправе и не подозревать.
Русский маппер напишет софт, который будет конвертить RU:urban в РФ и обламываться, если кто-то попробует сконвертировать им другую, малопопулярную африканскую страну из-за какого-нибудь ZU:urban. Что в этом хорошего?
К чему сужать область возможного использования данных?
Некоторые знаки имеет смысл мапить исключительно для навигационных целей (в смысле исключительно для навигации по карте без использования GPS/ГЛОНАСС).
Это, к примеру, российский знак 6.11 «Наименование объекта» и многие другие. При наличии работающего GPS от наличия его обозначения на карте никакого толка, но при отсутствии приёма GPS некоторые (но далеко не все и не везде) знаки могут быть хорошими ориентирами.
Во многих случаях, скажем в городах, ориентиров и так достаточно, и нанесение на карту дорожных знаков для целей навигации бесполезно.
Многие предупреждающие знаки (1.x в отечественных ПДД) навигатору бесполезны - скажем, навигатор и так знает, что впереди железнодорожный переезд, наличие в БД ещё и соответсвующего предупреждающего знака никакой дополнительной информации навигатору не несёт.
Подводя итог, можно сказать, что иметь полную карту знаков, конечно, будет неплохо, но практической пользы от присутствия в БД обозначений некоторой части знаков (см. примеры выше) почти нет.
Причём здесь люди, использующие софт? Речь о людях, софт разрабатывающих.
И они должны учитывать используемые значения, если хотят получить вменяемый результат.
Писать конвертеры, не обращая внимания на применительную практику тегов — нонсенс.
Постоянно менять практику тоже нонсенс.
maxspeed=60; maxspeed:source=RU:urban
более переносимая конструкция, чем
maxspeed=RU:urban
Я не вижу тут людей, которые напишут в своем конверторе табличку на сотню стран и будут поддерживать ее в актуальном состоянии.
Можно подумать, табличка с сотней тегов лучше.
А практика меняется постоянно и независимо от нашего желания, это нормально.
Нормально, когда она меняется. Ненормально, когда она меняется постоянно 
А как ещё? У нас нет единого самодержца, чтобы решал, когда можно менять практику. 
Конфиги для конвертации адрески странозависимые, причем у всех, например:
https://github.com/Zkir/osm2dcm/blob/master/jmp2mp2/src/ru/zkir/mp2mp/taskgeocoder/GeocoderConfig.java
Для XX:urban|rural придется иметь страноспецифичные конфиги. Например, прямо на вики.
Но насколько я знаю правильное, с точностью до целых километров, ограничение скорости никто не поддерживает.
Каково практическое значение? Ну будет заточен под них только локальный навик/рендер. В России, от силы только 7дорог будут пользоваться этой информацией. А как быть со странами, где нет “национального” маршрутизатора/рендера? Сомневаюсь, что программер озадачится изучением правил сопредельных государств.
К тому, что ограничения разные - они разные только по скорости в населённых пунктах и на трассах, но для этого мы в свойствах вея устанавливаем значения. Знаки же типа: ограничение скорости, остановка запрещена, опасный поворот, пешеходных переход, “стоп”, уступи дорогу и т.п. - может быть по отображению разные, но по сути одинаковые практически везде, даже в странах не принявшие венскую конвенцию.
Менять практику не постоянно, а изредка, сохраняя преемственность и совместимость.
maxspeed=60; maxspeed:source=RU:urban
Первая часть - указание конвертору, вторая часть указание мапперу, чаще всего локальному, кторый знает про особенности (RU:*) мест, где мапит.
maxspeed=RU:urban
Тут особенности национального мапинга ОБЯЗАН на выучить и конвертор - это хороший минус.
Но как ты хочешь это обеспечить?
«вот - знак (точка), а вот - дорога (линия с направлением)»
какое придумается)
будут браться готовые данные из отношения, как я понимаю.
что за «он», где требуется направление, но к дороге отношения не имеет?
Хм, а мне думается, что если известно, какой знак и где он действует, то это и есть «как_он_работает_в_комплексе». Ваши слова: «Для тех, кто ездил по 8 км в зоне действия “обгон запрещён” (который там ещё за ветками где-то стоит, а резметки уже года 3 как нет), думаю, не смысла объяснять зачем указывать “где стоит и где действует” (это же касается и других знаков).»
Хотел запилить быстрорендер знаков, да только тамошняя версия MapCSS не умеет в icon-rotation (а может, и в eval).
На счёт direction - это очень проблематично вычислить куда направлен знак (ну +/- 30 градусов ещё можно с ходу сообразить), не говоря про то, что direction - то ли куда направлен, то ли куда действует постоянно будет забываться (это не говоря про то, что у скамейки это “куда сидишь лицом”, у камеры - куда она снимает, у знака - куда он действует, т.е. в самом определении уже проблема).
Для меня - направление знака, это куда смотрит его лицевая сторона, а не куда он действует.
И действовать он может по разному. Примеры, что смотрит в одну сторону, а действует в другую или в обе стороны (если указывать “куда он действует” то получиться неразбериха т.к. основной знак действует в одном направлении, а табличка в другом, при этом табличка меняет смысл/направление основного знака):
http://www.fotopetropavlovsk.ru/photo/znak.jpg
http://gai.ru/i/exam/images2/22/22_12.jpg
Знак и его действие все же нужно отдельно мапить. Мапинг знаков позволит людям не знающим ПДД замапить все знаки. При желании более опытными мапперами будут добавлены соответствующие ограничения на дорогу (или конвертер/бот это добавит).
Ещё нужен тег для временных знаков (те что на желтом фоне).
И тег указывающий способ установки (на столбе, на доме сбоку, на специальной трубе) http://wiki.openstreetmap.org/wiki/RU:Tag:amenity%3Dclock - для унификации наверное лучше использовать то что уже есть, т.е. тег support=* .
Ещё есть знаки которые сами умеют светиться - для этого тоже тег отдельный нужен.
Примеры знаков которые светятся (СССР-версия) - http://vk.com/albums-72187180
Современная реинкарнация (из светодиодов):
http://kur-ort.ru/images/stories/011sznak2.jpg
http://atworks.ru/wp-content/uploads/2012/04/Светодиодные-знаки.jpg
Тут пишут, что есть ещё с внешней подсветкой (и заодно ещё фотография современного с внутренней подсветкой) http://tema.livejournal.com/1571845.html
Мне кажется что тег подсветки нужно унифицировать с рекламными щитами - они тоже часто светятся/освещаются и часами (циферблатом часов).
Ещё есть знаки из светодиодов, которые умеют меняться/выключаться:
http://lunch-park.ru/uploads/posts/2013-11/1385277554_766b_2.jpg
http://www.technotraffic.ru/netcat_files/Image/ZSD-ASUUD.jpg
Тоже как бы знаки, внешне похожи, но ими не являются - как мапить?
https://b-a.d-cd.net/bbfc3d8s-960.jpg
Просто примеры сложных случаев (табличка относиться только к знаку который выше, т.е. нужно либо порядок соблюдать сверху вниз/снизу вверх, либо отношение):
http://jabak.ru/data/p7-3-010910-002528.jpg
http://region69.info/_nw/132/49886393.jpg
Порядок знаков соблюдать не получиться (или для боковых знаков отдельные точки создавать и в теге способа крепления указывать, что крепиться сбоку от основного знака):
http://i2.obozrevatel.ua/5/1286770/gallery/811944.jpg
http://volh.in/wp-content/uploads/2011/04/img_0028.jpg
Взаимоисключающие знаки:
http://s.drom.ru/1/pubs/4483/12122/105299.jpg
Я считаю, что эти знаки не являются знаками ПДД, а потому их и обсуждать здесь не нужно. И обговариваемая схема тегирования знаков ПДД для них применяться не должна.
Смотрите, direction - если хотите указывайте, не хотите - не указывайте, я изначально ухожу от этой идеи (хотя, можно некую “виртуальную” ноду с ролью sign_face, но очень не хочется).
Ни чего не мешает сразу мапить только знак (в этом суть, нет обязательного “укажите где он действует” и т.п., если хотите - укажите, при чём, хотите - точками, хотите - отрезками, как угодно), без остальных вещей, но сразу отношением, что бы не плодить всего много (фековых нод и виртуальных веев).
И потом , один столб и 100500 знаков на нём? - не проблема, мапьте столб отдельно (какой-нить sign_postament +diametr+height+…), а знаки “вешайте на него”.
Далее, почему я говорю, что не хочу, что бы это отношение несло “как действует знак”, потому что это “первичные данные”, из них, уже другими, отдельными(самостоятельными, т.е.!) тегами (как то maxspeed,max_height) и т.д. должны выводиться “условно реальные” теги на веях/нодах и т.д., пускай даже на этапе конвертации в нужный формат, но не в рамках этого отношения.
Так же, все знают проблему “перевода”, и она первична, она не даёт замапить знаки, т.е. знак есть (те же “подача звукового сигнала запрещена” или “место для отдыха” или “пост ДПС”), но мы их не знаем как замапить, то ли потому что не можем “правильно перевести” (хотя ограничения на то, что все теги должны быть на английском - нет, то же name мы нормально пишем по-русски, там почему name для знака надо сочинять на английском и непременно в связке с “другим тегом, отображающим суть знака”), то ли потому что “через 30 км и так будет пост ДПС - по карте посмотри” и т.п., но знак есть, ориентир присутствует, а отметить не хотим.
Есть traffic_sign, есть статья на вики, где чётко написано:
Насколько я вижу проблему сейчас — не определён способ маппить несколько знаков на одну ноду. Понятно, что это отношение, но какое?
Можно предложить отношение с тегами type=traffic_sign + traffic_sign=* и нодой без роли.
Я ещё предлагаю уйти от traffic_ в сторону road_, т.к. это более точно и отображает, что именно дорожный знак, а не только тот, который для проезжих частей.
Опять же, разговор начал, потому что
Отмечать, где действует знак — невероятный геморрой, это будут делать 3.5 человека.
Схему, конечно, можно придумать, но я предупредил. :3
traffic_sign это позволяет.
Аще непонятно, в чём сложность. Можно указывать только кардинал, ну а для джосмеров всё совсем просто — азимут отображается на статусной панели, когда вы рисуете линию:
