OpenHistoricalMap/Tags
OpenHistoricalMap's tagging conventions are largely based on those of OpenStreetMap. In fact, some tags of marginal use in OSM, such as crop=* or anything under historic=*, are much more relevant to OHM. However, OHM has made some adjustments to accommodate aspects of historic geography that are irrelevant to OSM, namely: dates, (often secondary) sources, and their licensing and attribution requirements. OSM's "Map features" guide and other pages in the Key:, Tag:, and Relation: namespaces are generally a good starting point for determining how to map something, while this article serves as a supplement for any OHM-specific details.
As with OSM, OHM generally follows an "Any tags you like" philosophy, preferring to allow good ideas to percolate through the community through real-world use rather than top-down planning. There are practical constraints, such as the need for backwards compatibility with existing data consumers like the renderer on openhistoricalmap.org.
Although OHM has been around for a while, it is always evolving, and there are still many open questions. Tagging conventions are up for discussion on the talk page or any of our communication channels. As part of this evolution, it is helpful to think of what works now, what is in consideration to work in the near future, and what we aspire to support, but are not sure when we'll be able to.
Dates
- Main article: Open Historical Map/Dates And Times
Every feature should have a start_date=* tag that indicates when the feature came into existence, with the possible exception of natural features that would be impractical to date. Any feature that no longer exists should also have an end_date=* tag that indicates when the feature went out of existence. Without these tags, the feature will either fail to render or appear anachronistically depending on the time slider's position. For example, a feature with an end_date=* but no start_date=* will appear from the dawn of time until its demise.
The start_date=* and end_date=* keys accept the formats YYYY-MM-DD, YYYY-MM, and YYYY (commonly known as an ISO 8601 date). Specify the most specific date that your sources support, but no more specific than that. To record a specific time, or to record a date with some uncertainty such as "circa" or "nth century", add a start_date:edtf=* or end_date:edtf=* tag alongside start_date=* and end_date=*, which are still required for backwards compatibility. Also consider adding a note=* describing the reason for uncertainty. There are plans to eventually support EDTF format in editors and renderers. [1]
Some mappers are using as_of=* or as_of_date=* to indicate a feature's floruit – that is, when the feature was known to be in existence. 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.
Evolution over time
- Main article: Comparison of life cycle concepts
A single logical, real-world feature can change over time or even move. There are several strategies for handling these changes:
- Map the real-world feature multiple times, one distinct but overlapping geometry for each change. Each representation should have distinct start_date=* and end_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.
Sources and licenses
- Main article: OpenHistoricalMap/Tags/source
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
- Main article: 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?
Measurements
For backwards compatibility with software designed for OSM, any measurements in tag values are assumed to be in the metric system unless otherwise specified, even if the feature predates the metric system. To avoid anachronisms and conversion errors, consider expressing the quantity with the unit given in the source, specifying the unit symbol.
To do: Define unit symbols for common historical units.
External identifiers
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
- Main article: 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 member of both boundary relations. For example, Oregon Country shares an outer way with a number of other boundary relations, including Spanish Louisiana.
Metadata
If the boundary corresponds to a place=* node, add the node to the boundary relation with the label role. This allows geocoders like Nominatim to associate the two representations of this place. It also helps renderers label the place in an intuitive location, which may be a cultural or economic focal point rather than a geographic centroid. A different place=* node can serve as the boundary's admin_centre member, to associate the boundary with its seat of government (e.g., capital city).
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 subarea roles, but this practice is now discouraged.)
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 label member of multiple boundary relations, but the members of a chronology relation do not have to all share the same 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