Обсуждение формата внесения адресных данных в России

В последний год произошёл ряд конфликтов активных членов российского сообщества с участником Sowa1980. Один из поводов - формат внесения адресов.

Текущая версия страницы RU:Key:addr закрепляет упрощённую схему, как фактически сложившийся консенсус:

  • на здание помещаются только теги addr:housenumber и addr:street (на здании только улица и номер дома, всё теги более верхнего уровня на полигоне населённого пункта и связываются со зданием по факту его нахождения внутри этого полигона)
  • все адресные теги более высоких уровней (addr:city, addr:region, addr:country) помещаются на полигон населённого пункта
  • связь тегов на здании и на населённом пункте происходит по факту нахождения здания внутри границ НП.

Более того, в своё время проводились целенаправленные удаления лишней информации со зданий (например), которые не вызвали никаких возражений и откатов.

Sowa1980 оспаривает эту схему, ссылаясь на то, что вики-страница не есть результат голосования сообщества. Он вносит на каждое здание все теги, вплоть до addr:country, а в ответ на попытки привести эти данные к виду, описанному на вики, откатывает их обратно.

В связи с этим (и, если смотреть шире, безотносительно упомянутого конфликта) предлагается обсудить следующее предложение, которое позволит процедурально закрепить негласный консенсус:

“Утвердить “сокращённую” схему адресации и правила применения адресных тегов, в настоящее время описанные на RU:Key:addr, как настоятельно рекомендуемую к применению на территории РФ”.

Плюсы:

  • База не перегружается огромным количеством дублирующей информации, которая и без этих тегов выводится путём простых геометрических расчётов. Не расходуется место на серверах OSM, потребителям данным OSM нет нужды скачивать лишние гигабайты данных.
  • Наличие каждого адресного тега в одном отведённом ему месте позволяет легче редактировать данные и избегать неконсистентности. Не будет ситуации, что в границах города есть здание, на котором тег addr:city не соответствует этому городу (кому верить?). При переименовании населённого пункта и/или изменении структуры АТД (что в последние годы происходит не вот редко) не нужно массово перетряхивать адреску на всех зданиях внутри.
  • Данная схема уже давно и де-факто применяется во всех городах России, за исключением тех, которые в последнее время подверглись правкам Sowa1980 (Тамбовская область + частично Иркутская). Пересмотр её в пользу другой означает необходимость переделки большого объёма данных по всем остальным регионам.

Минусы:

  • При повреждении полигона НП адресная информация для всех зданий внутри становится невалидной (невозможно вычислить вхождение в границы) вплоть до починки границ. Аргумент выглядит сомнительным: ошибки в границах следует исправлять, а не маскировать посредством избыточных данных. Это скорее, плюс: сокращённая система адресации дополнительно стимулирует внимательно и аккуратно редактировать границы, содержащие адресные теги, следить за их валидностью, активно пользоваться валидаторами границ и т. д. В противном случае, по логике, можно зайти ещё дальше и начать на каждом магазине дублировать все адресные теги здания, в котором он расположен - чтобы магазин не остался без адреса в случае поломки полигона здания.

Пишите, кто какие ещё видит плюсы/минусы каждого подхода и/или насколько существенным считает описанные. Это пока ещё не голосование, а обсуждение. Согласно Proposal Process, оно будет длиться не менее 2 недель (а если потребуется, то и больше), и только после этого будет проводиться голосование на специально оформленной вики-странице.

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

Эта проблема возникла задолго до участника Sowa1980,
адепты так называемого “польского формата” не хотели заморачиваться
с выборками по границам НП (большинства границ тогда и не было)
и стали массово добавлять (и импортировать) всю иерархию, так как она им нужна для
функции адресного поиска. Их противники стали так же массово лишние тэги удалять,
так что ничего нового обсуждать особо нечего, тем более даже
ссылка на отсутствие границ уже не актуальна.

Исходное сообщение предвзято и его неплохо бы отредактировать в нейтральном ключе. Теги addr:city, addr:region, addr:counrty используются по всей стране, а не только в двух городах. Более того они используются по всему миру.

Полная схема карлсруэ (т.е. указание addr:country + addr:region + addr:city) существенно упрощает работу с адресами избавляя от тяжелых и дорогих геометрических запросов. Это позволяет работать с адресной информацией через Overpass API любому желающему. Сокращенная же карэсруэ доступна только программистам серьезно вложившимся в установку PostgreSQL+PostGIS, настройку тулчейна для импорта OSM и детально разобравшихся в тонкостях административно-территориального теггирования. Фактически это заградительный барьер на пути использования данных OSM ad hoc. На мой взгляд, такая ситуация больше вредит проекту чем помогает. В том числе она вредит тем мапперам, которые сами используют OverpassAPI. Не забывайте, что на основе Overpass API есть и другие инструменты, например, maproulette, а также плагины к QGIS и ArcGIS которыми люди также пользуются. В конце концов, мы маппим данные чтобы ими пользоваться, а не просто чтобы было.

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

Кроме того, удалять хорошие данные только потому что они кажутся вам ненужными или избыточными идет вразрез с ценностями проекта. Это потенциальная война правок и конфликты. Если вам не нравится полная адресная схема, ок, не маппьте ее. Но не мешайте маппить ее другим, если она им по какой-то причине нужна.

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

Не полная схема так же позволяет работать с адресами через Overpass. Так что превираешь и нагнетаешь.
ОСМ это всё же база данных и требует определённых умений для работы с ней. А то ведь скоро придётся на каждой линии подписывать расстояния, а то вдруг кто-то не сможет его вычислить по координатам. Да собственно и координаты у линии тоже не плохо бы дублировать, а то они на точках хранятся.

Если кто-то хотел работать с адресами, то уже поддерживает сокращённую схему, это просто неизбежно на текущий момент. А если он поддерживает сокращённую, то полная совсем без надобности.

Я изложил в нём те аргументы, какие были у меня на тот момент. Чтобы собрать другие, и была создана эта тема :slight_smile: На странице голосования будут изложены в сжатом виде все аргументы, что тут прозвучат.

В теории может и позволяет, а на практике любом масштбный запрос с геометрией будет считаться до морковкина заговения. И я что-то не наблюдаю чтобы ратующие за сокращенную карлсруэ выстраивались в очередь с патчами в Overpass или какой-нибудь другой софт.

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

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

Я за упрощённую схему.

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

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

Кстати, пример запроса на Overpass, позволяющий вытаскивать адреса верхнего уровня для зданий с полигона НП, был бы очень полезен. Это будет более дружелюбно к начинающим, чем просто сказать “берите с полигона НП, а как именно - разбирайтесь сами”.

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

Бессмысленное обсуждение, потом будет такое же бессмысленное голосование. Всё останется как прежде.
Будет принята сокращённая схема – кто вносил адреса полностью, так и продолжит это делать, потому что удалять лишнее никто не позволит, так данные валидные.
С полной схемой также всё останется по прежнему, никто не заставит заполнять все поля целиком. Вам надо вы и заполняйте.
А значит программам так и придётся поддерживать сокращённые схемы и брать данные из других мест.
Утверждение “берите с полигона place” тоже не понятно к чему. Те, кому нужен полный адрес, ничего с полигона НП не берут и брать не будут, по простой причине – на многих полигонах НП ничего, кроме name нет. До сих пор никто не озадачился внесением этих данных, не говоря уж о каком-нибудь валидаторе, по простой причине – те, кому надо берут все данные с вышестоящих полигонов. addr:city – из name полигона place, addr:region – из name полигона boundary=administrative + admin_level=4 и т.п.

https://overpass-turbo.eu/s/13Ez

Самое драгоценное - продуктивное время маппера ) Потратим его на внесение данных, которые нельзя получить скриптом из геометрии. Например, на полигоны границ НП.

Запрос для Overpass, дополняющий addr:city, addr:region и addr:country для линий с записанным по сокращённой схеме адресом: ------------------------

Upd. См. запрос в предыдущем сообщении - он лучше.

все дело в том что для сокращенной схемы нужны лишние телодвижения…

А building=no на всех объектах, кроме зданий, это ещё валидный тег или это другое?

Таким образом вы придерживаетесь мнения, что если некто начнет импорт “валидных данных”
addr:city, addr:region, addr:country и addr:galaxy для всех адресуемых объектов,
то это в порядке вещей ?
И как будет учитываться административная иерархия отличная от city,addr,country ,
ее тоже можно добавлять ко всем объектам?

необсужденный и неодобренный (а он не будет одобрен) сообществом импорт будет очень быстро откачен :sunglasses:

Обсуждение именно об этом. Чтобы признать дополнительные теги на зданиях невалидными и поступать с ними так же, как с транслитом в name:en, например. При рисовании новых объектов можешь вносить (и даже никто не заругает), потом другие могут удалить в рамках приведения к рекомендуемому виду. Но обратно вернуть удалённое, потому что “мне пофиг на договорённости, мне так нужно” - харам.

Я в шапке, кстати, привёл ссылку на один из чейнжсетов с удалением таких “валидных” данных.

Ну то есть всё равно есть откуда их взять (и берут), а не ожидают же, чтобы непременно всё на конкретном доме было.

Есть такой валидный в прошлом популярный тег is_in:country. Ничего, постепенно выпиливается
https://taghistory.raifer.tech/#***/is_in:country/

Имеются ли причины, по которой верное указание местоположения приводит к ошибкам, ломает что либо?

Имеются ли причины, по которым одна схема несовместима с другой?

Если ответ на оба вопроса негативный - тред не имеет смысла. Подписывать город на каждом здании - бесполезная работа, но с трудом понимаю как это может мешать.