Good question. This is a general issue with any secondary attribute of a feature, particularly noticeable to an experienced OSM mapper who would normally load up a feature with as many secondary attributes as possible. It’s an acute problem for roads, because the primary feature tag’s value is an importance-based classification that can change even if the road itself doesn’t physically change.
I don’t think we have a perfectly satisfactory answer yet, but here are two approaches that I’ve experimented with:
- Map each stage in the road’s evolution as a separate way (either overlapping or slightly offset). For example, this street overlaps with two other streets representing different time periods. iD’s validator will warn you if the streets overlap during the same time period.
- Map just one road geometry but add it to multiple route relations. For example, this highway is a member of four route relations, each representing one of the stages of the route’s evolution. In turn, the route relations are grouped in a chronology relation so it’s easier to keep track of them. This approach is more relevant for numbered highway routes than for ordinary city streets, though there’s been some work toward supporting a street relation type in the renderer.
Long ago, there was a proposal to introduce a “datespec” syntax as part of the key, so that you could reuse the same element even as individual attributes of the feature change at different times. Some mappers continue to use this syntax in OSM, especially for signposted former names of streets and buildings. However, it has no clear path to support in any software, because any kind of freeform syntax would greatly complicate a typical database schema. That isn’t a problem for OSM, where historical information about a feature is trivia, more or less, but it’s a bigger problem for OHM, which needs to visualize and analyze historical data.
Multilinestring relations have also been floated as a possible solution, similar to route relations but more general. But this is a geometry type, analogous to multipolygon relations, so it could be confusing if a roadway is part of multiple multilinestring relations and each one tracks only one attribute about the feature.