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

Не рисуем для навигатора!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.

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

отвечу цитатой из Вашего комментария к http://www.openstreetmap.org/browse/changeset/14946261

Определение иерархии по геометрической вложенности звучит красиво пока обсчитывать это не начнешь.

Беда в том, что количество границ в интересующем нас регионе исчисляется тысячами (а то и десятками тысяч), а потому каждый день какая-то часть из них оказывается поломанными - сегодня одни, завтра - другие.
В результате при отсутствии некоторой избыточности будет происходить потеря данных.
В базе всегда содержится некоторое количество ошибок, и избыточность нужна именно для того, чтобы эти ошибки не приводили к потере данных.
В OSM данных должно быть столько, чтобы прикладной софт мог обеспечивать на выходе работоспособный продукт и при наличии ошибок (которые, как ни прискорбно, не только “нужно исправлять”, но которые еще и регулярно появляются).

На все 100% поддерживаю.
Постоянно оказывается, что часть границ поломана, часть отсутствует, а часть - проходит не там, где должна проходить.

Кстати, пока работал валидатор по КЛАДР. ОКТМО, ОКАТО, можно было видеть, что пока в OSM присутствует менее половины нужных границ.

Да, по геометрии пока не реально и отказонеустойчиво.

Я за теги на точке (кроме name и относящихся к самой границе) и патч к osm2mp (судя по посту Baz310, как минимум один альтернативный конвертер такое понимает).
Правда place может быть мультиполигоном (а в особо редких случаях - отношением c type=boundary) и найти в нём ту единственную точку - не совсем тривиальная задача для perl-a и сырого osm-потока. Но POI же как-то ловятся :slight_smile:

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

Я процитирую Эцелопа из прошлого раунда обсуждения :slight_smile: