Mapping waterway changes - adding/losing land

I am mapping a river and its changes (there will be a later followup topic on the best practice for mapping a much larger area of this river and its harbour once I understand the options here).

The following 2 images show an aerial view of the river in 1944 and the OHM map for the current river profile/shoreline, which currently has no start_date.

I can easily show in OHM the addition of land with time by adding a river area with no start-date and an end_date somewhere between 1944 and now. There seems to be no corresponding ‘land’ area shortcut that I can use to map the loss of land. Is the proper way to break the river into segments with their own start and and end dates? I suspect that the answer is YES once I consider the adjacent land features such as the mangrove areas, which also change with time, but it would be nice if there was a ‘lose land’ shortcut for minor changes.

Thanks,
Andrew

1 Like

Yes, split up both the waterway way and the natural=water areas.

To keep the waterway ways coherent, you can join together the ways corresponding to a given time period into a type=waterway relation. There would be multiple such relations reflecting the different time periods. To keep them organized, you can add those relations to a type=chronology relation. But all this is optional; the renderer will do the right thing as long as you split up the features and tag them with dates.

2 Likes

@AndrewS_OHM - just following up here to make sure this answered your questions.

Mapping changes in river history is one of the coolest things about OHM, imo!! :slight_smile:

What OHM lacks a bit for mapping rivers and other natural objects is support for continiously changing features. Sure there have been river projects where something was constructed and then opened but most of the time you can’t say the river was at postion X at 1920-12-30 and on 1921-01-01 it moved 10 meters over.
It would be great if you could leave the start and end date away for such situations and just give an as_of (or as_of_date) and the map would interpolate the position for each day inbetween the two as_of dates. But I see that there could be technical diffulties assigning which old node moves to which new one, so understand that it is not done that way.

1 Like

Agree totally Jeff. Waterways often very visibly embody the relationship between humans and the land and that is something that interests me. And the changes are visible at very large scales! The waterways also map one edge of a settlement and the centre of activity - especially harbours and ports - so they are pretty foundational to all the other mapping activities and important to get correct.

Getting it correct is complex though and I would like to see a ‘best practice’ developed for waterways that takes into account the current OHM capabilities and where future development might head. I have mostly been following the advice of @Minh_Nguyen and breaking the area I am working on into segments and this is best explained with a screenshot.

This is one river segment and consists of a multipolygon relation of natural=water; water=river and this one represents the ‘original’ river prior to settlement (I haven’t tried this as a waterway relation, maybe it works the same). I used an end_date of 1878, this being the start of major river shoreline changes, but the segment is predominantly based on an amalgam of a 1944 aerial image and earlier maps of smaller scope and accuracy. The 15 km of river I am mapping is divided into a total of 11 segments that meet at straight line boundaries crossing the river. The segment shown in the image is actually subdivided into 2 segments after 1920 (when the central land was created) for ease of mapping all the changes where the ships are visible in the image.

Each river segment has a sequence of temporal ‘variants’ that line up with the existence of reliable large scale maps, subject to the frequency of changes of the shoreline. A couple of segments in the upper reaches of the river have only two temporal variants, largely because there was very little change over time. Some segments for the lower reaches around the harbour may have 4 or more temporal variants.

Around the shoreline of some segments there might be 10 or more mapped changes on different dates affecting a small part of the shoreline and rather than creating a new temporal segment for every change I have adopted the following approach:

  1. the temporal range for a temporal variant starts in the year following the previously available map of that segment (ie after the previous temporal variant) and ends in the year of the map that defines the segment shoreline (ie before the next temporal variant).
  2. In OHM I can’t see how to add land to a water area over time, but only how to subtract or add water. Therefore each area of land that will be ‘added’ during the time range of a temporal variant is included as a water polygon with an end-date equal to the date the land was added (and a start date equal to the temporal variants start date). Land that will be ‘lost’ during the temporal range is included as a water polygon with a start_date equal to the date the land was lost (and an end date equal to the temporal variant’s end date). This is my solution to the problem that @Bauer33333 highlighted and sometimes I have even added polygons that interpolate between dates if I have supporting non-mapping evidence. These polygons are not members of the segment’s multipolygon relation as they would breach the single temporal range requirement.

Note that the time range for the temporal variants within each river segment don’t align with other segments and I think this means that the chronology relation can’t be applied to the entire river as that relation prohibits overlapping temporal ranges (?).

The only alternatives I see to my approach are:
a) every change to the shoreline, no matter how minor, requires a completely new segment temporal variant to be created, or
b) the segment (or even the entire river) could be mapped as multipolygon relations with every change requiring a new relation and unchanged shoreline parts shared across relations. This would mean that every map used would be associated with a new relation (if the date was unique). This would be extremely complex to manage and difficult for future editors to maintain (or even interpret).

I think my approach is some form of hybrid, but maybe I have got it all wrong and there is a much simpler way. Please let me know!

The area is here and I haven’t completed the mapping yet, especially around the southern shoreline and the harbour mouth. Some of these areas reflect a previous strategy and need to be fixed. It is actually doing my head in trying to integrate all the various cartographic sources :slight_smile: OpenHistoricalMap

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.

I am impressed by everything that is happening here.
The tidal reservoir in D.C. shows up between 1885 and 1895!

BTW I can confirm this change. Click the years at the bottom of the screen here :: Chronoscope World @mprove

Funfact you can also click open the yellow disk /called the ChronoCuror/ and jump to OHM.

I’d also collect some cases that should be within the scope of a feature.
This one is wild (meandering Mississippi River): Plate 22 Sheet 6 Alluvial Valley of the Mississippi River. Ancient Courses Mississippi River Meander Belt. Cape Girardeau, Mo. - Donaldsonville, LA. - David Rumsey Historical Map Collection

This one is similar to D.C. when the river Rhine was straightened in 1777 Chronoscope World @mprove

The famous land fill of Boston :: Chronoscope World @mprove

Btw, very nice use of the time argument in the OHM URL! :pray:t2: Many thanks!! Now… to enabled a direct opening of an editor in OHM with that map as a base! (see: Add georeferenced IIIF image support to iD · Issue #768 · OpenHistoricalMap/issues · GitHub)

You don’t happen to have xyz tile endpoints for your Chronoscope maps, do you?

This is very timely… I’m about to create an OHM wiki project page for Boston. I love that map you’ve overlaid, but I cannot remember if it includes detailed links to the sources that were used to create it.

The maps in Chronoscope World always use the pixels from and link back to the original IIIF provider. In this case:

This is a composite of an entire thumbnail cinema: Boston shoreline - Digital Commonwealth Search Results

You might use the IIIF image api to slice tiles yourself. xyz tiling is not my area of expertise.

1 Like