Ko:OpenHistoricalMap/Tags

From OpenStreetMap Wiki
Jump to navigation Jump to search
OpenHistoricalMap/Tags - Other languages

오픈히스토리컬맵 (OpenHistoricalMap, OHM)의 태그 시스템은 오픈스트리트맵 (OSM)의 태그에 기반을 두고 있습니다. OSM의 기본 태그는 OHM에서도 거의 똑같이 적용됩니다.

OSM를 다루신 적이 있다면 태그를 붙이는 법에도 익숙하실 겁니다. 허나 아무리 똑같은 기반이라고는 하지만, OHM에서도 똑같이 자기가 익숙한 대로 태그를 붙인다 해서, 다른 편집자들이 항상 납득할 수 있는 것은 아닙니다. 다른 편집자들의 이해와 함께하면서 태그를 다는 것이 성공을 보장받는 가장 좋은 방법입니다.

OHM에는 OSM에서 약속한 태그 규칙과는 조금 다른, 몇가지 중요한 권장 태그가 있습니다. 이러한 태그는 시간별 정보의 렌더링에 도움이 되고, 지도 데이터 출처에 대한 세부정보를 제공하거나 저작권 문제를 명확히 하기 위해 도입되었습니다.

또 한가지 주의점은, OHM은 오랫동안 진행되고 있는 프로젝트지만 늘 더 나은 방향으로 변화하고 있다는 사실입니다. 태그에 관한 논의도 마찬가지이며, 해당 토론란에서 진행되는 논의들로 OHM의 태그가 현재는 어떻게 작동되는지, 추후 어떻게 작동되면 좋겠는지, 운영자분들이 무엇을 지원했으면 좋겠는지에 관한 이야기가 오가곤 합니다. 도입 개편이 불가능한 부분들도 있지만, 큰 변화가 생기면 아래에 소개된 내용이 달라질 수도 있습니다. Talk:Open Historical Map/Tags 토론란이나 인터넷상의 OHM 관련 포럼 페이지에서 논의가 진행되므로 참고하시면 좋습니다.

OHM의 기초 태그

날짜: 필수 태그

지물의 존속기간을 나타내기 위한 태그로, OHM의 핵심이나 다름없는 태그입니다. 아래 두 태그가 빠진다면 지도에 제대로 표시되지 않는다는 점을 기억해 주세요. 아무리 시점을 돌려봐도 안 뜬다거나, 특정 날짜에서 갑자기 사라진다거나 뜨지 않는 등의 문제가 발생합니다.

  • start_date=YYYY-MM-DD; YYYY-MM; YYYY - 시작 날짜입니다. 지물이 나타난 날짜를 뜻합니다. 반드시 적어주세요.
  • end_date=YYYY-MM-DD; YYYY-MM; YYYY - 끝 날짜입니다. 지물이 사라진 날짜를 뜻합니다.

각 태그에 날짜를 입력시 ISO 8601-01 Extended 포맷을 따라야 합니다. 쉽게 말해 (연도4자리)-(월2자리)-(일2자리) 순입니다. 정확한 날짜를 모를 경우 연월, 연도만 써도 적용이 됩니다. 예시를 들면 다음과 같습니다.

end_date / start_date 중 하나만 쓸 경우

상술했다시피 end_date=*를 쓸 때, 해당일까지만 지도상에 나타난다는 뜻인데, start_date=*를 안 써줄 경우 나타난 일자가 없음 처리됩니다. 재개발로 인해 사라진 산이나 강 등의 자연지물 등에 적용할 때에는 유용한 태그 표기지만, 사람이 만든 지물일 경우에는 일단 누가 만들었다는 뜻이므로 start_date=*를 쓸 여지가 남아있습니다. 아무리 시작일자가 불명이라 하더라도 아는 한에서 그 범위를 추려내어 연도를 적당히 적어 주세요. 도저히 모르겠다 싶으시면 note나 description 태그에 사정을 설명하고 다른 편집자의 도움을 기다립시다.

거꾸로 start_date=*만 적는 경우에는, 아직 해당 지물이 현재 시점에서도 사라지지 않았다는 뜻이며 그대로 적용이 됩니다. 분명 사라진 지물일 경우에는 end_date=*를 무조건 적어주세요. 현재 시점의 지도에도 뜨는 오류가 발생할 수 있습니다.

EDTF format dates

OHM currently supports the date part of extended format ISO 8601 compliant dates. In the future, we plan to support the Library of Congress Extended Date Time Format, a profile of ISO 8601-01 and -02) which will enable such terminology as "about," "around," "circa," and other more nuanced date formats. If you would like to use this style of dates, please add 2 tags - end_date=* a date for use by the vector rendering engine and end_date:edtf=* for EDTF format dates. Similarly, use start_date:edtf=* for start dates in EDTF format. The simple interval formats using the '/' character will suffice to show the boundary of what is known.

Use of Namespaces

Namespaces are a concept inherited from OSM that many may not be very familiar with. A tag can contain a ':' character, and with namespaces it is used separate a prefix (the namespace) from a suffix (a specific tag within the namespace).

Namespaces 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.

OHM Community Requirements

All of these tags fall into the category of what works now. The following tags should be considered the bare minimum for enabling rich interaction and collaborative mapping, as well as providing the credibility required for historical veracity. These tags should be able to help others quickly identify where the map traces came from and provide a foundation for a conversation about mapping that poi, way, or relation. Without these tags, another member of the OHM community is likely to prompt you to add them to your work.

  • name=* - the most basic identifier of all! Same as OSM.
  • source=https://yoursource.org - please just use a URL as the source of your data. 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.
  • source:name=* - this is just any plain text description of the URL. e.g., "Phelps Treasure Map of 1861"
  • license=* - without this tag, the assumption is that the license is CC0. If you are importing data from 3rd party sources, please be sure to mark all relevant objects (e.g., POIs, but not untagged nodes/vertices in a way) with the appropriate license.

In addition, the following tags are highly encouraged, in order to enable connection to other data sources across the Internet and to make OHM map data available to others.

  • wikipedia=* - these provide background information for the inspector.
  • wikidata=* - this is critical for open data queries of OHM.
  • source:wms=* - this enables another editor to continue mapping the exact same source you have mapped, just by plugging this URL into iD or JOSM.

The following tags are in need of clarification on how to best use them, but will also enrich the depiction of data on OHM.

  • Date modifiers: as_of=*, construction_start=* - not everything has a clearly-defined "start" date. Many construction projects have taken years. Other specifics are harder to nail down. A building can be on a map published in 1830, and have no known start date. So, as of 1830, we know it was there.
  • Images: image=*, image:date=* - we are working to include images in the object inspector.
  • Additional information: info=* - this is to provide links to other deep or rich sources of info about that particular way. This information might be complementary and beyond the level of detail in Wikipedia, or be relevant for a particular time in history.

Differences from OSM Tagging

Things to keep in mind that are different from OSM:

  • Tagging license=* at all.
  • Tagging source=* at the object and not changeset level. We want to keep the source of data as close as possible to the data itself. And, the source needs to be easily recoverable.

There are some other areas where we deviate from standard OSM tagging practices, as well. If you have questions, please just ask on Slack or Discord.

Where to Tag

Ideally, tagging should take place on the highest level object possible. And, in this case, relations are your friend.

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.

Boundaries

Boundaries can be tricky. Here are some recommendations:

  • Boundaries are best defined with Relations of type=boundary and boundary=administrative with an appropriate admin_level=*. See: Oregon Country (1804-46), San Marino (301-1150), The Roman Empire (106-270).
  • You can put start_date=* and end_date=* tags on your relations.
  • Where at all possible, do not tag your ways... almost all descriptive information is better stored in Relations. Exceptions might include source=* and license=* tags for the providers (if any) of your geometry.
  • Boundaries must be fully closed - any gaps in their continuity and they will not render properly. [note: having land-only boundaries would be cool - please let us know what you think.]
  • Relations have "stable" IDs, so even if their members change, links to them from 3rd party systems are less likely to break.
  • You can group related Boundary Relations into a Super-Relation (e.g. all of the various boundaries of Oregon over time).
    • Unfortunately, Boundary Relations do not play well when you try to use relations as members. For example, it is not helpful to try to create a boundary out of the various borders that define that boundary (e.g. making a "California" super-relation out of relations for "California Coast", "California-Oregon Border 1850-", "California-Nevada Border 1866-", "California-Arizona Border 1866-", "California-Mexico Border 1850-", and "California Islands 1850-". That said... having relations for those individual borders *is* something that would be extremely valuable for other purposes. [note: individual border relation creation is burdensome and not required by any means.]
    • As an alternative, you can group the dated boundary relations into a chronology relation.
  • Boundary relations need to have label members in order to render properly.
    • Label positioning matters. So, if you have a changing boundary, you may want to reposition the associated labels over time, as well. See here.
  • Boundary relations ideally also include an admin_centre member, but if that changes over time, we still need to figure out a best practice for that.

Known Issues

Multiple sources

Consider creating a wiki page under projects for your mapping project and provide detailed sourcing information there.

Multiple images

Use the image:0, image:1, ... notation to reference properly licensed imagery

Multiple names for a single way

Use relations to abstract meta data from geometry

Provisional OHM Tagging conventions

These tags are generally accepted but are potentially subject to improvements/changes.

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.

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 & Formations

There is currently discussion on this on the Open Historical Map/Projects/American Civil War page

Proposed Tags

Main category: OpenHistoricalMap proposals

Related Conversations

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Ko:OpenHistoricalMap/Tags&oldid=2702850"