RU:Multiple values

Тег в OSM обычно состоит из одного ключа и соответствующего ему значения. Обычно этого достаточно для описания большинства объектов реального мира, но иногда полезно или, по крайней мере, очень заманчиво использовать множественные значения (MV — multiple values), относящиеся к одному ключу. Здесь мы постараемся объяснить, почему и как следует применять множественные значения.

Когда (не) нужно использовать множественные значения

Первой реакцией картографа на множественные значения должно быть желание их избегать. По большому счёту это продиктовано слабой поддержкой множественных значений потребителями данных — либо наличие множественных значений мало кто ждёт, либо их сложно обрабатывать. Так как модель данных OSM не поддерживает множественные значения напрямую, они несут в себе некоторое неудобство.

Избегайте использования MV, если...

• Ключ логически не может иметь множества значений, например: highway=primary;secondary. Такое обычно бывает, когда программа для редактирования объединяет два объекта вместе и не знает лучшего способа исправить расхождение. Разберитесь, какой класс у дороги, и укажите его.
• Существует какая-нибудь другая схема тегирования, которая описывает вещи лучше. Например recycling=glass;paper при помощи recycling:glass=yes + recycling:paper=yes. Такие схемы проще обрабатываются и более универсальны.
• Всегда пытайтесь применять семантические теги вместо объединения нескольких значений в одном. Например, используйте old_name, loc_name, short_name вместо множественных значений в name=*
• Можно обозначить предметы как отдельные объекты. Например обозначить amenity=toilets отдельно от другого объекта amenity=*, в котором он располагается.
• Второе значение описывает незначительное свойство и может быть безболезненно отброшено. Например магазин домашней утвари, в котором также есть незначительный выбор сладостей.

Используйте MV, если...

• Ни один из указанных выше пунктов не подходит, но по-прежнему необходимо указать несколько значений.
• У вас не хватает сведений, чтобы применить более подходящий тег (например если нельзя определить, является ли название вышедшим из употребления (old_name) или местным (loc_name)).

Как тегировать множественные значения

Так как OSM (до сих пор) не поддерживает множественные значения для ключей, картографы пришли к различным схемам тегирования, каждая из которых имеет свои достоинства и недостатки. Каждая из перечисленных здесь схем имеет существенную поддержку сообщества и активно применяется. Во многих случаях выбор конкретной схемы — вопрос личных предпочтений. Иногда различные подходы из разных схем тегирования применяют к одному и тому же объекту или тегу, что делать не рекомендуется.

Разделитель ";" в значении

Используйте только один ключ, значения отделяйте символом ; (точка с запятой).

За:

• Не требуется много набирать на клавиатуре.
• Достаточно легко читается.
• Имеется довольно хорошая поддержка у потребителей данных в некоторых случаях, например у ref=*.

Против:

• Не подходит для использования с ключами, значения которых могут содержать ; (точку с запятой) (предложенный способ обойти эту проблему вряд ли кем-то поддерживается).
• Способствует быстрому достижению обусловленного API предела в 255 символов.
• Потребители данных, которые не знают о таком разделителе, встретив его в значениях тега, скорее всего, получат проблемы.
• Потребители данных, которые знают о таком разделителе, должны поддерживать список ключей, допускающих использование точки с запятой.

Числовой суффикс в ключе

Теги с суффиксами name_1=* и alt_name_1=* больше не следует использовать при тегировании, поскольку они — результат операций импорта, которые были проделаны абы как.

На данный момент Редактор iD самостоятельно проставляет суффиксы в тегах, которые были введены дважды при добавлении тега напрямую, через редактор тегов. Пожалуйста, следите за этим при сохранении результатов вашего редактирования.

Для обозначения объектов с множественными значениями применяются множественные ключи, оканчивающиеся на "_1", "_2" и т. д.. Возможны вариации суффиксов: [1] или %1 или :1 или даже 1, но они встречаются реже.

За:

• Достаточно легко читается.
• Отсутствие проблем с символом ; в значении или с пределом количества символов.
• Потребители данных, которые не знают о суффиксе, просто игнорируют дополнительные значения.
• Потребители данных, которые знают о суффиксе, могут использовать несложную легко понятную реализацию для всех ключей.
• Поддерживаются ключи с пространством имён с помощью указания, какое пространство имён ключа имеет множественные значения, вместо присваивания множественного значения всему ключу целиком (например source_1:name=* описывает второй источник имени, тогда как source:name_1=* будет описывать источник второго имени).

Против:

• Более многословный подход, нежели в других схемах, не очень элегантно выглядит.
• Поддержка потребителями может быть хуже, чем у других схем (?).

Префикс "alt" у ключа

Используйте два ключа, один из которых начинается с "alt_" для обозначения "альтернативного значения".

За:

• Просто для применения и понимания.
• Очень привычно и хорошо поддерживается потребителями для name=*.
• Потребители данных, которые не знают о префиксе, просто игнорируют дополнительное значение.

Против:

• Редко применяется для прочих тегов, скорее всего, не поддерживается потребителями.
• Можно указать только одно дополнительное значение.

Схемы Ad-hoc (для решения частных случаев)

Для ряда ключей имеются другие MV-схемы, что обычно объясняется особыми требованиями. Например схема RU:Lanes — это как бы двухуровневая точка с запятой, с хорошо документированной семантикой незаполенных (пустых) значений в полях и используемая как пространство имён. А схема тегирования Seamark похожа на числовой суффикс, использующий двоеточие : как разделитель в случаях, где важен порядок следования.

Отношения

Строго говоря, это не MV-схема, но факт, что объект OSM может принадлежать к нескольким отношениям, позволяет задавать такому объекту несколько схожих свойств. Например highway=* может принадлежать нескольким маршрутам.

Подводные камни

Редактор iD неожиданно создаёт ключи с числовыми суффиксами

Редактор iD на данный момент создаёт ключи с числовыми суффиксами весьма странным образом. Из-за этого некоторые теги foo_1=* в базе данных были созданы непреднамеренно. Следите за этим при использовании редактора тегов в iD. Если вы полагаете, что тег (например foo_1=*) в базе данных появился случайно, уточните это у человека, его добавившего.

Совмещение MV-схем

Избегайте совмещения подходов из разных схем, таких как alt_name_1=* или alt_name=Foo Street;Bar Street. В этом нет необходимости, и вряд ли такое поддерживается.