Нужен бот, который следит за отношениями?
наверное это должно быть актуально в свете недавнего переименования номеров дорог: меняем вручную номер в отношении, а бот правит по всем дорогам, в него входящих
также если улицы/дома собраны в отношение можно исправлять случайные ошибки в названиях
Лучше всё же не исправлять, а выдавать лог, а там уже смотреть кто что наменял и где истина.
Движемся к патрулированию. http://ru.wikipedia.org/wiki/%D0%92%D0%B8%D0%BA%D0%B8%D0%BF%D0%B5%D0%B4%D0%B8%D1%8F:%D0%9F%D0%90%D0%A2
Но в вики это дело захлебывается. Такое не редкость увидеть (http://ru.wikipedia.org/wiki/%D0%92%D1%81%D0%B5%D0%BC%D0%B8%D1%80%D0%BD%D1%8B%D0%B9_%D1%84%D0%BE%D0%BD%D0%B4_%D0%B4%D0%B8%D0%BA%D0%BE%D0%B9_%D0%BF%D1%80%D0%B8%D1%80%D0%BE%D0%B4%D1%8B)
Плохо это работает… Например, для дороги, которая сначала нарисована двумя веями, потом какая-нибудь хитрая (кольцевая, например) развязка, потом один вей - там куча разрывов образуется сама по себе.
Не надо такого. И вообще, валидаторов с одной кнопкой “исправить всё” не надо 
Оно, конечно, удобно, но очень велика вероятность, что будет только хуже 
Вот этого точно не нужно.
Автоматически исправлять не надо. К примеру, бывают “разорванные” улицы, у которых вэи не смежные. Что тут сделает бот?
Да и границы тоже лучше вручную исправлять, а не ботом.
Мне кажется нужен.
Только давайте назовём его валидатором. Очень они у Вас замечательно получаются.
И пусть он занимается проверкой, а уж решение исправлять/не исправлять, и что именно исправлять, лучше пусть принимает человек - ведь возможен вариант, что не теги на линии неправильные, а саму линию, по ошибке, определили не в то отношение.
про разрывы я и писал что можно выдавать список где в отношениях линии с разрывами, как чинить автоматом это я не очень представляю
а вот проверять и добавлять в отношения линии, править названия можно и автоматически было бы
хотя если неправильно в отношение добавят какую-нибудь, будет все попорчено 
надо попробовать для начала действительно выдать список таких ошибок, а там видно будет
+1
К тому же, бывает, что граница проходит по реке (или дороге), поэтому у линии вполне правомерно могут быть теги, не имеющие никакого отношения к отношению (уж простите за каламбур :).
я хотел менять теги на линиях, которые отличаются от тегов в отношении, возможно только заданных, например, ref, addr:street, name
если у отношения такого тега нет, то ничего и не трогаем
Еще раз: автоматическое изменение тегов недопустимо.
Похоже, я недостаточно ясно выразился.
Например, если граница проходит по реке, то одна и та же линия (way) может иметь несколько функций - обозначать как часть реки, так и часть границы. Соответственно, у линии, входящей в отношение границы, могут быть теги реки или дороги, она вообще может входить в несколько разных отношений - что же менять ее теги в соответствии с каждым из них?
Опять же, границы разного уровня имеют обыкновение совпадать. Один и тот же участок границы может принадлежать одновременно границам государства, области, района и населенного пункта. У каждой из них будет свой admin_level, т.е. попытки что-то править в линии, исходя из информации, содержащейся в одном из отношений, может вступить в конфликт с информацией, находящейся в других отношениях, куда входит эта линия.
Вообще-то перед тем, как задумываться о механической правки чего-либо, следует просто вывести в файл список того, что может подлежать правке и детально с ним разобраться. Тогда станет намного очевиднее вывод, что в подавляющем большинстве случаев механически править не следует.
Естественно, на этом “пробном” этапе следует брать весь объем данных, который предполагается обрабатывать. Провести диагностику на маленьком фрагменте, а потом запустить обработку для всего при таком подходе (если подразумевается именно правка, а не диагностика) - недопустимо. Более того, крайне желательно провести подобную проверку и на данных, для которых этот алгоритм использоваться не будет. Например, для Северной Америки. Потому что сам факт выявления каких-либо проблем в глобальном масштабе будет являться противопоказанием и для локальных прогонов алгоритма.