utilising ordnance survey map data with sumo traffic...
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.