Как обозначать? (Part 1)

Не понимаю почему. На множестве дней недели 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 вообще.

Но раз тут такое единодушие, то ок, сейчас быстренько переделаю.

В садике оно не очень-то защищает, если его сторож защищает. Придётся access=private ставить и в навигаторах учитывать.

В общеобразовательных учереждениях чаще не private, а permissive.

Пустит тебя сторож своего ребёнка встретить в amenity=shelter.

Дороги там, где не пускают даже родителей ни случайных короткоходильщиков - нужно тегировать access=private.

С точки зрения эгоистичного маршрутизатора amenity=shelter страновится private только когда до него ни одной дороги нет.

Если amenity=shelter + access=private, то маршрут к нему можно пострить по access=permissive дорогам: подойти можно, но пользоваться законно (access=private) нельзя?

Откуда access=private возникает на веранде в детском саду в первую очередь? Явный запрет кто даёт? Сторож? Если не сказал, таблички нет, постановления нет - запрета (access=private/no) нет. Если пускают внутрь - permissive. Веранда тоже будет permissive.

Такие рассуждения.

Я не понимаю, в чём вы сложность то нашли? Программа всё равно должна быть функциональной и в отсутствии тегов conditional, иначе какой в ней смысл? А если она и так всё учитывает как надо, то применение умолчаний в conditional происходит естественным образом: проверили условие, если не подходит - работаем как будто этого conditional нет.

сложность не в “и в отсутствии тегов conditional”, а “поддержке без-conditional тегов, когда conditional указан”

И в чём же сложность? В добавлении одного if-а? :roll_eyes:

Не одного а двух случаев… Для maxspeed, oneway, minspeed, overtaking

Учесть :backward :forward.
Учесть :lanes.

Удачи короче :roll_eyes:

В англоязычной документации amenity отнесены к community facility. Что можно перевести не просто как “объекты инфраструктуры”, а как “объекты общественной инфраструктуры”. То есть преимущественно, это такие объекты, которые можно более или менее свободно посещать и пользоваться их услугами (менее свободно - когда для этого нужен билет, абонемент и т.п., но когда эти билеты и абонементы можно получить).

В этот ключ, конечно, за каким-то чёртом занесли образовательные учреждения (вероятно, потому что “образование - оно тоже общедоступное”, что не является хорошей логикой в данном случае, так как в школу с улицы никто не приходит поучиться).

Так что конечно, сложно запретить кому-либо обозначать укрытиями от дождя подъезды без козырька с кодовым замком, навесы на территории предприятий с пропускной системой, веранды в детских садах, но практический смысл такого обозначения стремится к нулю, так как посторонний человек этим воспользоваться, скорее всего, не сможет, а тот, кто может, не нуждается в этой информации в карте. Учитывая, что для правильного описания такого объекта нужно городить систему запретов через access (которая далека от совершенства), осмысленность такого обозначения уменьшается еще сильнее. Это ровно тот же казус как с обозначением туалетов в частных домах - нечто из разряда микромаппинга из принципа, порождающее данные, которые практически невозможно использовать на практике, потенциально вводящие в заблуждение, хотя и не являющиеся, формально, ложными.

Описать навес, как building=roof - прекрасное решение, которое описывает его конструктивно (а если использовать 3D-схему, то делает это весьма подробно), но не создает никакого казуса.

Тут как раз недавно в дневниках какой-то англоязычный маппер, который последний раз трогал редактор в 2010-м году, описывал свое удивление по поводу парковок. Он написал, что раньше, на заре OSM, была практика обозначать только публично доступные парковки. А сейчас так обозначают и частные, для чего приходится также добавлять тег access=private. То есть изначально смысл amenity=parking был буквальным - публичная парковка. А потом уже стали обозначать и те, что общедоступными не являются.

У меня по этому поводу родилась мысль, что вот мы имеем разного рода теги access (из тех что private/permissive/no), но нет простого универсального тега, который бы обозначал, что тот или иной объект не является общественно-доступным, без уточнения деталей. Бывет ведь так, что детали условий доступа неизвестны, но сам факт того, что это не общественно-доступный объект - известен.

Дорога. Знак 6.3.1 “Место для разворота” и разрыв в сплошной через 50 метров. Как правильно обозначить разворот?

Судя по http://taginfo.openstreetmap.org/tags/type=restriction#combinations restriction=only_u_turn не используется, да и предназначено для пересечений дорог.