RU:OpenHistoricalMap/Tags

Тегирование OpenHistoricalMap (OHM) основано на тегировании OpenStreetMap (OSM), и поэтому практически любая стандартная практика для тегирования OSM будет применяться и к OHM.

Те, кто знаком с практикой маркировки OSM, знают, что это твердое, но не всегда обязательное руководство. Движение с толпой - самая большая гарантия успеха тегов.

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

Хотя OHM существует уже некоторое время, он постоянно развивается, и поэтому соглашения о маркировке подлежат обсуждению, что рекомендуется на вкладке Обсуждения этой страницы или на любом из наших различных онлайн-форумов.

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

Основополагающии теги OHM

Foundational OHM Tags

Даты: требуются для рендеринга

Dates: Required for Rendering

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

• start_date=ГГГГ-ММ-ДД; ГГГГ-ММ; ГГГГ - это ДОЛЖНО быть в одном из этих форматов.
• конечная дата=ГГГГ-ММ-ДД; ГГГГ-ММ; ГГГГ - то же, что и для начальной даты.

Это часть даты расширенного формата ISO 8601-01.

Использование только окончание даты или старт даты

Using only end_date or start_date

Если вы включите только end_date=*, ваш объект будет отображаться с начала времен до этой даты. И наоборот, большинство созданных человеком вещей, которые все еще существуют, будут просто иметь start_date=* . Попробуйте установить некоторые границы для обоих, когда это возможно. Если вы не можете добиться точности, оставьте заметку или тег описания, в котором обсуждается проблема.

Даты в формате ЕДТФ

EDTF format dates

В настоящее время OHM поддерживает часть даты в расширенном формате, совместимом с ISO 8601. В будущем мы планируем поддерживать расширенный формат даты и времени Библиотеки Конгресса (профиль ISO 8601-01 и -02), который позволит использовать такую терминологию, как "около", "около", "около" и другие более тонкие форматы даты. Если вы хотите использовать этот стиль дат, пожалуйста, добавьте 2 тега - end_date=* дата для использования механизмом векторной визуализации и end_date_edtf=* для дат в формате EDTF. Аналогично, используйте start_date_edtf=* для начальных дат в формате EDTF. Простых форматов интервалов с использованием символа "/" будет достаточно, чтобы показать границу того, что известно.

Использование пространства имён

Use of Namespaces

Пространства имен - это концепция, унаследованная от OSM, с которой многие могут быть не очень знакомы. Тег может содержать символ ':', а в пространствах имен он используется для отделения префикса (пространства имен) от суффикса (определенного тега в пространстве имен).

Пространства имен можно использовать для экспериментального тегирования. В OSM есть активные способы использования, где пространство имен ohm: указывает теги, которые ссылаются из OSM на OHM. В OHM проводится эксперимент, описывающий военные передвижения на поле битвы при Антитаме, и экспериментальные теги помещаются в пространство имен ephem: (эфемерное). Было бы разумно создать пространство имен mil: или с аналогичным именем для экспериментов. Основными причинами этого являются предотвращение столкновений и упрощение поиска помеченных объектов в поиске.

Требование сообщества

OHM Community Requirements

Все эти теги попадают в категорию того, что работает сейчас. Следующие теги следует рассматривать как минимум для обеспечения полноценного взаимодействия и совместного картографирования, а также для обеспечения достоверности, необходимой для исторической достоверности. Эти теги должны быть в состоянии помочь другим пользователям быстро определить, откуда взялись трассировки карты, и обеспечить основу для разговора о сопоставлении этого poi, пути или отношения. Без этих тегов другой член сообщества OHM, скорее всего, предложит вам добавить их в свою работу.

name=* - самый простой идентификатор из всех! То же, что OSM. источник= https://yoursource.org - пожалуйста, просто используйте URL в качестве источника ваших данных. В идеале это указатель на изображение старой карты или набора данных или какая-либо другая проверяемая ссылка на то, что вы отображаете. источник: name=* - это просто любое текстовое описание URL-адреса. например, "Карта сокровищ Фелпса 1861 года" лицензия=* - без этого тега предполагается, что лицензия CC0. Если вы импортируете данные из сторонних источников, пожалуйста, не забудьте пометить все соответствующие объекты (например, точки доступа, но не непомеченные узлы / вершины) соответствующей лицензией. Кроме того, настоятельно рекомендуется использовать следующие теги, чтобы обеспечить подключение к другим источникам данных через Интернет и сделать данные карты OHM доступными для других.

википедия = * - они предоставляют справочную информацию для инспектора. wikidata=* - это критично для открытых запросов данных OHM. источник: wms=* - это позволяет другому редактору продолжить сопоставление с тем же источником, который вы сопоставили, просто введя этот URL-адрес в iD или JOSM. Следующие теги нуждаются в разъяснении того, как их лучше всего использовать, но также обогатят представление данных об OHM.

Модификаторы даты: as_of=*, construction_start=* - не все имеет четко определенную дату "начала". Многие строительные проекты заняли годы. Другие особенности определить сложнее. Здание может быть на карте, опубликованной в 1830 году, и не иметь известной даты начала. Итак, по состоянию на 1830 год мы знаем, что он был там. Изображения: изображение = *, изображение: дата = * - мы работаем над включением изображений в инспектор объектов. Дополнительная информация: info= * - это для предоставления ссылок на другие глубокие или богатые источники информации об этом конкретном пути. Эта информация может быть дополнительной и выходить за рамки уровня детализации в Википедии или иметь отношение к определенному периоду истории.

Отличия от OSM тегов

Differences from OSM Tagging

Что нужно иметь в виду, что отличается от OSM:

Лицензия на пометку = * вообще. Источник тегов =* на уровне объекта, а не набора изменений. Мы хотим, чтобы источник данных был как можно ближе к самим данным. И источник должен быть легко восстановим. Есть и другие области, где мы также отклоняемся от стандартных методов маркировки OSM. Если у вас есть вопросы, пожалуйста, просто задайте их на Slack или Discord.

Где отметить

Where to Tag В идеале, маркировка должна выполняться на объекте самого высокого уровня. И в этом случае родственники - ваши друзья.

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

Границы

Boundaries

Границы могут быть сложными. Вот несколько рекомендаций:

Границы лучше всего определять с помощью отношений типа=boundary и boundary=administrative с соответствующим уровнем admin_level=*. См.: Страна Орегон (1804-46), Сан-Марино (301-1150), Римская империя (106-270). Вы можете поместить теги start_date=* и end_date=* в свои отношения. Там, где это вообще возможно, не помечайте свои пути... почти вся описательная информация лучше хранится в Отношениях. Исключения могут включать теги source=* и license=* для поставщиков (если таковые имеются) вашей геометрии. Границы должны быть полностью закрыты - любые пробелы в их непрерывности и они не будут отображаться должным образом. [примечание: было бы здорово иметь границы только по суше - пожалуйста, дайте нам знать, что вы думаете.] Отношения имеют "стабильные" идентификаторы, поэтому, даже если их участники меняются, ссылки на них из сторонних систем с меньшей вероятностью будут разорваны. Вы можете сгруппировать связанные граничные отношения в супер-отношение (например, все различные границы штата Орегон с течением времени). К сожалению, граничные отношения плохо воспроизводятся, когда вы пытаетесь использовать отношения в качестве членов. Например, бесполезно пытаться создать границу из различных границ, которые определяют эту границу (например, создание "калифорнийского" суперотношения из отношений для "Калифорнийского побережья", "Границы Калифорния-Орегон 1850-", "Границы Калифорния-Невада 1866-", "Граница между Калифорнией и Аризоной 1866-", "Граница между Калифорнией и Мексикой 1850-" и "Калифорнийские острова 1850-". Тем не менее... наличие связей для этих отдельных границ * - это * то, что было бы чрезвычайно ценным для других целей. [примечание: создание отдельных границ является обременительным и не требуется ни в коем случае.] Граничные отношения должны иметь labelэлементы для правильного отображения. Позиционирование этикетки имеет значение. Итак, если у вас есть изменяющиеся границы, вы также можете со временем изменить расположение связанных меток. Смотрите здесь. Граничные отношения в идеале также включают в себя admin_centreэлемент, но если это меняется со временем, нам все равно нужно найти наилучшую практику для этого.

Известные проблемы

Несколько источников

Подумайте о создании вики-страницы в разделе проекты для вашего картографического проекта и предоставьте там подробную информацию о источниках.

Несколько изображений

Используйте обозначения image:0, image:1, ... для ссылки на должным образом лицензированные изображения

Несколько названий для одного пути

Используйте отношения для абстрагирования метаданных из геометрии

Предварительные соглашения об пометке OHM

Эти теги являются общепринятыми, но потенциально могут быть улучшены / изменены.

Экспериментальные соглашения об пометке OHM=

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

Импорт набора данных (предлагается)

Импорт поощряется в OHM, в отличие от OSM, где к нему относятся (мудро!) с осторожностью. Однако импортируемые данные в OHM должны быть помечены соответствующим образом, чтобы восстановить любые потенциальные изменения в этих данных, которые могут потребоваться для сбора для возможных улучшений в исходном наборе данных, или для правильной обработки требований к цитированию (например, при лицензировании CC-BY импортированного набора данных.

dataset=* (предлагается) - это помогло бы объединить и связать воедино все связанные объекты OSM для конкретного импорта. Это должен быть какой-то уникальный идентификатор для определенного источника, данных и пользователя, управляющего импортом. например, "sea_his_soc_2024_02_29_jeff-Мейер" или, может быть, даже что-то более краткое. цитирование=* (предлагается) - для включения ссылки на источник данных на карте

Предоставление сведений в исторических дорожных сетях

Было опробовано несколько различных подходов.

отображение только сегментов дорог, которые больше не существуют, оставляя OSM для представления сегментов, которые все еще присутствуют. это имеет некоторые ограничения, поскольку в настоящее время не существует общепринятого способа связи между OHM и OSM, и поэтому сложно использовать данные. кроме того, если для представления отношений и концепций требуются отношения, этот подход работает неэффективно. отображение полных дорог независимо от дублирования OSM. Дублирование прискорбно, но тогда, если классификации изменились, такое дублирование, вероятно, необходимо. это упрощает построение отношений если со временем происходят изменения, которые не меняют геометрию (классификация, поверхности и т. Д.), Было предложено несколько подходов

несколько способов совместного использования узлов с разными датами тегов / начала и окончания для каждого отдельного способа. может быть сложно редактировать единственный способ, с отношениями, несущими различные теги и даты. Примером такого подхода, предложенного Леоном Карчером, является этот способ и набор отношений: [1]

Представление перемещений и формирований войск

В настоящее время это обсуждается на странице Открытая историческая карта / Проекты / Гражданская война в США

Предлагаемые теги

Открыть историческую карту / Теги / Предлагаемые/ Тег:start_date=datespec 'УСТАРЕВШИЙ' Тег: барьер = ом: военные: Проволочное препятствие Тег:date_arbitrary=да Тег:source_date=*,*,*

Связанные ссылки

Предлагаемые функции / Пространство имен даты

Обсуждение: Сравнение концепций жизненного цикла

start_date taginfo

историческая информация о тегах