A Shared Data Model for Historical Transport Networks

The English Channel and North Sea, from Adriaen Coenen’s Visboek (1578). © Koninklijke Bibliotheek, Netherlands.

This drawing from Adriaen Coenen’s remarkable ‘Fish Book‘ indicates seaports on both sides of the English Channel and the North Sea. Much of the trade between these ports was recorded in the Exchequer Port Books of England and Wales (from 1565), and also in the Danish Soundtoll Registers (from 1497), opening the possibility of mapping overseas trade networks. Overland trade routes have been the subject of numerous studies in recent years, using digital mapping to give deep insights into domestic economic networks. Among the most recent and ambitious of these projects is Viabundus, which aims to produce a digital map of transport routes in Northern Europe between 1350 and 1650.

Such studies tend to limit their scope to national borders, due largely to the geographic limits of record-keeping, and each study produces a new dataset tailored to the particular characteristics of the primary records used to generate them. Analysis of historical international trade is hampered by the lack of a lingua franca for modelling the fundamental elements of these data, that is the trading places and the routes between them (expressed mathematically as nodes and edges).

 

Existing methodologies may be convenient for individual projects and organisations but the fragmented and inconsistent approaches to collating and sharing spatial data devalue and limit the potential of these resources. Approaches to presenting spatial data are project driven, and thinking framed by traditional publications rather than seizing the opportunities digital technologies present in enabling data reuse.
McKeague, P. et al 2017

 

The recently-launched World Historical Gazetteer employs a data model described here. Although limited (for now) to point data, it appears to be a good basis for extension. One option would be to develop and publish a simple GML Application Schema,1Application schemas are normally designed using ISO 19103 (Geographic information – Conceptual schema language) conformant UML, and then the GML Application created by following the rules given in Annex E of ISO 19136. perhaps using the GeoNetwork platform. Any data shared and conforming to this schema might easily be rendered in any web interface developed according to local requirements, or downloaded for geospatial or other historical economic analysis. McKeague et al (and others working in cultural heritage) favour a spatial data infrastructure based on the INSPIRE Directive.

ExPLOT is a recently-established ‘interdisciplinary group of scholars who are exploring past landscapes using a range of digital and computational tools to research the geographies and histories of times past’. The group invites anyone interested to join their mailing list.


Current suggestions for node and edge properties and attributes (based on the Viabundus model) are listed below.

Node Properties
Property
Required
Format
Notes
Country Yes ISO 3166 Modern-day country code.
ID Yes Integer An identifier unique within the specified country.
Parent ID No Integer A node may be defined as a child node. For example, a settlement node may have child nodes representing markets, fairs, quays or bridges. In most cases, the parent node will be the central square or marketplace. However, there can be good reasons to assign a different place in a town as parent. Only nodes within a town should become child nodes. For example, in case of a junction in front of a town gate, which one can theoretically pass without entering the town itself, the node should not become a child of the town, but rather an independent node. The same goes for watchtowers which belong to the defensive line of the town, but are located outside them. These should be included as independent nodes.
Type Yes Text One or more of the following, separated with a semicolon: Settlement; Town; Market; Fair; Toll; Staple; Harbour; Ferry; Bridge; Lock; Junction.
Name Yes Text The name of the node that will be displayed on the map. For towns, this is usually the official modern name of the town in the local language, i.e. Aabenraa instead of Apenrade, Kaliningrad instead of Königsberg; Warszawa instead of Warsaw/Warschau; Bad Bentheim instead of Bentheim.
Alternative names No Text The field for modern names of towns in English or German when they are different from the official name (i.e. Danzig for Gdańsk), historical names from the sources, and names in the Cyrillic alphabet. Especially for the first category, inclusion of these names is very important, to facilitate searching on these names. Multiple entries should be separated with a semicolon.
Geometry Yes Point The coordinates of the node, expressed as a Latitude/Longitude pair.
Geonames ID No Integer The ID number of the place on geonames.org. Filling this field in helps with the identification of a place and its localization. Moreover, the geonames database includes alternate names in other languages, sometimes also historical names.
Zoom level No Integer This field sets the mininum zoom level of the map, on which the node will be shown. The higher the number, the further the user has to zoom in to see the node on the map.
Comments No Text Comments for internal use, not intended to be shown to the user.
Node Attributes
Property
Required
Format
Notes
From No Integer The years between which the attribute is valid. In most cases, the From field contains the year in which the attribute is first mentioned. In some cases, however, it makes sense to enter an earlier year. Also, it is only possible to enter complete years, which means that it is not possible to enter values like 13th century or before 1456. In such cases, enter 1200 and 1456 and add an explanation in the Description field. You can leave (one of) these fields blank, which means that the final application will interpret the attribute as being valid for the entire time frame (1350-1650).
To No Integer (see above)
Dates No Text The years between which the attribute is valid. Expressed as YYYY-, or YYYY-YYYY, or -YYYY. In most cases, the first parameter contains the year in which the attribute is first mentioned. In some cases, however, it makes sense to enter an earlier year. Also, it is only possible to enter complete years, which means that it is not possible to enter values like 13th century or before 1456. In such cases, enter 1200-1299 or -1456, and add an explanation in the Description field.
Day of Week No Integer [1-7] Relevant for Weekly Markets. 1 = Monday (ISO 8601).
Gregorian calendar No Integer The year in which the settlement introduced the Gregorian calendar. This is necessary for a correct calculation of fair dates after 1582. It is also possible to enter more than one period, in which case the start and end year should be separated with a hyphen -, and the separate periods with a semicolon ;. E.g.: 1582-1613; 1648 for a town which used the Gregorian calendar between 1582 and 1613 and from 1648 onwards. If the field is left blank, it is assumed that the Julian calendar was used until after 1650.
Category No Text Fairs are divided into three categories: local, regional and interregional. These are important for identifying the region in which the fair is likely to have attracted visitors. Local fairs would most likely attract only merchants from nearby towns (1-2 days of travel time), regional fairs would be appealing to merchants from a wider region. Interregional fairs are the large international fairs such as those in Frankfurt, Leipzig or Skåne. It is sometimes hard to assign a fair to a category. In this case the duration of the fair (if known) can provide suggestions: local fairs often do not last more than a day, whereas fairs with a duration for over two weeks are likely to have been interregional.
Duration No ? The duration of a fair defines the time frame of the fair around the mentioned date. It consists of a start day and end day, which can be defined as certain and uncertain.
Description No Text Short description of the attribute, which will be shown to the user. This is the place to add comments about the specific character of an attribute, uncertainties in the dating, references to archival sources, etc.
References No ?
Edge Properties
Property
Required
Format
Notes
Country Yes ISO 3166 Modern-day country code.
ID Yes Integer An identifier unique within the specified country.
Traffic No Text Classes of traffic to which the edge is suited. Any of the following, separated with a semicolon: Foot; Horse; Cart; Boat.
Name Yes Text The name of the edge that will be displayed on the map.
Alternative names No Text The field for modern names of roads in English or German when they are different from the official name (i.e. Danzig for Gdańsk), historical names from the sources, and names in the Cyrillic alphabet. Especially for the first category, inclusion of these names is very important, to facilitate searching on these names. Multiple entries should be separated with a semicolon.
Geometry Yes Polyline The coordinates of the edge, expressed as a sequence of Latitude/Longitude pairs.
Directional Yes Boolean Determines whether an edge is unidirectional. For example, a waterway which can only be used downstream would be assigned the value 'true', the useable direction being determined by the order of the coordinates defining the edge.
Dates No Text The years between which the edge existed. Expressed as YYYY-, or YYYY-YYYY, or -YYYY
Type Yes Text One or more of the following, separated with a semicolon: Land; Water; Ferry.
Certainty No Integer A number (1-3) indicating certainty about the reconstruction of the line. 1 is completely certain – i.e. mostly within towns with an unchanged road system, 2 is mediocre – the default, and 3 is where a guess has to be made where the road was located. Category 3 edges should be displayed on a map with a dotted line, so that the user does not get a false idea of accuracy.
Zoom level No Integer This field sets the mininum zoom level of the map, on which the edge will be shown. The higher the number, the further the user has to zoom in to see the node on the map. This field might be used to categorise the national or local importance of edges.
Length Yes Real Length of the edge in metres.
Elevation No Real Net gain in elevation along the edge.
Resistance No Real Cumulative gains in elevation along the edge. This is a measure of all the uphill sections of the edge, and unlike the Elevation parameter ignores downhill sections. Useful in least cost path calculations.
Comments No Text Comments for internal use, not intended to be shown to the user.
References No ?