Ko:OpenHistoricalMap/Tags
오픈히스토리컬맵 (OHM)의 태그 규정은 오픈스트리트맵(OSM)의 태그에 많은 기반을 두고 있습니다. 실제로 OSM에서 사용빈도가 낮은 태그, 가령 crop=*이나 historic=* 이하의 모든 태그는 OHM에서 훨씬 더 중요하게 사용됩니다.
다만 OHM은 OSM과는 무관한 역사 지리학적 측면, 다시 말해 날짜와 출처 (대부분 2차 출처), 그리고 해당 출처의 저작권과 저작자 표시 요구를 수용하기 위해 몇 가지 조정이 이루어졌습니다. 통상적인 지도 제작 방법을 파악하려면 OSM의 Map features 가이드와 Key:, Tag:, Relation: 이름공간의 각 문서를 출발점으로 삼으시는 것이 좋습니다. 여기서는 OHM과 관련된 세부사항을 보충해 놓았습니다.
OSM과 마찬가지로 OHM에서도 대체로 '쓰고 싶은 태그라면 뭐든지' 철학을 따르고 있으며, 위에서 정해져 내려오는 것이 아니라 실사용을 통해 커뮤니티에 좋은 아이디어가 유입될 수 있도록 하는 쪽을 선호합니다. 하지만 실질적인 제약조건도 존재하는데, 기존 데이터 소비자와의 하위 호환성 유지를 위한 오픈히스토리컬맵 홈페이지의 렌더러가 대표적입니다.
OHM은 오랫동안 사용되어 왔지만 계속해서 발전하고 있고, 여전히 해결되지 못한 문제들이 많습니다. 태그 규정에 대한 논의는 토론 페이지나 기타 소통 공간에서 진행할 수 있습니다. 이러한 발전 과정에서 '지금 구현된 기능은 무엇인가, 추후 구현될 수 있는 기능은 무엇인가, 지원했으면 좋겠지만 언제 구현될지는 불확실한 기능은 무엇인가'를 함께 생각해보는 것이 중요하겠습니다.
날짜
오픈히스토리컬맵의 지물에는 그 존재가 드러난 시점을 나타내는 start_date=* 태그가 반드시 달려야 합니다. 단, 지금 시점에서 가늠하기 어려운 자연지물의 경우에는 예외로 할 수 있습니다. 더 이상 존재하지 않는 지물일 경우, 그 지물이 사라진 시점을 나타내는 end_date=* 태그가 달려야 합니다. 이 두 태그가 없다면 지물이 지도에 표시되지 않거나, 시간 슬라이더의 시점과는 벗어난 엉뚱한 시점에 표시될 위험이 있습니다. 예컨대 end_date=* 태그는 있지만 start_date=* 태그는 없다면, 그 지물은 태초부터 사라지는 시점까지 모든 시점에 표시가 이루어집니다.
start_date=*와 end_date=*에는 날짜를 입력하는데, ISO 8601 표준에 따라 YYYY (연도 4자리), YYYY-MM (연도 4자리와 달 2자리), YYYY-MM-DD (연월일 4-2-2자리)의 형식으로 입력합니다. 출처에서 밝힌 가장 구체적인 날짜를 지정하고, 출처 이상으로 더 구체적일 필요는 없습니다. 특정 시간 단위까지 기록하거나, 'n년경', 'n세기' 등의 불확실한 날짜를 기록하려면 start_date=* / end_date=*와 더불어 start_date:edtf=* / end_date:edtf=* 태그로 해당 정보를 입력합니다. 또 시점이 불확실한 이유를 따로 적으려면 note=* 태그를 사용하면 됩니다. 향후 지도편집기와 렌더러상에서 EDTF 형식을 지원할 계획입니다.[1]
특정 지물이 실제로 나타나고 사라진 시점이 아니라, 존재가 확인되는 시점을 밝혀두는 목적에서 일부 편집자들은 as_of=*나 as_of_date=*를 사용하기도 합니다. 해당 지물이 기록 시점의 모습으로 표시된 지도 하나만을 자료로 사용할 경우에는 유용한 태그이지만, 그런 경우에도 start_date=*나 end_date=* 태그도 함께 써 주어야 한다는 사실은 변하지 않습니다. 또 그런 식의 기준 시점을 나타내려는 목적이라면 start_date:edtf=*와 end_date:edtf=*를 달아서 날짜 범위가 열려 있음을 나타낼 수 있습니다. 추후 EDTF 날짜 형식에 대한 소프트웨어 지원이 개선된다면, 특정 시점의 정보만으로 편집할 때 최적의 태그가 될 것입니다.
OHM는 날짜에 중점을 두는 방식이 OSM과 상당히 다르므로, OSM에서 OHM으로 대규모 데이터를 가져올 때 큰 장애요소로 작용할 수 있습니다.
시간에 따른 변화
현실에 당연히 존재하는 지물이라면 시간에 따라 변화하거나 위치가 옮겨지기도 합니다. 이러한 변화를 반영하기 위한 몇가지 방법은 다음과 같습니다.
- 현실의 지물이 변화한 가짓수를 따져서, 같은 위치에 겹치되 속성만 달리 하여 여러 번 매핑합니다. 이 때 그 순간 그 모습의 지물이 얼마나 존속되었는지를 나타내기 위해
start_date=*와end_date=*태그를 달아야 합니다. 그리고 모든 시간대의 지물을 하나의 연대기 (chronology) 관계로 묶어줍니다. 가장 보편적인 방법이라 볼 수 있지만 도로나 철도처럼 서로 연결된 선형 지형지물을 다룰 때에는 대단히 까다롭다는 단점이 존재합니다. - 선분(node)이나 길(way)에 대한 직접적인 태그를 자제하여 선형 정보만을 나타내도록 합니다. 그런 뒤 특정 관계에서 그 선형을 필요한 만큼 하위관계로 활용합니다. 결과적으로 하나의 선형이 여러 개의 관계에서 쓰이는 형태를 취합니다. 이 방법은 물리적 도로Minimize the number of tags on the node or way, so that it represents only the geometry. Add the feature to multiple relations, one for each kind of feature that it became. This approach is preferred when there are multiple related concepts, such as a physical road (represented by a
highway=*way) carrying an abstract route (route relation) or a boundary claim line (untagged way) forming part of a boundary relation.- Lifecycle tags or a lifecycle relation are proposed for distinguishing periods when the feature was fell into disuse etc.
- For example, there's a circular way in London's Regent's Park. Originally, it enclosed a private nursery. Later, it was home to the Royal Botanic Society. After that, it merged into the Park. Mapping each of those entities as a separate relation, with its own time intervals, enables the way itself to remain unchanged.
- 과거에는 지물을 한번만 매핑한 뒤 각 태그에 날짜 접미사를 직접 붙이자는 제안이나, 수명주기 접두사를 앞에 붙여 나타내는 방법도 있었으나 현재는 두 가지 방법 모두 구현의 어려움으로 사용되지 않습니다.
출처와 저작권
이 부분은 현재 OHM 포럼에서 더 자세히 논의되고 있습니다.
지물의 위치나 세부정보를 확인할 때 본인이 직접 관찰한 내용 외의 다른 자료를 사용할 경우, 그 출처 자료가 무엇인지를 source=* 태그로 밝혀주어야 합니다. 이때 주의할 점은 OSM에서처럼 변경집합에만 출처를 표기하는 것이 아니라, 지물 그 자체에 출처를 명시해야 합니다. 이는 무단전재를 막고 법적 위험의 여지를 없앨 뿐만 아니라, 역사 연구의 측면에서 OHM의 신뢰도를 높일 수 있습니다. 개별 지물에 태그를 지정하는 것은, 변경집합에 숨겨진 것보다 출처를 훨씬 더 쉽고 빠르게 확인할 수 있기 때문입니다.
출처의 URL 링크도 source=* 태그를 사용합니다. 여기서 URL 링크는 옛지도의 사진을 보여주는 링크, 아니면 매핑하려는 대상을 다루고 있고 확인이 가능한 참고자료 링크로 걸어두는 것이 가장 좋습니다. URL 링크만으로 출처의 정체를 명확히 알 수 없는 경우에는 source:name=* 태그를 써서 URL에 관한 설명을 적어주세요 (예: 대동여지도 (1861년) 제12첩 원본 참고). You can also set source:wms=* to the URL of the imagery layer from which the feature was traced, akin to imagery_used=* on an OSM changeset. This enables other mappers to verify the feature against the imagery layer and continue mapping the feature by plugging the URL into iD or JOSM.
If you are frequently relying on multiple sources to map features that are related by geography or theme, consider creating a project page and providing detailed citations there.
OHM data is in the public domain by default via a CC0 dedication. If you copy data wholesale from a copyrighted (but freely licensed) third-party source, you should respect its license by adding license=* and attribution=* tags to each individual feature. (It's unnecessary to add these tags to an otherwise untagged element, such as a vertex along a way.) Note that copyright law protects compilations of facts but not individual facts themselves. If you merely source a single name from a single copyrighted newspaper article, the article's copyright status is irrelevant, and you are encouraged to adhere to the default public domain status for the feature in question.
To do: resolve what to do with this section now that we have OpenHistoricalMap/Tags/source
명칭
- 주요 문서: Names
name=* 태그에는 해당 지물을 일컫는 가장 대표적인 이름으로서 현지의 언어를 사용하는 것이 일반적입니다. 여기서 현지 언어라 함은 오늘날 사용되는 언어가 아닐 수도 있다는 점에 유의해 주세요.
To do: 먼 옛날부터 '서울'로 불렸던 오늘날의 서울특별시처럼, 과거에는 단순하고 평범한 이름이었던 것이 오랜 시간이 지나 그대로 고유명사로 취급받게 된 경우도 있습니다. 이런 경우 그 두 이름을 어떻게 구분하면 좋을까요?
측정 단위
OSM 맞춤형으로 제작된 소프트웨어와의 하위호환성을 위해 태그값의 모든 길이 측정값은 별도 명시되지 않은 한 미터법을 사용하는 것으로 여깁니다. 이는 해당 지물이 미터법 이전의 것이라도 마찬가지입니다. 시대와 맞지 않거나 변환 오류가 발생하는 것을 방지하려면, 출처에서 밝힌 단위로 양을 표현하고 단위기호를 지정할 수도 있습니다.
To do: 널리 쓰인 옛 단위의 기호는 어떻게 정할까요?
외부 식별자
wikipedia=*와 image=*로 태깅한 건물의 예제해당 지물에 관한 위키데이터 항목이 있다면, 그 항목의 QID를 wikidata=* 태그로 입력해 주세요 이렇게 하면 OHM은 링크 데이터 프로젝트의 형태로 활용이 가능해집니다. 또 위키백과 항목이 있는 경우 하위호환을 위해 wikipedia=* 태그를 사용하여 위키백과의 요약문을 불러오도록 할 수 있습니다.
자유롭게 사용 가능한 이미지에 한해서 탐색기에 나타나도록 하려면 image=*와 image:date=* 태그를 사용하세요. 하나의 지물에 여러 장의 이미지를 나타내고 싶다면 image:0=*, image:1=* 등으로 순번을 붙입니다.
사생활 보호
OHM은 개인정보를 매핑하는 데 있어 제한사항을 잠정 준수합니다. 다만 출처에 따라서 주택소유자의 이름 등 일부 개인정보와 관련해 해당 정보가 오래전 옛날의 것이고, 지금까지 생존해 있지 않은 사람일 경우 민감하지 않은 정보로 취급이 가능합니다.
경계
- 주요 문서: Boundaries
행정경계는 오픈히스토리컬맵에 방문하면 가장 먼저 보게 되는 요소 중 하나입니다. 이러한 경계는 방향을 파악하고 장소를 검색하는 데 도움이 될 뿐만 아니라, 지도제작자가 특정 지역의 지도범위를 개선하면서 체계적으로 작업할 수 있도록 돕습니다.
지물의 형태
OHM은 OSM의 경계 모델을 계승하며, 경계선을 여러 개의 폴리곤으로 이루어진 하나의 지형지물로 표현합니다. 따라서 행정 구역의 경계는 type=boundary, boundary=administrative 태그가 달린 관계에 여러 개의 길(way)이 관계로 연결되어, 빈틈 없이 닫혀 있는 고리 형태로 매핑되어야 합니다. 만약 특정 길(way)이 경계 관계의 빈틈을 메꾸기 위해 임시로 그어진 것이라면, 다른 편집자가 해당 부분의 경계를 더 자세히 그을 수 있도록 fixme=* 태그로 남은 과제를 밝혀두어야 합니다. 이를테면 로마 제국의 국경선은 고대의 것으로 명확하지 않은 공백 구간이 많아 여러 사람의 검증이 필요하겠죠.
어떤 경계가 다른 행정구역과 맞닿아 있거나 그 경계선의 일부로 삼고 있다면, 태그가 달려 있지 않은 일반 길(way)을 두 경계 관계의 
outer
메타데이터
If the boundary corresponds to a place=* node, add the node to the boundary relation with the place=* node can serve as the boundary's
As with any other feature, you should indicate dates and sources and licenses on any boundary you contribute. If you used a source to ascertain a specific portion of the geometry, you can tag that way with source=* instead of the whole boundary relation. (In the past, it was common to append the start and end dates to the relation's name=*, but this practice is now discouraged in favor of start_date=* and end_date=*.)
영토 변화
If the boundary has changed over time, create a boundary relation for each stage in the boundary's evolution. Join the boundary relations together with a type=chronology relation. For example, San Marino's chronology consists of five boundary relations dating back to the country's establishment. (In the past, these superrelations were also tagged type=boundary and the members had
If part of a boundary remains unchanged, that member way should be a member of multiple boundary relations. A single place=* node can also be a place=* node. For example, among San José's 1,172 member boundaries, there are a total of nine labels, showing that the place=town grew into a place=city and moved away from a river due to flooding.
영토 분쟁
Some mappers have modeled territorial disputes by tagging the way representing the claim line with boundary=disputed. However, this prevents us from modeling a valid boundary after the dispute is resolved. Instead, another approach is to create a separate boundary relation for each party's claims, tagging each relation with boundary=disputed or disputed=yes, along with a relation to represent the boundary once the conflict was resolved.
To do: How to tag a known indeterminate boundary?
Experimental OHM tagging conventions
Mappers are using these tags as they feel their way towards standard ways of doing things. You are encouraged to review these to see if any might serve your mapping needs, and to enter data on your own experimental tagging.
Namespaces
A namespace can be used for experimental tagging. There are active usages in OSM where the ohm: namespace indicates tags that refer from OSM to OHM. In OHM, an experiment is being done describing military movements on the Antietam battlefield, and the experimental tags are placed in the ephem: (ephemeral) namespace. It would not be unreasonable to create a mil: or similarly named namespace for experiments. The principal reasons for doing this are to prevent collisions and make it easy to locate the tagged entities in a search.
Import datasets (proposed)
Imports are encouraged on OHM, as opposed to OSM, where they are approached (wisely!) with caution. Imports on OHM, however, should be tagged appropriately in order to recover any potential changes to that data that may want to be harvested for possible improvements in the original dataset, or to properly handle citation requirements (e.g., in a CC-BY licensing of the imported dataset.
dataset=*(proposed) - this would help unify and tie together all related OSM objects for a particular import. This should be some sort of unique identifier to a particular source, data, and user driving the import. e.g. "Sea_His_Soc_2024_02_29_jeffmeyer" or maybe even something briefer.citation=*(proposed) - to enable on-map citation of the data source
Representation of change in historical road networks
Several different approaches have been experimented with.
- representing only road segments that no longer exist, leaving OSM to represent segments that are still present. this has some limitations, as there is not currently an accepted way to link across OHM and OSM and it is therefore hard to use the data. additionally, if relations are required to represent relationships and concepts, this approach does not work well.
- representing complete roads regardless of duplication of OSM. Duplication is unfortunate, but then if classifications have changed, such duplication is probably necessary. it makes building relations easier
if there are changes over time that do not change the geometry (classification, surfaces, etc.), several approaches have been suggested
- multiple ways sharing nodes, with different tagging/start & end dates on each individual way. may be challenging to edit
- a single way, with relations carrying the varying tags and dates. An example of this approach, contributed by Leon Karcher, is this way and set of relations: https://openhistoricalmap.org/way/198180780
Representation of troop movements and formations
There is currently discussion on this on the Open Historical Map/Projects/American Civil War page
제안된 태그
- start_date=datespec 'DEPRECATED'
- barrier=ohm:military:wireObstacle
- amenity=transport_service
- date_arbitrary=yes
- source_date=*,*,*
- Open Historical Map/Historical Time Format