OS Multi-modal Routing Network
Introduction
OS Multi-modal Routing Network is a fully connected network dedicated for the multi-modal routing of people and goods, designed for use in routing applications. It contains connectivity between different modal networks and key transport sites, along with road restriction information and speed data.
OS Multi-modal Routing Network is a routable network providing connectivity between Road, Path, Ferry, and Rail data from other OS data sources brought together by Modal Change Points.
How has this product been created?
OS Multi-modal Routing Network was designed and built using the OpenStreetMap schema to facilitate straightforward import into many open-source and proprietary routing applications. It takes existing OS network and routing data (available in the OS NGD) and maps this to the OpenStreetMap schema. New connectivity is added in the form of modal change points, which are key interchange sites where you can transition between different transport modes, such as from foot to ferry or from rail to road. Additionally, the dataset contains road restriction information and speed data.
This enables simple A-to-B routing straight out of the box, and more complex and optimised multi-modal routing for those with more advanced routing or software knowledge and access to third-party data.
Key features of the product
Fully connected
OS Multi-modal Routing Network brings together existing OS Road, Rail, Path and Ferry networks in a single fully-connected dataset, using Modal Change Points to show where it is possible to transition between them, for example at railway stations and ferry terminals.
Ready-to-use
All the road restriction information needed for routing is included, as well as speed data, reducing the pain points of processing and joining multiple datasets.
OpenStreetMap schema
OS Multi-modal Routing Network is built in the OpenStreetMap schema, which is widely supported by routing software, enabling use in a range of applications.
The OS Multi-modal Routing Network premium product contains three feature types: Transport Link, Transport Node and Turn Restriction.
Transport Link
A Transport Link is a representation of where people can travel along our network.
Transport Links are linear spatial objects that define the geometry and connectivity of a road, path, rail, or ferry network between two points in the network. Transport Links are split for connectivity purposes (for example, at junctions) and Transport Nodes connect the Transport Links together. Each Transport Link provides a reference to the Transport Nodes in direction order from start to end.
Transport Links take information from the following OS NGD datasets and combine them into one feature type:
- OS NGD Road Links
- OS NGD Path and Connecting Links
- OS NGD Ferry Links
- OS NGD Railway Links
- OS NGD Access Restrictions
- OS NGD Speeds
Transport Links also incorporate Modal Change links which are a linear spatial object representing a logical connection between the transport network and a transport site.
Transport Links contain information about the type of link (for example, 'highway'='motorway') and information about the access restrictions for vehicles to indicate which modes can travel along the link (e.g., 'motor_vehicle'='yes'). There is also a maximum speed attribute, and two average speed attributes:
a conditional delimited list of all the speeds at different time periods
a single average speed using the Mon-Fri 12-2pm period.
The Transport Link is attributed with a unique (but not persistent) 'wayid', which routing software uses to build out the network. Transport Links are also attributed with the OSID of the corresponding OS parent feature that is published in the OS NGD Transport Theme.
Transport Node
Transport Nodes take information from the following OS NGD datasets and combine it into one feature type:
- OS NGD Road Nodes
- OS NGD Path and Connecting Nodes
- OS NGD Ferry Nodes
- OS NGD Railway Nodes
Transport Nodes build up the topology of the network and connect Transport Links together. They also represent Modal Change points where you can change travel modes.
A Transport Node is a point spatial object that is used to break up the Transport Network for connectivity. The Transport Network splits at the following locations:
Where an attribute changes.
The intersection or crossing of Transport Links.
The start / end of a Transport Link.
Modal Change nodes have been derived from specific transport sites (railway stations, ferry terminals, bus stations, docks, coach stations, tram stations, air terminals, airfields) and the point sits in the primary building of that site.
Transport Nodes are also present at every vertex along the network. These vertex nodes don’t split the network; they are provided to enable software that reads in OpenStreetMap (OSM) data to build up the network vertex by vertex. The vertex nodes allow customers to convert from GeoPackage format to OSM.
The Transport Node will be attributed with a unique (but not persistent) 'nodeid' and also the OSID of the corresponding OS parent feature that is published in the OS NGD Transport Network Collection.
Turn Restriction
A Turn Restriction highlights the line geometry of a turn and provides attribution that indicates turn restrictions for the given Transport Link (for example No right turn or No U turn) as well as any vehicle exemptions.
Where the Turn Restriction applies to specific vehicle type (for example, bus or HGV), this is identified by the corresponding separate attribute as described below, along with conditional values for when the turn restriction only exists on specific times or days.
The Turn Restriction is attributed with the OSID of the corresponding OS parent feature that is published in the OS NGD Transport RAMI Collection.
Turn Restrictions are named following a from-to-via pattern, where:
- 'from' is the 'wayid' of the first Transport Link involved in the turn restriction.
- 'to' is the 'wayid' of the last Transport Link involved in the turn restriction.
- 'via' is the 'nodeid' of the Transport Node at the junction (when there are only two links involved in the turn restriction), or a 'wayid' list of all the Transport Links which are not the from or to link (when there are more than two links involved in the turn restriction).
Modal Change
OS Multi-modal Routing Network contains Modal Change points to represent where you can transition between different transport modes (shown in pink in the image to the left). The OS Multi-modal Routing Network takes keys sites such as train stations, ferry terminals and car parks, and creates modal change points at these locations to enable connectivity.
Modal change connectivity is only provided between sites and the road, rail and ferry network. Modal change points do not connect to the Path network as we do not currently capture access points from paths to sites in OS data.
Within the Transport Link feature type there are Modal Change links which are a linear spatial object representing a logical connection between the transport network and the transport site. These Transport Links connect between the network and the Modal Change node.
Within the Transport Node feature type there are Modal Change nodes which are derived from transport sites. A node is created and sits within the primary building of the site. It is attributed with the 'os_nodetype' of ‘Modal Change’.
Grade Separation
Where Transport Nodes have been split apart due to grade separation, i.e., where Transport Links cross each other at different levels such as at an underpass or a bridge, the original node keeps the existing OSID and the additional nodes are indicated with the suffix --1 or --2, depending on the grade separation value. Also, the geometries of grade separated Transport Nodes are offset (5cm in both the X and Y axes) to prevent routing software failure due to point spatial objects being at the same position.
If a Transport Link has a different grade separation at the start and end node, the link is split. The OSID of the new Transport Node between the split links is indicated with a suffix of --S. One of the Transport Links keeps to original OSID and the other has the suffix of --S.
In the example to the left, there are entrance and exit roads associated with an underground carpark that have another service road passing over them. Two Transport Nodes are shown at each location where the Transport Links cross each other (but with a 5cm offset) with one of each pair of Transport Nodes given a --1 suffix to its 'os_parentid' attribute value to indicate its relative grade separation level.
Attribution
The following section provides details about the main attributes included with the various feature types. Other attributes exist for each feature type that are not detailed in this Story Map for the purposes of brevity. Full details, including the attribute data types in the different output formats and other metadata can be found within the Technical Specifications available from the NGD Documentation platform.
Transport Link
Each Transport Link is given a unique numerical ID, the 'wayid', which is commonly used by routing software as the primary identifier for the feature.
Multi-modal Routing Network Transport Links are derived from features in the OS NGD Transport Network Collection (road, path, rail, ferry) and the OSID of the corresponding NGD Transport Network feature is attributed here as the 'os_parentid'. In the case of grade separation, the 'os_parentid' will have a suffix of --1 or --2, etc. corresponding to the level of grade separation.
Transport Link attribution also references the OSID of the node from the relevant OS NGD Transport Collection feature at the start and end of the link: 'os_startnode' and 'os_endnode'.
If the Transport Link is a road link, the minimum width of the link is provided in the 'os_roadwidthminimum' attribute value. For rail, ferry, path, and modal change links, this value will be NULL.
The 'name' attribute represents the name given to the Transport Link to identify it, e.g., road name, number, or description. If there is a known alternative name, or a name known in an alternate language (Welsh or Gaelic), then these will also be provided.
For road or path features, the 'ascent:forward' and 'ascent:backward'; attribute values give the total accumulated height gain in metres in and against the direction of digitisation, respectively.
The 'access' attribute describes the nature of the access permitted to the Transport Link. A value of 'yes' indicates that access by the general public is assumed, but does not imply an official, legally enshrined right of way. If there is an access restriction in one direction of digitisation only and not in both directions then the 'access:forward;' or 'access:backward' attribute value will be populated.
The 'foot' attribute indicates whether a Transport Link can be traversed by foot and whether there is designated infrastructure for walking along the link, such as a pavement. In the example to the right, a value of 'designated' means that the link is a preferred route for foot traffic as generally indicated by a sign. Pavement presence is also provided via the 'os_overallpavementpresence' attribute, which gives a value for the percentage of the link that is served by a pavement.
For Transport Links that represent road or path features, the 'highway' attribute describes the type of road or path represented e.g. 'motorway', 'primary', 'footway', 'steps', or, as in the case of the example to the right, 'residential'.
Transport Links that represent railway features have the 'railway' attribute populated with a value that describes the type of railway infrastructure represented, e.g., 'rail', 'tram', 'preserved', 'disused', etc.
The 'rail' and 'ferry' attributes are used to indicate whether the Transport Link is accessible by rail or by ferry (value of 'yes' or 'no').
The next set of Transport Link attributes indicate whether there are any specific access restrictions for vehicles where a maximum permitted weight (in tonnes), height (in metres), width (in metres) or length (in metres) has been specified.
The '...:forward' and '...:backward' attributes will only be populated if the access restrictions only apply in the direction of digitisation of the link and not in both directions, e.g., if the link is a one-way link.
In the image to the right, the link has a maximum height restriction in both directions of travel of 4.8m, but no weight, width, or length restrictions.
Speed data is provided in several attributes. This information is needed for network analysis and route planning tools to determine the time taken to travel along the Transport Link. Speeds are provided for motor vehicles only, so speeds for other modes of transport will likely be required to be input into network and routing software manually where required.
The 'maxspeed:forward' and 'maxspeed:backward' attributes provide information about the speed limit along the Transport Link in the direction of and against the direction of digitisation of the link, respectively, in kilometres per hour (kph).
The 'averagespeed:forward' and 'averagespeed:backward' attributes provide information about the average speed on a Transport Link in the direction of and against the direction of digitisation of the link, respectively, during Monday to Friday between 12:00 and 14:00.
The 'averagespeed:forward:conditional' and 'averagespeed:backward:conditional' attributes break down the average speed data into more granular time periods.
The 'nodes' attribute provides a list of all the Transport Node IDs that the Transport Link is associated with in direction order start to end.
Attribution is provided to enable the transport network restrictions to be modelled for the following modes of transport or vehicle types: motor vehicle, bicycle, motorcycle, moped, public service vehicle (psv), coach, bus, goods vehicle, heavy goods vehicle (hgv), taxi, a vehicle towing a trailer, a vehicle towing a caravan, emergency vehicle, a vehicle carrying hazardous material, and disabled person's vehicle.
The attribution for the motorcycle mode of transport is highlighted in the image to the right. These attributes designate whether the Transport Link can be traversed using this mode of transport in both directions of travel, or just one direction of travel (forward or backward with respect to the direction of digitisation). In this case the link is one-way and can only be travelled in the backward direction of digitisation (indicated by a value of 'yes' in the 'motorcycle:backward' field)
If the nature of access is conditional on the day of the week or time of day, then values will be present in the '...:conditional' fields expressed in OpenStreetMap time-conditional formatting.
The same set of attributes are available for each of the modes of transport listed above.
The 'oneway' attribute indicates whether there is a one-way restriction on a Transport Link. A value of 'yes' indicates that travel is only permitted in the direction of digitisation of the Transport Link, '-1' indicates travel is permitted only against the direction of digitisation of the Transport Link (as in the case illustrated to the right), and 'no' indicates travel is permitted in both directions.
If the one-way restriction along a Transport Link varies depending on specific times or days, then the time periods will be populated in the 'oneway:conditional' attribute value in OpenStreetMap time-conditional formatting, for example, 'no @ (Mo-Su 07:30-18:30)'. When outside of the specified time / day(s), then the value in the 'oneway' attribute applies
Attributes are also present to indicate whether one-way restrictions apply to bicycles specifically. If Null, the value in the 'oneway' or 'oneway:conditional' restriction applies.
Transport Node
The 'nodeid' is a unique numerical ID given to each Transport Node. This is commonly used by routing software as the primary identifier for the feature.
The OSID of the corresponding feature that is published in OS NGD Transport Network Collection is represented in MRN as the 'os_parentid'. Where Transport Nodes have been split apart due to grade separation, the original node will keep the existing OSID and the additional nodes will be indicated with the suffix --1 or --2 depending on the grade separation value.
The 'os_nodetype' describes the type of node. Where the node represents a site of modal change, this attribute will describe the type of interchange site where appropriate e.g. 'Ferry Vehicular Terminal', 'Railway Station' and/or 'Modal Change'
If the Transport Node has an official name that is recorded in the OS NGD Transport Network Collection, such as that given to a junction, roundabout, or motorway junction, this is given in the 'name' attribute value.
Turn Restriction
A unique numerical ID is given to each Turn Restriction through the 'relationid' attribute value. This is commonly used by routing software as the primary identifier for the feature.
The osid of the corresponding feature that is published in OS NGD Transport Network Collection is given in the 'os_parentid' attribute.
The 'type' attribute describes the type of relation. All relations take value 'restriction' to describe how they should be applied.
The 'restriction' attribute describes the type of turn restriction, e.g., 'no_right_turn', 'only_straight_on'.
If the turn restriction only exists on specific times or days then the time periods will be populated in the 'restriction:conditional' attribute value in OpenStreetMap time conditional formatting , e.g. 'no_right_turn @ (Mo-Fr 07:30-09:30)'
Similarly, if a turn restriction applies only to a specific vehicle type, e.g., HGV, bus, or wide loads, then the corresponding attribute for that vehicle type will be populated with the type of turn restriction.
Turn Restrictions are described in a from-to-via manner. The wayid of the first and last Transport Links involved in the turn restriction are identified in the 'from' and 'to' attributes, respectively.
If the Turn Restriction only involves two Transport Links (the 'from' and 'to' links) then the 'via' attribute identifies the Transport Node at the junction where the Turn Restriction applies. If the Turn Restriction is more complex, the 'via' attribute will provide a list of wayid's of all the Transport Links that are involved in the Turn Restriction that are not the 'from' or 'to' Transport Links.
How to use this product
There are a number of software options available for using OS Multi-Modal Routing network and we have highlighted some of these in this section. However others are available and please check with your software provider for further details.
Software name | Software description | Software type | Ease of use |
|---|---|---|---|
R5py | R5py uses Python, based on R5 (Rapid Realistic Routing on Real-world and Reimagined networks). It is simple to use within an existing Python setup and is commonly used for statistical analysis around travel times. It can take into consideration different walking speeds and public transport access points to give indications on access to different amenities. To use it requires the library to be installed, using pip (or similar) to install, and it can read in MRN directly in the .pbf format. | Open | Easy |
QGIS - QNEAT3 | QGIS has plugin tools for network analytics such as service area and shortest path. One of these is QNEAT3 which is simple to use and gives a visually clearer output. MRN data can be used in Geopackage format but will need to be reprojected. | Open | Easy |
pgRouting | An extension of the open-source PostgreSQL database which requires the network data to be loaded into it first, and network edge and node ID’s to be created. Provides geospatial routing functionality that can take advantage of indexing and can give more options for what to do with the output. | Open | Moderate |
graphhopper | An Open-source routing library that uses Java. It has the same routing functionality as pgRouting but requires more setup and post-processing of the network data. Useful for travel matrices operations and can be served through API too. | Open | Moderate |
Valhalla | A versatile routing engine written in C++. It requires a bit more background knowledge in coding, but once familiar, it can become plug-and-play friendly with different routing datasets, especially multi-modal networks. | Open | Moderate |
Esri Network Analyst | Route planning and optimisation, providing route solving, multi-modal functionality and operation analysis. Can read in different sources and formats of network data but needs work to set-up the network. Once the network is created, it has easy-to-use to tools to perform analysis. Requires an ArcGIS license to use. | Licensed | Moderate to Hard |
MapInfo Pro | Offers routing functionality with a number of add-on tools including RouteFinder. Data can be read as a Geopackage although set up of the network is required. Has a range of simple-to-use tools for analysis. Requires a MapInfo Pro license to use. | Licensed | Not tested |
Basemap TRACC | MRN is supported in the latest release using Data Cutter to define an AOI. Can be linked to public transport stops and data. | Licensed | Not tested |
Use cases
OS Multi-modal Routing Network can be used for journey planning, routing, navigation, and distance and travel time analysis, to support use cases such as:
- Safe routes to school planning.
- Emergency services planning and response.
- Transport planning.
- Supporting Active Travel initiatives.
- Planning of accessible citizen services.
This image shows an example of where OS Multi-modal Routing Network data has been used to generate walk time isochrones around secondary schools.
The light blue isochrone polygons represent 10 minute walk times to secondary schools (shown as blue circles) in South London and were created using the Service Area analysis type in the Network Analyst tool in Esri ArcGIS Pro.
The image also incorporates bus stop location data from the National Public Transport Access Nodes (NaPTAN) dataset - shown as dark pink circles. This could be combined with public transport timetable information such as Bus Open Data Service (BODS) to give even greater analytical insight and illustrates the potential for OS Multi-modal Routing Network to support a multitude of use cases.
How to get this product
The OS Multi-modal Routing Network product is available as a premium data download from the OS Data Hub. It is available as a Full Supply only, and customers can order full GB coverage or a customisable Area of Interest (AOI).
Formats
It is available in two formats:
- Protocolbuffer Binary Format (PBF)
- GeoPackage (GPKG)
PBF is an open source transfer format for vector GIS data created by the OpenStreetMap (OSM) community. PBF is an alternative to the original OSM XML format. PBF files are generally much smaller than OSM XML files and are faster to read and write.
Update frequency
The OS Multi-modal Routing Network product is updated monthly in line with updates of the underlying OS transport network data.
Coordinate reference system
The coordinate reference system used by the OS Multi-modal Routing Network product is the World Geodetic System (WGS84: EPSG: 4326). This applies to both the PBF and GPKG formats and, as a result, some software users will need to reproject the data. The WGS84 spatial reference system uses the WGS84 geodetic datum. Positions on this projection are described as latitude and longitude, and coordinates are provided in decimal degrees.
This StoryMap has been created using the following data:
- OS Multi-modal Routing Network
- OS MasterMap Topography layer
- OS Maps API
- Department for Transport National Public Transit Access Nodes (NaPTAN) data available under the Open Government Licence v3.0
Information on OS's National Geographic Database (NGD) Transport theme, including Road, Rail, Path, and Ferry data, can be found on our OS NGD Documentation platform.
Information on the Multi-modal Routing Network can be found on the OS Download Products Documentation platform
More StoryMaps can be found on our More Than Maps platform.
Further details on all OS data products and services can be found from OS Data Products.
