Да, да нужно повсеместное внедрение отношения building, т.к. оно поддерживает указания poi находящихся в здании и входов/выходов.
freeExec
Шутки, шутками, но вроде кто-то же предлагал радикальный подход во время обсуждения фич API перевести всю инфраструктуру OSM на отношения. И рациональное зерно в этом, стоит признать, таки имеется.
Да ну какие шутки. Когда народ голосует против отношения person, позволяющее связывать разные сущности, объединение которых не возможно на голых данных ОСМ, вы тут предлагаете воспрянуть из пепла всяким subarea которые дублируют данные.
Суть та же самая - когда вместо использования геометрии начинают городить костыли из отношений.
OSM - это пространственные данные, заменить геометрию всякими subarea и is_in не получится да и не нужно.
Тем что это не часть мультиполигона. Тем что при попытке докачать границу РФ - выкачиваешь чуть ли не все атд РФ. Будь это отдельное отношение хранящее именно атд, имхо было бы удобнее.
Я согласен что постгис - это неудобно, особенно если вам не аналитику какую-то надо построить, а что-то отредактировать в том же жосме. Но и отношения все в одном тоже не очень удобно.
Я иногда общаюсь со сторонними разработчиками, использующими осм. Дак вот для многих отсутствие addr:city на поях и домах - это сильно неприятный сюрприз. В общем я не сказал бы что отношение с админисративным делением - однозначно вредная или бесполезная штука, но как часть существующих полигонов - мешается.
Это не часть мультиполигона, а часть отношения.
Что то не так делаете, я нормально выкачиваю границу без “все атд РФ” .
Вот теги addr:city, addr:country, addr:region, addr:district на домах и POI это зло.
Как всё повернулось… ))
В защиту subarea. Всё-таки административные границы — это абстракция, в реальности обычно не существуют. А потому могут возникать коллизии, когда геометрия не соответсвует административному подчиению. Т. е. subarea — это способ обозначить именно административное подчинение (которое, правда, в большистве случаев совпадает с геометрической моделью).
Хорошие примеры — это Крым (с его двойной принадлежностью) и ЗАТО Саров (с его границами, выходящими за пределы Нижегородской области, которой он подчинён административно).
Что значит воспрянуть из пепла? По тому что я видел, subarea, по крайней мере в России, применяется весьма активно вплоть до самых низких уровней. Так что вопрос не в воспрятии из пепла, а в добитии оставшихся 10-15 процентов муниципальных образований не использующих эту роль и создании рекомендации при обрисовке тех же сельских поселений не брезговать этой ролью.
Тут речь идёт далеко не об использовании отношений в роли категорий, а об использовании ролей для создания избыточности, которая весьма полезна для серьёзного облегчения работы программиста при работе с АТД на основе данных ОСМ. Нормализация и фанатичная приверженность пространственности данных это хорошо в теории, на практике же обычно лучше искать компромиссы, облегчающие и ускоряющие пользование данными. (аналогия с БД и сайтами полная)
Кроме того, аналогично можно сказать что теги addr:country, addr:district и т.д. тоже костыли которые дублируют пространственные данные, но тем не менее они широко используются не только по историческим причинам, но и потому что они банально удобны. (хотя, лично я, из соображений краткости и недублирования данных заменил бы их на систему отношений проходящих от страны до отдельного дома)
Да вы мазахисты. Только вчера я разгребал конфликт в отношении трассы с 2800+ членов - это ад и Израиль. Грузиться долго. Загрузить историю, чтобы увидеть хотя бы предыдущий changeset вообще не реально. Мержить такую хренотень ни кто не будет. И это предлагается при внесении любого домика.
Вот type=collection в некоторых регионах, в которые включены все районы — точно зло. Правда, облегчают задачу с добавлением subarea.
Это проблема не концепции, а кривой реализации. Проблемы большого количества членов решаются иерархией, в случае маршрутов разбитием на отдельные участки. Т.е. скажем условная М7 разбивается на участки “Москва—Владимир”, “Владимир—Нижний Новгород”, “Нижний Новгород—Чебоксары”, “Чебоксары—Казань” и “Казань—Уфа”, которые в свою очередь при необходимости могут разбиваться на участки вида “105 км—230км”. Ведь разбиваются же длинные веи, так почему бы не разбивать и отношения?
В случае же адрески последовательность следующая: для связи муниципальных образований используется роль subarea, потом для малых НП используется условная роль settlment для связи с МО, после чего отношения улиц (нечто вроде associatedStreet, но с решённой проблемой угловых домов) включаются в отношение НП (или района в случае крупного НП) с условной ролью street, а сами дома (если уж мы идём до конца и переводим и их на отношения) смогут легко и естественно включать в себя POI, входы и разноэтажность. Где в такой концепции тысячи участников? От силы сотня-две в самых крайних случаях, что весьма подъёмно.
Да, редактировать будет несколько сложнее (хотя это больше проблема инструментов, нежели самих отношений), но с другой стороны сплошные плюсы: на порядки меньше дублирования, нет возни с синхронизацией addr:street между домами и с name дорог, облегчается поиск, радикально меньше становится работы для программиста при работе с адреской и АТД, ибо никаких постгресов, груздей пространственных запросов, отлавливания ошибок и разбирательства в десятках возможных комбинаций. Да даже условную функцию “Что здесь?” как в гуглах и яндексах при клике на условный домик сделать будет на порядок больше, не говоря уже о построении полных индексов адрески для региона или страны.
Разумеется всё вышеописанное никак не пропозал, а всего лишь набросок концепции, (например, нужно учитывать адресацию по посёлкам, районам, несколько другие системы вроде японской и т.д.) но где же здесь вы видите мазохизм?
Как Вы вообще целостность будете проверять без геометрии: чтобы не было дырок и полигоны были встык? Если не нужна геометрия, зачем тогда вообще OSM?
Без postgis можно взять что-нибудь на основе geos и получить ту же геометрию, но postgis имхо проще.
А так есть структура admin_level и взяв например xapi или overpass пробовать выгружать, главное в таймауты не упираться.
Было http://wiki.openstreetmap.org/wiki/Relations/Proposed/Postal_Addresses, теперь уже нет, чесно говоря это отличный пример протухания данных.
Опять же поиск в полигоне place или возле точки place имхо должен решать эту проблему достаточно хорошо. Если напрячься, то и готовые скрипты по выгрузке адрессов можно найти.
Я раньше то же возмушался про проблем со вложенностью . На текущий момент если научится правильно её делать, то такой проблемы не будет. Будет очень красивое решение : ) .
А как маппер ценю своё время. Ведь в осм и так никто домики не нарисует кроме как вручную. А вы ещё предлагаете просто так тэги на вешивать! Имхо пустая трата времени!
Геометрические вычисления, разумеется, достаточно дороги. Поэтому использовать что-то дополнительное, что сократит их объем, всегда полезно.
Допустим мы ищем, в какое поселение входит нп. Можно тупо искать попадание во все подряд.
Но если на нп написано, addr:subdistrict=Хххх сельское поселение, то можно взять его в качестве первой попытки, если угадали, а мы угадаем почти всегда, то поиск окончен.
Если addr:subdistrict размечен неверно, то диагностируем ошибку, плюем на этот addr:subdistrict и ищем среди остававшихся поселений.
Аналогично и с subarea
Вот бы придумали пространственные индексы… 
Давно хочу сделать плугин к osmosis, который добавляет подобные теги исходя из геометрической вложенности объектов.
Может тогда перестанут заниматься бессмысленным дублированием в исходных данных?
а давай включим в отношение города еще и все магазины в нем
наверняка кому-то будет удобнее
Это не отменяет геометрических вычислений, особенно в момент их построения.
Даже с ними проверить один объект короче, чем поиск среди многих, даже если это делает база данных за одну строчку вашего кода.