Вообще-то дубляж еще углубится.
Надо будет домик включать и в уличное отношение и в адресное.
Ну и главные вопрос: это не реинкарнация “белорусской схемы адресации” в сушеном виде?
Объясните новичку, что дом надо включить в одно отношение, чтобы адрес по улице приписать, а потом еще в одно, чтобы просто саму улицу собрать. Да, проблем нет, но так делать почти никто не станет. Это дубляж, для всех это же одно и то же. Два раза делать одну и ту же работу - собирать улицу. В лучшем случае перестанут обращать внимание на associatedStreet, ибо получится, что оно не нужно, так как уже “на адресацию не влияет”.
Если убрать рюшечки, то белорусская схема есть тоже самое. Все адресные объекты собраны членами в отношение - адресный объект более верхнего уровня.
Так беды в том не будет. «Сборка» улиц — дело десятое (чисто добровольно-опциональное, как говорится). Адресация же — первое (добровольно-принудительное). «Добровольно» — потому что адреску никто не заставляет вносить, а «принудительное» — потому, что если взялся, то делай по уму.
associatedStreet и сейчас не в полной мере влияет на адресацию (т. к. принципиально не охватывает ряд случаев). В случае успешного внедрения associated_address — функция адресации полностью будет покрываться. А за associatedStreet останется группировочная функция.
Вопрос (для меня ответ ясен) — в приоритетах и эффективности решения поставленной задачи.
Да бросьте, зачем вводить людей в заблуждение? Зачем создавать образ пугала из несостоявшейся схемы и приравнивать к ней другую по всем параметрам, на порядки более простую и не требующую каких-то особых изменений схему. Общего у них — только слово «адресация».
Всё, что касается внесения данных, «упирается» в удобство инструмента (особенно для отношений). С этой задачей великолепно справляется JOSM с плагином reltoolbox. А если Илья (Zverik) поспособствует, то процесс будет полуавтоматический вообще (как сейчас для associatedStreet).
ИМХО, надо переходить к обратной модели - когда принадлежность объекта “отношению” является свойством объекта, а не “отношения”.
Оказия вышла. Нет, так уж совпало название (похоже, автор руководствовался тем же принципом). Там у членов отношения нет ролей, что странно. Автор предложения допускает только одну адресную точку в нём. Ну а подход близкий.
Кстати, там в конце говорится об особенности, появляющейся с применением адресного отношения. Фактически получается готовая таблица всех POI, привязанных к данному адресу/адресам (в моём случае).
Гроб с покойничком летает над крестами и — тишинааа…(c)
А ведь это неспроста. Сначала были желающие покритиковать, попридираться. Это хорошо, т. к. позволяет определить слабые места, подумать над их устранением. Вырабатывается вариант, к которому явных претензий никто не предъявляет (конструктивных, старые заезженные брюзгливые пластинки — не в счёт). Далее — надо бы подумать над продвижением идеи, возможно, с какими-то дополнениями/уточнениями. Хотя бы — согласие с принципиальной верностью предлагаемого решения. И здесь наступают заветные тишина и спокойствие. «Шоу» окончено, интерес пропал.
А более подробно раскройте мысль, может быть с примерами будет понятнее.
То есть ссылку по имени улицы “addr:street” меняем на ссылку по id улицы
Проблемы решаются если принять, что building != address.
Node и way простые объекты, если бы всё было Relation, то многие проблемы решились. Запретом тегов на node и way того же самого добиться можно.
OverQuantum, tbicr, это значительные перемены (с соответствующими усилиями по внедрению и «сложностями адаптации» (ввиду «смены парадигмы») в практическом применении для вносящих данные и для обрабатывающих), на мой взгляд.
Особенно большим «подводным камнем» кажется pos, могущий принимать значения по «хитрымым принципам», различным в конкретных ситуациях и означающим разные понятия. Сугубо вспомогательные точки (чисто технического назначения) тоже внушают скепсис.
Да. Уточнил в тексте.
ИМХО, тут у вас получается умножение сущностей без необходимости - добавляется отношение “адресная точка”, в который объекты должны входить без ролей.
ИМХО, сущность “отношение” необходима только если:
Увы, но без pos я не вижу как можно сохранить type=route.
Если порядок утрамбовать в role, получается ещё хуже.
role = path:3.1
role = stop:15
role = platform:15
ИМХО “адресная точка” итак существует, где-то это явно отдельная точка, где-то нет, с вытекающими ситуациями с угловыми домами и рендеренгом name вместо адреса.
Не соглашусь, если я Вас правильно понял, так как связь через теги не является строгой, те битые связи, сложность переименования и наличие неоределённости характерны для такого типа связи. У связи по ссылке таких проблем нет, то есть сейчас отношения обладают свойствами более подходящими для связей. Поэтому не соглашусь с выводом, что отсюда вытекает правило “Relations are not Categories”.
Конечно coastline это интересно, но по объёмности геометрии они не стоят рядом с адресом или улицами.
Уже сейчас есть отношения street, waterway. На простых объектах просто всё, трудности проявляются когда объект становится довольно сложным или появляются всякого рода связи между объектами.
Собственно данное предложение вместо запрета просто наделяет way и node свойствами relation (иметь ссылки на другие объекты), стирая различие между ними.
С другой стороны - переворачивается использование, теперь линия не сможет описывать несколько объектов с общей геометрией, ибо она и есть объект.