Не так. Barrier и без того уже отмечается своим тэгом. Тут нужно описание, кто дежурит на посту:
Точка с запятой засовывает несколько значений одной классификации в один тег.
А здесь две разные классификации. То же, что в тег “color” засунуть значение “green;fat”.
Не думал что тред про переходы разовьется до тэгов armed_guard 
Тут разный смысл. barrier может быть и не отмечен, а может быть отмечен, но очень просто преодолеваем. access_enforcement=no говорит что даже если барьер есть, за него можно без труда попасть.
Это имхо немного ортогональный тэг.
Такой тэг (наверное что-то типа guarded_by) может/должен обозначать наличие охраны вообще, а не ее функции, т.е. может по территории можно ходить, но правопорядок там усиленно поддерживается милицией или омоном, как на митингах например.
Я думаю если есть access=prohibited и guarded_by, можно предполагать что охрана прежде всего энфорсит закрытость территории.
И да, от темы мы отошли - я бы разобрался с access для начала.
Не вижу тут никакой проблемы. Начнем с того, что в access уже сейчас несколько классификаций, например designated собственно access’у весьма ортогонален, не говоря уже о agricultural/delivery/forestry.
И ничего хорошего я в этом не нахожу.
И что вы предлагаете, passability:* или *:passability с тем же деревом, что и у access? По мне, так слишком громоздко. Access помимо ограничения доступа употребляется и в смысле доступности как таковой, так что раздлить no на prohibited/impassable и добавить difficult вполне себе впишется в схему. Зато не будет boat=no, по которой непонятно, нельзя или не пройти.
Да, я предлагаю отдельный тег.
access - показывает, так сказать, правовую сторону дела.
И как в однотежной схеме показать, например, что формально проезд разрешен авто шириной до 2-х метров, а физически там протиснется и 2.5?
С моим вариантом все просто:
maxwidth = 2
passability:maxwidth = 2.5
Там уже есть maxheight:physical, логично что это и для maxwidth применимо. access с подтипами это и так большое дерево, с таким же параллельным деревом разбираться будет намного сложнее.
Здорово. Всё вразнобой. А я как раз предлагаю стройную систему - простой аддишн к тегу access превращает его из правовой информации в физическую.
с таким же … намного сложнее
Што? :3
Никакого разнобоя и, что важнее, лишних сущностей.
Ничего, просто на каждый X=* придется добавлять passability:X, что в итоге не будет влезать в редакторы ни по горизонтали ни по вертикали, одним запросто xapi нельзя будет выгянуть всю информацию с ограничениями для X, а по X=no не будет понятно, глас ли это из прошлого, который надо заменить на impassable/prohibited или это действительно нельзя. Есть тег, есть 3 новых значения, которые в него замечательно укладываются, а вы предлагаете по меньшей мере 13 тэгов длиной от 15 символов.
Единственный существенный аргумент. Но и он имеет место быть лишь “благодаря” изначальному использованию неверной схемы.
Как я уже говорил, не укладываются, ибо противоречат семантике. Нельзя в один тег и “зеленый”, и “толстый” писать. Это разные характеристики, и они могут иметь разные значения.
Потом, ты только что применил “:physical” к существующему access-тегу. По сути, воспользовался моим методом. :3
Про буквы-цифры совсем несерьезно - слова бывают разные, и passability предложил не я.
Где это написано? Зеленый и толстый можно написать в appearance, зеленый и гладкий - в surface, зеленый и блестящий таки в color.
Это не access тэг. access это access + дерево подтипов, речь идет только про него. min/max* это другая группа ограничений и для нее physical уже есть - используйте на здоровье.
Ну если вы обязуетесь отлавливать и исправлять все ошибки, которые оттуда полезут - включая просто опечатки, а также исправления access там где надо исправить/добавить :passability или если угодно, physical, может быть и несерьезно. Менее неудобным и громоздким оно от этого не становится.
На самом деле я был бы меньше против вашего варианта, если бы все boat= стали boat:access или access:boat, но сомневаюсь что это возможно и вообще оно того стоит. Собрать в один тэг boat разрешенность и физическую возможность передвижения я считаю весьма логичной.
А вообще, хотелось бы уже стороние мнения послушать.
Здесь и написано. Например, я могу написать bicycle:physical = hard, bicycle = yes. Что в твоем варианте нужно заносить в тег? Физическая возможность ну никак не лезет в ворота access.
Я веду речь о применении passability/physical и к нему тоже.
Ничего особенного оттуда не полезет, а для исправления принятых тегов уже есть боты. Сложный тег, кстати, наоборот, повышает внимательность к его вводу. Да и не вводят теги руками.
Как это не вводят? Я вот терпеть не могу менюшки. В них слишком долго выцеливать мышой. Мне проще написать тег. Даже на мобильнике проще написать сокращенный тег на экранной клавиатуре и потом его выправить, чем лазить по менюшкам.
Где?
bicycle=hard, если угодно bicycle=permitted;hard
Так нет изменения одним тэгом значения другого (напомню, http://forum.openstreetmap.org/viewtopic.php?pid=34859#p34859)), у вас не посмотри на bicycle:physical - bicycle скажет что там однозначно можно ехать. На деле же там как раз ехать не стоит. А это уже silent ошибки людей, которые physical обязательно пропустят и рендеров/конвертеров, которые не известно когда начнут его поддерживать, и полная неконсистентность данных, потому что ввели вы свой access:physical, и все - уже нельзя сказать про вей с bicycle=yes - можно там спокойно ехать, или лучше не нужно, потому что на деле там приходится велосипед на себе тащить, но bicycle:physical еще не проставили.
Как бот исправит, если no вместо bicycle:physical был добавлен в bicycle или наоборот?
Ага, щаз. Первые три раза - максимум.
Только руками и вводят.
Ладно, убедили. :3