Беда в том, что количество границ в интересующем нас регионе исчисляется тысячами (а то и десятками тысяч), а потому каждый день какая-то часть из них оказывается поломанными - сегодня одни, завтра - другие.
В результате при отсутствии некоторой избыточности будет происходить потеря данных.
В базе всегда содержится некоторое количество ошибок, и избыточность нужна именно для того, чтобы эти ошибки не приводили к потере данных.
В OSM данных должно быть столько, чтобы прикладной софт мог обеспечивать на выходе работоспособный продукт и при наличии ошибок (которые, как ни прискорбно, не только “нужно исправлять”, но которые еще и регулярно появляются).
На все 100% поддерживаю.
Постоянно оказывается, что часть границ поломана, часть отсутствует, а часть - проходит не там, где должна проходить.
Кстати, пока работал валидатор по КЛАДР. ОКТМО, ОКАТО, можно было видеть, что пока в OSM присутствует менее половины нужных границ.
Да, по геометрии пока не реально и отказонеустойчиво.
Я за теги на точке (кроме name и относящихся к самой границе) и патч к osm2mp (судя по посту Baz310, как минимум один альтернативный конвертер такое понимает).
Правда place может быть мультиполигоном (а в особо редких случаях - отношением c type=boundary) и найти в нём ту единственную точку - не совсем тривиальная задача для perl-a и сырого osm-потока. Но POI же как-то ловятся 
Если какой-то конвертер умеет только одну схему маппинга, а в наличии есть эквивалентная, но другая - в большинстве случаев можно написать препроцессор, который сделает из имеющихся данных те, что хочет данная программа. Данные корёжить в базе совершенно не обязательно.