Спасибо, теперь всё понятно.
Давайте будем тегировать так, чтобы “значений по умолчанию” не нужно было вычислять из других тегов.
Я за любую сложную писанину в
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-а? 
Не одного а двух случаев… Для maxspeed, oneway, minspeed, overtaking
Учесть :backward :forward.
Учесть :lanes.
Удачи короче
В англоязычной документации 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 не используется, да и предназначено для пересечений дорог.
А разве access=yes? На время пока не станут ясны уточняющие детали подойдёт.
Как в этой ситуации, по-вашему, должен помочь access=yes?
Встретил Будду — убей Будду
Не, не то…
А! Нет готового подходящего тега - придумай его. 
Тег access= и обозначает недоступность при определённых условиях. Вы сами написали, как обозначать при условии что “объект не является общественно-доступным”, но неизвестны детали. Вот и получается, да недоступен, уточнения найдите/напишите сами
Не представляю, откуда вы это взяли.
access=yes обозначает противоположную ситуацию: когда известно, что доступ к чему-либо гарантированно открыт для широкой публики.
Да вот как раз думаю.
Мотивация простая:
- не всегда детали известны и их можно сходу выяснить даже при обследовании,
- не всегда детали важны, важен сам факт отсутствия публичного доступа,
- схема access=* имеет довольно развитую структуру вложенности в части разных видов транспорта, но совершенно плоскую и тупую в части разного рода лиц и организаций, где всё сведено к нижнему детальному уровню, а более общий уровень весьма беден и груб, т.к. access=no обозначает общий полный запрет для general public, что подразумевает вообще кого угодно.
Но «промежуточные» варианты, всё же, есть:
access=customers/delivery/permissive (довольно мутный)/private.
Тут ещё полезно продумать нюансы типов доступа как такового: «юридическое» (правовое/законодательное) разрешение и физическая доступность. Например, barrier=block + bicycle=yes + foot=yes мы, ведь, имеем в виду именно физическую доступность весьма часто (блок поставлен, а запрещающих знаков нет или где-то раньше, на въезде имеется знак «тупик», но он не запрещающий).
В принципе, d1g уже обращал внимание на Proposed features/Obstacle
Чувствую, что без примеров понять туго.
Вот есть стояночное место (места) в пределах публично доступной стоянки у какого-нибудь торгового центра или еще чего-то такого. Оно как-то отгорожено и заперто на замок. По машинам, которые там стоят, понять, для кого это место - невозможно. Табличек нет. Караулить тех, кто там оставил машины - не представляется возможным.
Повесишь access=no - а хрен его знает, может оно на самом деле access=customer или access=permissive? Можно описать ситуацию через fixme или note, но оба этих тега имеют значения в свободной текстовой форме. Но для возможности использования данных такие мелкие детали и не особенно важны, может быть достаточно сказать что это “не публично, неизвестно почему”. Это перекликается с идеей отдельного обозначения для физического ограничения, но не повторяет её, потому что физические ограничения имеют свойство меняться (стоял столбик, который преграждал путь машинам, но он сломался, либо была канава, но её закидали мусором а края размесили). Да и перечислять/анализировать все возможные физические препятствия, вероятнее всего, избыточно.
Это, в какой-то степени, способ избежать своеобразного микромаппинга, который требуется сейчас.