Надо ли рисовать точку place внутри города с границей?

Нашёл я свой скрипт по анализу населённых пунктов, нужно его допилить для более точной статистики. Но бардак виден сходу. Буквально открыл и первая строчка отчёта:

Колпино это город или большой город?

Смотрим точку - http://www.openstreetmap.org/browse/node/60081897 place = city
Смотрим отношение - http://www.openstreetmap.org/browse/relation/337423 place = town

Как можно понять, где информация правильная а где неправильная. И такого рода неразрешимых противоречий предостаточно … Схема не должна потакать ошибкам.

Upd. Кстати, а почему “центр” Колпино расположен внутри одного из кварталов? Почему там а не на Привокзальной площади или на проспекте Ленина! Мне кажется это произвол.

А мне кажется произволом деление на town и city. В оригинале это зависит от количества жителей. Что можно брать из population. Лучше были бы человеческие gorod, poselok, selo, derevnya. И была бы схема не допускающая, почти, ошибок. А программы научить их отождествлять с town и тп не сложно

А бывает вообще смешно :slight_smile:

Город Кировск Ленинградской области:

Точка - http://www.openstreetmap.org/browse/node/246678899 Почему точка именно там - загадка. Если для навигатора то точка должна быть на дороге.

Вей http://www.openstreetmap.org/browse/way/116121865
Вей http://www.openstreetmap.org/browse/way/103783370

Отношение - http://www.openstreetmap.org/browse/relation/1430461

Как программным путём определить что есть Кировск. Ну и хорошо что нет путаницы в тегах между всеми этими 4-я элементами … Что наша схема говорит?

dr&mx, опять началась ололо-революция :slight_smile: Нынешняя схема place четко разделяет city|town по ожидаемой степени урбанизации в зависимости от совокупности признаков. Для официального статуса был какой-то тег (забыл какой именно), но он видимо никому не нужен. :slight_smile:

fserges, это подмена понятий. Вот есть какой то объект, и на нем есть некий тег, например shop=convinience. Как узнать, правильный он или неправильный? Каким образом схема тегирования магазинов (shop=*) помогает избегать ошибок?

По поводу положения центра НП. Некоторые вещи определяются методом экспертных оценок. Это не есть хорошо, но так есть. Если ты не согласен с положением центра какого-то НП, обсуди его место с тем кто его поставил. :slight_smile:

Людям нечем заняться же :3

Доктор, в тегах допустимы русские буквы. Ставьте местность=город, если хотите.

Просто действующая схема потакает такого рода ошибкам. А схема или точка или отношение с точкой в роли центр (или без точки) обладает устойчивостью. Почему вокруг Кировска 2 вея и один relation и на каждом висит place=town, name=Кировск? С точки зрения действующей схемы это всё правильно. Но как это обрабатывать автоматически?

Завтра построю таблицу по числу ошибок. Самому стало интересно, сколько косяков порождено действующей схемой.

fserges, еще раз повторю, это ни разу не проблема схемы. Ничего не мешает нагородить три вея с shop=convinience вокруг одного и того же объекта плюс точку внутри.

//Почему вокруг Кировска 2 вея и один relation и на каждом висит place=town, name=Кировск?
Это весьма интересный вопрос. Скорее всего Кировск обводили до тех пор, пока граница не заработала. У меня сейчас обрабатывается только один вариант - от Dinamik. (http://www.openstreetmap.org/browse/way/116121865) Я пока не готов ответить почему (интернет дохлый).

//Самому стало интересно, сколько косяков порождено действующей схемой.
Ошибки надо исправлять, кто спорит. :slight_smile:

Ну вот, кажется нашел.
отношение 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)

Как всегда виновата не схема, а чьи-то кривые ручки :stuck_out_tongue:

Только звери не могут понять что я не революцию затеял.

Не рисуем для навигатора!11 На центральной площади оптимально, обычно она так или иначе есть.

Ну так как у нас, osm2mp по прежнему использует addr:… исключительно с полигона?
(Мне некогда было в перловых библиотеках копаться)

Да, разумеется

Ну разумеется. Разве может быть как-то иначе?
Конечно же, это все знают, и это написано на каждом углу.
Блин.

Тогда встречный вопрос: кому нужна точка? И какие тэги там нужны, кроме place и name?

Тем, кто рисует город точкой с надписью. Собственно, это все пользователи конверсии в польский формат.

population, в основном :slight_smile:

В принципе это не единственный случай, когда один объект может быть как точкой (удобной для внесения данных), так и полигоном. Если boundary не очень подходит по политическим мотивам, можно изобрести универсальное отношение.

Например имеется существующая точка place, locality и пр. Продвинутый пользователь может нарисовать контур, можно без тегов, и создать отношение
type=outline|contour
members:
point|centre|label=[node]
outer=[way]

  • новичкам вообще про рилейшен можно не думать;
  • скачивая точку мы сразу знаем есть ли для неё обводящий контур и принимаем решение что рендерить, что нет (исключается дублирование подписей);
  • любой конвертер имеет всю нужную информацию без дублирования и разночтений.

Судя из моих наблюдений, конвертер osm2mp “кушает” теги как с полигона, так и с точки. По отображению н.п. в поиске навигатора, на картах с http://navitel.osm.rambler.ru, мы имеем 3 варианта:

  1. если теги addr:district, addr:region и т.п., есть на полигоне, а на точке они отсутствуют, н.п. корректно отображается в поиске, с указанием соответствующей информации
  2. если теги addr:district, addr:region и т.п., есть на точке, а на полигоне они отсутствуют вообще или частично, н.п. задваивается в поиске
  3. если теги addr:district, addr:region и т.п., идентичны и там, и там, см. п.1

Далее, я не знаю, какой конвертер используют конвертированные из ОСМ карты с проекта http://www.megamaps.org/, но там картина следующая

  1. если теги addr:district, addr:region и т.п., есть на полигоне, а на точке они отсутствуют, н.п. не отображается в поиске
  2. если теги addr:district, addr:region и т.п., есть на точке, а на полигоне они отсутствуют вообще, н.п. корректно отображается в поиске, с указанием соответствующей информации
  3. если теги addr:district, addr:region и т.п., есть на точке, а на полигоне они отсутствуют частично, н.п. задваивается в поиске
  4. если теги addr:district, addr:region и т.п., идентичны и там, и там, см. п.2

Спасибо за систематизацию. Вот же #@$@$ безобразие…

IMHO, проще “как есть”. Точка и полигон с одинаковыми тегами. Плюс на полигоне ещё и boundary=administrative, admin_level=8 (или какой там).

А точка всё же нужна. В навигаторе в зависимости от масшатаба отображается либо точка, либо полигон. А то, что на мапнике видны сразу и названия на полигоне, и название на точке - это косяк мапника. А может, и не косяк. Пусть будет. По крайней мере, можно визуально проверить, что название на полигоне и на точке таки присутствует, и оно одинаковое. Хотя, с другой стороны, лучше было бы, чтобы мапник проверял названия и прочие теги точки и полигона, и при их полном совпадении показывал бы только название на точке. А на полигоне либо не показывал, либо писал бы его вдоль границы полигона.

ну логично же, что если и точка, и полигон обозначают один и тот же населённый пункт, то addr:**** у них должны совпадать.
Впрочем, поскольку лёшин конвертер уже умеет автоматически привязывать населённые пункты к областям и районам просто по факту нахождения в границах области / района, то не вижу смысла в addr:**** на полигоне и точке населённых пунктов. Лишь бы границы были правильно обозначены.

Никакого