Обсуждаем способы задать адресацию

Communities Россия (Russia)
521

Если правильно понял всех высказавшихся, практических примеров по ссылкам выше — недостаточно. Странно (хотя, подозреваю, что смотрел их только Surly, ну и edward17, может быть). Документацию создавать даже нелепо как-то, при таком примитиве. Максимум — схемку с пояснениями. Это — можно. Спасибо и на том, что не попросили конвертер+мировой свет геокодер в придачу.
Задача: сформулировать схему тегирования адресной информации, обладающую:
а) Простотой (на уровне понимания и в практике);
б) Однозначностью (никаких интерпретаций «по вкусу»);
в) Гибкостью (масштабируемостью);
Желательно, чтобы схема не вступала в конфликт с уже имеющимися подходами или он был сведён к минимуму.
Предлагаемое решение:
Используя широко распространённые адресные точки (где, как минимум, указываются улица и номер здания) и собственно контуры самих зданий и/или точечные POI, объединить их в простое отношение, где: адресные точки получают роль «address», а все остальные элементы — «object». Само отношение можно назвать как угодно (в примерах — associatedAddress), оно не несёт никаких тегов, а лишь замыкает все элементы в систему «объект/ы+присвоенный адрес/а». Вот и вся «наука». Если убрать водичку (и оставить курсив), писать-то не о чем.
Как результат — получаем желаемое, со всеми перечисленными параметрами. Различные нюансы, типа куда ставить адресные точки: внутрь контура здания или прямо на него — существенной роли не играют (здесь можно и на «вкус» положиться). При этом не нарушается геометрическая составляющая (вложенность/принадлежность) и её можно легко использовать для решения этой же задачи. Сегодняшний рендеринг даже «не почувствует» никаких изменений (для него их попросту не будет). Старые конвертеры и поисковые системы — аналогично.
Для гипотетических новых — появится прозрачная структура данных без лишнего мусора и головоломок «что? куда? зачем?».
Не будет проблемы «как с минимальными телодвижениями и ошибками адресовать 100500 POI-точек в ТЦ?»***** или «как присвоить адресацию по нескольким улицам одновременно для POI-точек?*****(любого их количества, причём!)», «а справятся ли алгоритмы оценки геометрической вложенности?» (потому что они будут только альтернативой, но не обязательным инструментом).
P. S. edward17, описанный тобой метод не годится для решения пунктов, помеченных звёздочкой в конце. Просто попробуй это сделать в редакторе.
mixdm, «понятнее некуда это addrN:*» — возможно, но не знаю, где это работает. А если успешно работает, то почему мы это до сих пор не используем повсеместно? И это явно конфликтует со старыми схемами.

522

Любой конвертер (и обработчик информации, в принципе) получая относительную кашу на входе, создаёт некий свой «индексный файл/таблицу/что там ещё», где всё, что ему «интересно», структурируется, раскладывается по полочкам, а лишнее — вырезается.
Так почему не структурировать (более-менее) эту «кашу» ещё на этапе её создания? При том, что Общую Теорию Относительности при этом выводить и доказывать не требуется (хотя мне порой кажется, что скорее произойдёт это, чем я тут чего-то добьюсь от людей).

523

Для меня сейчас использование адресной точки, без всяких там отношений предпочтительно, потому что таким образом сейчас решается 2 задачи - 1-я это можно указать конкретное место где ожидаемо будут рендеры рисовать этот номер и 2-я это возможность осуществления подъезда к конкретной стороне здания в программах навигации (путем установки этой точки в предпочтительное место). В схеме с addrN:* и 1-е и 2-е сильно хромает. Ситуацию по “как присвоить адресацию по нескольким улицам одновременно для POI-точек” я уже отмечал - адрес все таки один. Кто нибудь может привести пример что у него в прописке/регистрации указано 2 и более адресов одновременно? Или у организации в документах официальных сразу 2 адреса указано?

524

Значит, возвращаемся к тому, что на POI необходимо указывать полный адрес, любо же делать костыль, чтобы привязать её к адресной точке

525

и 1-е и 2-е сильно хромает.

  1. Почему тогда не решаешь глобальную проблему - место где рендерить вообще все надписи, чё это только номер?
  2. Проблему куда ехать надо решать через точку входа, а не номер. Который вообще мягко говоря ни чего не гарантирует, где контора расположена в здании.
    Так что по обоим аргументам не зачёт.
    А addrN поддерживает например https://github.com/kiselev-dv/gazetteer, osmand в todo тоже записан, но видимо в переделками уишек они подзабыли.
526

От relation:street + AddrN это отличается тем где теги адресов хранятся (на адресных точках, а не в AddrN тегах у отношения). Это решение уступает одному relation:street т.к. теги улиц будут дублироваться у каждого отношения associatedAddress.

Как модель - неплохая, но нужно плагин сделать который упростит ввод, проверку адресов для адресуемых объектов + подсветка объектов “без адресов”.

Часть или всё из этого можно решить хитрым поиском в JOSM. Примеры функционала:

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

freeExec

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

528

Вставлю свои 5 копеек.

Адрес на здание против адресных точек.

В добавлении адреса на здание есть минус в том что такой адрес найдётся, но не всегда его увидишь когда у здания есть name. Если брать addrN то не совсем понятно к какой улице относится адрес глядя на карту, если его отрендерить вместе с основным.

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

addr: против отношений

Нормальные формы:

  • самый простой случай когда объект полностью содержет в себе всю информацию, например каждый адрес содержит помимо номера дома также название и геометрию улицы - у нас никогда не возникает вопросов по поводу объектов, но это огромное дублирование.

  • чтобы избежать дублирования вводятся всевозможные логические разделения и отношения между ними, суть в том чтобы избежать дублирования, но иметь возможность восстановить всю информацию об объекте.

Виды отношений бывают:

  • один ко многим - объект прямо ссылается на другой

  • многие ко многим - объект прямо ссылается на все зависимые либо существует объект который ссылается на связанные с известной ролью

один к одному можно рассматривать как часный случай один ко многим
многие к одному можно рассматривать как часный случай многие ко многим так и обратный вариант один ко многим

Сами связи могут быть:

  • геометрическая - скорее всего это один ко многим, например contains

  • по общему полю - можно реализовать отношения вплоть до многие ко многим

  • по ссылке - один ко многим, в ОСМ только в обратном порядке, way ссылается на node, relation на node, way, relation

  • через OSM relation - то же что и по ссылке, но многие ко многим

Задача

Если мы хотим задать дому адрес как номер дома с улицой то мы представляем себе:

Дом 12 на улице Бродвей с извесной нам геометрией дома и улицы, который находится в городе Г.

Схема addr:


улица - way
name=Бродвей

адрес - node
addr:housenumber=12
addr:street ссылается по общему полю на Бродвей

тут минусы могут быть в сл:

  • дублирование тегов: Бродвей состоит из 100 кусков, на каждом есть имя (на разных языках) + тег вики и еще теги

  • мультиязыковая проблема: Бродвей можно написать на аглийском и испанском, в принципе это не проблема если считать Бродвей в данном случае как идентификатор и имя брать из улицы

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

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

Избавление от дублирования:


улица - relation
name=Бродвей
member часть улицы 1 в роле части улицы
member часть улицы 2 в роле части улицы
member часть улицы 3 в роле части улицы

адрес - node
addr:housenumber=12
addr:street=Бродвей

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

Вместо общего поля попробуем использовать ссылки:


улица - relation
name=Бродвей
member id часть улицы 1 в роле части улицы
member id часть улицы 2 в роле части улицы
member id часть улицы 3 в роле части улицы

адрес 1 - node
addr:housenumber=12

связь 1 - relation
member id улицы Бродвей в роли улицы
member id адреса 1 в роли адреса

адрес 2 - node
addr:housenumber=13

связь 2 - relation
member id улицы Бродвей в роли улицы
member id адреса 2 в роли адреса

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


адрес 1 - node
addr:housenumber=12

адрес 2 - node
addr:housenumber=13

улица - relation
name=Бродвей
member id части улицы 1 в роле части улицы
member id части улицы 2 в роле части улицы
member id части улицы 3 в роле части улицы
member id адреса 1 в роли адреса
member id адреса 2 в роли адреса

Вуаля мы получили street/associationStreet. Если по анологии повозиться ещё с отношениями улиц в городе, городов в районе, районов в областях, областях в стране и тд мы получим “беларускую схему”.

минусы:

  • изменение нескольких объектов: чтобы добавить/удалить адрес мне нужно изменить адрес и отношение.

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

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

Я склоняюсь к сл варианту:


улица - relation
name=Бродвей
member часть улицы 1 в роле части улицы
member часть улицы 2 в роле части улицы
member часть улицы 3 в роле части улицы

адрес - node
addr:housenumber=12
addr:street=id улицы Бродвей

Но она не лишена проблем с удалением/пересозданием улиц и не поддерживается напрямую api.

Ещё

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

Итого

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

529

Именно. Только этот фактор напрямую зависит от степени сложности реализации и эксплуатации. Поэтому и предлагаю только лёгкую модернизацию уже существующего в виде надстройки, которая — в случае использования — решает то, что без неё либо не решается вовсе, либо — через «костыли». При этом ничего ломать не надо.

Сейчас для работы с отношениями и членами отношений очень удобен relation toolbox. Проверки с подсветкой нет, конечно (но есть стили, например Address Tag Validator или Coloured Streets и можно сделать аналог).

530

Вот я так и не понял, что сейчас не решается и в чем костыльность уже применяемых решений.

531

Ну как минимум группировка всех “адресов” (адресных точек) на один тип объектов OSM (отношения).
Чтобы был один объект которому указывать теги википедии, нескольких имён на многих языках и прочего.

Ещё просто не решаемый вопрос это выбор всех “улиц” в городе. relation street помогает в этом случае.

при том что несколько адресов одному объекту из OSM задать нельзя нормально (только AddrN). Либо ничем не связанные адресные точки.

Применяемых решений слишком много и они не решают все задачи. Простые теги addr:housenumber addr:street не поддерживают многоязычности если их применять на самих объектах адресации.

532

Преимущества relation street и associatedAddress в том что они выделяют “адресный набор” в отдельные сущности от адресуемого объекта (дома, POI).

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

Причём и в участники и в relation street учитывается many-to-many отношения в первую очередь, а не в последнюю. Поэтому с такой схемой дубликатов-тегов-адресов в базе будет меньше.

533

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

Нынешняя “проблема” множественных адресов не в плохих или хороших схемах, а в отсутствии поддержки у софта. Заинтересованные лица давно мапят addrN:* .

  1. Если до сих пор не удалось пропихнуть их поддержку повсеместно, то почему другую схему вдруг примут с распростёртыми объятиями?
  2. Избыточность данных не есть безусловное зло. Речь человека избыточна наполовину и это позволяет понимать частично расслышаное. В базе, где какая-то часть информации может быть в любой момент вольно или не вольно искажена, некоторая избыточность оказывается весьма кстати.
534

Когда “белорусская” схема адресации была полностью внедрена в Беларуси - выяснилось сразу что без препроцессирования данные никому не нужны, а заниматься приведением данных в удобоваримый вид никому не упиралось. Поэтому и померла схема - хотя избыточность хранения данных она конечно победила - но кому это оказалось надо? - оказывается никому… Вернулись к тому что имеем - и все ищется, всеми поддерживается, в любых редакторах без всяких плагинов и все понятно. Насаждать схему которую можно потом разгрести только при соответствующей квалификации смысла нет, какими бы простыми релейшены не были - все равно с ними работать не сильно интересно… Что касается поддержки мультиязычности - то вот пусть кому это надо и используют необходимую обработку имеющихся данных и на основе этой обработки и создают карты на нужных языках, в принципе так это сейчас и работает. Так что если есть желание все таки делать очердной армагедон в данных - выберите какой нибудь город, желательно небольшой и особо никому не нужный - и тренируйтесь, пытайтесь убедить разработчиков софта что Ваша схема найлучшайшая и самая достойная - а там смотришь и весь мир подтянется :slight_smile:

535

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

Сейчас нужна не одна! А целый десяток схем которые учитывают все “местные особенности” тегирования. Карлсруэ не используется в/на Украине. Кто вам насаждает relation street? Их уже сейчас используют.

Отношения в iD сейчас корректировать и создавать можно без головной боли.

Не сильно интересно - что это значит?

Нет, сырые данные должны быть настолько удобными чтобы ими можно было решать бОльший круг задач. http://www.openstreetmap.org/relation/4655900 - сколько есть названий, столько и указывают.

Даже если и в 2-3 раза. “улицы” дублируются по 50-100-200 раз. Вы это специально забываете?

Новички их вводят вручную потому что видят вокруг что “все теги адресации указаны” и указывают все дублирующиеся теги на каждом новом доме и магазине: Россия-Иваново-…

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

Одной name:ru=“Степана Разина улица” достаточно в отношении http://www.openstreetmap.org/relation/4655900, а не на каждом из 4х домов.

536

Всю страну нормализировать не нужно: достаточно дублировать на первом попавшемся place=* (city, suburb) теги стран, городов, областей.

Внутри НП: должны быть объекты адресных улиц. Логичнее всего их тегировать через relation street. Уже в этих отношениях легко указывается Википедия, несколько языков и прочее.

Если так нужен этот Номинатим (или что там ещё отношения не поддерживает?), то оставить для него теги Карлсруэ на домах и POI.

537

Я посмотрел этот и этот примеры. Были какие-то ещё?

Вопрос: новички гарантированно не будут добавлять новые POI в здании в отношение associatedAddress. Как предполагается бороться с этим? Или никак?

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

Присвоить несколько адресов точкам POI в здании? Да, украинская схема этого не умеет.

А они когда-то не справлялись?

Nominatim сейчас поддерживает отношения type=associatedStreet, не поддерживает type=street.

538

Так, погодите-ка.
Глянул ещё раз на отношение в Витебске и увидел, что там только один участник в роли “address”. Это что же, предлагается для всех домиков такое использовать, а не только для зданий со множественной адресацией?

Кстати, надо бы добавить эту линию в это отношение :wink:

539

Если написать патч к iD и плагин к JOSM - то почему будут?

Конкретно с этим вопросом валидатором бороться очень просто. Нет родительского отношения когда есть addr:housenumber - значит ошибка, исправляем либо вручную либо ботом.

Скачиваете точки с addr:housenumber.
Скачиваете отношения associatedAddress и всех детей с ролью “address”.
Отгружаете отношения associatedAddress и всех детей с ролью “address”.
Всё что осталось - данные затегированные не по associatedAddress.

Одна схема тегирования в данных лучше чем 3-5 одновременно. В данном случае - почему и не associatedAddress.

540

20 страниц разглагольствований, а оказалось, что всё может сделать бот/постобработка. Так на кой х…р оно тогда надо?