Дублирование информации о населенном пункте в точке и территории

А кто-то еще пользуется полтач1? Даже полтач2 отошел на второй план, когда ид появился. И ни один редактор не будет искать связь между несвязанными в отношение элементами, и навряд ли будет дублировать данные из одного элемента в другой.

Можа не адпавядаць і падагнаць можна, але вырашаць пераход на новую схему павінна суполка для якой трэба добра абгрунтаваць сваю прапанову, каб пазьбегнуць таго што кожан будзе мапіць пад сябе. Вы ж разумееце што напэўна амаль кожны хто сутыкаўся з гэтым дагэтуль меў падобныя пытаньні, і хто сутыкаўся з большага разумее плюсы і мінусы схемы, і такія прапановы зусім ня новыя.

Кто-то использует мапсми. Там пока НП еще не правят, но там пользователь в принципе ничего не знает о веях и релейшенах.
С его руки есть объекты, а как они утроены он и не представляет.

Граница города Минск обозначена отношением и не все ее линии имеют теги говорящие об их связи с этим нп.
Для столицы расчет адресного пространства идет по какому-то особому способу неприменимому к другим нп?

Мультиполигон и простой площадной объект логически взаимозаменяемые вещи. Можно и деревню мультиполигоном обозначить, можно столицу одним объектом. Но с большими границами чисто механически удобнее работать когда они оформлены отношениями.

Линии мультиполигона не обязаны иметь никаких тегов, достаточно того что они входят в отношение. Считайте, что теги отношения распространяются на все его члены.

Почему тогда это не может быть применимо к точке label?

Применимо.

Точно так же, как точка “остановка” - член отношения “маршрут автобуса №123” - является остановкой автобуса №123, хотя на самой точке это не указано. Теперь если в отношении маршрут 123 переименовать в 124, все остановки автоматически остаются актуальными. А без отношений нам пришлось бы вручную обновлять теги на всех затронутых остановках.

Осталось только дождаться, когда существующую программы будут поддерживать отношения нормально, отношения населенных пунктов в частности, чтобы название выводилось в точке label, но значение бралось из отношения.

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

Какие именно программы по Вашему мнению не делают это нормально, и что значит нормально?

Странно, отношения с тех пор и не поменялись :). И адресация эта не была “плохо работающей”. Просто была другой, не такой как у всех. И если сейчас сделать опять что то, что будет только у нас - то результат будет точно такой же.
P.S. Вообще то простым пользователям абсолютно всё равно, как там устроено внутри. Главное что бы то, что они хотят получить от проекта - соответствовало их ожиданиям. Не будет соответствовать - будут использовать другие проекты, благо чем дальше - тем конкуренция будет жестче…

Зачем изобретать велосипед?

Велосипед изобретать не надо, да вот только пока на двух колесах без рамы ездим. :slight_smile:

mixdm, а можете более предметно пояснить, какие вы видите недостатки в том, чтобы прописывать теги только в отношении и не дублировать их в точке? Понятное дело, что сейчас ни редакторы, ни мапник не могут такое правильно обработать. Но в целом чем схема не может быть рабочей то?

yaugenka, количество софта, который придётся изменить, переваливает за несколько десятков программ на разных языках программирования. Архитектурно очень мало где заложена возможность использования косвенных ссылок, так что это не тривиальное изменение.

Сколько лет назад на OSM ввели понятие отношений? И отменять не собираются. А разработчики ПО до сих пор упираются. Кто быстрее перестроится тот и окажется впереди. Но естественно понадобится не один, чтобы все согласованно заработало.

Впереди телеги :slight_smile: ?
уж столько, сколько Komяpa в теме OSM - он для Вас авторитетный источник информации по этой теме? Вам пытаются сказать, что ломать ничего нельзя пока данные в этом виде восстребованы и налажена их обработка. Надо Вам отношения ради отношений - лепите, чёрт с ними :slight_smile: Только всё что есть сейчас не ломайте. Просто если для Вас OSM это просто цацка, то не забывайте о том, что некоторые используют его в своей работе, и для них будет критично когда все перестанет работать…

mixdm,
+100500 :slight_smile:

Так уж мир устроен, что упряжи без лошади не бывает. Только лошадь может еще на воле резвиться, а телега либо плетется следом, либо стоит колом :slight_smile:

Печально, очень печально слышать такие фразы.
А ведь тема эта возникала неспроста. Буквально за последний месяц порядка тысячи населенных пунктов (не сто и не пятьсот, а тысячу!) перевести в урочище или иной статус. И пришлось делать это практически дважды.

Значит надо было начинать с подбора/создания инструмента, который бы работал с парой.

Само по себе это не произойдет, надо писать какие-то там пропозалы, голосовать, и судя по этому топику шансов мало