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=*를 사용하기도 합니다. This may be useful when your only source is a single map showing the feature at the time of publication; however, you still need to specify start_date=* and/or end_date=*. You can say "as of" by setting start_date:edtf=* and end_date:edtf=* to open-ended date ranges. Over time EDTF dates will gain better software support, making this an ideal option for when you only have information at a single point in time.
OHM's emphasis on dates differs significantly from OSM. This is an important obstacle to conducting a large-scale import of data from OSM to OHM.
시간에 따른 변화
현실에 당연히 존재하는 지물이라면 시간에 따라 변화하거나 위치가 옮겨지기도 합니다. 이러한 변화에 대처하기 위한 몇가지 전략은 다음과 같습니다.
- Map the real-world feature multiple times, one distinct but overlapping geometry for each change. Each representation should have distinct
start_date=*andend_date=*tags. Use a chronology relation to associate these features. This is the most general approach, but it can become complex when mapping connected linear features, such as roads and railroads. - 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.
- (Deprecated.)
Map the feature just once, adding a Proposal:Date namespace|date suffix to each key to qualify it by the dates when it applies. - (Deprecated.)
Map the feature just once, adding a lifecycle prefix to keys that do not currently apply.
출처와 저작권
This section is currently being discussed in deeper detail on the OHM Forum.
If you use a source other than your own observations to determine the location or details of a feature, you should credit the source in a source=* tag on the feature itself, not merely on the changeset as you would in OSM. This avoids plagiarism, bolsters OHM's credibility in historical research, and reduces legal risk. By tagging the individual feature, you make the source much easier to discover than if it were buried in a changeset tag.
You can set source=* to the URL of your source. Ideally, this is a pointer to an image of an old map or a dataset or some other verifiable reference to whatever you are mapping. If the identity of the source isn't obvious from the URL, you can set source:name=* to a plain text description of the URL, e.g., "Phelps Treasure Map of 1861". 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=* should be set to the most prominent name by which the feature is known, typically in the local language. Remember that the contemporary local language may differ from the present-day local language.
To do: Distinctive names are often applied retroactively to things that had a very mundane contemporary name. How to distinguish the two?
측정 단위
OSM 맞춤형으로 제작된 소프트웨어와의 하위호환성을 위해 태그값의 모든 길이 측정값은 별도 명시되지 않은 한 미터법을 사용하는 것으로 여깁니다. 이는 해당 지물이 미터법 이전의 것이라도 마찬가지입니다. 시대와 맞지 않거나 변환 오류가 발생하는 것을 방지하려면, 출처에서 밝힌 단위로 양을 표현하고 단위기호를 지정할 수도 있습니다.
To do: 널리 쓰인 옛 단위의 기호는 어떻게 정할까요?
External identifiers
wikipedia=* and image=*.When possible, set wikidata=* to the QID of the Wikidata item representing the feature. This enables OHM to be used as part of linked data projects. For backwards compatibility, also set wikipedia=* when available, so that the inspector can display a Wikipedia summary.
Use image=* and image:date=* to incorporate a freely licensed image into the inspector. To tag multiple images on a single feature, use image:0=*, image:1=*, etc.
Privacy
OHM presumably observes limitations on mapping private information. However, sources may consider some personal information, such as the name of a home's owner, to be less sensitive if it dates to the distant past and involves people who are no longer recently alive.
Boundaries
- 주요 문서: Boundaries
Administrative boundaries are some of the first things users see when they visit OpenHistoricalMap for the first time. These boundaries not only help to orient users and make it easier to search for places; they also make it easier for mappers to stay organized as they improve coverage in an area.
Geometry
OHM has inherited OSM's model of boundaries as a sort of multipolygon feature, rather than as a collection of claim lines. Therefore, you should map an administrative area's boundary as a series of ways forming a closed ring, held together by a type=boundary boundary=administrative relation. If a way only exists in order to close a gap in a boundary relation, tag it with fixme=* so that others know to investigate it further. This is preferable to the gaps seen in, for example, the Roman Empire. Any boundary that precisely lines up with a neighboring or containing administrative area's boundary should be a single untagged way that is an 
outer
Metadata
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=*.)
Territorial evolution
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.
Territorial disputes
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
Proposed tags
- start_date=datespec 'DEPRECATED'
- barrier=ohm:military:wireObstacle
- amenity=transport_service
- date_arbitrary=yes
- source_date=*,*,*
- Open Historical Map/Historical Time Format
See also