Почему в OpenStreetMap Boundaries другие данные, нежели в OpenStreetMap?

Question

[Александр Куракин]

(речь НЕ о политике, а о технической части.)

Крым в OpenStreetMap вроде бы в РФ: https://www.openstreetmap.org/relation/3795586, name="Республика Крым", addr:country="RU", ISO3166-2="RU-CR", "Отношение Южный федеральный округ (1059500) (в роли subarea)".

(Есть, правда, и другой Крым, https://www.openstreetmap.org/relation/72639, но речь не о нем.)

Так вот, скачивая РФ в OSM Boundaries, я не вижу там ни одного Крыма, зато два Севастополя.

А в поиске самого https://www.openstreetmap.org/ он отображается так: "Результаты от OpenStreetMap Nominatim - Область/Штат Республика Крым, Украина".

Как всё это работает? Почему (технически, где это можно увидеть?) в этих источниках принадлежность различная? В каждом из двух, кроме самого OpenStreetMap, случаях?

См. также мой пост: https://forum.openstreetmap.org/viewtopic.php?pid=...

Спасибо.

Comments

[Moskus]

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

[Александр Куракин]

Moskus, спасибо за ответ! А если спрашивать чисто технически, в конкретном случае? (Я не нашел,) в каком месте какой атрибут выставлен так, что указанный relation в той или иной стране?

Я изначально думал, что это addr:country или isin, или что там задает "отношение в роли subarea"...

[pfg21]

члены отношений subarea и isin считаются устаревшими и их поддержка и внесение не рекомендуется (хотя есть любители их пихать).
вложение регионов в друг друга рекомендуется просчитывать геометрически по вхождению контуров.

в РФ упрощенная система адресации в которой addr:country и прочие addr-теги высчитываются для произвольного объекта геометрическим нахождением внутри соотвествующего контура.
к примеру для addr:country это будет нахождение внутри контура
boundary=administrative
admin_level=2
name=Россия
для других тегов addr другие сборки тегов на контуре

[Александр Куракин]

pfg21, а зачем отношения задепрекейтели?

[pfg21]

Александр Куракин, не отношения :) а именно теги subarea и is_in.
сейчас рекомендуется выявлять вложенность админ.контуров геометрическим вхождением - т.е работой postgis библиотеки над развернутой в postgre базой осм.

[Александр Куракин]

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

[pfg21]

Александр Куракин, да, одно время использовали is_in и subarea для их связи. и еще подобных систем.
но потом пришло понимание что эту же связь можно высчитать скриптом. ибо понятно что составляющие федерального округа не могут выскочить за его пределы, также как и составляющие края/области/республики и т.д. и т.п.
т.е. административные регионы не пересекаются и имеют четкую иерархию, которая логически может быть выявлена из геометрической вложенности их контуров.
после чего применение subarea и is_in считается устаревшим и потихоньку вычищается из базы и документации.

[freeExec]

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

[Александр Куракин]

freeExec, если Вы про OSM Boundaries, то нет, там никто не заморачивался, потому что у них ни одного Крыма в России, но два Севастополя.

Answer 1

[Александр]

Ну это чтобы можно было выбрать тот, который тебе больше нравится.

Вообще существует два набора данных, где разные только родители.

Comments

[Александр Куракин]

Спасибо за ответ! О каких именно наборах Вы говорите?

[Александр]

RU и UA
Причем более свежий 3795586 - вероятно загружается через API ботом компании Garmin из своих баз.
А более старый 72639 был там изначально до всех событий.

Бот Garmin видимо не распознал старый набор из-за другого родителя и создал его дубликат.

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

Увидел косяк, зашел и поправил.

Answer 2

[pfg21]

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