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

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:**** на полигоне и точке населённых пунктов. Лишь бы границы были правильно обозначены.

Никакого

А вы выгляните за рамки мапанья под лёшин конвертер. :slight_smile:
Или на секундочку представьте, что отношение границы нечаянно поломали. Сразу область останется без НП?

Из практики. Возьмем сконвертированную вчера карту Челябинской области с проекта 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 писать? Да ещё и на двух языках…

Поломали - надо чинить. А не “представьте, что поломали, представьте, что удалили…”. Представьте, что у вас резинка в трусах завтра лопнет - подвяжитесь заранее шнурком :slight_smile:

А это уже косяки конвертера. Скорее всего, там старая версия конвертера. Возьмите другую карту. Вон, у меня (http://www.dimonster.w.pw/) населённые пункты чётко раскиданы по районам.

Да мало ли что может встретиться в карте, которую может править любой кому не лень. Не совпадает, не соответствует - ошибка. Исправляй.
Вон по Украине после старого импорта есть куча посёлков, где есть теги place и name на точке, а на полигоне ничего нет, кроме boundary.

А что, границами это никак не обозначить?