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

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

Современные БД это замечательно, но бывают и бессерверные решения. Например, у 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 и многие другие на всём, что есть. Нужно взвешенное “среднее” решение, без свала в какую-либо крайность. С адресами оно по факту уже сложилось, осталось лишь это осознать и принять.

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

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

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

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

Я предлагаю придерживаться следующей стратегии:
Внутри НП у зданий и POI не указывать дублирующую информацию, только если по факту она по какой-то причине действительно отличается.
Текущие объекты не трогать. Только при ручном редактировании.
У зданий за пределами НП необходимо указывать тег НП к которому он относится. Тег страны указывать не надо, кроме Антарктиды.

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

Я против автоматизации тегов адрески. Как со стороны совы, так и удаляющих их. Могут попасть здания у которых на самом деле принадлежность НП отличается.
Так же могут попасть здания на ошибочной или устарелой границе разных НП.

Ловко вы всё в кучу смешали и громким словом обозвали. Стратегия, да. Где же это мы недавно такую стратегию видели, а ну да, ну да, за изменения в Конституцию так же голосовали.

Вот тут нас полдюжины человек обсуждает, возможно даже обсудим и проголосуем. Позовем в чате, придет еще полдюжины.
А по стране только в этом году 800 человек вносило новую адреску (номера домов)
http://wowik.byethost7.com/hn/2021/ru.htm (программка нынче шалит, приписывает мапперу немного лишних регионов)

Они ни про чат, ни про форум, ни про вики и слыхом не слыхивали. У них только редактор перед глазами, а там форма для ввода адреса по полной схеме, да с кривым переводом.

За упрощенную.

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

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

Ну так пока за это никто и не голосует ещё. Можем и без автоматизации обойтись.

И все 800 человек будут также напролом отстаивать свою схему, как Сова? Вносить как угодно пусть вносят. Просто не надо сидеть на своих данных, как кащей, запрещая кому-либо к ним притрагиваться.

Так она и сейчас разрешена.

Вопрос же не так стоит:

Надо ли запретить полную схему?

Потому, что если не надо, то это так, как сейчас. А вопрос толлерантности мапперов к мнению других лежит вне технического вопроса формата внесения данных. Он относится к воспитанию и воспитанности.

почтовый индекс в РФ не является элементом адресной системы :slight_smile: так что он здесь ни сбоку, ни с припеку :slight_smile:

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

Не надо политоты.

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

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

любой :slight_smile: главное чтобы его пользователи/рендеры поддержали.

а вас лично вопрос толерантности и воспитанности не касается, он только для других? Сколько раз и сколько человек вас вежливо просили не делать правки на полмира сразу (потому что это неудобно когда отслеживаешь правки по своему региону), и писать комментарии к ним (хотя бы если это правки только по России) не на польском или французском, а на других, более близких маперам языках?

За отказ от точечной схемы в пользу полигональной.
Объявить точечную схему устаревшей и потихоньку вычистить из базы.
(Предусмотреть процедуру, которая исключает потери данных на этом этапе.)

Это же и значить запретить

Устаревшей (не рекомендуемой, не одобряемой) она типа и сейчас является.
Остался вопрос в том, чтобы объявить

запрет и полное уничтожение

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

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