User:OverQuantum/Relations

"не область ссылается на линии, а линии на область"

"вместо полигонов будут костлайны"

(c) Илья Зверев [1]

Предложение

Принадлежность объекта отношению должно быть свойством объекта, а не отношения.

В этом случае добавление/удаление объекта в отношение производится редактированием объекта, а не отношения.

Сейчас таким "отношением" уже является nature=coastline

Синтаксис

Отношения лишаются member-ов. Линии, точки и отношения получают возможность использовать relationref.

<way id="..." ...>
  <tag k="..." v="..." />
  <nd ref="..." />
  <nd ref="..." />
  <relationref ref="1050..." role="outer" pos="" />
  <relationref ref="1051..." role="inner" pos="3" />  
  <relationref ref="2030..." role="path" pos="3.1" />  
</way>

ref - идентификатор отношения

role - роль объекта в отношении, аналогично существующим ролям

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

Допускается вхождение объекта в отношение несколько раз, если роли или положение отличаются.

Контроль целостности данных

Сначала должно быть добавлено отношение, только потом другие объекты могут на него ссылаться.

Перед удалением отношения должны быть удалены все объекты, которые на него ссылаются. Циклы из отношений разрешаются также как и сейчас.

Применение в простых случаях

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

• type=street
• type=associatedStreet
• type=collection
• type=hierarchy
• type=network
• type=site
• type=public_transport+public_transport=stop_area
• type=restriction
• type=route_master

Применение в сложных случаях

• type=multipolygon и type=boundary

Все требования multipolygon применимы. Ровно 2 незамкнутые линии могут иметь общую крайнюю точку (endpoint - начало или конец линии) и т.д. Вместо существующей рекомендации правильно проставлять последовательности объектов (для целей удобства контроля целостности контуров) - рекомендация проставлять pos по условному номеру контура, все линии одного контура - одинаковый pos (в чём-то похоже на использование layer). Возможно, простановка pos усложнит потом разрезку одного контура на несколько, но это должна быть редкая задача для больших контуров, где придётся править много объектов.

• type=route - требует задания последовательности линии в маршруте, порядка остановок, а также связи stop_position и platform

Все линии в маршруте - (role=path или role="" как сейчас), pos - задаёт положение линии в маршруте. stop_position и platform - с соответствующими ролями, pos - задаёт порядок остановок в маршруте. Пара stop_position и platform, относящаяся к одной остановке, может иметь одинаковый или близкий pos для ассоциирования.

Варианты проставления pos:

1) Условные метры от начала маршрута

2) Условный порядковый номер, изначально с шагом 1 (или 10) - далее может быть дробный по мере вставления объектов между имеющимися.

Дополнения

Для упрощения рендеринга больших объектов типа береговой линии и границы стран, можно

1) Начать требовать корректно задавать направление линии или менять роль линии в отношении - если точки в линии идут по часовой стрелке для внешнего контура то role=outer;backward (или role=outer_backward), а если против часовой для внутреннего контура то role=inner;backward (или role=inner_backward).

Само отношение при этом должно быть тэгировано, так что бы было понятно, что линии должны быть направлены, например type=directed_multipolygon

2) Задавать вспомогательные точки, которые точно находится внутри внешнего контура и вне внутренних контуров - role=interior_point (или helper_point). Например, если такие точки расставлены с шагом 1 км в ~1 км от береговой линии, то для заливки даже части водного массива достаточно скачать область включающую в себя хотя бы 1 такую точку - 2х2 км или около того. Дополнительно можно сделать и точки role=exterior_point - точно лежащие вне внешнего контура.

Тэгирование

Тэги объектов никогда не переходят на отношение. Тэги отношений переходят на объекты в соответствии с ролями. Если лес нарисован через отношение multipolygon, то тэги леса должны стоять на отношении, а все тэги на линиях применимы только к ним самим (например тэг natural=water на контуре с ролью inner в multipolygon-е означет что вода внутри только этого контура и т.д.)

Новые возможности

Адресация может использовать отношение для ассоциации здания с улицей.

• Принадлежность объекта отношению улица (type=street) заменяет addr:street

• Параметр pos может использоваться для задания номера дома в улице, вместо addr:housenumber

Например, здание с адресом "Лесная, д.12 / Пивоварова д.7":

<way id="..." ...>
  ...
  <relationref ref="3050..." role="housenumber" pos="12" />
  <relationref ref="3060..." role="housenumber" pos="7" />  
</way>

Нет необходимости использовать такую схему для задания единственного адреса.

Плюсы

• Добавление/удаление объекта в отношение не требует редактирования отношения, поэтому возможно править одно и то же отношение одновременно.
• Береговые линии и границы стран легко рисуются
• Если необходимо требование направления позволяет редактировать или отрисовать часть области без ошибок.
• Решается проблема множественной адресации

Минусы

• Требуется построение обратного индекса "какие объекты в этом отношении", однако сейчас и так есть индекс - "в каких отношениях этот объект"
• Требуется простановка pos для маршрутов, значения pos менее интуитивны, чем порядок внутри списка
• Для проставления pos при разрезании улиц придётся выяснять значения pos следующего/предыдущего объекта

Альтернативный/переходный вариант

Без параметра pos="", но с сохранением существующих отношений, которые ссылаются на объекты. Вариант умножает сущности, но позволяет проще решить вопрос с маршрутами.