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

Я за сокращенный.

  1. Нужно беречь базу. Избыточная информация чревата появлению проблем. Простота и полнота - разные вещи.
  2. Если какой-то населенный пункт станет частью другого (крупным городам свойственно поглощать города-спутники), то из-за этого придется делать огромный объем **бессмысленной **работы! Тогда как сокращенная схема позволяет легко поправить границы и здания легко унаследуют нужные теги.
  3. Современные системы позволяют легко наследовать данные объектов покрывающих их область. Вместо того чтоб тотально забивать гвоздями информацию, следует потратить это же время на освоение современных систем и баз данных.

Чушь какая-то. Мне пришлось лишь С++ установить.

Кстати, еще адреса на каждом ПОИ надо прописать, а то, как мне попалось в украинском чате, у отдельных пользователей проблемы написать оверпас для РФ

У нас уже муниципальные районы в городские округа, а потом далее в муниципальные округа, переделывают по всем регионом. что еще ведет к сносу addr:subdistrict
Ну и самим регионам любят где приписать слово республика, а где убрать.

Но в ограниченном масштабе использование addr:* тегов полезна.
Когда какие-то границы не скачаны в выгрузку или объекты залезают в выгрузку соседних регионов и т.п.

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

Сокращенная форма была придумана для ленивых мапперов, чтобы им не приходилось вносить все addr:*, а карта в навигаторе у них бы была с поиском, благодаря известному конвертору.
Теперь у нас теперь просто есть не ленивые, которые хотя вносить все теги, и у них свои способы конвертации в свои системы.

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

Валидаторы есть, но ошибки такого рода мало кого заботят, так как раз конвертор работает, то и ладно.

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

Проблемы в OSM возникают однозначно, когда пытаются разные варианты обязательно подогнать под что-то одно, а остальное пристрелить.

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

помню еще в навителе постоянно выскакивали вторые города :slight_smile:

адресный формат гармина был сломан еще до эпохи возникновения ОСМ,
и уши city/region/country растут именно оттуда, а не из Карлсруэ.

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

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

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

Это слабое место всех ситуаций в OSM, когда приняты две равнозначных схемы тегирования - война правок по субъективным предпочтениям “а мне больше нравится вот так” становится лишь вопросом времени. Потому что невозможно сказать, кто из двоих прав - оба правы в равной степени. Вот с Совой именно так и вышло.

Чтобы такой ситуации не было, необходимо сообща признать одну из схем более желательной. Тогда внесение новых данных (тут в любом виде) в OSM - хорошо, переделка существующих из нежелательного вида в желательный - ещё лучше. А вот целенаправленное движение в обратную сторону - из более желательной схемы в менее желательную - однозначно плохо. И тот, кто это делает, даже после комментариев и ссылок на итог обсуждения - уже не сторонник одного из альтернативных подходов, а сознательный вандал, не желающий принять факт того, что здесь совместный проект, в котором нельзя взять и единолично установить свои порядки без обсуждения и согласия большинства.

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

Лучше бы болота и ручьи маппили

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

Так что было бы желание…

За пределами областей НП конечно.

Я за удаление тегов выше addr:city. addr:city удалять, если есть полигон НП. Страну и регион удалить автоматом, остальное руками. С ПОИ также удалять номер дома и улицу, если они совпадают с тегами на здании, в котором эти ПОИ находятся.
На нытьё вида “я вносил, тратил время, а вы всё одним движением удаляете” не обращать внимание.
Я лично вручную добавил на каждую точку place в своём регионе теги addr:country, addr:district, addr:region, addr:subdistrict и official_status. На все 1695 точек, руками, без скриптов. Потратил много времени, жалко, но сову включать не буду, удалять, так удалять.

Поддерживаю и полностью разделяю это мнение.

Современные БД это замечательно, но бывают и бессерверные решения. Например, у StreetComplete нет своей копии БД, они используют в качестве бэкенда Overpass API. Довольно глупо ради голой дедупликации отсекать себя от возможности использовать эти инструменты. Со временем таких инструментов будет становться все больше и больше. Например, с полным карлсруэ валидатор по списку объектов можно сделать вообще не программируя, пользуясь гугл таблицами. Поэтому было бы неплохо если бы кто-то из считающих что отсутствие дублирования в базе вызвался доработать overpass чтобы дефолтные значения полей addr:* брались из полигона при загрузке данных, а не при исполнении запроса. Это ведь несложно, как вы говорите.

“Беречь базу” и “экономия места” это очень опасные аргументы. Сейчас ради экономии мы удалим избыточный addr:*, завтра кому-то не понравится что дорога отмечена с точностью 1000 точек на километр и он упростит ее до 100 точек на километр, послезавтра еще кто-то упростит до 25 ведь “современные средства позволяют интерполировать сплайнами”. Другому покажутся избыточными площадные дороги отрисованные по openaerialmap. Третьему отдельные деревья. Это скользкая дорожка ступив на которую однажды очень трудно остановится.

То, что дедупликация помогает от ошибок это заблуждение. Когда кто-то двигает границу населенного пункта и какие-то дома вылетают из адресации или улетают в другой регион мы об это узнаем лишь случайно, когда кто-то обнаруживает что что-то не работает. А если бы у нас был полный карлсруэ, у нас была бы возможность сразу получить “красный флаг” – адреса на зданиях не соответствуют полигону границ, разбирайтесь что не так. Причем такую проверку можно сделать на maproulette даже не программируя.

То же самое с адресами на POI. OSM это живая карта, там постоянно кто-то что-то двигает. Если POI нет собственного адреса и ее сдвинули за пределы здания, она теряет адресацию и мы этого никогда не узнаем. Если бы адресация была, можно было бы сделать проверку “POI с адресом за пределами здания” хоть в JOSM, хоть на maproulette. К тому же адрес POI не всегда можно вычислить из адреса здания однозначно. Скажем, школы маппятся полигоном amenity=school и на территории этого полигона бывает несколько зданий с разными адресами, в то время как адрес у школы только один.

Раз уж здесь перешли от аргументов к мнениям, предлагаю сформулировать вопросы:

  1. Должны ли мапперы проставлять теги addr:country, addr:city и addr:region?
    а) всегда, когда есть такая возможность
    б) только если значение тега отличается от того, что можно вычислить из границ
    в) допустимо эти теги не использовать
    г) не должны никогда

  2. Как мапперы должны поступать с существующими тегами addr:country, addr:city и addr:region?
    а) удалять всегда
    б) удалять только если значение отличается от того, что можно вычислить из границ
    в) удалять только если значение ошибочное
    г) исправлять если значение ошибочное и не трогать если значение правильное

  3. Как мы должны относиться к массовым правкам тегов addr:country, addr:city и addr:region на основании вычисленных из границ значений?
    а) автоматизированные правки в этом вопросе недопустимы
    б) автоматизированные правки допустимы только если они добавляют теги, правки удаляющие или изменяющие эти теги недопустимы
    в) автоматизированные правки допустимы только если они удаляют теги, дублирующие информацию которую можно вычислить из границ
    г) автоматизированные правки допустимы во всех случаях

Исходя из ответов на эти вопросы у нас три стратегии:

  1. Автоматически удалить все теги addr:country, addr:city, addr:region если они дублируют информацию которую можно вычислить из границ и в дальнейшем систематически удалять эти теги и проводить разъяснительную работу с мапперами, которые их используют. Т.о. теги addr:country, addr:city, addr:region останутся только в качестве костыля для ситуаций когда адресация почему-то не соответствует границами.
  2. Автоматически заполнить недостающие теги addr:city, addr:region и в дальнейшем поощрять автоматическую и полуавтоматическую синхронизацию этих тегов с полигонами границ.
  3. Не трогать существующие теги специально но и не давать автоматически их исправлять. Т.е. на долгое время законсервировать существующее положение вещей когда полную схему карлсруэ использовать на практике бесполезно, а исправлять ее руками бессмысленно.

Было бы неплохо, если бы люди, склоняющиеся к первой или второй стратегии задались вопросом “готов ли лично я вести эту работу?”

У StreetComplete нет таких проблем. Он корректно определяет ближайшие улицы при указании адреса.

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

Мои ответы на вопросы:

  1. Должны ли мапперы проставлять теги addr:country, addr:city и addr:region?
  1. Как мапперы должны поступать с существующими тегами addr:country, addr:city и addr:region?
  1. Как мы должны относиться к массовым правкам тегов addr:country, addr:city и addr:region на основании вычисленных из границ значений?

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

Это проблема разработчика. Мы не мапим под навигаторы и прочие клиентские приложения.

Кстати, избыточная адреска может создать проблему при навигации, если у НС пункта что-то изменилось, а в строениях этих изменений нет. Пользователи могут просто не найти нужный им адрес, так как у строения будет указан другой город, и скорее всего он будет иметь приоритет. Либо придется колхозить проверку проверки тегов полигона НП… к чему мы опять в итоге возвращаемся… И такая проблема более вероятна.

И сейчас можно делать “адрес за пределами НП”, “ПОИ за пределами адреса”.
Давно пора уяснить, что сырой ОСМ не пригоден для использования сразу, его надо доделывать, чтоб было удобно под свои нужды. И это не только адресов касается. Вон кто-то клеит полигоны леса, чтобы выглядело красиво. Кто-то разворачивает значок ЖД вокзала вдоль рельс, чтобы было похоже как не генштабе. Кто поворачивал номера домов вдоль той улицы, к которой они относятся. Я уж не говорю, что визуализируют какие-то характеристики из тегов, а не выдирают что-то из name. И ещё много чего делают.
Если бы все придерживались точки зрения, что без дополнительного кода нельзя работать, мы бы до сих пор сидели на лексиконе с .txt и ни каких .pdf и прочих .doc у нас ни когда не появилось. А то как это, нужен какой-то word чтобы прочитать текст, как жить не программисту.

Я бы предложил голосовать именно за стратегию, потому на по отдельности разные вопросы можно дать неконсистентные ответы (как уже было с “военным” голосованием).

Конкретно я придерживаюсь следующего подхода:

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

Но и обратная дорожка - “лишней информации не бывает” - тоже скользкая. Можно начать расставлять теги is_in:*, access=yes, location и многие другие на всём, что есть. Нужно взвешенное “среднее” решение, без свала в какую-либо крайность. С адресами оно по факту уже сложилось, осталось лишь это осознать и принять.

Речь об заведомо избыточной информации.

Вы с Совой настаиваете на том чтоб проставить всем домам теги стран и городов, тогда как эту же информацию можно взять из полигона НП.

Если прям так хочется, ставьте вручную и следите за этим. В автоматическом режиме по всей стране этого делать не надо! Где гарантия что вы сможете вовремя среагировать и внести изменения НП в здания покрывающие его? Как быть со зданиями которые перестали относится к НП?

Вы будете за всем этим следить? Как долго?