utilising ordnance survey map data with sumo traffic...

33
Utilising Ordnance Survey Map Data with SUMO Traffic Simulator Author: Gregory Albiston PhD Research Student Nottingham Trent University Date: March 2016

Upload: phungkhanh

Post on 09-Mar-2018

223 views

Category:

Documents


4 download

TRANSCRIPT

Utilising Ordnance Survey Map Data with SUMO Traffic Simulator

Author: Gregory Albiston

PhD Research Student

Nottingham Trent University

Date: March 2016

Contents Overview ........................................................................................................................................................................... 5

UPP Secondment Context ................................................................................................................................................. 5

Objectives.......................................................................................................................................................................... 5

Investigatory Justification ................................................................................................................................................. 5

Contextual & Technical Information ................................................................................................................................. 7

SUMO Traffic Simulator ................................................................................................................................................ 7

Supported File Formats ............................................................................................................................................. 7

Esri Shapefile ................................................................................................................................................................. 7

Open Street Map (OSM) ............................................................................................................................................... 7

Ordnance Survey (OS) ................................................................................................................................................... 8

OS MasterMap .......................................................................................................................................................... 8

OS OpenRoads........................................................................................................................................................... 8

OGC Geographic Markup Language (GML) ................................................................................................................... 9

EXtensible Stylesheet Language Transformation (XSLT) ............................................................................................... 9

Advantages ................................................................................................................................................................ 9

Disadvantages ........................................................................................................................................................... 9

Implementation .............................................................................................................................................................. 10

Context Summary ....................................................................................................................................................... 10

Design Options ............................................................................................................................................................ 10

Option 1: Develop custom parser to extend NETCONVERT application ................................................................. 10

Option 2: Convert GML (XML based) to SUMO input files (XML based)................................................................. 10

Option 3: Generic integrated XSLT parser to extend NETCONVERT application .................................................... 11

Implemented Features .................................................................................................................................................... 12

Nodes & Edges ............................................................................................................................................................ 12

One Way Edges ........................................................................................................................................................... 12

Roundabouts & Mini-Roundabouts ............................................................................................................................ 12

Grade Separation ........................................................................................................................................................ 13

Turning Restrictions: Mandatory Turn & No Turn ...................................................................................................... 13

OS MasterMap Potential Features .................................................................................................................................. 14

Buildings, Land Use, Points of Interest ....................................................................................................................... 14

Bus stops, rail links – NaPTAN dataset ........................................................................................................................ 14

Pedestrian Footpaths & Cycle Paths ........................................................................................................................... 14

Restricted Access: No Entry, Limited Access, Prohibited Access ................................................................................ 14

Road Altitude .............................................................................................................................................................. 14

Limitations of OS MasterMap with SUMO ...................................................................................................................... 16

Number of lanes .......................................................................................................................................................... 16

Local road speed limits ............................................................................................................................................... 16

Traffic Signal Location and Sequencing ...................................................................................................................... 16

Pedestrian Crossing Locations .................................................................................................................................... 17

Limitations of SUMO with OS MasterMap ...................................................................................................................... 18

Pedestrians .................................................................................................................................................................. 18

Edge Access Permissions ............................................................................................................................................. 18

Edge Access ............................................................................................................................................................. 18

Private Roads .......................................................................................................................................................... 18

Vehicle Max Height Based Restrictions ................................................................................................................... 18

Date & Time Based Restrictions .............................................................................................................................. 19

Edge/Lane Connection Exceptions .......................................................................................................................... 19

Evaluation ....................................................................................................................................................................... 20

SUMO Road Network .................................................................................................................................................. 20

Statistical Comparison ................................................................................................................................................ 21

Issues Summary .............................................................................................................................................................. 23

Road Specific Information ........................................................................................................................................... 23

Traffic Signal and Pedestrian Crossing Locations ........................................................................................................ 23

Traffic Signal Sequencing ............................................................................................................................................ 23

Traffic Signal Controlled Pedestrian Crossing ............................................................................................................. 23

Edge Access Restrictions ............................................................................................................................................. 23

Partially Complete Roundabouts ................................................................................................................................ 23

Grade Separation ........................................................................................................................................................ 23

Altitude Data ............................................................................................................................................................... 23

Turning Restrictions Vehicle Exemptions .................................................................................................................... 24

Self-Looping Edges ...................................................................................................................................................... 24

GML Clipping Tool ....................................................................................................................................................... 24

Co-ordinate Reference System ................................................................................................................................... 24

SUMO Network Analysis ............................................................................................................................................. 24

Ordnance Survey Documentation ............................................................................................................................... 24

Recommendations .......................................................................................................................................................... 26

Conclusion ....................................................................................................................................................................... 26

Future Work .................................................................................................................................................................... 26

References ...................................................................................................................................................................... 27

Appendix A: Road Route Information Qualifiers - OS MasterMap ITN Technical Specification ..................................... 29

Appendix B: Estimation of Number of Lanes in Topographic Layer ............................................................................... 31

Appendix C: Supplementary Gradient Data - OS MasterMap ITN Technical Specification ............................................ 32

Appendix D: Software Development Notes .................................................................................................................... 32

Netconvert: SUMO Plain XML to SUMO (*.net.xml) ................................................................................................... 32

Netconvert: Open Street Map (*.osm.xml) to SUMO Network (*.net.xml) ............................................................... 33

Study Area Bounding Box ............................................................................................................................................ 33

Open Street Map Discounted Edges Types ................................................................................................................. 33

Appendix E: SUMO Issues Log ......................................................................................................................................... 33

Overview The purpose of this report is to examine the capability of Ordnance Survey datasets to support conversion to SUMO

traffic simulator road network format, identify an appropriate approach for the format conversion, implement a

proof of concept of a minimum road network and provide recommendations for enhancement of the dataset or

traffic simulator to meet the objective of simulating high quality traffic scenarios. The viewpoint has been to achieve

as much of the conversion process as possible without manual intervention.

The completion of the work outlined in this document will provide the UK SUMO community with a readily

accessible source of high quality data for UK traffic simulation and identify how these existing datasets can be

further developed to assist the objectives of traffic simulation.

UPP Secondment Context This work was undertaken as a secondment between the author at Nottingham Trent University and the Transport

Systems Catapult as part of the IMPART Project under the University Partnership Program. The secondment took

place 3rd-18th February 2016 and was presented at the IMPART “Combining traffic simulation models for advanced

traffic simulation” workshop on 24th February 2016.

Objectives • Gap analysis between OS datasets and SUMO network format for the purpose of road network traffic

simulation.

• Identification of requirements for format conversion process.

• Recommendations for enhancement of OS datasets and SUMO simulator to maximise existing capabilities of

both.

• Recommendations for enhancement of OS datasets and SUMO simulator to meet the objectives of high

quality traffic scenarios.

• Identification of alternative datasets to support objectives of high quality traffic scenarios.

• Proof of concept format conversion from OS dataset to SUMO network format for a minimum functional

road network simulation.

Investigatory Justification A key input in traffic simulation is the road network, and associated supporting information. A common public

source for this dataset is Open Street Map (OSM) (Open Street Map 2014) which provides global coverage of free

geographic data. While being a significant open-source project, OSM was not specifically designed to capture road

information and suffers from issues due to inconsistent quality and labelling related to its international scope,

flexible data structure and community based maintenance. Efforts are underway to highlight tagging inconsistencies

for Great Britain specifically (Tag Info 2016) and tagging errors more generally (MapBox 2016) but a definitive

approach has not yet emerged.

A popular traffic simulator in academic research is the open source SUMO simulator (Krajzewicz, Erdmann et al.

2012) which is able to convert the OSM format into its own road network format. However, this conversion process

applies heuristic methods to infer or assume missing information in the OSM dataset to meet the needs of traffic

simulation. The result of this are simulation road networks that require manual error checking and cleaning which is

prohibitive in scenarios beyond small scale. Examples of issues resulting from this process include missing stop signs,

lack of traffic lights, deprioritised traffic light sequencing, undedicated lane connections at junctions, lack of local

road speeds and disconnected road segments preventing vehicle routing throughout the entire road network.

Enabling UK traffic researchers to be able to quickly construct traffic simulations from high quality and consistent

data that fully captures the road network will provide dividends in time, cost and quality of research. However, the

issues mentioned previously represent significant short and long term challenges to improving the OSM dataset, it’s

applicability for traffic simulation and resources required to sustain those changes.

The UK government has actively sought to make public data openly available (data.gov.uk 2016). This has included

encouraging public bodies, such as Ordnance Survey (OS) (Ordnance Survey 2016b), to offer open datasets under

Open Government Licence (National Archives ) and make premium datasets available on more favourable terms for

public bodies, such as universities (Ordnance Survey 2016a) and other organisation through Public Sector Mapping

Agreements (Ordnance Survey 2016f).

The OS provides high resolution and quality road network information with a regular and sustained maintenance

programme. The OS is a commercial entity and is therefore likely to invest resources to expand its products, or

create new products, to keep relevant for its customers and is currently in the process of expanding its premium

mapping product (Ordnance Survey 2016c). It therefore represents a good candidate for consideration as an

alternative data source to OSM for UK traffic researchers.

Figure 1: Comparison of level of detail for the same residential roundabout in Milton Keynes for Google Maps (top left), Open Street Map (top right) and OS MasterMap (bottom centre).

There is distinct contrast in the level of detail provided by different mapping products, as highlighted in Figure 1

above. While some abstraction may be applied for clarity it can also be seen that the OS MasterMap takes a very

meticulous approach to documenting detail when Open Street Map is very sparse while Google Maps has used the

same representation of a footpath (lower left quadrant of the roundabout) as for a cycle path.

The OS’s data products are provided in the geospatial standard data format GML (Open Geo Spatial 2016) with

supporting data schema (Ordnance Survey 2016d). However, these are not currently supported by SUMO as it is

typical for traffic simulators, of which there are numerous, to follow their own data schema for which specific

converters are written based on demand. Any investigation into reconciling OS with SUMO must also consider the

practical implications and achievability of undertaking format conversion with an ideal approach being one that has

the potential to be easily adapted or repurposed to satisfy multiple traffic simulators.

Contextual & Technical Information

SUMO Traffic Simulator SUMO Traffic Simulator is a free and open source simulation that is in active development and progressing towards

version 1.0 in 2017 (SUMO Traffic Simulator 2016c). It is a popular choice in traffic simulation in part due to its cost

and extendibility which has seen the community add new features and connect the simulator with third party

systems.

The simulator is a collection of interoperable standalone applications that undertake different activities during the

simulation process. The focus of this work being the NETCONVERT application which accepts road network

definitions in a number of third party file formats and SUMO’s own Plain XML files. These input files are converted

into SUMO’s Network XML (*.net.xml) format which is in turn imported into the actual SUMO Simulator application,

see Figure 2 below. It is warned that the Network XML files should not be directly generated due to complex inter-

dependencies in the file format and instead custom parsers should be developed to extend the NETCONVERT

application.

Figure 2: Overview of road network file conversion process.

Supported File Formats

Native SUMO input format (*.edg.xml, *.nod.xml, *.con.xml, *.tll.xml)

Open Street Map (OSM - *.osm.xml)

VISSIM (*.inpx)

OpenDrive(*.xodr)

Esri Shapefiles (*.shp, *.shx, *.dbf)

It should be noted that each of these file formats, except Esri Shapefiles, are XML based. The level of feature support

and usability of produced Network XML files also varies across file formats. The Esri Shapefiles (GIS file format) and

Open Street Map (global mapping service) which are very popular in GIS applications and therefore represent two

candidates for comparison when considering an alternative data source and file format.

Esri Shapefile The Esri shapefile format is a popular choice for GIS representation originally developed in junction with the ArcView

software and now more widely utilised. SUMO features a shapefile import functionality as part of its NETCONVERT

application. However, two investigations which successfully converted road networks from shape file format also

highlighted a number of issues with missing or incomplete data in the original format and conclude that the

Shapefile format is not completely usable for traffic simulations. (SUMO Traffic Simulator 2016b)

Open Street Map (OSM) Open Street Map (Open Street Map 2014) is an open source community led global mapping exercise. Its aim is to

provide a free editable world map that documents both the natural and built environment. Due to its global scope

and cost it is a popular basis for road network information. To achieve its aims a highly flexible data schema has been

adopted whereby key/value tags are assigned to objects. Any user can create, or reuse, a tag to capture any concept.

Given the international scope this enables a diverse range of scenarios to be captured. However, while guidelines are

provided there is not a mandatory or consistent schema.

This in turn means that two identical concepts could be represented in a subtly different and inconsistent manner

which makes interpretation of the dataset more complex. In addition, the community led approach relies upon

volunteers collecting and maintaining the dataset which natural leads to inconsistency in completeness and

coverage. The OSM has also not been specifically developed for traffic routing and so the data structures developed

are not necessary suited for the purposes of traffic simulation.

Figure 3: OSM “building” key tags. Source: taginfo

Where tags have been assigned the utility of the key or value can also vary considerably when being considered for

data processing. Figure 3 above highlights a number of these issues where the OSM “building” tag for Great Britain

has “yes” as the most common value. The presence of a “building” key implies that a building is present and so the

“yes” is redundant. The “house” value occurs only 786,314 times when DCLG estimates that there are 26m

households in Great Britain (Department for Communities and Local Government 2015) and it is not clear whether

“house”, “residential”, “terrace” and “apartments” are complimentary or subsets of each other. Several tools, such

as TagInfo (Tag Info 2016) covering Great Britain and OSMLint (MapBox 2016), have been developed to highlight

data quality and inconsistency but their adoption is not mandatory.

Ordnance Survey (OS) The Ordnance Survey (OS) is the UK government agency responsible for the official, definitive topographic survey

and mapping of Great Britain. It maintains a suite of interconnected mapping products under free and paid licences

(Ordnance Survey 2016e) with two, OS MasterMap and OS OpenRoads, being focussed upon road networks. These

products are made available in GML format.

OS MasterMap A licenced product is updated every six weeks and uses a unique TOID identifier to connect between several layers in

the product and to other OS products. The primary focus of this work has been the conversion of the OS MasterMap

Integrated Transport Network Layer (ITN) to the SUMO road network format.

OS MasterMap Layers:

Integrated Transport Network Layer (ITN): road network links, nodes and routing info

Topography Layer: buildings, addresses, routes, imagery, land use

Integrated Transport Network Urban Paths Layer: footways and cycle paths

Water Network: rivers, streams, lakes and canals

OS OpenRoads A free product providing core road network links and nodes but minimal detail and updated bi-annually. This product

does not make use of the unique TOID identifier and so cannot be directly linked to the other mapping products. It is

provided in large regional areas for the whole of Great Britain. Due to a limitation in GIS tool available it was not

possible to produce a tractable sample in the time available. However, the dataset of features is a subset of those

provided by OS MasterMap and an alternative template could be quickly developed.

OGC Geographic Markup Language (GML) The OGC GML (Open Geo Spatial 2016) file format is an XML grammar for expressing geographic features and can be

expanded with custom schemas to capture further concepts and data. The OGC envisages extension application

schema, such as transport, being developed by the user community to enhance the base grammar but still provide

consistent representation of information.

EXtensible Stylesheet Language Transformation (XSLT)

The eXtensible Stylesheet Language Transformation (XSLT) open standard is part of a family of standards that

includes the file format eXtensible Markup Language (XML). The purpose of XSLT is to enable the transformation

between different schemas of XML in a consistent and platform independent manner for machine processing.

Currently, version 2.0 (World Wide Web Consortium, (W3C) 2007) is the recommended standard with version 3.0

candidate recommendation (World Wide Web Consortium, (W3C) 2015) being released in November 2015.

XSLT is template based and adopts a functional programming approach where by nodes of the XML are selected

using XPath expressions for processing. The XLST templates and source XML documents are provide to the XLST

processor, either a command line tool, browser plugin or programming language specific API, which then produces

converted target XML documents. XSLT 2.0 supports the processing of multiple source and target documents so that

diverse data can be combined or divided as required. XLST 2.0 also supports parameter passing, so that a static

template can respond dynamically at the time of processing, and the importing of other templates so that a concept

hierarchy for processing can be developed.

Third-party processors are available on multiple platforms. However, only Java seems to offer a good choice of XSLT

2.0 compliant processors followed by .NET but only XSLT 1.0 seems to be supported for C++. This restriction for C++

could conceivably be circumvented, such as by invoking a Java XSLT2.0 processor within the C++ application (Oracle

Corporation 2010), but would add complexity.

Extension modules have also been developed by some processor developers to incorporate more sophisticated or

domain specific processing. One of particular interest in a geospatial applications such as road traffic simulation is

the BaseX Geo module (BaseX 2016) which supports geospatial functions, such as geometry intersection and overlap,

as specified in the OGC Simple Features Access (Open Geospatial Consortium 2016) and which is compatible with

GML encoded data.

In Java, Java API for XML Processing (Oracle Corporation 2015) provides a pluggable interface layer so that

processors can be switched dynamically to take advantage of processor specific support. In principle, XSLT can be

combined with XSD schema definitions, also a W3C standard and part of the XML family, to validate XML output but

processor support is currently highly variable.

Advantages

Multiple input or output documents can be processed by a single template.

Templates can import templates to incorporate new features and data.

Non-XML can be processed but not the intended purpose.

Third party extension modules. e.g. BaseX geo for GML geospatial calculations.

Disadvantages

XML based syntax is verbose.

XSLT processor support for version 2.0/3.0 available in Java but version 1.0 in C++.

Small changes can have large effect on results and performance.

Functional programming paradigm can be unfamiliar to many programmers.

Implementation This section outlines the design options and basis for selection in developing a converter from OS MasterMap to

SUMO Network file format.

Context Summary The following bullet points highlight the key contextual points when considering an implementation solution.

SUMO NETCONVERT supports several XML based file formats each requiring a custom C++ parser.

OS MasterMap includes a diverse range of information that could be incorporated into SUMO and other

simulators.

Additional information is available for incorporation and availability will vary from user to user.

Changes to OS MasterMap and SUMO NETCONVERT are likely to emerge over time and there will be a need

for future maintenance.

SUMO NETCONVERT already includes a large selection of general and format specific processing options

which increase or create the impression of complexity in the application.

Design Options In evaluating the design choices three possible approaches were considered. Although Option 1 to extend the SUMO

NETCONVERT application is the standard approach provided by the SUMO developers it was decided to implement

Option 2 to apply XSLT and convert the OS GML to SUMO Plain XML files. The selection of Option 2 was based on a

view to provide greater choice going forward both in terms of decoupling the conversion process from

NETCONVERT, so that it can be developed within other applications, and the greater flexibility given to the user to

incorporate new datasets.

Option 3 highlights the potential to directly incorporate Option 2 into the NETCONVERT application to simplify its

operation and potentially develop a library of templates so that a greater range of datasets and XML file formats can

be supported.

Option 1: Develop custom parser to extend NETCONVERT application This option represents the default method for supporting new formats. The C++ parser is incorporated into the

NETCONVERT package and distributed with SUMO.

Figure 4: Custom parser outline design

Advantages

Single step execution for the user.

Disadvantages

Updates require recompilation and release of NETCONVERT.

Option 2: Convert GML (XML based) to SUMO input files (XML based) This option seeks to take advantage of XSLT’s primary purpose for the conversion between XML schemas.

Conceivably templates that have been developed for SUMO could be adapted for import into other simulators. In

addition, when local datasets are available to the user they can be incorporated into the template or additional

templates developed without reliance on modifying the main SUMO distribution.

Figure 5: XSLT parser outline design

Advantages

Support new XML grammars with new templates.

Users customise template to integrate additional data.

Inspection of SUMO input files simpler than SUMO network file.

Platform and language independent.

Command line or user application integration.

Disadvantages

Multi-step execution for the user.

Option 3: Generic integrated XSLT parser to extend NETCONVERT application This option represents the combination of Option 1 and Option 2 and would provide a generic XML parser for SUMO.

All XML based formats, such as OSM and OpenDrive, could be supported with their own template. Users would be

able to select the required template and submit adaptations without having to alter the core source code of

NETCONVERT. This would simplify the NETCONVERT application and its ongoing maintenance.

Figure 6: Generic XML parser outline design

Advantages

Single step execution.

Support new XML grammars with new templates.

Users can customise template to integrate additional information.

SUMO can support a single generic parser with templates rather than multiple XML based parsers. (OSM,

VISSIM, OpenDrive, OS GML, MatSIM)

Disadvantages

Dependent on C++ XSLT processor to required version (i.e. minimum XSLT 2.0)

Implemented Features This section outlines those features of SUMO traffic simulator that it has been possible to implement in the time

available.

Nodes & Edges Both Ordnance Survey and SUMO construct their road networks based on similar concepts. Ordnance Survey (OS)

has RoadNodes and RoadLinks which correspond to the concepts of Nodes and Edges in SUMO. However, there are

some differences in approach.

SUMO Nodes are conceptual the points at which roads join or changes to the road structure occur, such as additional

lanes. OS RoadNodes can be placed when the name or number of a road changes, a one way restriction is changes, a

carriageway changes, carriageways intersect (i.e. a junction) or carriageways cross (e.g. a flyover, see Grade

Separation). In both models the geographic location is specified on the nodes with links/edges simply connecting to

the nodes and not having a geographic location. SUMO operates on a planar co-ordinate system using x, y co-

ordinates in metres. OS products use the Ordnance Survey National Grid reference system (OSGB36), which

represents Great Britain as a planer co-ordinate system using easting, northing coordinates in metres. Therefore,

there is no need for conversion of the co-ordinate references between OS RoadNodes and SUMO Nodes.

SUMO Edges are unidirectional and can consist of multiple lanes. OS RoadLinks are bidirectional, unless specified

otherwise by one way attributes and road orientation, and have an unspecified number of lanes. OS RoadLinks do

include the shape of the road and so non-straight SUMO Edges can be displayed. The bidirectional to unidirectional

issue can be overcome by reversing the road shape according to the road orientation and prepending a ‘-‘ to the

RoadLink unique identifier.

Therefore, the creation of a basic road network is a very straightforward process but finer detail need to be

incorporated.

One Way Edges As indicated in the previous section SUMO Edges are unidirectional and OS RoadLinks are bidirectional. Therefore,

two SUMO Edges are created for each OS RoadLink, unless a One Way attribute is specified. When the One Way

attribute is specified the orientation of single direction edge can be identified. However, OS RoadLinks can be one for

only certain vehicles and other vehicles, such as buses and taxis, are able to travel in the reverse direction, i.e. the

road is still bidirectional. SUMO Edges support the specifying of allowed and disallowed vehicle classes. Therefore,

the structure of physically unidirectional and physically bidirectional with restrictions can be represented.

Roundabouts & Mini-Roundabouts These road features possess characteristics of being unidirectional and providing priority to vehicles on the

roundabout over those joining the roundabout. Both OS and SUMO capture this information but with different

approaches. SUMO requires sets of Edges that constitute the roundabout. OS provides an indication that a RoadLink

is part of a roundabout but not the specific roundabout or the collection of RoadLinks.

However, by collating all the roundabout RoadLinks together and then recursively searching it is possible to build the

separate sets of roundabouts. The search is based on traversing the roundabout through matching RoadLinks by

their starting and ending RoadNodes until returning to the starting RoadNode. Additional complexity is added due to

OS RoadLinks not having consistent orientation so that edges meeting at a node orientated in (+,-), (-,+), (+,+) and

(-,-) can occur. The complexity of this approach, while functional for the purpose, is a risk if unexpected roundabout

scenarios are included such as a RoadNode being part of two roundabouts or a RoadLink being defined twice.

Partially complete roundabouts, such as those clipped at the geographic bounds, will be constructed but may not

contain all available edges in the dataset.

Mini-roundabouts are modelled in OS MasterMap as RoadNodeInformation that relates to specific RoadNodes. This

is similar to SUMO where Nodes can be given the type of “right_before_left” so that priority is given to those

vehicles approaching the junction from the right. However, there is no visual indication, other than the marked

priorities, that a mini-roundabout is present.

Grade Separation Roads do not always intersect but can cross over each other as overpasses or bridges. This is captured in OS mapping

products using grade separation. The crossing roads will be represented by RoadLinks that meet at a single

RoadNode, see Figure 7 below, but each RoadLink above the ground level will have an indicated Grade Separation.

Figure 7: Crossing RoadLinks (red & white lines) joining at a single RoadNode (black dots). Source: OS MasterMap ITN Layer Technical Specification

SUMO models changes in height by adjustment of co-ordinate z attribute in Nodes while Grade Separation is

recorded on the OS RoadLink. This means that additional Nodes need to be created to represent the variation in

height. An arbitrary value of 10m is multiplied by Grade Separation to provide the adjusted z height of the Nodes

and needs to be reviewed on the basis of typical road data.

All Nodes are prepended the integer value of the Grade Separation to their unique identifier, with no specified

Grade Separation value being assigned the value 0. This means that the unique identifier can be constructed when

RoadLinks are being processed, with consideration of the specified Grade Separation, and correctly assigned to the

corresponding Node. The OS MasterMap ITN Technical Specification states that Grade Separation values range from

1 to 6 with 3 being the in-use maximum and ground level being equivalent to 0. This leaves open how tunnels are

modelled as it would be assumed that a negative integer would be used but this is indicated to not be the case and

further investigation is required. There would be no issue to model a tunnel in SUMO if the tunnel RoadLink does not

have a joining RoadNode to the RoadLink above it.

Turning Restrictions: Mandatory Turn & No Turn The OS MasterMap captures information about turning restrictions, i.e. mandatory turn and no turn, as part of

RoadRouteInformation, a separate element to RoadLinks and RoadNodes, at the road level, see Appendix A. These

turning restrictions limit the routing options at junctions. This can be captured in SUMO by specifying Connections

either at a road or lane level. Mandatory Turns are modelled by specifying only the valid Edge to Edge Connection

while No Turns are modelled by removing the invalid Edge to Edge Connection.

Therefore these turn restrictions can be modelled but based on the ITN Technical Specification there is the potential

for turning restrictions to include vehicle exceptions that permit certain vehicle types or uses to ignore the

restriction. This cannot be modelled in SUMO as the connections do not support allow or disallow attributes that can

be applied to Edges. However, in both OS MasterMap datasets examined during this work there were no turning

restrictions with vehicle exceptions.

OS MasterMap Potential Features The following section identifies the concepts captured in the OS MasterMap which have the potential to be utilised

in SUMO. However, due to time availability or complexity these have not been implemented.

Buildings, Land Use, Points of Interest The OS MasterMap Topography layer includes information on buildings, land use and points of interest that can be

incorporated into SUMO as Polygons and Points of Interest (POI). These concepts also utilise the unique TOID

identifier that is included in the OS MasterMap and enable connectivity between the different layers. At the current

time the representation of Polygons or POIs in SUMO is for purely visual purposes but could be of use when

combining SUMO with other simulators or in visualisation.

Bus stops, rail links – NaPTAN dataset An existing dataset exists for the United Kingdom covering the public transport connection points called National

Public Transport Access Nodes (NaPTAN) (Department for Transport 2016). The NaPTAN dataset provides unique

identifiers for each interface, uses Ordnance Survey Grid Reference co-ordinate system and is XML based. Therefore,

it should be straight forward to incorporate using a XSLT template as an optional extra when required. SUMO allows

public transport connections to be captured using Bus Stop identifiers. The NaPTAN dataset only captures the points

of interface but not the route that public transport takes between points.

Pedestrian Footpaths & Cycle Paths The OS MasterMap ITN Urban Paths layer captures the footpaths and cycle paths available in Great Britain and links

these to the topographic areas in the Topographic layer. These include the shape and construction material of the

path. However, there is not an explicit link between a roadside footpath and the road it runs alongside. In addition

there is not an indication of the width of the footpath. This might be possible to extract from the Topographic layer

through geometry and is a similar issue to number of lanes in each road, see Appendix B.

SUMO captures footpaths as either Edges with no road lanes or additional pedestrian only lanes as part of road

Edges. Therefore, there are inconsistencies in how the information is captured but it should be possible to combine

the ITN and ITN Urban Path layers for conversion to SUMO’s Plain XML format so that at least minimal information

on footpaths can be represented if not guaranteed accurate.

Restricted Access: No Entry, Limited Access, Prohibited Access In a similar manner to the Turning Restrictions outlined earlier, using RoadRouteInformation elements, the OS

MasterMap ITN layer captures access restrictions along specific Road Links. However, rather than taking place at a

specific RoadNode at the start or end of a RoadLink these restrictions can take effect a certain distance along

RoadLink, e.g. x metres from the start. This is incompatible with SUMO’s Edge permission approach and would

require RoadLinks to be split and new nodes created once the correct geo-spatial co-ordinates corresponding to the

instruction have been calculated.

These restrictions also allow date time restrictions and exceptions for vehicles based on use, type or load which is

not easily modelled in SUMO’s current Edge permission approach, see (SUMO Traffic Simulator 2016a).

Road Altitude It has already been outlined how roads crossing above ground level can be separated with an indication of height.

However, there is not an explicit measure of the quantity of height or the height variation along a particular

RoadLink. The OS MasterMap ITN Technical Specification does describe a category and a specific unimplemented

attribute for gradients, see Appendix A. In both cases it is suggestive, although not explicit, that a label, such as

“steep” and “very steep”, is applied rather than a measure of gradient. There is indication that an additional dataset

is available, see Appendix C, of road gradients but again it indicates a label is used rather than a numerical value but

it has not been possible to locate this dataset for inspection.

In SUMO the modelling of variation in height is achieved by specifying the z attribute of a Node. There is therefore a

straight line gradient along the Edge itself between two Nodes at different heights. In order to closely model

variations in height would likely require the creation of additional Nodes and Edges to model significant gradients.

Information on altitude at specific nodes would be the most directly applicable into a traffic simulation.

The OS MasterMap Topographic layer does include information on the “physical level” of a topographic feature and

altitude at specific SpotHeight nodes. The “physical level” of a feature is a relative indication to ground level in a

similar manner to Grade Separation in the ITN layer. The SpotHeight nodes measure the “heightAboveDatum” in

metres with a typical accuracy of 2.5m. However, SpotHeights are associated with the topography rather than ITN

elements and so there is no reason to assume a direct link to RoadNodes or RoadLinks. Therefore a search for the

nearest SpotHeight/s would be needed to give a particular RoadNode an altitude. Accuracy in this calculation would

rely upon the assumption that the SpotHeights are located regularly at sufficient density. There is no indication of

the regularity or the density other than the “accuracyOfPosition” is 2.5m. This indicates a separation of at least 10m

and more likely higher at 50m or 100m but these are essentially guesses.

Two additional OS mapping products are available, OS Terrain 5 (licenced) and OS Terrain 50 (free), which indicate

spot and gradient contour lines. These products provide different resolutions of 5m and 50m respectively available

in GML format. In principle geo-spatial calculations could be applied to determine points of intersection and assign

altitudes to RoadNodes and generate additional Nodes and Edges for significant variations in gradient. This would be

feasible in XSLT using an extension such as BaseX geo module (BaseX 2016) to incorporate the additional datasets.

However, it is likely to be challenging and require certain assumptions to be made.

Overall, it is highly likely but technically challenging that altitude information could be incorporated. The

Topographic layer could provide easily accessible but low quality altitude estimates while the OS Terrain 5 dataset

would provide more technically demanding but higher quality altitude estimates. However, in both cases they would

be surpassed by the ITN layer RoadNodes being extended to include a specific altitude attribute.

Limitations of OS MasterMap with SUMO The following section outlines the areas where OS MasterMap is not able to represent functionality present in

SUMO. It should be noted that no national dataset which is publicly available has been found for any of these

characteristics in the UK. Instead isolated cases of a single public dataset covering one local authority area each was

found for traffic signal locations (Transport for Greater Manchester 2015) and pedestrian crossings (Leeds City

Council 2015). This indicates that it is possible to make this information available but there is lack of a co-ordinating

body and lack of motivation amongst local authorities. Therefore, there is no authoritative source other than ad-hoc

requests to local authorities.

Number of lanes In SUMO the number of lanes present on an Edge can be defined in two ways. Firstly, each Edge can be associated

with a road Type. The road Types provide generic characteristics of Edges according to a user defined classification,

such as maximum speed, width, access permissions and number of lanes. All Type defined characteristics can be

overwritten by a local attribute on each individual Edge, which provides the second method for defining the number

of lanes.

The OS MasterMap does not contain information on the number of lanes along each RoadLink in the ITN layer.

Relying on road classification is not effective since a motorway classification would assume that motorways have

three lanes but examples such as stretches of the M1 or M25 show that four lanes are possible and frequent.

Alternatively each RoadLink has associated TopographicArea/s in the Topographic layer that defines the physical

shape of the road. However, these TopographicAreas do not contain a width component which could be used to

provide an estimate if a minimum lane width, or set of widths based on road Types, was known. A possible

workaround is outlined in more detail in Appendix B but it relies on a number of assumptions that will limit the

reliability of the approach. Overall, the inclusion of number of lanes in the ITN layer would be the most useful and

easily resolved approach.

Local road speed limits In SUMO the local road speed limits can again be defined in two ways following the same approaches outlined for

the number of lanes. Again the OS MasterMap does not define this information on a RoadLink basis. Instead the best

that can be achieved is an assumption based on the road classification. These assumptions can rapidly become

undermined since a UK dual carriageway can have local speed limits of 40, 50, 60 or 70 mph when the assumption

would be that all are 70 mph. Therefore, local ad-hoc information would need to be incorporated which would be

better co-ordinated by the Ordnance Survey.

Traffic Signal Location and Sequencing In SUMO it is possible to define traffic signalling at junctions. These traffic signal can be provided with an

automatically derived or custom signal sequence. The definition of such traffic signalling affects the priority and flow

of traffic through the road network and the traffic simulation.

The OS MasterMap does not capture information on traffic signal locations. The OS MasterMap Real World Feature

Collection document recognises the concept but describes it as “not captured under the current specification”. Given

the purpose of the ITN and Topographic layers this is very surprising, especially given that objects such as telephone

boxes and bollards are included.

The capturing of traffic signal sequencing is beyond the scope of OS MasterMap given the level of information

required and purpose of the OS MasterMap so an alternative approach for disseminating this information nationally

is required. It is likely that further investigation will reveal a significant range of issues and complexity that will need

to be captured. Examination of a traffic signal timing sheet suggests that it can be accurately represented in SUMO’s

traffic sequencing model if made available. However, several conversations about traffic signal record keeping

suggests that record keeping in local authorities is paper based, not systematically maintained and stored with each

traffic signal unit.

Pedestrian Crossing Locations SUMO is able to represent pedestrian priority crossings without traffic signals, i.e. zebra crossings. However, the OS

MasterMap Real World Feature Collection document recognises the concept but describes it as “not captured under

the current specification”. This is again surprising given the purpose of the OS MasterMap ITN and Topographic

layers and the capturing of other features.

Limitations of SUMO with OS MasterMap This sections outlines the areas where further development of SUMO would better able represent and act upon the

information captured in the OS MasterMap.

Pedestrians In SUMO pedestrian and vehicle interaction is currently highly constrained. Pedestrians occupy pavement areas and

can only move across road lanes at specified crossings. This means that pedestrians cannot exhibit free flow of

movement across roads, i.e. jaywalking, which is both legal and common in the United Kingdom.

There are two types of pedestrian crossings in SUMO with each depending on whether or not the pedestrian has

priority. If the pedestrian has priority, i.e. zebra crossing, then the vehicles will stop to give way to the pedestrian. If

the pedestrian does not have priority the vehicles will continue to travel and the pedestrian will wait until a large

enough gap exists to cross ALL lanes in the Edge successfully.

In both scenarios there is potential for the non-priority user to experience significant delays. There does not seem to

be any traffic signal controlled crossings which would allow greater flexibility where by pedestrians will only have to

wait a maximum amount of time before being given priority. In this scenario the pedestrian is able to trigger the

traffic signal to respond rather than waiting on a fixed sequence rotation. Traffic signal crossings are a common

feature in the United Kingdom and can exist in isolation specifically for pedestrians or as part of road junctions.

Edge Access Permissions The OS MasterMap captures a wide range of access permission that exist in the road network. These restrictions can

be for the type of vehicles able to use a specific lane or turning through to height restrictions under low bridges and

road closures in specific periods.

In SUMO Edge permissions are based on a fixed set of abstract vehicle types, termed vClass, which cannot currently

be customised. An individual vehicle belongs to a user defined vehicle type, termed vType, which defines physical

characteristics. A vType belongs to exactly one vClass and so can only have one set of access permission. These

restrictions on customising vClass and limited vType to belonging to one vClass severely limit the flexibility for the

user to model real-world access permissions.

In order to accommodate the various different real world scenarios could require a complex and confusing modelling

process to utilise the fixed set of vClasses, manual customisation of the road network for a specific simulation and

the creation of multiple scenarios each with different parameters and configurations that could have unforeseen

consequences on comparability.

Edge Access The OS MasterMap distinguishes type (e.g. buses, cycles), use (e.g. resident, access, school bus, loading and

unloading) and load (e.g. explosive, wide, abnormal) of vehicles when applying mandatory, no entry or no turning

restrictions. SUMO is focussed on type and does not accommodate use or load.

Private Roads The OS MasterMap identifies public accessible and restricted access roads where access is based on purpose rather

than type. SUMO is focussed on type and does not accommodate use or load. The choice of routing through Edge

weightings and removal can be applied to partly compensate for access-only and private roads but this increases the

complexity of the modelling and would likely require manual intervention.

Vehicle Max Height Based Restrictions The OS MasterMap schema currently includes max height restrictions and defines max weight, length and width for

possible future use. This can be modelled in SUMO but would require a specific vClass for each height restriction, e.g.

up to 4 metres, up to 5 metres etc., that cannot currently be created and would become significantly more

complicated if another restriction was incorporated such as max width, e.g. up to 4 metres height and up to 2.0

metres width, up to 4 metres height and up to 2.5 metres width.

Date & Time Based Restrictions The OS MasterMap indicates time periods that edge access restrictions apply, including specific days, dates, times,

school hours and dusk till dawn. SUMO does not differentiate temporality and only captures the time since the

simulation started rather than seeking to reflect changes in road conditions and driver behaviour at different times

of the day. Any such configuration and control has to be established and managed externally to the simulation.

Edge/Lane Connection Exceptions SUMO is able to limit the connectivity at junctions between Edges or Lanes. This allows the capturing of mandatory

or not permitted turning at junctions. However, this connectivity is an all or nothing approach so that specific

exceptions cannot be applied. This means that it is possible to specify that all vehicles cannot turn left at a junction

but not possible to say that only buses may turn left.

Evaluation In order to evaluate the effectiveness of the OS MasterMap in comparison to the Open Street Map dataset a study

area was defined in the Milton Keynes area that included a range of urban, suburban and transport infrastructure.

The SUMO NETCONVERT application includes a number of optional processing options that can be used to apply

heuristics to Open Street Map data to correct obvious data errors and infer missing data. These have not been used

in this evaluation as the objective is to develop an authoritative and complete data source, see Appendix D for

further details.

SUMO Road Network The below images, see Figure 8, show the SUMO road networks generated from both datasets. It can be seen that

the general road network has been replicated. However, there are areas of detail where they differ from each other.

It should be noted that the OSM dataset contained numerous additional edge types that needed to be discounted,

as they were irrelevant or not comparable to OS MasterMap, and any misclassification would see them being

removed.

Figure 8: SUMO road network produced from OS MasterMap ITN layer (left) and Open Street Map (right) datasets for Milton Keynes city centre and residential area.

A fundamental area of difference is the non-capture of car parking in the OS MasterMap, with a simple indication of

the entry and exit points, which instead in Open Street Map are represented as being service roads. This non-capture

is a simplification that could assist during SUMO simulation as it avoids the routing of vehicles through unrealistic

paths. Care should also be taken when identifying differences at the edge of the study area due to different clipping

effects that might occur during data preparation from different sources.

A5

A416

A5

A416

Statistical Comparison Due to time available a detailed decomposition of the OS MasterMap and Open Street Map has not been possible.

There exist a significant range of parameters and considerations that would need to be accommodated in a robust

analysis, which would likely arrive at a conclusion that both datasets have their strengths and weaknesses. In this

context a conclusion that the OS MasterMap is at least comparable, if not superior, would be sufficient. The

following analysis has been undertaken to ascertain if such a general conclusion can be drawn. The SUMO simulator

includes a number of analysis tools of varying completeness and utility with the main usage being of the

netconvert.py script to determine network connectivity.

Item OS MasterMap Open Street Map

Total Edges 9,738 10,141

Connectivity 99.47% 98.53%

Disconnected Groups

- Largest

- Mean

- Median

- Mode

16

8.667

6

1,2,4

26

16.556

9

2

Roundabout Edges 962 423

Traffic Signals N/A 42

One Way 2,316 916

Figure 9: Table of edge connectivity in generated network files (*.net.xml).

It can be seen in the table above, see Figure 9, that there is a variation of 4% in the number of edges, which can be

attributed to different approaches to modelling and level of detail, but suggests similar coverage. The OS Master

Map achieves a greater network connectivity percentage. This is a measure of the joining of edges and nodes

together so that routing and traversal by vehicles can take place during simulation. Ideally a figure of 100% is

achieved but due to clipping may not be practical in real world datasets. The OS Master Map edges which are

orphaned are collected into smaller groups.

The Open Street Map contains 42 traffic signal nodes which may represent junctions or individual traffic poles at

junctions, which would equate to about 7 traffic junctions and not represent significant coverage in an area the size

of the study area. The OS Master Map contains 2.5 times more One Way edges despite utilising less edges suggesting

that Open Street Map’s coverage may not be as complete, although different tagging approaches could mean that

this is not the case.

Item OS MasterMap Open Street Map

Total Edges 9,738 10,141

Number of lanes N/A 351

Local speed limit N/A Total: 654

70mph: 278

60mph: 148

50mph: 5

40mph: 37

30mph:186

Road Access Total: 409

Publicly accessible:

65

Restricted: 330

Access Limited To: 3

Except For: 11

Total: 59

Private: 38

Customer: 4

No access: 8

Yes (public access): 9

Figure 10: Table of edge specific information

Figure 10 shows information that is captured specifically on edges, rather than road types. It has been outlined that

OS Master Map does not currently capture certain information which is captured by Open Street Map. However, it

can be seen that the coverage within Open Street Map is very sparse. The number of lanes with a specific value is

3.4% of those defined with the remainder relying upon the road type. Yet none of this information is carried over

into the SUMO Network (*.net.xml), probably due to its sparsity, with all number of lanes being defined by the road

type.

The local speed limits are also similarly sparse at 6.4% being explicitly defined and the remainder relying on road

type. In the Open Street Map dataset three subtly different speed notations were found in the sample study area,

which complicates any data processing and demonstrates the variable data consistency. The defined local speed

limits are predominately (93.58%) for the national speed limits (30, 60, 70), which can often be inferred by the road

type. Therefore, where specific speed limit information is included it may not be adding any more detail, e.g. 40 mph

and 50 mph on dual carriageways or 15 mph and 20 mph on single carriageways, than could already be derived

without it.

Issues Summary This section provides a brief summary of the issues that have been identified in greater detail in the rest of the

document. It also includes more general issues that have been identified in the process of undertaking the work and

could server as the basis for further investigation.

Road Specific Information The OS MasterMap does not capture specific local information on roads such as number of lanes and local speed

limits. This is surprising given the purpose of the OS MasterMap ITN and Topographic layers. Reliance on the

constructed generic road types from the Descriptive Term and Nature of Road is quickly demonstrated to not

capture the full range of permutations that exist in the United Kingdom.

Traffic Signal and Pedestrian Crossing Locations The OS MasterMap, or other national publicly available dataset, does not capture information on the location of

traffics signals and pedestrian crossings. This is surprising given the purpose of the OS MasterMap ITN and

Topographic layers.

Traffic Signal Sequencing There is no national publicly available dataset to model the traffic signal sequencing present at controlled road

junctions. There are indications that this is an area significantly lacking in modern approaches to data management

and central co-ordination. The lack of sequencing information, even as sets of generic plans, will have a significant

impact on the validity of traffic simulation models and presents a significant gap for simulation construction.

Traffic Signal Controlled Pedestrian Crossing There does not seem to be anyway to model in SUMO a pedestrian crossing which the pedestrian is able to trigger to

respond to their presence and which changes traffic signals within minimum and maximum time delays. Instead the

crossing would either be part of a traffic signal operating on a fixed sequence, with traffic being stopped even when

there are no pedestrians, or without traffic signals, with a fixed priority for either pedestrian, as in a zebra crossing,

or vehicles, potentially causing log waits for the pedestrian.

Edge Access Restrictions The current access restrictions and permissions available in SUMO are not able to fully represent the range of

purposes and types of restrictions currently available in existing traffic management that OS MasterMap is able to

model. The current approach with a fixed set of vClasses quickly become unable to model the different scenarios

without significant complexity and manual intervention and is an area that needs significant development.

Partially Complete Roundabouts Although it has been possible to reconstruct the sets of edges that constitute a roundabout the approach is

susceptible to incompleteness if the roundabout is only partially defined and error if a node is present on more than

one roundabout, a scenario it has not been possible to confirm or discount. Ideally the OS MasterMap would be

adjusted to explicitly state which edges constitute each roundabout to avoid ambiguity.

Grade Separation The information contained in the OS MasterMap is sufficient to construct a road network with varying heights.

However, it does not contain detail as to the amount of separation that exists between two crossing roads. Instead a

general assumption as to the height of points above ground level has to be made. This will reduce the effectiveness

of traffic simulations which take into account fuel usage or detailed modelling of vehicle speeds.

Altitude Data The OS MasterMap ITN layer simplifies the complexity of terrain into a 2 dimensional environment. While, indicators

such as Grade Separation and gradient Environment Qualifiers provide an indication of altitude variation they do not

provide a numerical quantification required for traffic simulation. Incorporation of altitude information could be

achieved through the inclusion of additional datasets but is likely to be computationally intense and prone to

assumptions and errors. However, altitude information could easily be included in the ITN layer within the

RoadNode element.

Turning Restrictions Vehicle Exemptions There is the potential for turning restrictions to be modelled in the OS MasterMap that include vehicle use and type

exceptions which cannot be modelled on a Connection basis in SUMO. Vehicle exceptions can only be modelled in

SUMO on an Edge and not a Connection. However, this is a potential scenario as no cases of turning restrictions with

vehicle exceptions have been identified but the ITN Technical Specification does not explicitly rule out this scenario.

Self-Looping Edges OS products capture looping roads, such as cul-de-sacs or turning circles, as a single RoadLink which starts and ends

at the same node. These type of edges are termed self-looping and are automatically removed by SUMO

NETCONVERT with a warning message. Although, this is unlikely to present a problem in most scenarios it could

provide an issue when incorporating other datasets or performing routing that expect these removed edges to be

present. There is no indication of a processing option to prevent the removal of self-looping edges by SUMO

NETCONVERT.

GML Clipping Tool The OS MasterMap can be supplied as a series of separate geographies with each representing a square bounding

box or a custom bounding box. In most applications there will be a need to combine and clip the separate

geographies to a desired sub-geography. The OS OpenRoads is provided for the entirety of Great Britain in large

regional chunks and needs to be clipped to a desired size. The QGIS tool is a popular open source GIS tool for

manipulating and converting between GIS file formats, such as GML. However, when using QGIS to merge, clip and

save the separate geographies the output GML file had an altered schema to the original input schema. This creates

a hard dependency on the QGIS tool which is not permissible. A free open source tool that allows the merging and

clipping of GML file formats without altering the schema needs to be identified or developed. The altering of the

schema and large regional file sizes has meant that developing and demonstrating a template for OS OpenRoads is

impractical.

Co-ordinate Reference System There are inconsistent references, such as Ordnance Survey Great Britain 1936 (OSGB36), Ordnance Survey Grid

Reference (OSGR) or British National Grid, or no explicit statement, to the co-ordinate systems in use in Ordnance

Survey and other UK datasets. This means that often an assumption has to be made as to co-ordinate reference

systems being identical with the risk of minor or significant geospatial error if not the case. The EPSG Geodetic

Parameter Registry (International Association of Oil and Gas Producers) provides a unique international identifier for

the various co-ordinate reference systems utilised in different countries. The OSGB36 co-ordinate reference system

has the EPSG identifies 27700 and it would be highly useful if such an internationally recognised identifier was

consistently used.

SUMO Network Analysis The SUMO Traffic Simulator is a collection of applications that are packaged together and are interoperable. This

package includes a number of tools/scripts for the analysis of the produced SUMO Network (*.net.xml) files, such as

netcheck.py, netstats.py and network_statics.py. The level of detail and utility of these scripts could be further

developed to more fully analyse the range of information that the SUMO Traffic Simulator is capable of modelling.

Ordnance Survey Documentation The OS MasterMap ITN Technical Specification is a detailed guide to the ITN map schema. However, it is not an

exhaustive guide to all the attribute values and combinations that can occur in the datasets and there are minor, but

impactful, typographical variances, e.g. “Taxis” instead of “Taxi” or “Access Limited To” instead of “Limited Access”.

This is acknowledged in the Technical Specification, see Appendix A, which also does not include consistent definitive

explanation of category terms introducing ambiguity in interpretation. Some attribute values were only discovered

following processing of datasets and review of the output which means that extensive and ongoing testing would be

required to validate any data processing. The specification also includes potential future expansions to the data

schema without a clear indication as to when, or if, they will be incorporated into the dataset.

The OS MasterMap Real World Object Catalogue lists all the features that are currently being captured in the

Topographic layer along with indications of those that are not. The latest version, confirmed via email, was produced

in November 2001 and has apparently not required updating despite several updates to the OS MasterMap schema.

The current version of OS MasterMap is version 8 with version 9 announced on the OS website as taking place from

April 2015, from May 2015 (see Figure 11 below) and from Autumn 2015. At the time of writing in March 2016 the

change to version 9 has still not taken place.

Given that the OS MasterMap is the Ordnance Survey’s premium mapping product these minor inconsistencies and

long delays in providing schema updates are somewhat concerning, although they do not detract from the quality of

the actual product.

Figure 11: Version 9 launch date taken from https://www.ordnancesurvey.co.uk/xml/schema/index.html.

Recommendations Based on the investigation and work that has been carried out the following recommendations have been

developed:

1. Ordnance Survey seek to incorporate the following into MasterMap ITN layer:

o Number of lanes

o Road speed limit

o Traffic signal locations

o Pedestrian crossing locations

o Pedestrian roadside footpath associate with road links

o Node altitude

2. Ordnance Survey reflect changes in road situation with nodes e.g. no entry signage

3. SUMO develop a user defined approach to vehicle class definition.

4. SUMO develop edge connections to have allow/disallow permissions.

5. Further investigation into development and publication of a national dataset for traffic signal sequencing

(ideally linked to the OS MasterMap ITN layer).

6. Further investigation into incorporating altitude and pedestrian footpaths data from OS MasterMap

Topology layer and other OS products into conversion template (if OS not able to incorporate into ITN layer

as outlined above).

Conclusion The undertaking of this work has identified that the OS MasterMap provides a good basis for road networks in traffic

simulation when compared to Open Street Map. The main components for traffic simulation are available within the

OS MasterMap and there is additional information that could be incorporated which is beneficial. However, there is

key information for traffic simulation which is unavailable in OS MasterMap and also not available more generally.

Instead there would be a reliance on obtaining such information from local sources on ad-hoc basis or applying

heuristics.

This document outlines a number of areas where information is not available or not easily utilised in the OS

MasterMap ITN layer. However, the range of issues identified does not preclude the OS MasterMap from use since

alternative data sources, such Open Street Map, are also subject to a large range of issues in data availability,

coverage and quality. A significant advantage of the OS MasterMap is its ongoing regular maintenance, managed

schema and consistent coverage of Great Britain. There are a number of areas where the dataset could be expanded,

or new layers created, to provide a highly valuable resource for traffic simulation and transport research in the

United Kingdom.

The selected approach of XSLT is suitable to the outlined scenario and could be adapted for users to incorporate

local XML data. Implementation of generic XML parser in the SUMO NETCONVERT application could yield a number

of benefits such as the simplification of the application and externalising of the conversion process so that a library

of templates can be developed for users to select and enhance.

Future Work There are a number of areas, particularly edge access permissions, where the SUMO Traffic Simulator would benefit

from enhancement to enable higher quality simulation of the data captured in the OS Master Map and present in

traffic management. The lack of a consistent and authoritative national dataset for traffic signal sequencing is an

area in need of further focus. The OS Master Map could accommodate traffic signal locations within its schema and

conceptually. However, it would not be appropriate to include detailed sequencing information and so an alternative

approach should be developed.

National Public Transport Access Nodes (NaPTAN) dataset (Department for Transport 2016) for Great Britain

provides information on all the access points to public transport and is a common reference set for public transport

information. It is available in XML format so would be suited to the XSLT approach and investigation into it

conversion to SUMO XML format.

References

BASEX, 2016-last update, Geo Module. Available: http://docs.basex.org/wiki/Geo_Module.

DATA.GOV.UK, 2016-last update, data.gov.uk. Available: https://data.gov.uk/.

DEPARTMENT FOR COMMUNITIES AND LOCAL GOVERNMENT, 2015-last update, Live tables on household projections. Available: https://www.gov.uk/government/statistical-data-sets/live-tables-on-household-projections#history.

DEPARTMENT FOR TRANSPORT, 2016-last update, National Public Transport Access Nodes (NaPTAN). Available: https://data.gov.uk/dataset/naptan.

INTERNATIONAL ASSOCIATION OF OIL AND GAS PRODUCERS, , EPSG Geodetic Parameter Registry. Available: https://www.epsg-registry.org/.

KRAJZEWICZ, D., ERDMANN, J., BEHRISCH, M. and BIEKER, L., 2012. Recent development and applications of SUMO–simulation of urban mobility. International Journal On Advances in Systems and Measurements, 5(3 and 4), pp. 128-138.

LEEDS CITY COUNCIL, 2015-last update, Pedestrian Crossing Points. Available: https://data.gov.uk/dataset/pedestrian-crossing-points.

MAPBOX, 2016-last update, OSM Lint.

NATIONAL ARCHIVES, , Open Government Licence. Available: http://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/2016].

OPEN GEO SPATIAL, (., 2016-last update, Geospatial Markup Language. Available: http://www.opengeospatial.org/standards/gml2016].

OPEN GEOSPATIAL CONSORTIUM, 2016-last update, Simple Feature Access - Part 1: Common Architecture. Available: http://www.opengeospatial.org/standards/sfa.

OPEN STREET MAP, 2014-last update, Wiki Main Page. Available: https://wiki.openstreetmap.org/wiki/Main_Page2016].

ORACLE CORPORATION, 2015-last update, Introduction to JAXP. Available: https://docs.oracle.com/javase/tutorial/jaxp/intro/index.html.

ORACLE CORPORATION, 2010-last update, Java Native Interface Specification. Available: http://docs.oracle.com/javase/1.5.0/docs/guide/jni/spec/invocation.html.

ORDNANCE SURVEY, 2016a-last update, Education and Research. Available: https://www.ordnancesurvey.co.uk/education-research/index.html2016].

ORDNANCE SURVEY, 2016b-last update, Ordnance Survey. Available: https://www.ordnancesurvey.co.uk/2016].

ORDNANCE SURVEY, 2016c-last update, OS MasterMap Topography Layer upgrade 2016. Available: https://www.ordnancesurvey.co.uk/business-and-government/help-and-support/products/os-mastermap-topography-layer-upgrade-2015.html2016].

ORDNANCE SURVEY, 2016d-last update, OS MasterMap XML Schema Repository. Available: https://www.ordnancesurvey.co.uk/xml/schema/index.html2016].

ORDNANCE SURVEY, 2016e-last update, Product Finder. Available: https://www.ordnancesurvey.co.uk/business-and-government/products/finder.html.

ORDNANCE SURVEY, 2016f-last update, Public Sector Mapping Agreements (PMSA). Available: https://www.ordnancesurvey.co.uk/business-and-government/public-sector/mapping-agreements/public-sector-mapping-agreement.html2016].

SUMO TRAFFIC SIMULATOR, 2016a-last update, Abstract Vehicle Class. Available: http://sumo.dlr.de/wiki/Definition_of_Vehicles,_Vehicle_Types,_and_Routes#Abstract_Vehicle_Class.

SUMO TRAFFIC SIMULATOR, 2016b-last update, Network Imports Arcview. Available: http://sumo.dlr.de/wiki/Networks/Import/ArcView.

SUMO TRAFFIC SIMULATOR, 2016c-last update, Trac Road Map. Available: http://sumo.dlr.de/trac.wsgi/roadmap [March 6, 2016].

TAG INFO, 2016-last update, Tag Info Open Street Map. Available: http://taginfo.openstreetmap.org.uk/ [March 6, 2016].

TRANSPORT FOR GREATER MANCHESTER, 2015-last update, Traffic Signal Locations. Available: https://data.gov.uk/dataset/traffic-signal-locations.

WILLIAMS LEA, 2016-last update, Design Manual for Roads & Bridges: Volume 6. Available: http://www.standardsforhighways.co.uk/dmrb/vol6/.

WORLD WIDE WEB CONSORTIUM, (W3C), 2015-last update, XSL Transformations (XSLT) Version 3.0. Available: https://www.w3.org/TR/xslt-30/2016].

WORLD WIDE WEB CONSORTIUM, (W3C), 2007-last update, XSL Transformations (XSLT) Version 2.0. Available: https://www.w3.org/TR/xslt20/2016].

Appendix A: Road Route Information Qualifiers - OS MasterMap ITN Technical

Specification This section provides images, see Figure 12 and Figure 13, of the OS MasterMap ITN Technical Specification pages

relating to the vehicle, date time and environmental qualifiers. In the images it can be seen that the provided

categories are not exhaustive and that additional elements are defined but not implemented. Reconciliation

between these qualifiers and SUMO’s current permission model is also difficult with concepts such as date time,

vehicle use and vehicle load not being easily utilised.

Figure 12: OS MasterMap ITN Layer Technical Specification Date/Time Qualifiers

Figure 13: OS MasterMap ITN Layer Technical Specification Vehicle and Environment Qualifiers

Appendix B: Estimation of Number of Lanes in Topographic Layer An alternative method to provide an indication of the number of lanes is based on information already contained in

the Topography layer dataset. Each RoadLink in the ITN layer has a length and one or more associated

TopographicArea in the Topography layer. The TopographyArea describes the physical road as a polygon, see Figure

14. By determining the area of the polygon and dividing by RoadLink length then the width will be known, assuming

a predominately rectangular shape. However, in curved or highly irregular areas this assumption is weakened. By

dividing the width by the minimum lane width then an indication of the lanes in the geometry would be gained.

However, the minimum and maximum widths outlined in the Highways England Design Manual for Roads and

Bridges (Williams Lea 2016) vary depending on road design speed and other design decisions, see Figure 15. Finally,

the RoadLink length can potentially spread over multiple TopographicAreas, see Figure 14, which affects the third

parameter. Therefore, all three parameters in this calculation are subject to assumptions that could be weakened.

If the ITN layer was to include the number of lanes, the ideal solution, or the Topographic layer included the width

then a more reliable and less intensive estimation could be made.

Figure 14: OS Master Map ITN Layer Technical Specification showing the relationship between two RoadNodes (dots), RoadLink (white lines with red text label) and geographic features.

BaseX geo module (BaseX 2016) provides functionality to support the OGC standard of Simple Features Access (Open

Geospatial Consortium 2016), such as calculations for GML polygon area, within XSLT templates. Therefore, a pre-

processing step would not be required.

Figure 15: Department for Transport Manual for Streets – 2007 showing various scenario widths suggesting a minimum of 2.75m per lane.

Appendix C: Supplementary Gradient Data - OS MasterMap ITN Technical

Specification This section provides an image of the OS MasterMap ITN Technical Specification page, see Figure 16, relating to

additional information on gradient data. A search for this supplementary data was undertaken and enquires made

but at the time of writing it was not possible to inspect this dataset for its utility.

Figure 16: OS MasterMap ITN Layer Technical Specification Supplementary Data Attributes, page 40.

Appendix D: Software Development Notes The outputs of this work were primarily the development of a XSLT template, “itn-sumo.xslt”, for the processing of

OS MasterMap into SUMO Plain XML files. The intention to develop a XSLT template for OS OpenRoads was

prevented in the time available due to the large file sizes that the dataset is distributed in and limitation with GIS

tools available to clip the geographies correctly. However, a XSLT template for OS OpenRoads is entirely feasible with

the XSLT approach and would represent a subset of the concepts captured in the OS MasterMap template.

The template can used with any XSLT processor on the command line or packaged as part of an application. During

the course of this work a Gradle project was used to simplify the execution and management of dependencies. The

dependencies include SAXON-HE, a Java XSLT 2.0 processor, and Jcabi, a simplified XSLT interface, which interface

through the JAXP layer. Included in the package is code for native Java JAXP API which can be used for finer control

of the SAXON-HE processor. The project also contains the sample files used for the evaluation area and the

Ordnance Survey example GML.

Netconvert: SUMO Plain XML to SUMO (*.net.xml) The following command line instruction was used to convert the generated plain XML files “osITN.nod.xml”,

“osITN.edg.xml”, “osITN.typ.xml” and “osITN.con.xml” to the SUMO Network file “osITN.net.xml”. The generated

plain XML files are those produced by processing the XSLT template against the OS MasterMap ITN layer file.

netconvert --node-files=osITN.nod.xml --edge-files=osITN.edg.xml --type-files=osITN.typ.xml --connection-

files=osITN.con.xml --output-file=osITN.net.xml --lefthand true --ignore-errors

Netconvert: Open Street Map (*.osm.xml) to SUMO Network (*.net.xml) The following command line instruction was used to convert the Open Street Map file “mk-study-area.osm” into the

SUMO Network file “osmNet.net.xml” for simulation. It was necessary to remove a number of edge types to give a

comparable level of detail, mostly pedestrian footpaths, car parks and railways.

netconvert --osm-files=mk-study-area.osm --output-file=osmNet.net.xml --lefthand true --ignore-errors --remove-

edges.by-type

highway.bridleway,highway.service,highway.cycleway,highway.services,highway.footway,highway.ford,highway.pat

h,highway.pedestrian,highway.raceway,highway.stairs,highway.step,highway.steps,railway.light_rail,railway.preser

ved,railway.rail,railway.subway,railway.tram

Study Area Bounding Box The following co-ordinates were used to extract the study area information from Ordnance Survey and Open Street

Map.

OS Master Map/Open Roads OSGB: 485000.000,235000.000 490000.000,240000.000

Open Street Map WGS84: 52.006937,-0.763078 52.051091,-0.688941

Open Street Map Discounted Edges Types The list below show the Edge types which were not included in the SUMO Network file (*.net.xml) by specifying

them for removal as the NETCONVERT parameter “remove-edges.by-type”. This was to enable a more like for like

comparison in the level of detail present in the OS Master Map ITN layer. The ITN layer specifically does not include

car park areas, which are captured in OSM as Highway Service/s types, but which can help avoid unrealistic routing

around traffic jams.

The OS Master Map ITN Urban Paths layer captures the information that would be expected in the OSM Highway

Pedestrian, Highway Footway, Highway Bridleway, Highway Cycleway, Highway Stair, Highway Step/s and Highway

Path types.

The OS MasterMap Topographic layer captures features associated with the OSM Railway Light Rail, Railway

Preserved, Railway Rail, Railway Subway and Railway Tram.

highway.bridleway

highway.service,

highway.cycleway,

highway.services

highway.footway

highway.ford

highway.path

highway.pedestrian

highway.raceway

highway.stairs

highway.step

highway.steps

railway.light_rail

railway.preserved

railway.rail

railway.subway

railway.tram

Appendix E: SUMO Issues Log During the course of this investigation two issues were identified within SUMO NETCONVERT tool and accepted for

resolution by the SUMO development team. Both issues were minor in nature with one being quickly resolved.

Closed ticket – 2141 http://sumo.dlr.de/trac.wsgi/ticket/2141 - Fixed in r19939 (post version 0.25) – conversion of

maps not displaying correctly, malformed junctions and display artefacts.

Open ticket - 2148 http://sumo.dlr.de/trac.wsgi/ticket/2148 - truncated processing for errors which should be

ignored when converting xml with incorrect vClass.