насколько я знаю (хотя и другие могут догадываться), КЛАДР расшифровывается - классификатор адресов РОССИИ!!!
и эта тема - обсуждение использование кладр на территории России
что подразумевает наличие тега cladr:code только на териитории России
и при чем тут Болгария?
ну если KekcuHa туда как-то прилепит болгарский аналог нашего кладра
Ответ, тот же. 
Это я намекаю тем, кто предлагает ограничиться кодом КЛАДР, что за границей России подобной вещи нет (точнее, где-то есть, но именно подобный, а не наш свой). А OSM действует во всем мире. Так что утилитам при расшифровке адреса придется пользоваться не КЛАДР (или не только им). Например liosha конвертирует кроме России еще 8 стран.
О чем и речь.
Кроме того “addr:*” довольно наглядны, а расшифровывать ссылки с помощью JOSM, Potlatch, … а тем более визуальным просмотром “.osm” крайне непросто.
Конечно, можно (и наверное стоит) в параллель ввести иерархию по ссылкам, и пропихивать ее в майнстрим. Ну а там, глядишь и редакторы начнут разбираться, и очередная версия api будет обеспечивать целостность, а то вдруг кто-то удалит дубль улицы на которую ссылалась половина домов…
Опять нашел затык: в предложенной схеме http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema
Предлагаемой схемой не предусмотрено:
- Прописывание addr:streetname для улиц (возможно только для домов)
- Прописывание addr:district и addr:region.
- В схеме есть addr:state, но написано что там должно быть сокращение.
update:
Идеальный вариант, конечно же http://wiki.openstreetmap.org/wiki/Relations/Proposed/Postal_Addresses
Можем сейчас сделать по предложенной мной схеме, потом тогда будет проще переходить на схему с релейшенами.
1,2. А кто нам мешает все это ввести?
3. “addr:state” нужен только в Штатах и Австралии, а двухбуквенное сокращение требуется в “addr:country”.
Еще можно и addr:suburb придумать.
Что-то мы (Российское сообщество) слишком разошлись в придумывании новых тегов.
Хотелось бы максимально использовать то, что уже принято как стандарт.
Лично мне достаточно одного тега: addr:city, а addr:country я предлагаю только для полноты. А по поводу сложных адресов есть тег addr:full.
Предлагаю в данный момент остановиться на этом, а новые теги вводить только после согласования с остальным (нерусскоязычным) сообществом.
Кстати, а не сложно будет многоуважаемому KekcuHa и его боту проставлять эти теги так же и для домов? Про addr:streetname я не говорю - это нельзя сделать автоматически
Пока обработка домов вообще не проводится.
А какая разница, сколько запросов? Это проблема производительности БД, а не информации в ней. Что там, непрерывно будет селектиться каждый дом? Есть такой тип БД (data warehous), где как раз и производится полное разворачивание всех ссылок для быстрого поиска, но данные в таких БД практически не должны обновляться и занимают в разы больше места, чем в обычной OLTP БД, где данные приведены к нормальной форме.
Задача поиска к чему сводится? По названию города, улице и номеру дома найти дом. Сначала ищем города, потом внутри полигона или окрестности точки (города) ищем точки или полигоны с тегом билдинг и отбираем там по тегам улица и номер. Математический аппарат для поиска точек в полигоне и пересечения полигонов достаточно развит, и есть интерфейсы к БД, где этот поиск делается одним запросом.
Или тупо ищем все дома с нужным номером и улицей, потом среди них находим ближайшие к нужному городу. Тут запросов больше, но требования к БД меньше, справится и компьютер, и любая железка.
В общем, проблема поиска надуманная, и не стоит ради неё городить огород из тегов.
Мда. Рекомендую попробовать на практике написание поиска в ОСМ по любому из предложенных алгоритмов 
А теперь то же самое поподробнее:
Задача 1.
Пусть у нас есть точка или полилиния.
- По номеру запрашиваем ее из OSM:
**http://www.informationfreeway.org/api/0.6/node[id=###] **или http://www.informationfreeway.org/api/0.6/way[id=###]
2…
Задача 2.
У нас есть left,top,rigth,botton.osm
Надо проиндексировать все населенные пункты, улицы и дома. Да, да, и возле прямоугольника области тоже. Нет, граница государства в прямоугольник не попала, в какой мы стране неизвестно. Нет, интернета у нас нет, просто на флешке файлик принеслии.
Есть относительно стандартная/универсальная схема, см. RFC 4119 и http://wiki.openstreetmap.org/wiki/Relations/Proposed/Postal_Addresses
У меня вопрос – под какой лицензией распространяется КЛАДР (искал, не нашел), и совместима ли она с Creative Commons Attribution-Share Alike 2.0 Generic License (http://creativecommons.org/licenses/by-sa/2.0/legalcode) и Open Database License (http://wiki.openstreetmap.org/wiki/Open_Database_License) ?
Ща и Кладр окажется нелицензированным, кому-то придётся откатывать
Ха-ха, как смешно. Если бы мне это было надо, я бы думал именно в этом направлении, а не плодил бы теги. Планета=Земля, Система=Солнечная, Галактика=Млечный_путь ещё впишите тогда, а то вдруг напейсатель программы алгоритмов работы с точками не знает где подглядеть, и
- Что интересно, КЛАДР “откатывается” совершенно безпроблемно - просто удаляюся все cladr:*.
- Лицензия КЛАДР очень интересна, и не менее интересна лицензия данных КАДАСТР.
Определенная надежду дает то, что эти данные фактически являются “первоисточником” и с точки зрения лицензии должны иметь тот же статус, что и закон. Т.е. это должен быть набор фактов (которые, как известно, не могут быть предметов авторского права), причем не несущий в себе элементов творчества (от силы некоторые тонкости структуры БД). Кроме того заказчиком выступало государство, т.е. налогоплательщики и данные не содержат какой-либо тайны (иначе не были бы выложены в свободном доступе). - В OSM попал не КЛАДР, а некоторые данные из него, что тоже может иметь отличия по ограничения.
На нее тоже в свое время посмотрели и увидели следующие недостатки:
- Число членов в отношении не может быть больше 2000 (по крайней мере не рекомендуется) - в Москве 3656 улиц (по КЛАДР)
- У отношений нет географической привязки, т.е. получить отношение можно только зная его id. И при этом не в объекте указана ссылка на отношение, а наоборот. Т.е. проблемы как в том чтобы по объекту найти адрес (имея id объекта не узнаешь id его адреса - впрочем как-то же JOSM выдерживает запреты поворотов…так что может и здесь небезнадежно), так и в том, чтобы по стране определить ее области и т.д. (аналогично)
- Работа с отношениями во всех программах сделана довольно… в общем не до конца проработана.
- Нормальная работа с этой системо без поддержки со стороны программных средств невозможна.
устарело. в апи 0.6 ситуация изменилась. это раз.
во вторых вы невнимательно читали про Postal_Addresses
там восходящая схема. т.е. не город хранит “у меня стотыщпицот улиц”, а улица хранит “я отношусь к городу ХХХХ”
читать http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6 в части касающейся “Relations for Element”
вот с этим полностью согласен. тут к сожалению пока всё не очень радостно. хотя в josm уже можно работать не сильно через анус.
непонял фразы. а с какой системой можно работать без поддержки программных средств?
как бы то нибыло нормальную поддержку адесации без релейшенов не реализовать. все другие схемы гораздо хуже.
не есть пару проблем которые вы почему то не назвали:
- поддержание системы в валидном состоянии. нужны боты типа кладровского которые будут отслеживать и поддерживать целостность структуры релейшенов т.к. в отличие от физических объектов тут нарушения визуально не заметны
- в текущей схеме предполагается что в релейшене будет вся адресная информация + что релейшен будет создан для каждого элемента адресной сети. т.е. для каждого здания. а это значит что общий объём данных будет солидно больше. в минске по скромным подсчетам от 20000 домов. соответственно добавление адресной привязки только для одной столицы беларуси увеличит количество релейшенов в базе осм на треть минимум (сейчас текущий номер релейшена помоему в пределах 80000)
оптимальным было бы слегка доработать схему. например до уровня иерархии выше дома оставить без изменений, но все дома одной улицы хранить в одном релейшене улицы. это сильно разгрузит базу и немного упростит работу по созданию и контролю целостности. но это ещё надо обдумывать…
Подождите, почему для каждого дома отдельный релейшен? Создается общий релейшен для улицы, дома нумеруются через addr:housenumber и записываются в него как член со статусом house
Вот как тут ,например:
http://www.openstreetmap.org/edit?lat=55.85148&lon=37.49019&zoom=15
Потому что это разнородные системы адресации - первая схема: почтовые адреса, вторая - адресация домов на улице. Соответственно, конвертер должен будет поддерживать обе.
Прошу модераторов почистить тему - вопросы адресации выделить в отдельную ветку.