Посмотрел в ФИАС, там это поле, если не пустое, имеет тип “строение”, “сооружение” или “литер”.
На практике “строение” и “сооружение” зачастую не различают.
Именно это.
Участники не при чём, но цель — чтобы стали причастны.
Согласны не все, а цель — убедить многих, показав, что это работает и работает лучше (тогда другие подходы не будут привлекательны, что сократит неразбериху в них, как минимум).
Часто упоминавшаяся белорусская схема адресации, сколько участников о ней знали? Сколько из них (и потенциальных — в том числе) могли в ней разобраться? Какие общие корни она имела с уже распространёнными схемами? Ответом на все эти вопросы будет «почти никто» или «почти никак». Отсюда — её предсказуемый уход со сцены.
Вот был предложен похожий на мою схему, но более комплексный подход, где всё организовывалось в рамках отношения type=building.
К сожалению, выяснил, попробовав, что iD катастрофически не приспособлен для редактирования отношений, если у них нет, например, тега name (или другого). Тогда просто невозможно выбрать конкретное отношение для работы над ним/с ним (добавлять новых участников — самое основное). Рекомендация использовать временные фейковые имена в процессе редактирования, а перед сохранением данных — удалять их, — будет глуповато выглядеть.
После JOSM, в iD чувствую себя инвалидом (человеком с ограниченными возможностями) 
А на официальном сайте — только бледный косвенный намёк на существование JOSM (мол, iD и Potlatch2 — рулят, а остальное — ерунда, не заслуживающая внимания, что само по себе является инверсией действительности в угоду ущербности).
Очевидно, что какие бы сильные аргументы я ни привёл — подобная инициатива не сдвинется с мёртвой точки, если только я сам не «напишу», например, конвертер в польский формат (а это невозможно в силу отсутствия квалификации) или не найдутся сторонники идеи, которые помогут довести её до логического конца (практического применения) тем или иным путём (подключением соотв. людей или непосредственным участием).
LLlypuk82, когда в РБ была эта “белорусская” схема адресации, все кто пытался работать с Беларусью в OSM о ней и знали 
- проблема была в том, что с сырыми данными без препроцессинга работать было нельзя. Именно поэтому отказались от ее использования. /Ну еще и потому что память в компе у того кто препроцессингом занимался закончилась :)/
И сколько ждать выполнения этого чуда для Москвы? Сколько памяти займёт для Москвы выбрать все улицы этим способом?
Проверки на совпадения имён - на плечи потребителя данных.
Проверки на 2-3 куска - на плечи потребителя данных.
Проверки каждого куска на наличие тега Википедии - на плечи потребителя данных.
Грабли одноименных улиц (даже в рамках одного Питера) расставим и пользователям не скажем как обходить (“только по имени улицы”).
… почему на хабре о OSM про красноглазых говорят?
Адресная улица это отдельная сущность и должна быть в базе явно для простоты пользователей “адресных улиц”. Не нужно её подменять “именами улиц” разбросанными по кускам highway.
“улица” это те 60-80 домов, школ и заводов в одном отношении. Возможность банально посчитать количество улиц (без написания при этом геокодера!) должна быть в сырых данных.
Автор Разработчик Nominatim-а заявляла в 12-м что “теги addr:street быстрее обрабатываются”. Так вот это не так для всех задач. Особенно когда пользователю всё равно: 50000 адресных точек в Москве или уже 500000; ему нужны другие инструменты для работы с “улицами”.
d1g, обычному пользователю не надо “банально посчитать количество улиц”. Давайте не будем рассматривать OSM как инструмент для профи. Что надо обычным людям? - им надо что бы они могли найти конкретное здание-сущность по конкретному адресу. Как это там будет внутри устроено им абсолютно все равно. И если они не находят этого в картах OSM - а находят в каком нибудь навителе - то все - для них OSM отстой - ведь там же ничего нет из того что они искали. Ну и тут им говорят - а Вы сами заполните адресок в OSM - и он появится для следующего поиска - и что он будет разбираться со всякими отношениями? - нет конечно - он просто забудет об OSM и все. Тот у кого уровень выше среднего или тот кто конкретно занимается обработкой существующих данных OSM и улицы посчитает, и домики и все что там есть, применяя те знания, которые нужны для этого, а чего не знает - научится. И если ему надо работать по серьезному с данными OSM то сконвертирует в нужный формат и все у него будет быстро и искаться и считаться. Я застал и расцвет и смерть белорусской схемы адресации, и прекрасно видел, в какой тупик ставят релейшены неподготовленных пользователей, и если просто внести адрес при помощи тегов как на соседнем здании ни у кого не вызывало проблем, то добавить в какой то релейшен зачем то - это был темный лес…
Возможно не в тему, но все же спрошу. В некоторых маленьких населенных пунктах, а так же в садовых товариществах нет улиц, номеров домов, есть только номера участков, Как их сдедует тегировать?
Точкой.
Если площадь известна - то вот так http://wiki.openstreetmap.org/wiki/RU:Tag:landuse%3Dallotments, там же есть ссылка на обсуждение на форуме.
То есть чтобы работал адресный поиск, нужно на садовом участке указать тег lot с номером участка?
В чём вопрос? В СНТ или в одном меленьком участке?
Если вопрос в СНТ то читаем “Садоводства, адресация и обозначения” (landuse = allotments + name=* + другие теги по вики). Отдельные “дома” можно указывать адресными точками с тегом addr:housenumber.
Если вопрос в участке, то тегируем его boundary=lot + lot=номер и ждём как появится поддержка этого.
Мне помогла вот эта http://garll.ru/osm_addr/ статья, там все подробно описано про садовые товарищества с улицами и без улиц, находящиеся в городе или за городом.
Она очень старая, смысл ее не как правильно замапить, а как замапить под конвертер.
В те времена еще даже не было place=allotments (не landuse, а именно place), который многое поменял.
Посему раньше лепили place=suburb в городе, и place=hamlet/village за городом, теперь есть возможность обозначать садовые товарищества правильно.
Поскольку это, вроде как, основная тема по адресации, хочу вернуться к давнему спору о том, что “адрес может быть только у здания и ‘владения’ - это выдумка бюрократов”. Все, что касается этой темы, регулируется правилами, утвержденными Постановлением Правительства РФ от 19 ноября 2014 г. № 1221 “Об утверждении правил присвоения, изменения и аннулирования адресов”.
Краткий вывод: адрес может быть назначен участку независимо от наличия на нем строений. Об использовании там термина “владение” (как и других) в этом законе - ни слова. Зато на него ссылается
Федеральный закон Российской Федерации от 8 июня 2015 г. № 140-ФЗ “О добровольном декларировании физическими лицами активов и счетов (вкладов) в банках и о внесении изменений в отдельные законодательные акты Российской Федерации”:
Если популяризировать и всячески продвигать/восхвалять associatedStreet (который уже поддерживается Nominatim-движком, как я понимаю) и добавить к нему associatedAddress associated_address (нормальное название, тем более, что эти отношения «родственные» и не будет пересечений с ролью «address»), то получится логичная связка и качественный «инструмент-алгоритм» для работы с адресацией, решающий до сих пор не решаемые проблемы (с мультиадресами и точечными POI).
Как я это вижу:
Предлагаемое отношение associated_address позволяет удобно и гибко привязывать здания и точечные POI к адресным точкам, а уже, в общем-то, одобренное и практикуемое associatedStreet привязывает здания к уличной сети (попутно группируя её саму (сегменты улиц) и решая гипотетическую проблему мультиязычности названий в адресном поиске). Получается, что если даже только контур здания имеет однозначную привязку по адресу, то все POI внутри (или на контуре) могут геометрическим путём получать адрес, что в свою очередь делает необязательным их включение как в associated_address, так и в associatedStreet, равно как и множить дубли адресов (что происходит сейчас).
Теперь вопрос: к кому в ноги падать, чтобы это ближе к реальности подвести?
P. S. Для начала можно документировать, но заниматься этим целесообразно только при весомом одобрении хотя бы здесь, на форуме.
- А что за “проблема мультиязычности названий”? Мне сдается это была проблема одного известного конвертора.
- Всем POI внутри здания и сейчас как бы не обязательно адреса ставить - по геометрии можно с дома взять.
Вообще-то дубляж еще углубится.
Надо будет домик включать и в уличное отношение и в адресное.
Ну и главные вопрос: это не реинкарнация “белорусской схемы адресации” в сушеном виде?
- Хотел сказать про мультиязычность в адресном поиске (её принципиальную возможность). Но это отношение не полноценно адресное, скорее — группировочное (дороги-дома). Потом, не будем забывать, что улица не всегда участвует в адресе, а здание и адресная табличка (пусть даже условная) — всегда.
- Не устану твердить: схема адресации должна предусматривать наибольшее кол-во случаев (мультиадресность на одном объекте, особенно — точечном, только лишь геометрией нельзя это решить). Дубляж чего? Разве зря я выделял что и куда привязывается? Будет косвенный дубляж, разве что, названия улицы. Так он и сейчас есть и никому не мешает.
А в чём проблема включения объектов в разные отношения? Это нечто из ряда вон? Обычная практика.
Главный ответ: белорусская схема не имеет ничего общего с обсуждаемым предметом, сколько можно о ней-то? И вы ещё говорите об инерции мышления
Объясните новичку, что дом надо включить в одно отношение, чтобы адрес по улице приписать, а потом еще в одно, чтобы просто саму улицу собрать. Да, проблем нет, но так делать почти никто не станет. Это дубляж, для всех это же одно и то же. Два раза делать одну и ту же работу - собирать улицу. В лучшем случае перестанут обращать внимание на associatedStreet, ибо получится, что оно не нужно, так как уже “на адресацию не влияет”.
Если убрать рюшечки, то белорусская схема есть тоже самое. Все адресные объекты собраны членами в отношение - адресный объект более верхнего уровня.