Нашёл я свой скрипт по анализу населённых пунктов, нужно его допилить для более точной статистики. Но бардак виден сходу. Буквально открыл и первая строчка отчёта:
Как можно понять, где информация правильная а где неправильная. И такого рода неразрешимых противоречий предостаточно … Схема не должна потакать ошибкам.
Upd. Кстати, а почему “центр” Колпино расположен внутри одного из кварталов? Почему там а не на Привокзальной площади или на проспекте Ленина! Мне кажется это произвол.
А мне кажется произволом деление на town и city. В оригинале это зависит от количества жителей. Что можно брать из population. Лучше были бы человеческие gorod, poselok, selo, derevnya. И была бы схема не допускающая, почти, ошибок. А программы научить их отождествлять с town и тп не сложно
dr&mx, опять началась ололо-революция Нынешняя схема place четко разделяет city|town по ожидаемой степени урбанизации в зависимости от совокупности признаков. Для официального статуса был какой-то тег (забыл какой именно), но он видимо никому не нужен.
fserges, это подмена понятий. Вот есть какой то объект, и на нем есть некий тег, например shop=convinience. Как узнать, правильный он или неправильный? Каким образом схема тегирования магазинов (shop=*) помогает избегать ошибок?
По поводу положения центра НП. Некоторые вещи определяются методом экспертных оценок. Это не есть хорошо, но так есть. Если ты не согласен с положением центра какого-то НП, обсуди его место с тем кто его поставил.
Просто действующая схема потакает такого рода ошибкам. А схема или точка или отношение с точкой в роли центр (или без точки) обладает устойчивостью. Почему вокруг Кировска 2 вея и один relation и на каждом висит place=town, name=Кировск? С точки зрения действующей схемы это всё правильно. Но как это обрабатывать автоматически?
Завтра построю таблицу по числу ошибок. Самому стало интересно, сколько косяков порождено действующей схемой.
fserges, еще раз повторю, это ни разу не проблема схемы. Ничего не мешает нагородить три вея с shop=convinience вокруг одного и того же объекта плюс точку внутри.
//Почему вокруг Кировска 2 вея и один relation и на каждом висит place=town, name=Кировск?
Это весьма интересный вопрос. Скорее всего Кировск обводили до тех пор, пока граница не заработала. У меня сейчас обрабатывается только один вариант - от Dinamik. (http://www.openstreetmap.org/browse/way/116121865) Я пока не готов ответить почему (интернет дохлый).
//Самому стало интересно, сколько косяков порождено действующей схемой.
Ошибки надо исправлять, кто спорит.
В принципе это не единственный случай, когда один объект может быть как точкой (удобной для внесения данных), так и полигоном. Если boundary не очень подходит по политическим мотивам, можно изобрести универсальное отношение.
Например имеется существующая точка place, locality и пр. Продвинутый пользователь может нарисовать контур, можно без тегов, и создать отношение type=outline|contour
members:
point|centre|label=[node]
outer=[way]
новичкам вообще про рилейшен можно не думать;
скачивая точку мы сразу знаем есть ли для неё обводящий контур и принимаем решение что рендерить, что нет (исключается дублирование подписей);
любой конвертер имеет всю нужную информацию без дублирования и разночтений.
Судя из моих наблюдений, конвертер osm2mp “кушает” теги как с полигона, так и с точки. По отображению н.п. в поиске навигатора, на картах с http://navitel.osm.rambler.ru, мы имеем 3 варианта:
если теги addr:district, addr:region и т.п., есть на полигоне, а на точке они отсутствуют, н.п. корректно отображается в поиске, с указанием соответствующей информации
если теги addr:district, addr:region и т.п., есть на точке, а на полигоне они отсутствуют вообще или частично, н.п. задваивается в поиске
если теги addr:district, addr:region и т.п., идентичны и там, и там, см. п.1
Далее, я не знаю, какой конвертер используют конвертированные из ОСМ карты с проекта http://www.megamaps.org/, но там картина следующая
если теги addr:district, addr:region и т.п., есть на полигоне, а на точке они отсутствуют, н.п. не отображается в поиске
если теги addr:district, addr:region и т.п., есть на точке, а на полигоне они отсутствуют вообще, н.п. корректно отображается в поиске, с указанием соответствующей информации
если теги addr:district, addr:region и т.п., есть на точке, а на полигоне они отсутствуют частично, н.п. задваивается в поиске
если теги addr:district, addr:region и т.п., идентичны и там, и там, см. п.2
IMHO, проще “как есть”. Точка и полигон с одинаковыми тегами. Плюс на полигоне ещё и boundary=administrative, admin_level=8 (или какой там).
А точка всё же нужна. В навигаторе в зависимости от масшатаба отображается либо точка, либо полигон. А то, что на мапнике видны сразу и названия на полигоне, и название на точке - это косяк мапника. А может, и не косяк. Пусть будет. По крайней мере, можно визуально проверить, что название на полигоне и на точке таки присутствует, и оно одинаковое. Хотя, с другой стороны, лучше было бы, чтобы мапник проверял названия и прочие теги точки и полигона, и при их полном совпадении показывал бы только название на точке. А на полигоне либо не показывал, либо писал бы его вдоль границы полигона.
ну логично же, что если и точка, и полигон обозначают один и тот же населённый пункт, то addr:**** у них должны совпадать.
Впрочем, поскольку лёшин конвертер уже умеет автоматически привязывать населённые пункты к областям и районам просто по факту нахождения в границах области / района, то не вижу смысла в addr:**** на полигоне и точке населённых пунктов. Лишь бы границы были правильно обозначены.