на кой когда есть addr:country=RU
Потому что теги addr:* применяются к объектам, которые имеют адрес. Административно-территориальные образования не являются объектами в обычном понимании и не имеют адреса 
is_in же (к сожалению) популярный тег: http://taginfo.openstreetmap.org/keys/is_in#overview
Почему к сожалению, пусть будет. Можно подумать что для определения вложенности по геометрии не нужен валидатр.
Изучение с нуля геометрических алгоритмов, реализация их и тд и тп тоже может занять кучу времени.
Более того, PostGIS даёт возможность использовать геометрические индексы, что для немалого количества сложных задач очень помогает.
Во-первых, всё совсем не так просто.
Во-вторых, писать заново когда существует не так давно работавшее решение не всем хочется.
В-третьих, неправда, что никто таким не занимается, см. например https://github.com/Scondo/fiosm
Отвечу кратко, этот подход вполне рабочий для ограниченных и стабильных объектов. Объекты АТД не настолько часто изменяются, новички вряд ли справятся с корректной правкой объекта АТД, ведь это узелок релейшенов порой на десятки элементов. Количество объектов АТД можно подсмотреть здесь - http://www.gks.ru/free_doc/new_site/bd_munst/1-adm_2012.xls
Требование вытягивания всего из геометрии - надуманное. Точнее в общем случае оно верно, но в ряде случаев оно вполне может быть опущено. Как часто появляются новые субъекты федерации, насколько часто муниципальные районы переходят из одного субъекта федерации в другой? Но неужели вас не заботят сторонние потребители продукта? Далеко не для каждого программиста выяснения что во что вложено оптимально, особенно если не работаешь с planet.osm. А объекты АТД в ОСМ имеют важное значение так как участвуют в формировании адреса того или иного объекта. Зачем анализировать геометрию поднимаясь до уровня границ России если всю информацию можно вытащить из объекта интересующего уровня?
Кроме того, наличие “дубликата” в нормальных системах дополнительный элемент обеспечения надёжности, т.к. сломанная граница региона разрушает правильный анализ геометрической вложенности.
А где вы планируете остановиться? Ну уровне субъекта? На уровне муниципального образования? На уровне населённого пункта? Или будем добавлять по одному is_in-у для каждого уровня вложенности ко всем точкам - а вдруг кому понадобиться?
Я предлагаю этим потребителям использовать подходящие инструменты вместо неработающего механизма. Геометрический поиск не такой страшный, поверьте, особенно с использованием нормальных геометрических индексов.
Я же не говорю что PostGIS это хуже. Для полноценной работы понятно что оптимально пользоваться специализированным ПО. Когда возникнет потребность в очень сложных алгоритмах то понятно что разумнее потратить месяц-другой на игры с этим продуктом. Но сейчас у меня нет времени для этого и главное отдача будет невелика, после написания валидатора я не буду лезть в геометрию ещё много месяцев.
Писать заново придётся немногое, даже скажу более, для моих частных задач нужен вообще минимум, но валидатор требует большего. Ну а если другие занимаются значит скоро будет конкурирующее решение 
Лично мне вполне хватало прежнего валидатора, но его нет и работающей альтернативы нет. Поэтому и стараемся …
А как это быстро сделать в Perl? На входе - файл russia.osm, скрипт на Perl, на выходе - деревни входящие в Антроповский район Костромской области.
- Делать проверку вложенности совсем не сложно. Для этого достаточно разобраться в структуре данных осм и уметь немного программировать. С этим смог справится даже я.
- Эта забота о пользователях слишком умозрительна. Чтобы кому-то что-то гарантировать (например, что кто-то сможет определить принадлежность некого релейшена АТД РФ по тегам), нужно очень внимательно следить за данными.
Я ж говорил - подходящими инструментами.
Я не знаток perl-а, тут лучше liosha может подсказать.
По простому можно обойтись 3 командами, которые можно запустить на любом языке:
getbound.pl 1698924 -o antr_kostr.poly
osmconvert russia.osm -B=antr_kostr.poly -o=antr_kostr.osm
osmfilter antr_kostr.osm --keep-nodes="place=*"
Можно и без команд, если воспользоваться соответствующими библиотеками. Например на Java это библиотеки JTS и GeoTools.
Не надо нам is_in в отношениях границ, спасибо пожалуйста.
Загрузи всю геометрию в postgis, половина работы будет сделана.
Я так понял что здесь собралась масса умных людей Ну так сами и напишите этот валидатор. Пока писали в эту тему могли давно бы его и набросать, там делов то всего - 5 минут.
В этом весь ОСМ
На вопрос, а зачем нам subarea который может быть извлечён из геометрии (он чем-то принципиально лучше is_in?) получаешь ответ что это надо.
А когда предлагаешь довести эту идею до ума, чтобы не завязываться только на геометрическом поиске то получаешь ответ что не надо.
Повторю вопрос ещё раз - нам нужен subarea? Или any_tag_you_like ради any_tag_you_like?
Не лучше. Кому конкретно надо?
Кому “нам” то? Мне - не нужен. Спрашивать надо тех, кто его расставляет. Очень подозреваю что его ставят только потому что он в вики упомянут.
А вот всё ли вы вытащите из геометрии?
Просто вопрос - а сколько городов в Архангельский области? Действуя по геометрической схеме мы находим отношение Архангельской области. Вот оно - http://www.openstreetmap.org/browse/relation/140337 и натравливаем скрипт. И что в итоге? Город Нарьян-Мар который находится на территории Архангельской области в итог не попал. Ненецкий автономный округ входящий в состав Архангельской области не вошёл в отношение Архангельской области … Аналогичная картина и с Тюменской областью. Обидно? Геометрического алгоритма недостаточно?
А как насчёт работы геометрического алгоритма в случае Иультинского района - http://www.openstreetmap.org/browse/relation/1949881 ? Всегда ли он даст ожидаемые ответы?
Или например граница Нижегородской области и Мордовии - почтитайте обсуждение Сарова на нашем форуме. А теперь сравните контур Мордовии в окрестностях Саров в ОСМ - http://www.openstreetmap.org/browse/relation/72196 и в Яндексе - http://maps.yandex.ru/-/CVbjzD8J Есть разница?
Что значит обидно? Если должно быть верно “Город Нарьян-Мар находится на территории Архангельской области” значит вот эти отношения являются неверными - “Ненецкий автономный округ входящий в состав Архангельской области не вошёл в отношение Архангельской области”. Надо исправлять либо сами отношения либо их административные уровни.
Что значит недостаточно? Вы нашли ошибку в границах благодаря этому алгоритму, даже не запуская его.
У меня сложилось такое впечатление, то что программисты (в данном случае fserges и другие) на самом деле хотят написать инструмент и под него уже подогнать ОСМ.
Что-то мне подсказывает, то что is_in который здесь обсуждается это такой очень старый костыль, который нужно выпиливать, выпиливать и ещё раз выпиливать.
Почему? Объясню чуть ниже.
И так программист, который спрашивает меня как сделать валидатор насел пунктов (а не адм тер дел) .
На что мой ответ примерно таков:
Первое. Нужна первичная база по которой будет работать валидатор к примеру ФИАС(не ОКТМО, ОКАТО или КЛАДР). Так же с возможностью внесения автором валидатора новых НП, или изменений. И как следствие никаких кодов в виде fias:code (желательно, но необязательно, т.к. если будут какие-то ошибки я не думаю, что исправление бд будет полноценным с кодами кладра и т.п.) .
Второе. Каждая точка деревни должна иметь addr:country, addr:region addr:district и думаю всё же правильным будет указание addr:subdistrict (сельских поселений т.к. они в фиасе есть) при 100% совпадении деревня должна считаться замапленной (соответственно если два одинаковых имени и два одинаковых имени то ок, три или один не ок). Этот пункт я думаю может быть реализован даже на диффах еже минутных!!!
Третье. Когда будет отточен второй пункт. Появится ещё инструмент, а именно проверка полигона точки на соответствие тэгов точки нп. Его например можно cделать из выгрузок гислаба. Не думаю, что получится сразу это реализовать на минутных диффах, хотя всё зависит от искуссности программиста.
Четвёртое. Когда будет реализованы предыдущие этапы и будет готовый продукт, то можно вынести отдельным пунктом разрывы адм границ. Т.е. неправильно замапленными или битыми .
Пятое. Когда останется высшая ступень : ) , то уже проверки нелогичности. Типа почему addr:disctict не равен name соответствующему отношению и т.д.
Теперь я выскажу своё мнение поповоду почему это должно выглядеть именно так,а не по другому. Идея приравнивать и брать тэги из вложенности отношений просто идеальна! Однако на практике она плохо реализуема. Я не говорю про техническую сторону вопроса. А про мапперскую. У нас есть границы до районов, но не для сельских поселений(или штучные, далее сп). Для сп их так просто не обрисуешь + они постоянно меняются. Поэтому я считаю, что реализация проверки наличия деревни (по addr:*) должна быть отдельна от проверки границ. Реально обоснованным последним перед названием думаю максимум сельские поселения, хотя может всё же имеет смысл использовать административное деление (т.е. страна, область, район, нп), т.к. тут можно напридумывать много: Страна, область, район, сельское поселение, сельский округ, нп.
А если серьёзно сказать fserges начни уже писать)))), т.к. практика показывает, что не вики и участники диктуют как маппить, а валидаторы))). Т.к. они приводят к одинаковой схеме тэггирования на всей территории страны. И если мапперы захотят использовать валидатор , то либо им придётся подстраиваться под него, либо не использовать.
Извините за 5 минут вашей жизни потраченных на чтение этих строк. Более коротко не получилось.
lenux, это называется “схема Карлсруэ” и в русском OSM на практике никем не применяется. Причина проста: поддерживать 100500 копий адресного дерева на каждом объекте нереально.
Alexandr Zeinalov прочитал в вики. Там говорится о домах. Я же предлагаю делать исключительно для НП. В ЯО их порядка 6к, значит с полигонами всего 12к и для очень большинства все они прописаны. Прописывать все addr: до нп для домов(и для объектов внутри нп) не нужно. Это не логично, т.к.они находятся в полигоне нп. А его пусть и формальные границы всегда можно нарисовать.
Однако как я думаю не стоит говорить о схеме реализации валидатора приравнивать к реализации других вещей, типа адресного поиска, пои и т.д. Т.е. тем самым например полный адрес соседнего магазина или НП в поиске строится по одному принципу, а в валидаторе по иному принципу.
Я использую subarea
Не весь ОСМ денно и ношно сидит на форуме
Вопрос странный, вроде всё очевидно. is_in - это аналог subarea времён отсутствия в ОСМ отношений. В те далёкие времена так пытались наладить семантику вложенных объектов. Он полностью потерял значение с появлением релейшенов. Suarea - это как раз тот дополнительный механизм контроля целостности про который вы говорили выше. У него есть недостаток - он реализован через отношения, а отношения легко рушить. Но польза от него на мой взгляд с лихвой это покрывает. Давайте кто-нибудь мне расскажет, как без гемороя выгрузить в JOSM границы Московской области, 3-4ёх входящих районов и вложенных поселений. Я понимаю, что случай очень частный, но как иначе следить за этим непростым зоопарком в отсутствии валидатора границ?
Мне нужен. Вы его сносить собрались? Это явно не случай кладротегов.
Научите - КАК вы это делаете? Вот сколько использую subarea, ни разу с этим проблем не имел. Серьёзно. Мне очень интересно, где же эти грабли, мимо которых я постоянно промахиваюсь.