Boundary. Которое в случае рисования границы по официальным данным было бы, наверное, более уместно. Разумеется, не administrative, а какого-то отдельного типа.
Угу, она там упомянута. Но от этого она не становится менее избыточной.
теперешняя ситуация когда один реальный объект “населенный пункт” описывается двумя объектами: точкой и полигоном в осм еще больший не феншуй.
То, что точка label для отношения-полигона не избыточна очевидно на примере городского округа Ноябрьск, геометрический центр которого находится в болотах, далеко за пределами указанного ГО.
И это уже никакое не рисование под софт, необходимость label на указанном примере думаю очевидна, не всегда геометрический центр полигона place совпадает с общепринятым местом отображения надписи.
для Уфы центр полигона place, сколь помню, будет в лесной чаще 
Аргумент негодный, потому что есть алгоритмы, которые пишут название с учётом самых замысловатых форм, а использование геометрического центра - это прошлый век. Mapnik (я имею в виду рендерер, а не стиль), например, с этим вполне справляется:
http://www.openstreetmap.org/relation/20451#map=16/55.7921/37.7608
^^ Я бы не переоценивал возможности автоматических алгоритмов. Вот один из городов где точка центра постоянно ездит туда-сюда - Кашира. http://www.openstreetmap.org/relation/4574292 Иногда контуры бывают реально замысловатые. Вот совсем недавно отрисовывал Донской. Это официальная граница города - http://www.openstreetmap.org/relation/1440612
Это не меняет того факта, что label - это свойство, которое служит только функции отображения.
Это свойство, которое никак не мешает рендерам с хитровыдуманными алгоритмами игнорить сей label, и ставить имя там где им покажет алгоритм.
При этом рендеры, учитывающие label, будут ставить его там где указано.
универсальное решение не правда ли.
Принцип отделения данных от отображения не связан с тем, чтобы что-то не мешало рендерам. Это вопрос избыточности данных.
Конечно, это не такой уж большой грех, потому что при обработке данных его можно просто игнорировать, но речь о самом принципе.
BushmanK, опять вы со своим уставом в чужом монастыре
В осм отсутвует понятие избыточности данных, эти проблемы сброшены на импорт данных под конкретное использование.
“any tag you like” не забывайте.
а необходимость label в отношении или точки в дополнении контура place вылезает из того, что место постановки имени в общем случае не алгоритмизируемо.
Когда я агитировал где-то год назад за упрощение тегирования НП, отказ от сложноверифицируемых точек и переход только на контуры и мультиполигоны с доп.точками с ролью label (или centre, кому как нравится) в случае необходимости, мне начали доказывать почему я не прав (видите ли якобы все роутинги и рендеры от этого сломаются, хотя никаких технических причин для этого нет), но вот мы снова вернулись по сути к этому же предложению.
Потому что роль label это не часть мультиполигона.
http://wiki.openstreetmap.org/wiki/RU:Отношения_-_мультиполигон - раздел “участники” НЕ актуален, но про inner и outer там правильно сказано
https://josm.openstreetmap.de/wiki/Help/Concepts/Object#Relations - сейчас дописываю, речь в мультиполигонах только о inner и outer
- это не отказ от точек, а их использование, но в другой схеме. Предлагайте схему которая использует и мультиполигон и точки.
- Ролей label и centre не было у мультиполигонов, прочитайте описание выше.
Мультиполигоны админ границ (admin_level) с ролью label можно перетегировать на type=boundary отношения.
type=boundary - где есть не только роли “label”, но и “admin_centre” (для столиц и центров областей)
http://wiki.openstreetmap.org/wiki/Relation:boundary#Relation_members
Я считаю это стоит делать, а не ломать обработку простых мутиполигонов, которые только с inner/outer.
- Предложение было в том, что для большинства НП (более 80-90%) можно обойтись обычным полигоном или мультиполигоном без явно заданного центра, в остальных случаях можно дополнять мультиполигон точкой label (предпочтительное место для надписи) или centre (“культурный центр” упоминающийся в текущей документации). Т.е. для большинства НП это было бы именно отказом от точек. Плюсами этой схемы было бы: упрощение тегирования малых НП, избавление от дублирования надписи НП на простых рендерах и потенциальное создание полного дерева из отношений админ границы, НП и улиц с адресами.
- label де-факто устоявшийся стандарт, который используется много где, и не только маперами, но что важно и рендерами. А centre было гипотетической ролью в случае если кому-то не понравится явная направленность на рендеры роли label. Кроме того, добавление новых ролей большинство софта не ломает, ибо нормально написанная программа просто игнорирует неизвестные ей роли.
Тегруйте отношение
type=boundary
label участников не указывайте.
Роль label у мультиполигона нет. Не усложняйте предельно простую модель мультиполигона. Мультиполигон для водных массивов, лесов с дырами и прочим.
Для “центров” объектов он не рассчитан хотя бы просто по описанию вики.
А 10-20% данных программам нужно выкидывать или обрабатывать те самые точки “label” как специальный случай? Никуда они не делись для обработки “админ. делений”.
Не указывайте мне что делать и не скажу куда вам идти.
В общем, обсуждать эту тему далее, тем более с вами, я не желаю. Прошлого обсуждения данного вопроса и предыдущего общения с вами мне хватит.
Суть первого поста была в том, что на мой взгляд текущая схема с дублированием явное legacy, от которого сложно, но необходимо постепенно переходить. (например, на отношение type=boundary; boundary=settlment) Если кто-то с доступом на вики оформит подобный переход в пропозал, то я его обязательно поддержу.
newpavlov вы демагог, я предложил схему обозначения “простых НП без явного центра”:
но вы решили подать это “приказы кому и что делать”.
newpavlov ваши высказывания неприемлимы и не относятся к теме “Контуры НП: рисование под валидатор или реальные границы”
http://wiki.openstreetmap.org/wiki/Etiquette
fserges вообще не упоминал ни мультиполигоны и boundary отношения.
Перепринимать их только потому что newpavlov не сподобился прочитать wiki? И ещё тыкает кому и что делать и говорить?!
Поддерживаю type=boundary отношения и “label” роль у них.
Мультиполигоны пусть будут простыми, без “центров” и “столиц”, т.е. ставить admin_level=* нужно на type=boundary отношения, а не мультиполигоны.
Также стоит указывать boundary=administrative у действительно административных границ.
Другие границы нужно уточнять ключом boundary=*:
http://wiki.openstreetmap.org/wiki/Key:boundary http://wiki.openstreetmap.org/wiki/Boundaries
pfg21, а с каких это пор “монастырь” тут стал чей-то, чтобы быть мне “чужим”? Ерунду пишете.
Аргумент об избыточности той или иной схемы используется в обсуждениях новых тегов постоянно (где он применим), отсутствие избыточности является хорошим тоном в схеме любой БД (которой, по случаю, является OSM).
Ну и в любом случае, это не главное противоречие label, главное касается принципа отделения данных от отображения.