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

fserges · 2011-07-06T14:58:24.000Z

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

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

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

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

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

dr_mx · 2011-07-06T15:22:38.000Z

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

fserges · 2011-07-06T15:46:42.000Z

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

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

Точка - 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-я элементами … Что наша схема говорит?

Zkir · 2011-07-06T16:01:52.000Z

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

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

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

Hind · 2011-07-06T16:06:20.000Z

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

Чернусь:

Если же ты хочешь революцию,
В этом деле я с тобою не друган:
В мирное русло направь поллюцию,
Дело получше найди рукам!

Zverik · 2011-07-06T16:16:41.000Z

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

fserges · 2011-07-06T16:21:26.000Z

Zkir:

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

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

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

Zkir · 2011-07-06T16:44:10.000Z

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

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

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

Zkir · 2011-07-06T16:51:15.000Z

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

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

dr_mx · 2011-07-06T17:14:01.000Z

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

gps-Max · 2011-07-06T19:26:45.000Z

fserges:

Если для навигатора то точка должна быть на дороге.

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

akks · 2013-02-13T08:53:55.000Z

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

liosha · 2013-02-13T09:46:03.000Z

akks:

Ну так как у нас, osm2mp по прежнему использует addr:… исключительно с полигона?

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

esaulenka · 2013-02-13T10:12:17.000Z

liosha:

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

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

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

Zkir · 2013-02-13T10:16:05.000Z

Тогда встречный вопрос: кому нужна точка?

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

И какие тэги там нужны, кроме place и name?

population, в основном

chnav · 2013-02-13T10:25:08.000Z

wowik:

VikDD:

chnav:

А что если полигоны place постепенно заменить на relation type=admin_boundary в случае если административные границы известны, либо type=place если нарисованы на глазок ? Соответственно атрибуты будут браться из точечного admin_centre, и не будет дублирования информации.

Тогда не на точку, а на отношение надо вешать все теги.

Вот кол, вот мочало…
Точку нп любой новичок нарисует и поправит.
Всё просто и наглядно.
Проще редактировать, проще использовать.

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

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

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

Baz310 · 2013-02-13T11:08:54.000Z

akks:

Так как оно, теги-то по прежнему только с place кушает? (код osm2mp же чуть ли не каждый день исправляется, т.е. жив)) )
Ответ в тему http://forum.openstreetmap.org/viewtopic.php?id=12892 , пжалста

Судя из моих наблюдений, конвертер 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

akks · 2013-02-13T11:49:54.000Z

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

dimonster · 2013-02-13T12:52:57.000Z

Продвинутый пользователь может нарисовать контур, можно без тегов, и создать отношение

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

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

если теги addr:district, addr:region и т.п.,

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

liosha · 2013-02-13T12:54:47.000Z

dimonster:

Плюс на полигоне ещё и boundary=administrative, admin_level=8 (или какой там).

Никакого