OpenHistoricalMap/Tags/Relation/chronology
 chronology
|
 |
| Description |
|---|
Each of the elements representing a single feature over the course of time.  
|
| Group: Lifecycle |
| Members |
|
|
| Status: in use |
| Tools for this tag |
In OpenHistoricalMap, a chronology relation groups together all the elements that represent a single real-world feature as it changes over the course of history.
Rationale
OpenHistoricalMap intentionally violates the "One feature, one OSM element" principle for the purpose of tracking changes over time. However, there is still a need to refer to a feature as a single concept regardless of the time period, and to explicitly indicate that each dated element describes the same feature as the others.
In practical terms, the Wikidata community balked when San Jose (Q16553) was modified to link to each of the city's 1,172 boundary relations in OHM, overwhelming the item with 1.3 megabytes of time series data. Wikidata's data model is often not scalable enough for time series data, but Wikidata and Wikipedia do often describe the evolution of a boundary over time as a concept, so OHM should be able to represent the same concept natively.
The main website's inspector relies on each feature to be explicitly tagged with the name and URL of its successor in followed_by:name=* and followed_by=*, respectively. However, this approach is fragile compared to a relation, and nothing in the database triggers this functionality as of April 2024. [1]
A time-spanning relation type may make it easier to convert OpenHistoricalMap data to the Linked Places Format used by the World Historical Gazetteer and other projects. [2]
When to use
Use a chronology relation when something has changed in the real world over time, causing OpenHistoricalMap to represent it as multiple redundant elements, for example:
- A place has been renamed
- A city has annexed some land, changing its boundary
- A railroad has been rerouted along a different track
- A building has progressed from construction to its finished state
- A new wing has been added to a building
- A shop has moved down the street from where it used to be
For an insignificant feature that has only changed a few times in history, a chronology relation may be overkill. If two elements have matching feature tags and Wikidata items but differing start_date=* and end_date=* tags, a data consumer can infer that the elements represent the same feature in different time periods.
To group multiple parts of a feature, use Relation:multipolygon, Relation:multilinestring, Relation:building, etc. To group multiple elements that are mapped separately for some reason other than time, consider a different relation type, such as Relation:collection or Relation:site, but consider that relations are not categories.
Members
A chronology relation must contain at least one member. Each member must represent the same conceptual feature in its entirety. Members should be sorted chronologically from earliest to latest.[1] Members may overlap spatially but should not overlap temporally.
An element may be a member of more than one chronology relation, in order to represent overlapping concepts. For example, a shop may double as an address point, so one chronology relation can track the shop's location over time while the other tracks that address's occupants over time.
The role of relation members should be left blank. This may seem odd to leave a field unfilled, but it is perfectly ok – and preferred.
Tags to use in combination
Add start_date=* and end_date=* tags to the chronology relation to indicate when the feature began and ended in reality. The relation's start_date=* tag may differ from the first member's start_date=* tag to indicate that the feature is not yet mapped all the way to its inception. This is especially useful when a feature is known to exist from a certain date, but its original location is unknown.
The name=* tag should be the feature's most prominent name. This may be the most recent name, the longest-lasting name, or the name at a particularly significant point in the feature's history. If a feature's name has changed over time, each member should have a name=* tag appropriate to its respective time period.
A wikidata=* tag can link to a Wikidata item about the feature's history, to be specific.
Any other tag on the chronology relation should be applicable to the whole feature throughout its lifetime. However, chronology relations are primarily for representing changes over time, not for sharing tags among features for convenience. A chronology relation tends not to have many tags, because the members already describe the feature in detail.
Examples
- Chronology of the boundary of San Jose, California, as the city annexes territory (see: territorial evolution of San Jose (Q114348668) on Wikidata)
- Chronology of WORKS/San José as the art gallery relocates across town
- San Marino: Chronology relation for the expansion of The Most Serene Republic of San Marino over time (see: territorial evolution of San Marino (Q120752286) on Wikidata)
Software support
iD has a preset for chronology relations.
See also
Notes
- ↑ As of October 2022, neither iD nor JOSM supports automatically sorting a relation's members by start_date=* value. One workaround is to query the Overpass API for each member and its tags, convert the results from JSON to a sorted CSV using jq, transform the CSV to JOSM file format, and upload the file to OHM using JOSM.