1. Life Cycle modeling in OpenHistoricalMap (OHM) is more complex than proposals that have been made for OpenStreetMap (OSM) due to OHM focusing on modeling changes over time.
2. Common approaches to modeling life cycles in OSM, like using construction tags, are limited because they assume data only represents the present day.
3. Alternate approaches to modeling life cycles in OHM include duplicating geometry, encoding date information in tags, or using relations to decouple life cycle metadata from geometry. These approaches involve tradeoffs between complexity, compatibility, and ease of editing/consumption.
4. Initial experiments in OHM include modeling "ghost tracks" using an abandoned circuit relation proposal
4. Life Cycle Modeling in OHM
• Substantially more complex than anything anyone is trying in OpenStreetMap
• Proposals have been made for OSM but not gone anywhere
• limited motivation given OSM focus on Now
• after all, we have an OHM for that
5. Time in OHM
• integral to Life Cycle
• but I’ll talk about it in a lightning talk tomorrow(?)
• assume we’re using something related to ISO 8601-01 and -02
• potential for historic and/or non-ISO times in the future
• we are focused on the times in tags, not internal to the vector renderer
6. Life Cycle mapping brings complexity
• Not any way to avoid complexity
• We have to decide, then, how we will represent and deal with it
• Complexity impacts both mappers and data consumers
• easy for one may not be easy for the other
8. Common OSM Life Cycle
• fine for what OSM uses it for
• OSM also has things like the disused namespace
• all built around the idea of *now*
• Does not handle OHM levels of complexity
highway=construction
construction=primary
9. Alternate Approaches:
Duplicate Geometry
• Can be challenging to edit with current tools
• Can be challenging to even spot with current tools
• Potential to be made easier with well conceived extensions and/or plugins
• Sometimes unavoidable in contexts with dense histories
10. Alternate Approach:
Lifecycle Encoding in the key
• abandoned OSM proposal
• embed date information in key side of key/value pair
name:2005-2010=My Name
• could generalize to any key value
11. Alternate Approach:
Lifecycle Encoding in the key
• Issues
• hard to search via overpass or other means
• stress on data consumer side
• compatibility issues with both start_date specs and with ISO 8601/EDTF
• database people don’t like stashing data on the key side of a KV pair
12. Alternate Approach:
Life Cycle with Relations
• Failed OSM proposal
• Treat life cycle data as metadata to be decoupled from geometry
• Carry start_date and end_date in relations
• Being actively experimented with in OHM
13. Alternate Approach:
Life Cycle with Relations
• Cannot eliminate complexity - but we can move it
• Instead of sorting through a thicket of complex keys, traverse a graph of
relations, ways, nodes
• We may not need a new relation type - we can add start_date and end_date to
any existing relation type
• There maybe other reasons for a generic “group” relation type
15. First Experiment - Ghost Tracks
• uses abandoned proposal for “circuit” relation type (abandoned, but in use)
• same in OSM and OHM (except OHM adds end_date)
• leaflet widget treats data returned by overpass the same for OSM & OHM
• NOTE: the OHM rendering engine is *not* the only data consumer and it is not
the only viable view of OHM data
16. New Experiments
• “Life Cycle Laboratory”
• try extending these concepts to other kinds of entities?
• Easy start by adding start_date and end_date to existing OSM relation types
• OHM rendering engine support is evolving, some works and some doesn’t
• Useful for figuring out things to ask for
17.
18. NYS Canal System
• Uses waterway tagging (relations & ways)
• Relation complexity increases substantially with size and complexity over time
• Erie Canal was substantially improved between 1837 and 1862
• changed from year to year
• Need to consider better tool support
• https://www.openhistoricalmap.org/#map=15/42.7818/-
73.7050&layers=O&date=1900&daterange=1783,1900
21. Events?
• Potential to model historical events
• Voyages
• Military battles & campaigns
• Same DB or a parallel DB?
• I’m experimenting in the existing OHM DB for now
