Фэйковые вело-дорожки и bicycle=yes везде и всюду

Вот проверьте и поставьте, а мои труды в трубу не вылетят в любом случае, потому что помимо bicycle=yes я использую mtb:scale и пр.
Запрета на использование тега нет, хотя бы потому что он стоит по умолчанию. Значит установка тега, там где на местности нет запрета, правил не нарушает и в принципе верна.
Использование тега под рендер базовых правил не нарушило. Нашел я в нем для себя легальную плюшку - я молодец, точно также как открыл когда-то для себя ОСМ и начал в нем рисовать в т.ч. для себя - я молодец. А довод о бессмысленности - ну он бессмысленен. Как показала практика, никто тег массово не расставляет, потому что нет обязательного правила ставить его при таких-то условиях, никакого вреда мне он не наносит, а вот пользу несет.

Присоединяюсь к Владимир К и BushmanK :slight_smile:
Чтобы понять неверность своей логики в действиях, нужно довести её до абсурда (а не прилежно-избирательно обходя острые углы, делая вид, что их нет). Что и было проделано на примере «все тропинки посинели».
Из той же оперы расставление 100500 галочек в iD «кому можно/кому нельзя», откуда и получается «шибко детальная информация» на highway=footway, где «смешались кони, люди, грузовики, троллейбусы и велосипеды». Тут впору ставить на ВВП ufo=no (или yes?). Строго обязательным считаю добавление (freeExec уже предлагал, но его не поддержали, отчего-то) на railway=rail foot=no и далее по списку (ей-богу, запрещено же, и знаки имеются, и правила есть о «прогулках вдоль или по ж/д полотну»).
Более разумным считаю метод исключения (на что и указывает osm-wiki).
Массовая расстановка bicycle=yes (а она неизбежна по абсурдной логике, и не надо тут приводить «аргумент», дескать, «поди проверь знаки на тропах/дорожках», лабуда это, и знаков (запрещающих) в 99 % не будет, неужели не ясно?) делает абсолютно бессмысленным такое «выделение проверенных троп», поскольку они перестают выделяться (а сам процесс такого выделения — явное тегирование под «картинку»). Кроме того, получается, что те тропинки, где нет bicycle=* как бы «повисают в неизвестности» и требуется их обязательная проверка «на знаки».
В то же время понятно, что такая «проверка» не требуется в подавляющем большинстве случаев, а при обнаружении исключения — логично добавить информацию о нём (будь то запрет или разрешение, в зависимости от того, что является исключительным). Именно эта информация и приносит реальную пользу, давая возможность учесть местные нюансы.
P. S. А в случае с «синими пунктирами», вообще говоря, получается «рендеринг под кривое тегирование» (выделение только тех дорожек, где имеется явное разрешение, вместо того, чтобы показывать явно запрещённые пути, а все остальные считать равными), потому что он и провоцирует новичков заниматься откровенным притягиванием за уши каких-то интерпретаций и «выискиванием запятых» и «скрытых смыслов» в текстах wiki, после того, как было открытым текстом заявлено: «мне и всем-всем просто нужна такая красивая картинка, потому что это очень удобно» (не думая о том, что сказано выше).

Ну подтверждаете, что массовый снос тега основан не на правилах, а на “здравом” смысле?

А вы ратуете за отмену/исправление глупых правил (буде таковые найдутся)? Или за продолжение/распространение следованию им? Или за использование неоднозначности каких-то формулировок (при их наличии) в угоду глупости (в целом) и собственной недальновидности?
Какова ваша цель?

Ларчик просто открывался: я не видел этого обсуждения. Поддерживаю предложение вводить foot=no где есть запрет пешеходам, а уж тем более если на местности есть и разметка и знаки.

Кроме того, вполне логично что маршрутизации по ЖД путям пешеходам не должно быть, а ходить можно хоть угодно где вокруг этих путей, благо страна гигантская.

Галочки в iD приплетать не нужно. Речь ведётся о законах и ПДД (знаки это только малая часть ПДД).

Мои цели прозрачны как слеза младенца - они были озвучены 3 или 4 страницы назад, их уже 10 раз обсудили, попорицали, потыкали меня носом и т.д.
Но как-то так вышло, что не я оказался нарушителем правил, а те, кто сносят тег на основе “общепринятой” интерпретации и “здравого” смысла. Мне тут предлагают писать разработчикам, чтобы они рендер изменили как мне нравится. Может лучше вам, как ярым борцам с тегами устранить разночтения, чтобы молодые да зеленые типа меня, которые 7 год рисуют, не имели никакой законной возможности возразить мастодонтам?
Данная тема была создана 31 августа 2011 года. За 5 лет никто не почесался устранить разночтения в правилах, а мне указывают, как я неправильно поступаю)) Добавить правило “тег bicycle=yes запрещается употреблять во всех случаях, кроме” = миссия невыполнима)

Тегирование под ПДД и законы страны.

проверяет “на знаки” какая часть сообщества? Которая отделилась и пописывает Bycicle или основная часть которая вводит все access теги не выпячивая один или два тега с требованием “только со знаком”?

Т.е. автомобилисты следуют и разметке и знакам и правилам ПДД у них теги access, а у велосипедистов только на “знаке” все свелось. Нет.

Даже пешеходам foot=yes указывается по ПДД (либо где есть право прохода).

Для плохо видящих, напишу явно д-о л-а-м-п-о-ч-к-и к-а-к о-н-о о-т-о-б-р-а-ж-а-е-т-с-я.

У того же Владимир К постоянно вопросы по ПДД в ключе “Но ведь по проезжей части действительно запрещено ходить” - у него права или понимание ПДД есть? Чего он куралесит базу если ПДД не понимает толком?

http://forum.openstreetmap.org/viewtopic.php?pid=553700#p553700

В общем, новых аргументов нет, но не могу не сказать, что с позицией LLlypuk82, Владимир К и BushmanK, а также всех остальных уважаемых мапперов (кроме d1g) солидарен.

Ну вы возьметесь внести правки в правила для устранения разночтений?

Вики не для устранения разночтений а для описания позиций всех сторон.

Либо преобладающей позиции и “других”.

В т.ч. должно быть описана моя позиция о не бинарности тегов access (и bicycle как частного случая access тегов)

http://forum.openstreetmap.org/viewtopic.php?pid=613293#p613293
http://forum.openstreetmap.org/viewtopic.php?pid=613273#p613273
http://forum.openstreetmap.org/viewtopic.php?pid=613298#p613298

И должно быть написано что как минимум d1g следует ей.

Солидарно не можете опровергнуть мой тезис? Да, собралась толпа повторяющих одно и то же в надежде что кто-то примет это за аргументированный подход :slight_smile:

у-хаха :slight_smile:

К сожалению, ваше сообщение бессодержательное.

http://wiki.openstreetmap.org/wiki/Etiquette

Моя позиция описана 3 сообщениях ранее

http://forum.openstreetmap.org/viewtopic.php?pid=613293#p613293
http://forum.openstreetmap.org/viewtopic.php?pid=613273#p613273
http://forum.openstreetmap.org/viewtopic.php?pid=613298#p613298

Ни на одно literan ответить не в состоянии. Информатика и право тяжело идут вместе :frowning:

Я не предлагал тегировать building=no дорогам. Аргумент исчерпан?

Такой же как и у surfase=asphalt. Указывать свойства объектов реального мира.

Не использовать эти таблицы-угадайки вообще. http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions

Ни при маппинге, ни при написании программ.

Хотите угадывать - угадывайте, меня не заставляйте и уж тем более явные теги то что удалять.

Вики хоть раз в жизни открывали борцы с умолчаниями?

"Access permission for pedestrians "

Аж с 2008 никаких намёков на “умолчания”. http://wiki.openstreetmap.org/w/index.php?title=Key:foot&action=history

Даже если сюда прибежит 100000 мапперов и скажет что они следовали договорённостям - я просто следовал документации. В документации ни слова про умолчания, а все вдруг делают по-другому - ну так что ж теперь мне делать? Я следую документации.

Если не будет таблиц-угадаек то, нужно использовать тег “движение=правостороннее” для России на всех дорогах. Так как это важнейшее правило дорожного движения. Такого знака нет в реальности на каждой дороге, но его наличие следует из правил дорожного движения. В Японии нужно обязательно использовать тег “движение=левостороннее”. Без такого тега любой иностранец (или иностранная программа) не будет знать, по какой стороне дороги следует двигаться, и возможно, попадёт в аварию. Виноват в аварии будет OpenStreetMap так как не предоставил правильной информации, а предложил пользоваться таблицей с указанием типа движения по странам.

ВладимирК, прошу вернуть на место снесенные теги во всех моих правках, по которым вы прошлись ввиду:

  1. отсутствия реальных оснований подтвержденных правилами OSM
  2. отсутствия у вас объективной информации по каждому конкретному случаю с привязкой на местности, что, однако, не помешало устроить массовый снос. Более того, даже вопреки доведенной до вас информации о том, что часть троп из отредактированных сначала мной, а потом вами, правок создавалась велосипедистами для велосипедистов, как специализированные велотрассы

Лично я не вижу криминального чтобы затегировать право-лево стороннесть хотя бы у отношений стран.

Эта информация не важнее чем указать у страны name=Россия. Это абсолютно тривиально, но это верно и соответствует объектам.

“важнейшее правило дорожного движения” - в принципе, да, но оно распространено на всю страну.

https://josm.openstreetmap.de/wiki/left-right-hand-traffic - если я ошибаюсь там нет исключений, в отличие от права доступа.

Охранник или КПП делает из умолчания vehicle=yes уже vehicle=private.

Сейчас многие КПП тегируют как name=КПП, не вижу явного вреда что будут указывать и vehicle=private и vehicle=yes участки у дорог.

access же моделируются:

  1. знаками
  2. разметкой
  3. временной разметкой
  4. полосами движения
  5. текстом ПДД
  6. чем-нибудь ещё не вписывающийся в ПДД (охранник, режим доступа в парках Канады и США - да и в России тоже иногда)

из всех 1,2,3,4,6 можно было бы просто вводить foot=yes где это имеет место.

Сторонники “умолчаний” делают серьёзное допущение когда все правила моделируются “одинаково к объектам”.

Знак “есть или нет”, текст ПДД же имеет более сложную формулировку чем наши conditional и access теги, не так редко мы что-нибудь да упускаем из ПДД.

Сравните таблицу “умолчаний” с вопросами к инспекторам ГИБДД на форумах (“а можно ли так здесь?”, “а можно ли так туда?”).

Какой практический вред принесет использование использование тега “движение=правостороннее” в России?
На мой взгляд оно может даже привести к абсолютно положительному результату и исправить ошибку, которую могли допустить разработчики маршрутизации. Навигатор выпустили в японии, карты там же сконвертировали, случайно в бета-версии забыли указать, что в РФ другой тип движения, карта ушла в народ через торренты. И навигатор будет отправлять водителей по левой полосе, несмотря ни на какие ПДД. А вот казалось бы тег движение=правостороннее самым что ни на есть железным образом заставит водителя ехать по правой полосе, ну или заставит задуматься, что что-то тут не так. Везде было по левой полосе, а тут вдруг по правой.

Лично я не вижу криминального чтобы затегировать право-лево стороннесть хотя бы у отношений стран.
Ну тогда положить туда и default:highway:path:access:foot=yes
если я ошибаюсь там нет исключений
Ну а как же oneway.

Какой практический вред принесет использование использование тега “движение=правостороннее” в России?
Тогда нужно или исключать из роутинга все дороги где нет этого тега, или же обратно возвращаемся к дефолтному значению.

Но не на весь мир. Если мы вообще отказываемся от значений по умолчанию, то логично, что тип движения нужно проставить для каждой дороги в каждой стране. Информации будет много, но пользы от неё мало. Так же и с ограничениями. Если проставлять ограничения для всех видов транспорта везде, то информация вроде бы есть, но она очевидна. Вот когда она не очевидна (например, на территории заповедника) или явна указана на местности (например, есть знак «Велосипедная дорожка» или, наоборот, «Движение на велосипеде запрещено»), то она полезна.

  1. Данные занимают место. Из-за добавления многочисленных тегов увеличится размер дампа с данными. Из-за этого увеличится время обновления данных для пользователей OpenStreetMap (людей, конвертирующих данные для навигаторов, валидаторов, веб-сервисов) и износ накопителей (жёстких дисков, SSD).

  2. Чем больше данных, тем больше вероятность ошибки. Повторяющиеся данные желательно выносить куда-нибудь «за скобки» (например, теги “addr:country”, “addr:region”, “addr:city” указывают на границе населённого пункта вместо того, чтобы указывать их на каждом доме).

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

Мы можем улучшить программы в этом плане, но я не вижу криминала просто затегировать объекты.

Скажем, Яндекс делает виды транспорта у каждого куска дороги видимым - я лично вижу это удобным.

Новые разработчики тратят время на начальное написание таких таблиц и поиска всех “умолчаний”. Я приводил пример с вики, у нас документация очень далека от идеальной ровно в этом вопросе “умолчаний”.

Благо у нас теги access иерархичные (http://wiki.openstreetmap.org/wiki/Key:access#Transport_mode_restrictions) и можно просто указывать более общие варианты, когда это возможно.

Прямо сейчас в “очевидных” умолчаниях есть ошибки, я приводил пример с парками и КПП.

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

Зато код программ намного упростится. У разработчиков не будет необходимости вникать в “умолчания” каждой страны (в те таблицы), а просто подбирать теги со страницы Key:access и доверяться местным мапперам если они указали данные.

Т.е. от умолчаний не отказываемся, просто тегируем их как мы указываем “lit=yes” или “lit=no”

У нас есть 100М объектов highway http://taginfo.openstreetmap.org/keys/highway - сколько займёт места добавление 5-6 свойств для всех объектов?

Я вижу увеличение на 6* 1-8 байт * 100000000 (6* 100-800 мб) как допустимое, у меня на телефоне в десятки раз больше места.

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

Поэтому сравнение surface с access и oneway и lit более взаимо-заменяемые между собой.