Сейчас для населенных пунктов задается одна и та же информации в точке и границе, что не есть хорошо.
Есть вариант объединить их в отношение multipolygon с точкой в роли label и задавать информацию либо только в точке, либо только в отношении.
Кто что думает на этот счет?
Населённый пункт отмечается границей - чтобы работал адресный поиск внутри него, и точкой - чтобы правильно позиционировать надпись.
Выходить за рамки спецификации OGC Simple Features и изобретать конструкции “полигон, переходящий в точку” - значит, что-то поломать. 
я делал на эту тему презентацию на последнем gisconf, видео тут - https://www.youtube.com/watch?v=Fv3C_WiJ48I - рекомендую посмотреть
Любой стандарт призван структурировать данные, а дублирование информации ломает суть любого стандарта на корню.
Собственно для того в osm и были введены отношения, чтобы не допускать такого.
в итоге на стандартном стиле имеем две надписи, одна на точке, другая в геометрическом центре границы 
Добры дзень! Прапаную ў адным з выпадкаў пісаць у name на беларускай мове. Тады назвы будуць бачны на 2-х мовах адначасова.
Нет, так не стоит делать, так как это нарушит организацию данных. За отображение отвечают рендеры и подгонять данные под них не стоит.
yaugenka
Ну да - давайте поломаем нахрен OSM в отдельно взятой Беларуси. Мапсми ломает-ломает - но как то медленно и печально. А тут всё так классно - одни отношения, никакой дублирующей инфы… И никто нихрена не поймет заоодно во всем этом хозяйстве. Ах да - давайте еще так называемую “белорусскую адресацию” на релейшенах обратно замутим - ломать так уже с толком 
Прописывать одни и те же теги сотню раз, как например для реки Днепр http://www.openstreetmap.org/relation/2086905, чтобы она таки отрисовалась в навигаторах это реально классно. И веселье продолжается, когда нужно еще какой тег добавить или поправить - и пошел по кругу эту сотню линий редактировать. А, ну да, у нас же стандарт “Простые фичи”!
Хотите сказать, что вы сейчас не можете рассчитать адресное пространство для населенных пунктов, которые реально состоят из нескольких полигонов, как например Минск, если в каждой ее линии не прописать все теги?
yaugenka
Я хочу сказать что можно сколько угодно наступать на грабли, лежащие зубьями вверх - и результат будет примерно одинаковым. Что и наблюдается на протяжении существования проекта. Если Вы замутите то, что реально никем поддерживаться не будет - то этим и пользоваться никто не будет. Кстати не надо спрыгивать с начальной темы населённых пунктов на релейшены рек - если реки Вы вдруг поломаете - то будут просто бухтеть все, а вот если адреску грохнете - то можно крест тогда ставить на проекте для Беларуси
Слишком большую значимость для навигаторов взяли. osm не только для них существует и никуда не денетесь, подтянетесь, если отношения наберут силу.
Как говориться, не переводите стрелки. Не мы ломаем, а вы не справляетесь править программы должным образом в соответствии уже давно принятыми нормами на osm в этом отношении.
Вы так и не ответили на мой вопрос относительно адресного пространства населенных пунктов, которые в реальности являются мультиполигонами. Или тут такая же картина как с реками, что для таких нп все равно нужно дублировать инфу для каждой линии?
Точка ещё используется для навигации в более-менее вменяемый центр НП (в отличие от геометрического, который может попадать в лес или болото и т. п.)
yaugenka
А они и не теряли никакой силы Судя по Вашим репликам Вы не зацепили тот момент, когда адресация на релейшенах была основной схемой в Беларуси. Схема классная, но - увы больше мертва чем жива. И именно потому что напрямую работать так как со всем остальным OSM было невозможно… И дело не в навигаторах, а в полезности и возможности использования данных. И если данные будут не понятны - то будет опять Беларусь белым пятном посреди OSM, проходили уже это…
Никто и не спорит, что нужно указывать точку нп, вопрос только в целесообразности дублировании данных и в точке и в отношениях мультиполигонов и как выясняется еще и в каждой линии этих мультиполигонов.
Не думаю, что ключевые люди osm проекта на столько глупы, чтобы вводить отношения, которыми по вашим словам невозможно пользоваться.
Она и не могла быть основной, потому что до сих пор большинство нп не являются отношениями. Можете пояснить, по какой причине эта схема сейчас недееспособна?
Не прошло и 5 лет, как все напрочь забыто Если Вы чего нибудь не знаете, то это не значит что этого не было
Для того, чтобы надпись не дублировалась, нужно разнести полигон жилой застройки (landuse=residential) и полигон населённого пункта (place=hamlet) на разные объекты. Дублируются они как подпись квартала (landuse=residential с названием, в Минске можно посмотреть на примеры) и как подпись населённого пункта на точке.
Полигональный населённый пункт на рендерере не подписывается.
Чудной вы человек все-таки, mixdm. Как можно наговаривать на плохо работающую с отношениями адресацию пятилетней давности, когда отношений еще толком не было, да и сейчас 90% населенный пунктов не являются отношениями.
Необязательно дублировать всю информацию, достаточно name и place, остальное можно взять с другого члена пары точка/граница
Представьте себя на месте новых людей. Вы наткнулись на сайт openstreetmap.org, нашли знакомый нп, задумали поправить, открыли редактор - и хрен поймешь где править то надо, потому как и там и сям одно и тоже по двести раз. И то же самое с реками и остальными множественными объектами. Вот и забивают люди. А ведь от многих да понемножку и была бы наша Беларусь нормально прорисована. А так силами разработчиков только и рисуется. Печально в общем, когда нет организованности данных.
А представьте обратное.
Поправил в одном месте - не работает. Поправил в другом, опять не работает. Где находится то единственное место и тот единственный способ его правки непонятно. Потыркался, не нашел, забил.
Любителей баз данных в ОСМ бесит отсутствие четкой и фиксированной структуры данных.
На самом деле это может являться преимуществом, ибо дает гибкость.
Так машинный язык отличается от естественного.
На естественном языке одно и тоже разные люди говорят разными способами. Обычно это не препятствует общению.
А на машинном языке обычно есть единственная конструкция.
И то, в С++ нагородили десятки способов написать текст, генерирующий один и тот же код.