Вопрос относительно subarea. Насколько данная роль важна, кто её использует? Для валидатора это избыточные данные и анализировать их я не собираюсь. Проверяются ли subarea кем-нибудь?
Subarea, например, используются в Кемеровской области - http://www.openstreetmap.org/browse/relation/144763
Ещё вопрос - насколько является анахронизмом расстановка admin_level на линии? Очевидно что это приводит к ошибкам типа таких:
Более общо, почему считается нормальным на линии границ, входящих в отношения границ и не являющимися самостоятельными объектами (реками, дорогами и т.п.), принято ставить теги boundary=administrative и admin_level=n, где n — минимальное значение admin_level от всех отношений, содержащий эту линию? Простановка admin_level здесь представляет некий произвол.
Ну и туда до кучи. Является ли такая точка правильно оттегированной?
А такого добра у нас просто навалом …
Лично я не знаю где ещё используется admin_level за исключением границ АТМ.
admin_level = 3
name = Елань
place = village
ИМХО это полная ересь и подлежит сжиганию.
Ну а рассчитывать на addr:country=RU не стоит. Да и 90% НП можно быстро проверить по вписанному боксу в Россию.
Ну можно не расссчитывать а просто взять и проставить 
Только определиться как правильно.
90%? Наверно да. Но почему бы не упростить жизнь пользователям карт? Чем прозрачнее будет схема данных тем удобнее будет писать что-то на основе ОСМ тем больше приток нормальных пользователей. Зачем лезть в геометрию страны (что не совсем тривиальная и не всегда быстрая задача) если информацию можно получить из данных. Ведь далеко не все используют planet.osm а довольствуются огрызками интересующих их конкретно. А в какую-нибудь Брянскую или Оренбургскую область влезает куча иностранных мунициальных образований и населённых пунктов … Избыточность для ОСМ это не зло, главное в этом - чувство меры Конкретно я сейчас напишу пост-обработку отбраковывающие огрызки границ объектов административно-территориального деления других стран но разумнее упрощать жизнь не разработчикам валидаторов, которые рассчитывают на самое худшее а жизнь потенциальных пользователей, возможно и из других стран.
Т.к. это не правило, то рассчитывать и делать на это упор глупо, даже если ты их будешь раз в неделю проставлять. Плюс появится куча противников автоматических правок.
Противники найдутся против любых правок В ОСМ делает тот кто делает. Мне вот не нравится вот такой вот полигон Чукотского АО - http://www.openstreetmap.org/browse/relation/151231 но раз его создали таким то наверное иначе появляются проблемы … Поэтому я не собираюсь его приводить в нормальный вид, это будет попахивать вандализмом, хотя геометрически он неверен так как создаётся несуществующая граница внутри региона. Аналогично выглядит и Иультинский район - http://www.openstreetmap.org/browse/relation/1949881 . Но это не значит что нужно создавать как можно больше проблем тех кто захочет распарсить данные из ОСМ Система дружественная пользователю не ценит хардкор.
Одна из задач валидаторов (на мой взгляд) унификация в том числе и тэгов. Поэтому я думаю, что приводить к какому-нибудь единому стандарту всё же правильно, чем не правильно. (это по вопросу про полигоны Чукотского АО)
Из описания будущего я не совсем понял в нём деревни будут? Или только границы мун обр?
fserges хочу обратить твоё внимание на одну просто грандиознейшую проблему предыдущего валидатора это отсутствие возможности править деревни. Т.е. например в Костромской области вместо 3,5к деревень было 1,5к всего.
Я тоже пробовал сделать сей валидатор. Но поскольку я не программист, то всё остановилось как только понадобилось чуточку кода написать.
Суть: Имеется файл с перечнем деревень (к примеру обработанный http://www.adm.yar.ru/duma/zased/090929/z_09_053p.doc ) и преобразованный в csv , потом с помощью osmfilter и osmconvert добился на основе выгрузки гислаба (т.к. не пробовал на всём мире) получил с такими же полями другой csv . И в общем-то оставалось сравнить два csv файла (читай две таблички) .
Логичным продолжением данного пункта после отсутствия деревень и отдельным от этого… поиск “нелогичностей” к примеру addr:district один, но находится в полигоне другого и т.д. деревни без полного addr:* . Так же деревни без полигона и полигон без точки.
Т.е. я хотел бы видеть активную возможность вносить изменения в валидатор. как например в валидатор Scaurr0ck’а. Плюс возможно часть функционала наличия/отсутствия деревень по дифам. Возможно даже БД с деревнями вручную подготовленными для валидатора, а не фиас или окато.
Прежде чем чего-то рекламировать нужно это сделать. Поэтому ближе к альфе обсужу вопросы детальнее.
Так или иначе эта проблема всплывёт, в зависимости от масштаба бедствия будем принимать решение. Хочется максимально соответствовать официальным документам а если отклоняться то тоже пользуясь достоверными источниками. К слову, в моей БД 3016 деревень в Костромской области.
А пока я осилил импорт файла OSM. Обработка 315 миллионов строк (24 гигабайта) занимает 108 минут + постобработка. Не так страшно как думал изначально хотя утром вряд ли я смогу запускать полную процедуру. Теоретически что-то можно анализировать уже и сейчас (без анализа геометрии), но я сейчас хочу наладить проверку хотя бы базисной геометрии. А вот с более сложной геометрией придётся повозиться, с ней я ещё ни разу сталкивался и отнимет это непредсказуемое время так как помимо ОСМ есть ещё куча всяких дел.
Если везде использовать subarea, то дёргание любого куска границы России может привести к вытягиванию всего АТД.
Это нужно для рендеринга, и пусть лучше так, чем огрести из-за того, что в нужную кому-то вырезку планеты входит не вся граница России.
fserges, советую не изобретать с нуля велосипед, а работать с данными, загруженными в базу PostGIS. Это гораздо быстрее и эффективнее.
Это точно связано с границей Россией? Я вот вижу такое образование и в Московской области. Если “России” это опечатка то замечание другое - если какой-то тег используется на 20% объектах а на 80% не используется то ценность этого тега минимальна. Или нафиг его совсем или уже проставить по всем 100% объектов.
Вдаваться в эти детали не буду, может и так. Но замечено что старые костыли уже часто не нужны, ведь тулы улучшаются, может это такой же костыль который когда-то был важен а сейчас он ничего не значит? Во всяком случае в выборке я встречал весьма кривые обозначения но граница не валилась.
Ну для этого нужно знать что такое PostGIS Изучение SQL и PostGIS боюсь займёт у меня гораздо больше времени нежели решение частной задачи не оптимальным образом. А если в PostGIS эта задача делается легко - почему её так никто и не осилил? Задачка то несложная - загрузить границы, проверить замкнутость/самопересечение контуров, проверить пересечение границ разных объектов, сверить получившийся список объектов с эталонным справочником, выдать отчёт в HTML …
Я чего-то не понимаю или роли inner/outer уже не используются? То есть можно писать всё подряд но софт должен сам догадаться что и как?
Здесь точно нет ошибки? - смесь outer, inner, пустой роли в одном валидном контуре … Или это глюк JOSM-а?
Одинцовский район как отношение - http://www.openstreetmap.org/browse/relation/181346
дефолтная роль outer
Не является никаким анахронизмом, это важная и нужная фича. Это используется для рендеринга. Такой вей можно сразу рисовать линией границы в соответствии с admin_level а не востанавливать мультполигоны из релейшенов.
Ну тогда и такие объекты должны проверяться:
На inner/outer полагаться не стоит, дефолтной роли в мультиполигонах нет.
Никаких обязательных тегов в осм ввести нельзя. Все теги сугубо добровольные.
тег is_in=RU наверно можно поставить на все релейшены АТД силами одного человека. Но ведь расставить мало - нужно следить за его наличием и правильностью 
Скажем так, могут проверяться
Вот-вот. Почему-то многие считают что могут однократной правкой всех осчастливить.
Использовать всякие суррогаты типа is_in вместо геометрических проверок - это тупиковый путь, от него уже давно отказались, смысла опять его реанимировать немного.