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.
- 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. 
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=*. start_date:edtf=* and end_date:edtf=* are an alternative way to say "as of".
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.
Map the feature just once, adding a Proposal:Date namespace|date suffix to each key to qualify it by the dates when it applies.
Map the feature just once, adding a lifecycle prefix to keys that do not currently apply.
Sources and licenses
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.
- 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.
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.
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.
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 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
labelmembers 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_centremember, but if that changes over time, we still need to figure out a best practice for that.
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.
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'
- Open Historical Map/Historical Time Format