Спадар yaugenka, я цалкам згодны з Вамі наконт недасканаласьці дубляваньня і некатогых варыянтаў тэгаваньня. Але таксама ня трэба рабіць закіды ў бок распрацоўшчыкаў.
Калі ўзяць варыянт, што дадзеныя осм трапляюць у postgres+postgis, які ведае па сутнасьці толькі геаметрыю і спасылкі, але ня ведае што такое палігон+кропка цэнтару+кропка для надпісу, то зьяўляецца адзіна з прычынаў заганнай схемы - адсутнасьць апрацоўкі сэмантыкі, якая можа на сабе ўзяць дубляваньне тэгаў ў кропакі.
Другое пытаньне рэдактараў, якія таксама ня дужа могуць быць прыстасаваны для працы з больш сэмантычна складанымі аб’ектамі, то бок толькі што прыйшоўшаму чалавеку таксама будзе не зразумелы сэмантычна складаны аб’екта як і дубляваньне тэгаў, калі толькі гэтая скалданасьць не будзе апрацоўвацца рэдактарам.
То бок каб зрабіць схему лепш, то трэба мець добры плян як перайсьці на яе, а то зараз выглядае аднабакова.
Даже представить себе не могу, как можно не заметить, что линия или точка (особенно без тегов) входит в состав отношения. А вот догадаться, что где-то еще нужно продублировать - реальная сложность.
А если все-таки принять истину, что OSM НЕ соответствует стандарту OGC? OSM это склад бревен, который каждый может подогнать под нужный ему формат перед использованием, а не лепить дом из необтесанного.
Это от редактора зависит. В потлатче1 с отношениями ой как не просто.
А ежели редактор уже понимает, что точка и граница относятся к одному и тому же, и дает редактировать как нечто целое, то пользователю уже фиолетово, как эта парочки реализована, отношением или нет, с дубляжом или как.
А кто-то еще пользуется полтач1? Даже полтач2 отошел на второй план, когда ид появился. И ни один редактор не будет искать связь между несвязанными в отношение элементами, и навряд ли будет дублировать данные из одного элемента в другой.
Можа не адпавядаць і падагнаць можна, але вырашаць пераход на новую схему павінна суполка для якой трэба добра абгрунтаваць сваю прапанову, каб пазьбегнуць таго што кожан будзе мапіць пад сябе. Вы ж разумееце што напэўна амаль кожны хто сутыкаўся з гэтым дагэтуль меў падобныя пытаньні, і хто сутыкаўся з большага разумее плюсы і мінусы схемы, і такія прапановы зусім ня новыя.
Кто-то использует мапсми. Там пока НП еще не правят, но там пользователь в принципе ничего не знает о веях и релейшенах.
С его руки есть объекты, а как они утроены он и не представляет.
Граница города Минск обозначена отношением и не все ее линии имеют теги говорящие об их связи с этим нп.
Для столицы расчет адресного пространства идет по какому-то особому способу неприменимому к другим нп?
Мультиполигон и простой площадной объект логически взаимозаменяемые вещи. Можно и деревню мультиполигоном обозначить, можно столицу одним объектом. Но с большими границами чисто механически удобнее работать когда они оформлены отношениями.
Линии мультиполигона не обязаны иметь никаких тегов, достаточно того что они входят в отношение. Считайте, что теги отношения распространяются на все его члены.
Точно так же, как точка “остановка” - член отношения “маршрут автобуса №123” - является остановкой автобуса №123, хотя на самой точке это не указано. Теперь если в отношении маршрут 123 переименовать в 124, все остановки автоматически остаются актуальными. А без отношений нам пришлось бы вручную обновлять теги на всех затронутых остановках.
Осталось только дождаться, когда существующую программы будут поддерживать отношения нормально, отношения населенных пунктов в частности, чтобы название выводилось в точке label, но значение бралось из отношения.
Еще один очень важный моментом хранения всех тегов именно в отношении - это история. Только при таком подходе вся история нп будет собираться в одном объекте, включая изменение тегов, геометрию границ и расположение точки label.
Какие именно программы по Вашему мнению не делают это нормально, и что значит нормально?
Странно, отношения с тех пор и не поменялись :). И адресация эта не была “плохо работающей”. Просто была другой, не такой как у всех. И если сейчас сделать опять что то, что будет только у нас - то результат будет точно такой же.
P.S. Вообще то простым пользователям абсолютно всё равно, как там устроено внутри. Главное что бы то, что они хотят получить от проекта - соответствовало их ожиданиям. Не будет соответствовать - будут использовать другие проекты, благо чем дальше - тем конкуренция будет жестче…
mixdm, а можете более предметно пояснить, какие вы видите недостатки в том, чтобы прописывать теги только в отношении и не дублировать их в точке? Понятное дело, что сейчас ни редакторы, ни мапник не могут такое правильно обработать. Но в целом чем схема не может быть рабочей то?
yaugenka, количество софта, который придётся изменить, переваливает за несколько десятков программ на разных языках программирования. Архитектурно очень мало где заложена возможность использования косвенных ссылок, так что это не тривиальное изменение.
Сколько лет назад на OSM ввели понятие отношений? И отменять не собираются. А разработчики ПО до сих пор упираются. Кто быстрее перестроится тот и окажется впереди. Но естественно понадобится не один, чтобы все согласованно заработало.
Впереди телеги ?
уж столько, сколько Komяpa в теме OSM - он для Вас авторитетный источник информации по этой теме? Вам пытаются сказать, что ломать ничего нельзя пока данные в этом виде восстребованы и налажена их обработка. Надо Вам отношения ради отношений - лепите, чёрт с ними Только всё что есть сейчас не ломайте. Просто если для Вас OSM это просто цацка, то не забывайте о том, что некоторые используют его в своей работе, и для них будет критично когда все перестанет работать…
?