Нет, не следует. Если какой-то период опущен - то для него условие conditional не действует, а значит значение вычисляется из других тегов (применяется значение тега без conditional, а при его отсутствии берётся значение по умолчанию). Вот если не указывать oneway без conditional и дорога не одностороняя по умолчанию (motorway), тогда будет no, но будет проблема с совместимостью, которая интересует большинство для практического использования.
Это неверное понимание механизма работы conditional, перечитайте его описание. Он не заменяет собой сами теги.
Откуда это пошло? Есть причины для этого?
На вики я такого не помню, либо что-то новое.
Раздел Default restrictions
Да… Т.е. :conditional теги завязывают на обычные (oneway=*)… Ломая при этом старые теги…
http://wiki.openstreetmap.org/wiki/Proposed_features/Conditional_restrictions:
- The conditional restriction can be defined as a single tag.
- Backward compatible. Doesn’t break any established tagging schemes.
Смотрю примеры и действительно простые теги учитываются сначала, а потом уже conditional
http://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Conditional_restrictions&oldid=821276#Examples
maxspeed=50
maxspeed:conditional=30 @ (Mo-Fr 07:00-17:00)
Maxspeed limited to 30 on 7am - 5pm weekdays, but 50 otherwise.
Получается
oneway=no + oneway:conditional=yes @ Mo-Sa
правильное тегирование того знака по предложению?
Что будут делать программы которые понимают только oneway=*?
правильное получается
oneway=yes + oneway:conditional= no @ Su
Тогда они будут считать, что всегда oneway, что не так далеко от правды.
А если дорога односторонняя, утрированно, с понедельника до 12-00 четверга?
И со скоростями сравнение некорректное. Потому что скорость может быть хрен его знает какая, а режим проезда — либо одно-, либо двусторонним (бинарный вариант, третьего не дано). И если задано условие, когда этот режим принимает одно значение, то автоматически становится ясно, что вне условия режим будет противоположным.
Обозначил веранды в детском саду как man_made=shelter. Ничего более подходящего не нашёл. Хочется, чтобы рендерилось в мапнике серыми прямоугольниками, как другие man_made, но пока из всех подобных объектов в мире веранды в двух моих детских садах составляют больше половины этого количества, предлагать рендерить рановато…
А на building=roof оно не тянет?
Не понимаю почему. На множестве дней недели oneway:conditional=yes @ Mo-Sa и oneway:conditional=no @ Su эквивалентны. Пишем либо то, либо другое. Вместе - избыточно, как “Магазин открыт с 9 до 20, закрыт с 20 до 9”.
А вариант с oneway=no вообще сломает логику в системах, которые не знают про :conditional.
По мне веранда - чаще всего тянет на building=roof (A building open on at least two sides)
amenity=shelter я в принципе в любое место втыкаю, которое хорошо защищает от дождя (A small place to protect against bad weather conditions), а не только декоративные верандки (http://wiki.openstreetmap.org/wiki/Key:shelter_type)
Поддерживаю, для бинарных :conditional тегов явное тегирование Default restrictions погоды не делает, а только ломает оные.
Либо приходится писать в :conditional тегах когда это правило НЕ ДЕЙСТВУЕТ.
В первую очередь это здание, building=roof - а shelter это уже дополнительные свойства, как мне кажется.
В OSM практически нет бинарных тегов, oneway не исключение. Кроме yes/no там ещё документированы такие значения как -1 и reversible
Потому что он так работает, как условная модификация тегов (“если то-то, то применяем такое значение тега”), а не как безусловная замена (“вместо этого тега вычисляем его conditional вариант”). Поэтому вне заданного диапазона получается как будто этого тега нет, и используется значение из остальных тегов.
Я согласен что он плохой.
Условная модификация? В английской вики в Evaluation of conflicting restrictions пункт 3:
“A conditional restriction overrules a non-conditional restriction of the same transportation mode and direction”
Если я правильно перевел, значение oneway=* должно быть проигнорировано, если есть :conditional.
upd. Тоесть oneway=yes остается только для совместимости?
Вы целиком читайте, а не только избранное. Там перед этим стоит такая фраза: “When an object has two or more different restrictions both matching the given traffic and conditions, the following algorithm determines which one is valid.”, т.е. это применяется только когда условие в conditional выполняется. Вот если вы добавите условие для Su (oneway:conditional=yes @ Mo-Sa; no @ Su), тогда получится что conditional применяется всегда, и сам oneway действительно остаётся только для совместимости.
Если же есть ситуация, когда же условие не выполняется - тогда вступает в действие значение по умолчанию, вычисляемое из других тегов.
Спасибо, теперь всё понятно.
Давайте будем тегировать так, чтобы “значений по умолчанию” не нужно было вычислять из других тегов.
Я за любую сложную писанину в
oneway:conditional=yes @ Mo-Sa; no @ Su
но чтобы
oneway=*
не нужно было учитывать новым программам или заготовкам.
Связано это с тем, что :conditional встречаются у множества тегов от maxspeed до oneway. И как Sergey Astakhov напомнил, нужно будет учитывать все “-1”, “reversable” в программах, которые хотят только вводить/править временные ограничения
Это стили и заготовки, opening_hours редакторы, а не маршрутизаторы.
Править только “yes @ Mo-Sa; no @ Su” не так сложно, как и учитывать ещё к этому “-1”, “reversable” у oneway=*.
Почему-то думал, что она просто не тянет на building вообще.
Но раз тут такое единодушие, то ок, сейчас быстренько переделаю.