На местности наблюдался шлагбаум, проезд через который был явно ограничен. Никаких оснований полагать, что для проезда всех велосипедистов без исключения этот шлагбаум будут поднимать, не было. Находящийся рядом со шлагбаумом проезд шириной 1 метр, через который можно проехать на велосипеде, отмечен отдельным ребром, на котором тегов доступа, ограничивающих проезд велосипедов, нет.

Вероятно, Вы не прочитали мой предыдущий комментарий целиком. При сравнении базы данных с местностью я обнаружил barrier=block (osm.wiki/RU:Tag:barrier%3Dblock) в месте, где блока нет. Это могло быть вызвано либо ошибкой при внесении сведений в базу данных, либо изменением ситуации на местности. Я удалил из базы данных блок – это первое действие. Также в месте, где в базе нет barrier=lift_gate (osm.wiki/RU:Tag:barrier%3Dlift_gate), был обнаружен шлагбаум, который по умолчанию был опущен (закрыт), но приподнимался (открывался) для некоторых транспортных средств. Я добавил в базу шлагбаум с ограничением проезда для транспортных средств – это второе действие. Ни одного пешехода и ни одного велосипедиста, для которых шлагбаум был бы поднят, я не наблюдал – поэтому о специальном режиме прохода пешеходов и проезда велосипедистов через шлагбаум оснований что-то писать у меня не было.

Здравствуйте! Что там было всю жизнь, я не знаю. На момент исследования местности ранее отмеченный блок отсутствовал (поэтому блок я удалил), но имелся действующий шлагбаум с ограниченным доступом для транспортных средств (поэтому шлагбаум я добавил).

Если искать объекты просто по расстоянию по прямой, может оказаться, что ближайший объект находится с другой стороны забора/автомагистрали/реки/границы – чего-то, что мешает попасть к объекту. Если задачей того, кто ищет, является не построение маршрута к объекту поиска, а просто его визуальный осмотр со стороны, то теги доступа на самом объекте, получается, можно и не учитывать.

access на детскую площадку я добавил, но ещё я бы рекомендовал рассмотреть возможность исключения при поиске ближайших объектов тех, к которых можно подойти только по дорогам с ограниченным доступом. В данном случае на всех подходящих к детской площадке путях стоял запрет использования, но программа Вас всë равно повела. На детских площадках, расположенных на территориях детских садов и закрытых дворов часто не стоит access.

Если у 20% дорожек ничего не менялось, они обозначены и обозначены правильно, зачем Вы удалили и их тоже?

Я добавлял на закрытые дорожки парка access=no (пример: way/413136445/history ), потом Вы всë удалили.

Сейчас тег access=no добавлен вновь. Полагаю, этого должно быть достаточно, чтобы Вас не вело транзитом через закрытый парк.

Уточнение геометрии по трекам – хорошее дело. Но удалять что-то, потому что оно было нарисовано на основе менее точной привязки, не стоит.

Вы не имеете права удалять то, что на местности есть. После Ваших правок в пределах парка не остаëтся вообще ничего, что очевидно не соответствуют действительности, т. к. имеется растительность и дорожки.

Я не думаю, что тегирование двухполосного Дунайского проспекта это хорошая идея.

Если у 10% дорожек геометрия верна, то как минимум их удалять не следовало.

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

Актуальное фото в качестве примера: https://i-mg24.ru/images/100325183859-4xjih.jpg

Не знаю, какой Esri Вы смотрите. В той подложке Esri, что по умолчанию подгружается в стандартных слоях для OSM ещë многие новые дорожки не построены, но на что-то уже можно ориентироваться.

Здравствуйте! Пожалуйста, не удаляйте актвльные данные с местности, соответствующие перестроенному на основе старой сети дорог парку. Если Вам достоверно известно, что геометрия какой-то отдельной дорожки некорректна, можно поправить (сдвинуть) именно еë, не удаляя.

Восстанавливаются данные, соответствующие текущему состоянию на местности.

Подскажите, пожалуйста, какие спутниковые снимки Вы рекомендуете использовать? Общедоступные известные устарели.

Данные и так вносятся по результатам натурных наблюдений.

Уточните, пожалуйста, о совпадении чего с чем идëт речь. Трассы некоторых старых дорожек при реконструкции были сохранены, некоторые дорожки были убраны, некоторые новые дорожки были добавлены.

Здравствуйте! Не удаляйте, пожалуйста, данные из базы.

Если много выезжают, значит, трафик уже не 1.5 машины в день. По поводу получающегося транзита при выезде налево, видимо, пока я объяснить не смог. Если машина находится во дворе в service, навигатор будет вести до ближайшей «нормальной» дороги. В рассматриваемом примере это дорога на север, точка примыкания service. После достижения этой линии у навигатора может включиться строгий запрет на транзит через service. Получается, что единственный остающийся вариант – это поворот направо, т. к. для поворота налево нужно, уже находясь на «обычной» дороге, проехать по service.

Если разворачиваться на T-образном перекрëстке при движении «слева направо по верхней черте буквы», разворот выполнить ничуть не легче – что ж теперь на перекрëстках куски дорог как service обозначать?

Зависимость удобства использования от габаритов – физическая характеристика дороги, а Вы сами писали, что ключевым параметром является относительная «важность» дорог. Бывает, что по trunk проехать невозможно, а тут типовой разворот на асфальтовой дороге.

Про пробки не ясно: как из неучëта пробок навигаторами следует, что линию, по которой по факту ездят много, нужно понижать до service?

Выдуманная дорога – это если через крутую гору motorway нарисован, а не когда имеющий место участок, активно использующийся для движения, обозначается как link (даже не как «полноценная» дорога).

В качестве примера первое попавшееся - way/118191117 . Т. к. при движении на запад на расположенном южнее перекрёстке разворот запрещён, а на участок перед перекрёстком выезжает много машин от жилых домов и торгового комплекса, те, кому нужно в итоге развернуться и ехать на восток, поворачивают на перекрёстке направо, едут до ближайшего разрыва, там разворачиваются, возвращаются на перекрёсток, где выполняют левый поворот и едут, куда им надо. По полученной сейчас базе выходит последовательность primary - tertiary - service - tertiary - primary. При настроенном запрете транзита через service такой маршрут навигатором не будет даже предлагаться, хотя он разумен, реализуем и используется.

Есть несколько очевидных случаев, когда такой разворот нужен. Например, автомобиль стоит носом в одну сторону, а ехать нужно в другую. Человек без навигатора будет ехать до ближайшего места, где разрешëн разворот, и менять направление.

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

Если линия посередине дороги обозначена service, она не будет последней service на маршруте – навигатор может принудить подъезжать с другой стороны для съезда во двор правым поворотом, чтобы не ехать транзитом через service посередине. Надо понимать, те навигаторы, что позволяют повернуть налево через транзитный service, не настроены на жëсткий запрет транзита по service.

Но мы обсуждали другое: было сказано, что существуют актуальные теги и актуальная схема тегирования. Рекомендация к изменению схемы где-то опубликована, обсуждена? Или предлагается смириться с изменениями просто по той причине, что правки такого объëма мало кто может отменить для продолжения обсуждения при исходном состоянии базы?

Заметок может оказаться по числу затронутых линий (т. е. очень много). Многие (возможно – все) изменения заключаются в изменении линий, тегирующих разрывы в разделительной линии, с ..._link на service, в результате чего получается, что навигаторы либо должны разворачивать через service (что спорно, т. к. на транзит через service может быть установлен логичный запрет), либо попросту не будут правильно поворачивать и разворачивать.

Почему предлагается считать service посередине дороги актуальным тегом?

Здравствуйте!
На местности – по-разному. Таблички с посëлком ещë не поменяли: https://i.ibb.co/n8D47hyT/IMG-20250112-175924.jpg . Во всяком случае, канцеляритной формы «Тельмана, город» на местности нет.
«Посëлок Тельмана» звучит по-русски обычно, а «город Тельмана» необычно?

В областных законах и реестрах названия приводятся в определëнном виде (кодифицированном, упрощающем обработку реестров), столбец/графа с указанием падежной формы названия в нëм не предусмотрена. Если бы для других топонимов указывалось бы, что падеж родительный, а для обсуждаемого именительный, это что-то бы утверждало. Но такого указания нет.

Статья подтверждает, что название имеет форму родительного падежа, а не именительного падежа или множественного числа.

Если форма именования не изменилась и раньше в name было «посëлок Тельмана», почему при изменении посëлка на город в name предлагается писать не «город Тельмана», а «Тельмана»?

Уточните, пожалуйста, почему схема тегирования, применявшаяся ранее, объявлена устаревшей, где описаны называемые Вами актуальными стандарты редактирования?

P. S. Такое большое количество линий, полагаю, вручную в один пакет просто не собрать: нужно загружать большую область, запускать с помощью программных средств массовые выделение и перетегирование. По полгода данные редко копят, тегируя, по возможности, сразу. А тут получился колоссальный набор изменений, который при сомнениях/возражениях и поправить-то трудно чисто по техническим ограничениям.

Здравствуйте! Данный пакет правок содержит массовые изменения, затрагивающие огромное количество линий. Часть изменений является ошибочной (или как минимум спорной). Пожалуйста, поясните Ваши действия, а при необходимости внесения изменений в отдельных местах выполняйте их вручную по результатам изучения на местности.