Mapping waterway changes - adding/losing land

This is just something I wrote on the wiki one day, with the expectation that we’d be able to create validator warnings for unordered chronology relations. If folks disagree, we can relax that requirement. Currently, the only software project that actively supports chronology relations is iD, but it needs some work anyways. Its automatic member sorting functionality sometimes wreaks havoc on chronology relations when splitting and joining ways.

I haven’t mapped many waterways yet, but I’ve mapped plenty of other linear features like roads and railroad tracks that similarly get realigned over time. My approach has been what you describe: creating multiple route relations, one for each stage in the thoroughfare’s evolution, and joining them together in a chronology relation. For example, here’s a chronology relation for California State Route 152, or at least the portion over the Pacheco Pass that got rerouted several times, including due to the construction of a large reservoir.

I recognize that this can be a monumental task for long waterways and large bodies of water. It reminds me of the first chronology relation, representing the territorial evolution of the City of San José. The data source we imported contained annexation polygons rather than boundaries per se, but we merged and collated them into boundary relations because that’s more useful when you want to know where the city’s boundaries were at a given time. This approach comes with the downside that some ways are members of hundreds of boundary relations.

For railroads, I’ve sometimes taken a shortcut that maybe you’d find acceptable: a single railway route relation has a start date of (say) 1900 to 2000 and includes a segment that only existed from 1900 to 1980, alongside the segment that replaced it in 1980. As long as the members of the route relation are spatially and temporally exclusive, then the route remains valid no matter which year you evaluate it in. But I have no idea if this approach applied to multipolygons would be compatible with editors and data consumers, which have date support sort of grafted onto the side.