Просто действующая схема потакает такого рода ошибкам. А схема или точка или отношение с точкой в роли центр (или без точки) обладает устойчивостью. Почему вокруг Кировска 2 вея и один relation и на каждом висит place=town, name=Кировск? С точки зрения действующей схемы это всё правильно. Но как это обрабатывать автоматически?
Завтра построю таблицу по числу ошибок. Самому стало интересно, сколько косяков порождено действующей схемой.
fserges, еще раз повторю, это ни разу не проблема схемы. Ничего не мешает нагородить три вея с shop=convinience вокруг одного и того же объекта плюс точку внутри.
//Почему вокруг Кировска 2 вея и один relation и на каждом висит place=town, name=Кировск?
Это весьма интересный вопрос. Скорее всего Кировск обводили до тех пор, пока граница не заработала. У меня сейчас обрабатывается только один вариант - от Dinamik. (http://www.openstreetmap.org/browse/way/116121865) Я пока не готов ответить почему (интернет дохлый).
//Самому стало интересно, сколько косяков порождено действующей схемой.
Ошибки надо исправлять, кто спорит. 
Ну вот, кажется нашел.
отношение 1430461 не обрабатывается никак:
; ERROR: Multipolygon’s RelID=1430461 part WayID=103783335 is not closed
; ERROR: Multipolygon’s RelID=1430461 part WayID=103783370 is not closed
Вей 103783370 тоже не обрабатывается никак:
; ERROR: Area WayID=103783370 is not closed at (59.905018,30.9999802)
Как всегда виновата не схема, а чьи-то кривые ручки 
Только звери не могут понять что я не революцию затеял.
Не рисуем для навигатора!11 На центральной площади оптимально, обычно она так или иначе есть.
Ну так как у нас, osm2mp по прежнему использует addr:… исключительно с полигона?
(Мне некогда было в перловых библиотеках копаться)
Да, разумеется
Ну разумеется. Разве может быть как-то иначе?
Конечно же, это все знают, и это написано на каждом углу.
Блин.
Тогда встречный вопрос: кому нужна точка? И какие тэги там нужны, кроме place и name?
Тем, кто рисует город точкой с надписью. Собственно, это все пользователи конверсии в польский формат.
population, в основном 
В принципе это не единственный случай, когда один объект может быть как точкой (удобной для внесения данных), так и полигоном. Если boundary не очень подходит по политическим мотивам, можно изобрести универсальное отношение.
Например имеется существующая точка place, locality и пр. Продвинутый пользователь может нарисовать контур, можно без тегов, и создать отношение
type=outline|contour
members:
point|centre|label=[node]
outer=[way]
Судя из моих наблюдений, конвертер osm2mp “кушает” теги как с полигона, так и с точки. По отображению н.п. в поиске навигатора, на картах с http://navitel.osm.rambler.ru, мы имеем 3 варианта:
Далее, я не знаю, какой конвертер используют конвертированные из ОСМ карты с проекта http://www.megamaps.org/, но там картина следующая
Спасибо за систематизацию. Вот же #@$@$ безобразие…
IMHO, проще “как есть”. Точка и полигон с одинаковыми тегами. Плюс на полигоне ещё и boundary=administrative, admin_level=8 (или какой там).
А точка всё же нужна. В навигаторе в зависимости от масшатаба отображается либо точка, либо полигон. А то, что на мапнике видны сразу и названия на полигоне, и название на точке - это косяк мапника. А может, и не косяк. Пусть будет. По крайней мере, можно визуально проверить, что название на полигоне и на точке таки присутствует, и оно одинаковое. Хотя, с другой стороны, лучше было бы, чтобы мапник проверял названия и прочие теги точки и полигона, и при их полном совпадении показывал бы только название на точке. А на полигоне либо не показывал, либо писал бы его вдоль границы полигона.
ну логично же, что если и точка, и полигон обозначают один и тот же населённый пункт, то addr:**** у них должны совпадать.
Впрочем, поскольку лёшин конвертер уже умеет автоматически привязывать населённые пункты к областям и районам просто по факту нахождения в границах области / района, то не вижу смысла в addr:**** на полигоне и точке населённых пунктов. Лишь бы границы были правильно обозначены.
Никакого
А вы выгляните за рамки мапанья под лёшин конвертер.
Или на секундочку представьте, что отношение границы нечаянно поломали. Сразу область останется без НП?
Из практики. Возьмем сконвертированную вчера карту Челябинской области с проекта osm.rambler.ru. Границы районов там обозначены, а н.п., которые не имеют тегов addr, болтаются как … в проруби, имея только привязку к области. Опять же, неоднократно сталкивался с тем, что, в той же области, имеется несколько одноименных н.п. До добавления тега addr:district они, зачастую, видны, в поиске, как один н.п., а если не один, то встает проблема выбора нужного
Это в идеале, а на практике я встречал не совпадающие значения addr:district= и place=. Да и в привязке по территориальному принципу не все правильно. Например, Бижеляк (http://www.openstreetmap.org/?lat=55.594997&lon=60.728809&zoom=18&layers=M) поиск , на openstreets.org, выдает принадлежность поселка к Аргаяшскому району, а на самом деле он относится к Озерскому городскому округу, о чем есть соответствующее упоминание в уставе округа
Ну, выглянул. Вот, к примеру, конвертер для navit требует теги is_in, которые вроде уже нигде не используются. И что? Мне теперь везде is_in вместо addr:region, addr:district писать? Да ещё и на двух языках…
Поломали - надо чинить. А не “представьте, что поломали, представьте, что удалили…”. Представьте, что у вас резинка в трусах завтра лопнет - подвяжитесь заранее шнурком
А это уже косяки конвертера. Скорее всего, там старая версия конвертера. Возьмите другую карту. Вон, у меня (http://www.dimonster.w.pw/) населённые пункты чётко раскиданы по районам.
Да мало ли что может встретиться в карте, которую может править любой кому не лень. Не совпадает, не соответствует - ошибка. Исправляй.
Вон по Украине после старого импорта есть куча посёлков, где есть теги place и name на точке, а на полигоне ничего нет, кроме boundary.
А что, границами это никак не обозначить?
Определение иерархии по геометрической вложенности звучит красиво пока обсчитывать это не начнешь.
Беда в том, что количество границ в интересующем нас регионе исчисляется тысячами (а то и десятками тысяч), а потому каждый день какая-то часть из них оказывается поломанными - сегодня одни, завтра - другие.
В результате при отсутствии некоторой избыточности будет происходить потеря данных.
В базе всегда содержится некоторое количество ошибок, и избыточность нужна именно для того, чтобы эти ошибки не приводили к потере данных.
В OSM данных должно быть столько, чтобы прикладной софт мог обеспечивать на выходе работоспособный продукт и при наличии ошибок (которые, как ни прискорбно, не только “нужно исправлять”, но которые еще и регулярно появляются).