Editing historical road layouts : Persistence in the Urban Landscape 3

It's a while since I've written a post on the theme of persistence in urban landscapes, and this despite covering some additional examples in my talk at SotM13 in Birmingham. This post takes one example I included in that talk: how road layouts persist.

However, I have also used it as a convenient hook to discuss how we might enable the capture of such data for something like OHM (Open Historical Map). I hope the latter discussion might provoke further ideas from those interested in developing OHM and both links with Wikimedia Commons and Wikidata in the future.

Derby Road, Nottingham

Current OSM Map of Derby Road compared with
Sanderson's Map of 1835. Changes in alignment marked with arrows

I've touched on the history of Derby Road before. Here I'll show what I know of it's history in detail from around 1800. The key point is that the basic line of the road has changed very little: the major changes being well understood and mostly comprehensively documented by the Lenton Local History Society.


The main changes of line that I am aware of are:

A hollow or bank: part of the old alignment of Derby Road

• In the 1820s the owner of Wollaton Park built a brick wall surrounding the estate. This was part of a series of works designed to defend Wollaton Hall and its park from attack by discontented local people. As a result of the wall, the route of Derby Road was pushed further S from the top of Adam's Hill (today marked by its use as the name of the residential service road on the N side of Derby Road) to where the road crossed, in quick succession, the Nottingham Canal and the River Leen. This change in alignment is obvious if one inspects modern maps: my brother drew my attention to this several years ago. At the entrance to Wollaton Park there are traces of the original alignment, as shown on the 6 inch map of a hundred years ago. My general impression is that the original route was less steep than the current route.
  
  

  

  This image of Wollaton Park Housing Estate, Wollaton, 1928
  from Britain from Above (CC-BY-SA-NC) shows two changes of alignment
  1: the carriage road from Lenton Lodge which is disappearing under housing is on the old alignment of Derby Road,
  2: in the near foreground right the old Rose and Crown pub can be seen with a grassy area to its right (a bowling green

  
  
• Realignment around the Rose and Crown pub. The original Rose and Crown building created an awkward pinch point on the road, with possibly a slightly blind corner. As motor traffic built-up this no doubt became more and more inconvenient. In 1935-6, a new, more substantial pub was built in the grounds of the old pub. Once the new pub was open, the old pub was demolished and the road widened and straightened. Details in the Lenton Times article online.
  
  

  

  Although taken with rain running down the bus window this image
  shows the sharp change of alignment introduced by the railway bridge on Derby Road
  (starting at the second set of traffic lights).

• Bridge over the railway. Originally Derby Road crossed the railway by a level crossing next to Lenton Station. The original alignment is still present next to the Three Wheatsheaves to the W of the railway. In 1909 a railway bridge was built slightly to the S of this alignment. The detail of these changes are described in the Lenton Times Issue 26.
• Junction with Nottingham Ring Road. Originally this was a T-junction with a minor lane called Sandy Lane. The junction as it stands was created in the 1920s just after the City Council had bought Wollaton Park and started to build social housing in the E part of the park. Middleton Boulevard and (the then) Abbey Boulevard (now Clifton Boulevard) were part of a set of dual carriageways built round the W side of the city simultaneously with extensive tracts of council houses. The principal engineer was a Mr Clarke. He was the father of our GP when I was a child.
  
  Originally this junction was a roundabout. Sometime in the 1960s it was re-configured to be signal-controlled, but with rising traffic this still wasn't enough. In the early 1980s the ring road bypassed the junction entirely through the construction of an underpass. Finally in the past 5 years the new roundabout has been altered so that traffic flow is all under the control of traffic signals. However none of these changes has resulted in any significant alteration of the basic line of the road.

I have started trying to document the alignment of the road at the start of the 19th century on Open Historical Map. This is a bit of a cheat as my primary source is Sanderson's Map 20 Miles around Mansfield which was compiled in the early 1830s and thus post-dates the first alteration of alignment.

Wollaton Park area, showing Derby Road alignment c. 1820
vector map on OHM View Larger Map

One of the nice things about OHM is that it is vector data, so it is very easy to compare current OSM ways for Derby Road and the ones I have entered in OHM, and furthermore look at the temporal tagging needed to enable use of a single way in different time periods (as distinct to creating new vector data sets for each time period snapshot).

Temporal Tagging of Ways 

By temporal tagging I mean using some tags to indicate the time period when a way was in existence with the associated attributes. Typically this is done in temporal databases by using start_date and end_date columns, and the basic idea is to do this with tags. We know this can work for OSM data. Since my original tests, MaZDerMind, the guy behind the OSH full history extracts of the OSM database has developed a comprehensive suite of tools to populate and render OSM data using a temporal schema (although this is a system date, the time data entered the system, not a real world date which is what we want with OHM). For a neat example of what is possible see Joost Schouppe's diary entry which arrived at an opportune moment for this post.

Derby Road is a nice simple case as long as we avoid worrying about attributes: in the 200 years under consideration things like speed limits, surfaces, streetlighting, width will all have changed in many places many times. (Even in the past 5 years changes in bus routes have led to many changes to the composition of the ways which make up Derby Road).

So if we ignore attributes we can take every existing section of Derby Road and add them to OHM with tags of start_date=1800-01-01 and either not create an end_date tag or populate it with some far off date in the future (conventionally 9999-12-31 is used). Now for those sections of road which are newer than 1800 we need to adjust the start date. Finally the ways which have gone in the alignment which I have already put into OHM can be similarly tagged with a start_date of 1800-01-01, but with different end_dates according to the information above.

In outline:

No.	Start location	End location	Start Date	End Date	Comment
1	Priory Roundabout	Adams' Hill	1800	9999
2	Adams Hill	Lenton Lodge	1800	1825	Through Wollaton Park
3	Adams Hill	Lenton Lodge	1825	9999	S of Wollaton Park
4	Lenton Lodge	W of Rose and Crown	1800	9999
5	W of Rose and Crown	E of Rose and Crown	1800	1936
6	W of Rose and Crown	E of Rose and Crown	1800	1936
7	Three Wheatsheaves	Faraday Road	1800	1910	Level Crossing
8	Three Wheatsheaves	Faraday Road	1910	9999	Railway Bridge
9	Faraday Road	Tollhouse Hill	1800	9999

I have ignored the extra complexity of the Middleton Boulevard/Clifton (Abbey) Boulevard/Sandy Lane junction because the changes are more recent and are much more intricate.
 

Editor support for Temporal tagging and data entry 

So far all I have done is show that :

• We broadly know how we ultimately want to store historical geographical information (as a temporal database of some form).
• We could use tags for the temporal information
• That creating such data for road networks is not too horrendous.
• The more attributes are added, the more different temporal records are needed.

I'd also hoped to discuss the following point in detail, but this post is long enough already.

• Holding attributes in a different federated data store has some appealing properties; not the least of which is a potentially larger community to crowd source such information.

However in the short term we want to make it easier to capture such data, and in doing so make the most of all the software infrastructure developed by OSM over the past 10 years. OSM has no support for temporality in its toolsets, and to my mind trying to create a modified OSM by adding temporality is a step too far for OHM in its early stages.

For some time I have been thinking about how one can do this by extending the editors. A recent discussion suggested it was really time for me to write up some of these notions. I'm doing this in a bit of a hurry because there is a big hack weekend in Zurich imminent and I hope these might at least provoke some discussion.

My starting point is as follows:

• Only OHM elements with attributes need to have temporal tags. Tags solely concerned with metadata (source, fixme, note, etc.) do not count.
• Temporal tags are special, I call them 'privileged' tags as the editors treat them in special ways from ordinary tags. In practice I think they should be hidden from the end-user who can only manipulate them through the editing interface. (There is already some support in editors for recognising and handling some particular tags, although this is to delete them!)
• The basic editing would be on a historical snapshot with defined start and end dates. This would be defined at the start of the editing session, and initially the two may be identical.
• Adding tags to an untagged element would automatically cause the element to inherit the base temporal tags of the edit session.
• Individual elements could have their temporal ranges changed by an additional control within the editor (for instance a slider on the left-hand tag panel in Potlatch2). Again this is a second stage step.
• Temporal tags would be all UPPERCASE to highlight their distinctness. So something like OHM_START_DATE and OHM_END_DATE.
• Temporal tags would probably include some indication of the fuzzyness of the dates in the value field, so something like earlier_than 1800-01-01 , or no_later_than 1963-11-22. The sophisticated way in which opening hours tagging has been handled suggests that this is viable if the values are controlled by the edit interface and are thus not truly freeform.

This provides a baseline which requires the addition of

• a dialogue or control on start of the edit session to set the basic timesnapshot
• an additional control on the standard edit panel: for Potlatch this may be directly configurable, although preventing it being shown in Advanced Edit mode will require coding work.

Now comes the harder bits. These are:

• Modifying how the editor pulls data down from OHM through the standard OSM API which is not temporally aware. The simplest case is to pull everything down and only expose elements which fall into the appropriate temporal range. The best analogy to this is JOSM's Purge menu option. Untagged nodes will present a particular problem, as they need to be purged based on whether their parent's temporal tags.
• Changing the temporal tags of an existing element. If temporal ranges are extended this may create conflicts with existing ways in another time period. I think we have to live with that and have tools to resolve such conflicts. If the range of temporal element is contracted then the relevant element needs to be split into two (when only start or end date is changed) or three (when both are changed).
• Changing the geometry of an existing temporal element. Geometry changes may only apply to the relevant time box of the snapshot. Therefore such changes should be treated in a similar way to changing the temporal bounds of an element. For instance if I start with Derby Road as it is now as a a single way, then if I realign it in an 1800-1820 snaphot view, then this creates two ways one 1800-1820, the other 1820-future. (of course ideally the editor would split the ways in such a way that this does not occur).
• Absence of linkage across time. This is analogous to the fact that OSM has no notion of a street, so for now I don't think this is an issue. The main problem is that the time boxes of temporally adjacent elements may come adrift if edited as part of different time snapshots. Anyway, we always have relations which are the time honoured way of dealing with data which is not conveniently handled by existing editors or data consumers: i.e., an institutionalised hack!
• Shared untagged nodes. It is entirely possible and reasonable for ways from different times (epochs?) to share nodes: this is certainly allowed if temporal tags are only needed on elements with 'normal' tags. A classic example, which current OSM tagging allows for, are cycleways on old railway alignments. The problem arises when someone wants to refine the geometry of one of the relevant ways for a given snapshot time. Logically we cannot know that the shared nodes are always shared in all time periods, so a change in geometry of a shared node should require that the new position be represented by a new node.
• Merging elements across time periods. All our editor views are geographical. Additional tools or interfaces will be needed to recombine ways with disjunct temporal tags. This will be necessary as the above default actions may create many ways representing the same object which could be combined.
• Validation and QA tools. A host of new validation and QA utilities will be needed. Particularly tools will be needed to spot overlaps and gaps in elements over time rather than space. Suitable visualisations of

I can see existing features in various OSM editors which handle some of these aspects, but given the different approaches and code-bases I suspect some things are much easier adding to one editor than another. One approach would be to try and decompose the actions further so that there might be some possibility of adding them directly to the underlying object model of the editor: that of iD was nicely described by John Firebaugh in a series of posts last year.

I know chippy thinks there is an element of running before we can walk in these thoughts. I certainly dont have his technical knowledge or, perhaps more pertinently, his knowledge of the Ruby on Rails platform. However, these notes are really aimed at avoiding, at least for now, any kind of fork of the core OSM infrastructure for OHM.

In the mean time I'm going to spend some time with 19th century street directories like this sample:

Extract from 1840 Street Directory of Nottingham
CC-BY-SA-NC from Leicester University Special Collections.

A list of street names is a great place to start the hunt for reconstructing the road layout of the city 175 years ago. Unfortunately I cant use this particular source because of the restrictive licensing, but I will be visiting a local library which has these volumes next week so will get some copies then.