1 Introduction

Sustainable accessibility policy goals are concerned with all modes of travel, and give particular attention to walking and cycling for local travel, and to multimodal travel using public transport over longer distances (Van Nes 2002). Studies on the relation between land use and travel patterns have, in the past, had a series of shortcomings (Stead and Marshall 2001; Van Wee 2002), namely the use of aggregate descriptions of urban form, low spatial resolution, a small number of case studies and the difficulty in comparing the results and methods used. These can in part be explained by data sets’ reduced geographic coverage or detail, by the cost of acquiring new or existing data, and by modelling and analytical constraints imposed by both software and hardware. Advances over the last decade in open geospatial standards, data collection and distribution, and in open Geographic Information System (GIS) and spatial analysis technologies allowed some of these shortcomings to be addressed, building urban models that are disaggregated, detailed, large scale, relational and reproducible (Jiang 2011, 2013). Recent studies measure sustainable accessibility at the city and regional level by private and public transport modes (Le Clerq and Bertolini 2003; Bertolini et al. 2005; Yigitcanlar et al. 2007; Scheurer and Curtis 2008; Mavos et al. 2012; Hadas 2013) using rich GIS data sets. This type of measurement suits a map view (Goodchild 2000): a static network model requiring a high level of accuracy in the location of and relation between features, consistent coverage and rich attribute data.

GIS-based multimodal network models are data models representing the mobility infrastructure of an urban area as a network, laying out the affordances available for travel using all modes of travel. Goodchild (2000) and Miller and Shaw (2001) have highlighted the challenges and laid out the principles of developing multimodal transportation data models for GIS. Some challenges specific to multimodal network representation relate to the data availability and its multiple formats, overlapping routes of similar or different modes on the same network, the modelling of transfers between modes, and the integration of travel costs on different modes.

There are numerous examples of detailed GIS multimodal network models that include data on public transport lines, services and timetables (Friedrich 1998; Butler and Dueker 2001; Li 2007; Liu 2011; Hadas 2013), and even the internal layout and access points of public transport stations (Chen et al. 2011). These models are usually developed for navigation and route choice modelling, and their level of detail is higher than required to understand the general structure and configuration of multimodal networks (Van Nes 2002). Nevertheless, they offer approaches to address the connection between different modes, for example adding ‘abstract connectors’ in a single layer (Ismail and Said 2014), or connecting multiple layers and systems for each mode (Mouncif et al. 2006), offering a robust and flexible data model that allows the analysis of each system in isolation (Galvez-Fernandez et al. 2009). Existing studies also highlight the importance of a correctly represented pedestrian network for measuring walking affordances, and propose methods for extending existing street network representations (Kim et al. 2009; Ballester et al. 2011).

This chapter presents the process of building a multimodal urban network model using the OSM street network data set as its main structure, onto which additional public transport and land use data sets are connected, using the case of the Randstad region of the Netherlands. The following sections describe the multimodal urban network model’s structure, the selection and pre-processing of the various data sets used, and the procedures developed to integrate the various elements into a topologically consistent model. It concludes with results and reflections on lessons learned from the process, highlighting some of the current challenges in building urban analytical models using OSM data.

2 The Structure and Infrastructure of a Multimodal Urban Network Model

The multimodal urban network model represents the multimodal mobility infrastructure and land use, integrating a private transport system (car, pedestrian and bicycle), a public transport system (rail, tram, metro and bus), a land use system, and interfaces interlinking all three (Fig. 1). The smallest spatial unit of each system is the street segment, the transit stop area and the individual building, respectively. The aim of this model is the analysis of the spatial characteristics of neighborhoods in the region, and of the structure of the region as a whole. This quantitative analysis aim imposes requirements on the data that, in particular regarding its attributes and topology, are different from the requirements for cartographic visualization. At the same time, there is an interest in building a platform that supports the automation of model maintenance, its reproducibility in different geographic contexts, and is accessible to all. These aims inform the subsequent choices of data set and technology stack.

Fig. 1
figure 1

Structure of the multimodal urban network model’s systems—a private transport system, b public transport system, and e land use system—and of the interfaces between all three c, d, f

Full size image

2.1 Data and Software Stack

The multimodal urban network model is built using various VGI and open data sources, taking advantage of the benefits, and attempting to address the issues, of integrating different data sets (Sester et al. 2014). The OSM data set forms the backbone of the model, because of its open access nature, universal coverage and standard, and rich feature set covering all modes of transport. In the case of the Netherlands, when OSM is compared with official street network data (Nationaal Wegen Bestand) according to various categories (Girres and Touya 2010; Jokar Arsanjani et al. 2013a), it presents itself as the most appropriate choice for a multimodal urban network model. OSM offers better semantic accuracy because it includes a representation of soft modes (i.e. walking and cycling) which is essential for the analysis of the walking and cycling environment (Chin et al. 2008); OSM’s positional accuracy is not substantially different from official street network data (Girres and Touya 2010; Haklay 2010; Neis et al. 2011; Graser et al. 2014); OSM can have a very good level of completeness: in the Netherlands a contributed road dataset was imported in early 2007Footnote 1 and OSM contributors have been supplementing and correcting this data since. In addition, the public transport networks can be partly derived from the same OSM data. However, in the case of the Netherlands public transport data has to be complemented with data from OpenOVFootnote 2 timetable data, and verified against route maps from local network operators. Detailed land use data is still very incomplete and inconsistent in OSM (Jokar Arsanjani et al. 2013b; Estima et al. 2013; Jokar Arsanjani and Vaz 2015), both in terms of building footprints and points of interest. In the case of the Netherlands, we used land use data extracted from the public data set Basisregister Addressen en Gebouwen (BAG),Footnote 3 which is currently in the process of being imported into the OSM data set.

In line with the chosen data sets, the multimodal urban network model described uses Free and Open Source Software (FOSS) GIS platforms. Osmosis is used to load the OSM data dump into a PostGIS database, where it is maintained together with the other datasets, the model is analyzed using pgRouting, and the results are visualized using QGIS. This software stack offers scripting capabilities in SQL, PL/SQL and Python, thus allowing the model building procedures to be reproduced and adapted to other cases.

2.2 Spatial Data Model

The OSM data set is composed of nodes (points) and ways (polylines), populated by a rich and open set of attribute tags, made up of keys with one or more values. It also supports relations (topologies) combining ways and nodes to describe larger entities, such as routes or named areas (polygons). Polygons can also be defined in closed ways, with a tag identifying it as an area. This data model is compact and flexible, combining all the different features based on their ids. However, this data model also makes data querying and manipulation a non-trivial task. In order to facilitate the analysis and display of the multimodal urban network model, it is based on a more conventional relational spatial data model. In the following sections we dive into the details of building the multimodal urban network model’s systems, presenting the procedures for processing and integrating the various data sets, that result in the spatial data model illustrated in Fig. 2.

Fig. 2
figure 2

Diagram of the multimodal urban network spatial data model

Full size image

3 Creating the Private Transport System

The private transport system is the backbone of the multimodal urban network model and, for this reason, it is the first system to be created. It defines the network of streets and paths for cars, bicycles and pedestrians onto which the public transport nodes and the land use activities are connected. The private transport system uses a standard road center line representation and data model, with a table of street segments and one of intersection nodes, populated with attribute fields defined specifically for multimodal urban network analysis (Fig. 2). The following procedure, illustrated in Fig. 3, describes how these features and attributes are created from the original OSM data. The main stages include the preparation of the street network segments, followed by the preparation of the street intersection nodes, concluding with the creation of pedestrian area links.

Fig. 3
figure 3

Procedure to create the private transport system data classes, from OSM data

Full size image

3.1 Street Network Segment Classification and Correction

There are several steps required to produce the street network segments. Firstly, the OSM ways that contain a ‘highway’ tag are extracted and inserted into a street segments table, keeping the complete tag contents. Secondly, the street segments are filtered and classified according to mode permissions and restrictions, and road hierarchy using the associated tags. Thirdly, the street segments need to be corrected for geometry and topology problems.

3.1.1 Street Network Segment Classification

The street segments in the multimodal urban network model are assigned attributes that indicate permission or restriction of the private modes (i.e. ‘car’, ‘bicycle’ and ‘pedestrian’), based on observable affordances (Scheider and Kuhn 2010) extracted from a wide range of tags available in the OSM data set (step A1 in Fig. 3). The level of completeness of attributes is critical to this type of network model (Neis and Zielstra 2014), and one has to adopt a simpler model specification (e.g. ignoring turn and speed restrictions) that is consistent throughout the study area, extracting as much information from additional keys as possible.

The first step is to identify the keys and key values available in the data set, their frequency, and to define their relevance to different modes (Table 1), supported by examples mapped over aerial photography. The main key for classifying the street network is ‘highway’, with values directly related to mode (e.g. ‘cycleway’, ‘footway’, ‘pedestrian’, ‘track’, ‘path’, ‘steps’), and to road hierarchy (e.g. ‘motorway’, ‘trunk’, ‘primary’, ‘secondary’, ‘tertiary’, ‘residential’). In the case of the ‘highway’ key, the most common value is ‘unclassified’, which can be complemented by information in other mode related keys, namely ‘motorcar’, ‘motor_vehicle’, ‘bicycle’, ‘cycleway’, ‘foot’, ‘footway’ and ‘route’. These specify if the segment is designated, accessible (e.g. yes) or restricted (e.g. no) for the given mode. Street segments with the ‘construction’ value should be ignored, and street segments with the ‘service’ value are ignored if their access is restricted (e.g. controlled by a gate), they are private, or are exclusively for public transport use. Once we have identified the relevant keys and values, we run a series of queries to populate the private mode attributes with Boolean values, where true is used when the segment is designated, false when the segment is forbidden, and null if the segment is simply accessible to that mode. The latter is the state that applies to the majority of street segments, which can be shared by all three modes.

Table 1 Summary of relevant “highway” key values in the OSM data set, with their frequency count, and indication of the mode that they are accessible to (‘T’, ‘F’ or blank)
Full size table

The open nature of the tagging system in OSM allows contributors to introduce rich detail in feature attributes, but it also adds heuristic complexity. In the data set for a given region one might find keys or values spelt differently (i.e. yes, Yes, YES, y), using regionalisms (i.e. underground, tube, metro), in different languages, or simply misspelled. One has to analyze and consider these specificities when using a data set for the first time, and develop queries to classify the segments based on a broad set of key-value pairs.

3.1.2 Street Network Segment Correction

Regarding the OSM street segment geography and topology, there is a range of possible problems (Girres and Touya 2010): duplicate segments, where geometry is exactly the same; overlapping segments, where geometry partially coincides; missing segments; closed segments, representing areas; orphans, unconnected segments from the rest of the network; segments without segmentation, where intersection nodes exist; contiguous segments, separated where no intersection nodes exist; missing intersection nodes; intersections at bridges or tunnels. One has to identify which problems are present, to what extent, how critical they are for the intended use of the data set, and ultimately decide the degree of error that is acceptable, making corrections accordingly. Considering that the aim is to produce a multimodal urban network model representing a large region, resulting from an automated procedure towards reproducibility and operationalization, we should not introduce steps that depend on the individual identification and correction of mistakes, such as missing data or incorrectly classified data. When creating a smaller network model, one should consider scanning and correcting any additional problems.

The correction steps proposed convert the OSM street segments into a standard road center line representation (A2 in Fig. 3). Firstly, we eliminate duplicate geometry, choosing to remove the segment with greater access restrictions. Secondly, we remove closed polylines that represent pedestrian zones, and do not correspond to road center lines. Thirdly, we split segments that continue over intersections where there is an intersection node, and eliminate any new duplicates resulting from overlapping geometry. Finally, multiple contiguous segments between crossings are merged together into a single polyline.

3.2 Street Intersection Node Classification

The standard road center line representation uses nodes at the endpoints of street segments to indicate level crossings. Where two segments intersect without a node, this indicates the absence of a level crossing, as in the case of bridges and tunnels. The nodes layer is selected from the OSM ‘nodes’ data set, namely those with an id in the ‘node_id’ attribute of the ‘way_nodes’ table, whose ‘way_id’ is in the extracted street segments table. The intersection nodes can be used to quantify morphological characteristics of the street network, namely the typology of crossings and cul-de-sacs, and to provide this typology, each node has a ‘count’ attribute with the number of street segments that share it.

3.3 Pedestrian Areas Links Generation

The OSM street network includes pedestrian paths and cycle lanes, however some public open spaces, such as squares, parks or urban block interiors, are represented by closed polylines disconnected from the street network, with the ‘highway’ = ‘pedestrian’ value, and a ‘area’ key with value ‘yes’. We create pedestrian area links to represent routes that pedestrians and cyclists can take across these open spaces. These are important shortcuts that affect the measurement of local neighborhood characteristics, because the routes around the perimeter of blocks and open spaces can represent a considerable increase in walking distance.

The procedure (C in Fig. 3) generates pedestrian links in an extension of the street network, using the existing street segments, intersection nodes and open areas, without changing the street network geometry or affecting its topology. The first stage is the selection of the pedestrian area polygons, merging together pedestrian areas that intersect, are adjacent, have the same name key, or have the same OSM id. The second stage is the selection of intersection nodes to be connected, identifying ‘inner nodes’ that belong to street segments intersecting the pedestrian areas and are located on or inside the areas’ perimeter, and ‘outer nodes’ that are located outside but immediately adjacent to the pedestrian areas, within a 25 m buffer. Finally, we exclude ‘outer nodes’ that are directly connected to ‘inner nodes’. The third stage is the creation of new links between the inner and outer nodes belonging to the same pedestrian area. We simplify this procedure by ignoring the pedestrian area’s shape and allowing links to cross the perimeter of concave shapes, because the link does effectively exist, albeit not so direct in terms of geometry. The final step eliminates excessive links that cross external buildings, cross external street segments, are entirely outside the pedestrian area, or are duplicates of existing street segments. The result is illustrated in Fig. 4.

Fig. 4
figure 4

Map with examples of pedestrian areas, with pedestrian area links complementing the connectivity of the street network

Full size image

4 Creating the Public Transport System

The next stage in building a multimodal urban network model is to build the public transport network and to connect it to the private transport network (Fig. 5). The public transport network is also multimodal, including rail, metro (or light rail), tram, and bus networks. We have opted for a simplified representation of the network focusing on the connectivity of the infrastructure, rather than on the service provision, i.e. the lines, services, and their frequency. This simplified representation has lower data requirements, and is easier to produce, verify and explain, retaining an adequate level of detail for the measurement of multimodal accessibility and urban structure (Van Nes 2002). It is made up of nodes representing stations or stops; lines representing the links between stops of the same mode; ‘transit-mode interfaces’ representing the transfer between stops of different modes; and ‘transit-street interfaces’ connecting the stops to the streets of the private transport network (Fig. 2).

Fig. 5
figure 5

Procedure to create the public transport system data classes, from OSM data and other sources

Full size image

4.1 Public Transport Networks Preparation

The public transport networks consist of a single node of each mode at a given location, independent of the number of physical stops, platforms, or station entrances that exist; and one line segment between nodes of the same mode, where a service exists connecting them. The OSM dataset has the required tags to construct such a network, however the level of coverage and detail of the data varies across regions and across transport modes. This can lead to different approaches to produce the multimodal network model, which is less systematic than desired, but is useful to understand different methods and issues for different data scenarios.

4.1.1 The Rail, Metro and Tram Networks

The public transport network nodes for the modes that use rail tracks were extracted from the OSM nodes data, where the node tag has a ‘railway’ key. The values of the ‘railway’ key (Table 2) are used to assign the mode to each node, or to exclude nodes that are not relevant. The resulting nodes are then checked against other sources of information, mentioned in Sect. 2.2. It was found that the OSM data set could have inconsistent quality, namely missing stations, duplicate stations, inactive stations, and wrongly classified stations. In the present case, the rail network was mostly complete and correct; the metro network was mostly complete but whole segments were incorrectly classified as ‘tram’, and the tram network had 2 % of the stations missing and had classification issues such as missing names or name inconsistencies.

Table 2 Summary of railway key values of the nodes and ways data
Full size table

The ‘match_name’ attribute of the public transport network nodes table stores a lowercase and simplified version of the stop or station name, standardizing certain prefixes or suffixes that can occur differently in different modes. This attribute can be used to compare and merge data from different sources, and relate public transport nodes of different modes. When verifying station/stop names of local transport modes, such as metro, tram and bus, across a larger region, one must take care to include the municipality and/or district name in the query. Often there are general names, historical dates, or historical names, occurring in different cities or districts, raising false matches.

The public transport network links connecting the nodes are created next. The OSM data set includes ways representing the physical rail tracks, which have a railway key (see Table 2 for values). However, these are not necessarily complete and do not match the stations in the same way the street segments match intersection nodes. Therefore, these line segments can only be used for visual support when digitizing links between stations, or after generating links from sequences of node names. The first method was carried out in this case, as the number of links is not excessive, and it allows a careful verification of public transport nodes.

4.1.2 The Bus Network

While the semi-automated verification and manual digitization method can be adequate for rail track-based public transport modes, it is impractical to create the bus network, because it is quite extensive and is difficult to identify routes by visual inspection. The recommended approach for creating a network model of public transport modes is to use an automated and systematic procedure, and for that one requires route data and/or timetable data. The OSM data set can include the bus network, with bus stops in the nodes table identified with the key ‘highway’ = ‘bus_stop’, and routes connecting stops encoded as relations of ways with the keys ‘type’ = ‘route’ and ‘route’ = ‘bus’. However, the relation data is often missing and only the nodes information is available. In such cases, one should look for public transit timetable data, the General Transit Feed Specification (GTFS) being a well-known standard used worldwide. In this case, the OpenOV timetable dataset was used.

Typically, public transport timetable datasets have a complex relational data structure, i.e. includes stops, links, services, cars, directions, and times. The first stage (B1, Fig. 5) is to understand the data structure and how to extract relevant information, namely the stop name, stop id and its geographic coordinates, and the links’ mode, origin stop, and destination stop. Then we extract this data into the simplified node/link public transport network data model. It is important to visualize the automatically generated public transport network to have visual feedback on the progress, and to assess its completeness and overlap with the available OSM dataset. The second stage (B2, Fig. 5) is to clean and reduce the data, keeping only bus nodes and links, and eliminating links and stops that are exact duplicates in terms of the ‘match_name’ and geometry attributes. The third stage (B3, Fig. 5) is to complete missing data, if required. In this case, the data from one of the bus network operators was missing and one had to resort to a semi-automated process similar to the rail networks. The fourth stage (B4, Fig. 5) is to generalize the resulting bus network, merging stops around a location that correspond to different routes or different route directions.

Ideally this is done using a universal unique feature identifier, otherwise one has to use name matching, paying special attention to different naming conventions for stops used by different operators. When merging equivalent stops, using the ‘match_name’ together with the municipality and district attributes as recommended in Sect. 4.1.1, one must limit the operation to a given distance (in this case we used 200 m) because in the case of bus networks, there are routes crossing the same street a few kilometers apart but all the stops receive the same name. The merging operation involves assigning a unique identifier to stops and links that meet the above criteria, and removing features with duplicate unique identifiers, keeping one stop for each unique identifier, and one link for each start and end node stop pair. The link’s geometry is then updated based on the new start and end stops location, giving a reduced set of new generalized links (Fig. 6).

Fig. 6
figure 6

Map with sample result of the bus network generalization procedure, comparing the original route data set with the simplified network of single bus stops and links

Full size image

4.2 Public Transport Network Interfaces Generation

After creating the public transport network tables, we integrate the public transport modes together and connect them to the street network of the private transport system. The ‘transit-mode interfaces’ (Fig. 1c) are links connecting public transport networks between stations and stops that share the same name. Typical examples are the stops around central train stations where all modes converge, which have the same stop name. Using the ‘match_name’ attribute, in conjunction with the municipality and district names, we insert in the modal interfaces table pairs of nodes that share the name but belong to a different public transport mode. The ‘transit-street interfaces’ (Fig. 1d) are links connecting the public transport nodes to the street network. These links allow the measurement of availability of and proximity to public transport, and the measurement of multimodal trips, e.g. where walking is combined with a longer public transport journey. Each public transport stop is connected to several of the nearest street segments, making sure that they connect to each of the private transport modes (pedestrian, bicycle and car). The procedure followed to produce these interfaces is detailed in Fig. 7. This is a nested iterative procedure, with a sequence of steps gradually loosening restrictions to find connections, this same sequence of steps being repeated at increasing scales, and the full sequence being repeated to connect to each private transport mode. Without describing every step in detail, it is important to raise a couple of points. The relaxation of crossing buildings and water is introduced because these features come from different data sets and are not topologically consistent with the mobility networks. The restriction of connecting to endpoints of street segments aims to reduce the number of links created initially, and to obtain links perpendicular to street segments.

Fig. 7
figure 7

Procedure to create the public transport system interface with the street network

Full size image

5 Creating the Land Use System

The final stage in building the multimodal urban network model is the creation of the land use system. This system provides the origins and destinations for the journeys across the mobility infrastructure, and furthermore allows the calculation of urban form characteristics related to functional density and accessibility. The land use system is made of three components, namely the land use nodes, the building polygons and the land use–street interfaces. The procedure to produce this system is illustrated in Fig. 8.

Fig. 8
figure 8

Procedure to create the land use system data classes

Full size image

The first stage is to verify the quality of the data, even when it comes from official data sources, namely the attribute values’ statistical and spatial distribution. In this case, it was found that ‘null’ values, which should be empty fields as per specification, were in certain areas recorded using numbers, e.g. 999999, 99999, 949999; and in some areas the decimal values had lost the decimal sign. In order to obtain a smaller number of nodes in the network model, the next stage is to aggregate the land use nodes information on the corresponding building polygon using a spatial join, calculating the total number of land use units and total area, and the number of units and area of each land use category. Any buildings without land use points were discarded from land use related analyses. The final stage is to create interfaces between the buildings and street segments or intersection nodes. In some data sets, the land use address attribute includes postcode, street name and door number, and can be used to define these interfaces. However, geocoding is not always an option, as the complete address is rarely available on both the land use and the OSM streets data set. Hence, one can define the interface as the (set of) line(s) from the building to the nearest the street segment(s) following a procedure largely similar to the one depicted in Fig. 7, with the difference that each iteration uses the building centroid first, and then repeats using the building perimeter.

6 Results

Following the procedures described in Sects. 3 to 5 we have produced a large-scale, detailed, multimodal transport and land use network model for the Randstad region of the Netherlands. It consists of 676,248 street segments, 462,384 street intersection nodes, 161 rail, 186 metro, 614 tram and 7,680 bus nodes, and 2,430,945 building polygons (Fig. 9). This model offers a rich representation of the region, supporting analysis of a regional scale but also goes down to the level of detail of the local neighborhoods and individual buildings.

Fig. 9
figure 9

Maps of the three main systems of the multimodal urban network model, for a data sample around central Amsterdam: a private transport system, b public transport system, c land use system

Full size image

By querying the network model to use relevant layers, e.g. pedestrian and local public transport, and to select specific sets of origins and destinations, e.g. residential buildings or education establishments, one can use network analysis and routing algorithms to calculate multimodal shortest paths and catchment areas. This is demonstrated next, with the results of shortest routes calculated around pedestrian areas, and catchment areas calculated for different transport modes.

6.1 Multimodal Network Model Analysis

The shortest routes were calculated between buildings in a section of the network model in central Amsterdam, which has several pedestrian-only streets and pedestrian areas (Fig. 10). The calculation uses three different model filters: one that includes all pedestrian links (A), one that excludes the pedestrian area links described in Sect. 3.3 (B), and a third that does not include any exclusively pedestrian links and corresponds to the car network represented in official street network data sets (C). These results in Table 3 show the impact of adding pedestrian links on local shortest route calculations.

Fig. 10
figure 10

Shortest routes between pairs of buildings (AB, CD, EF, GH, ST) on the private transport system, a including all pedestrian links, b including pedestrian paths without pedestrian area links, and c including only car accessible links

Full size image
Table 3 Difference between model A and models B and C, in terms of shortest route distance between pairs of points (Fig. 10), and in terms of catchment area
Full size table

As found by other studies (Chin et al. 2008), the pedestrian routes can be considerably shorter in model A when compared to model B and in particular with model C. This impact is obviously dependent on the quantity and location of pedestrian areas and pedestrian streets. As there are only a few pedestrian areas, certain routes in model B are not affected at all (e.g. C–T and S–T), while others are considerable affected (e.g. E–F). However, pedestrian streets are common in this urban area, hence model C gives a significant increase in distance travelled in all cases. The difference between models A, B and C is smaller in the results of the catchment area calculation for 5 and 10 min travel time, and this difference drops with a greater distance travelled. This seems to indicate that in aggregate calculations of many origin destination pairs including longer routes (e.g. S–T), the reduction in distance travelled from the presence of pedestrian paths and areas will have a small overall impact. From these results, it is clear that the location and concentration of pedestrian movement features will have a variable local effect on the results of network analysis. However, to draw definitive conclusions on the level of this impact on a given multimodal model, one would have to conduct a systematic study on the whole model using the full range of analyses that are required.

The results of a catchment area analysis for different travel modes are shown in Fig. 11, where one can observe the number of buildings accessed within a 10 min travel time: walking (Fig. 11a, b), comparing models A and C; using public transport (Fig. 11c), where pockets of buildings near public transport stops become accessible; and driving (Fig. 11d), with a more extensive coverage than public transport due to the fact that the central core of Amsterdam has very few public transport stops and uses a large part of the travel time budget walking to the nearest stop.

Fig. 11
figure 11

Catchment area maps for a 10 min travel time a walking using model A, b walking using model C, c using public transport, and d driving

Full size image

These results are mainly for demonstrating the use of the multimodal urban network model in basic network analysis calculations. From the calculation of shortest paths and catchment areas we can derive a wide range of analysis metrics of proximity, density and accessibility of the different mobility networks, which support the comparative assessment of sustainable accessibility of urban neighborhoods in the city-region. This is further described and developed in work by Gil and Read (2012, 2014), and Gil (2014).

6.2 Reflections on the Multimodal Network Model

At this stage we would like to reflect on aspects of the multimodal urban network model’s design and lessons learned from the process of producing it. The network model is intentionally simple for the purpose of analyzing the multimodal structure and accessibility of city-regions, and this is reflected in its data model. However, the geometry of the private transport system network could be generalized to address inconsistent representation of multiple lanes, cycle lanes, pedestrian pavements and crossings, complicated intersection layouts, and to allow a correct classification of crossings typology. We opted for a general classification of the street segments using mode attributes, because the geometric generalization using OSM data is not a trivial task, and the current procedure interferes less with the original data model and facilitates update and maintenance of the network model.

If the decision goes for a more detailed model, for example in a smaller study area, the private transport system procedure from OSM data remains the same but one should add parking space information to the street network, and complete the pedestrian network with correct representations of crossings (Ballester et al. 2011). On the other hand, one should produce a more detailed public transport system using the full timetable data, including multiple stops, platforms, lines and services, as seen in other models (Friedrich 1998; Butler and Dueker 2001; Li 2007; Liu 2011; Hadas 2013).

The network structure and level of detail of the model is also related to the type of analysis algorithm being used. In this case we use basic undirected shortest route and catchment area analysis suitable for a simpler network representation, but more detailed models would require advanced network analysis algorithms based on specific multimodal graph representations, as can be found in the works of Lozano and Storchi (2001), Bielli et al. (2006), or Ayed et al. (2011).

Data set selection and processing remains one of the biggest tasks in network model production. Some important lessons are: all data sets must be carefully verified and possibly corrected, whatever their source; data sets have strengths and weaknesses regarding the desired data model, which encourages the combination of the best available data sets from different sources; however, this can be problematic and requires workarounds, because data sets are not topologically consistent (e.g. network and building geometry), lack common unique feature identifiers, and use different naming or classification conventions (e.g. public transport attribute data).

Regarding the OSM data set, it has the potential to become a unified source for this type of urban analysis work: it is user-contributed and freely accepts updates, it is open to imports of large official datasets, it supports a wide range of features and attributes, and is based in a single geographically and topologically consistent platform. However, it still faces many of the challenges raised by Haklay and Weber (2008). For OSM to be further used in urban analytical studies, the challenge is to improve data quality (Mooney et al. 2010; Goodchild and Li 2012), especially of its attribute data (Neis and Zielstra 2014), supported by software applications for data editing that are user friendly and intuitive to attract many contributors—the crowd—but sophisticated enough in the background to provide quality control—automated. For example, in order to ensure a standard street network representation, OSM could include topology processing scripts on the server side to operate on features as they are edited on the database, similar to the procedures described in Sect. 3.1.2. Furthermore, in order to facilitate data analysis and modelling based on attributes, OSM could require a minimum level of attribute classification of features. This would be supported by tools including an ontology-based data specification (e.g. Fonseca et al. 2000; Scheider and Khun 2010; Scioscia et al. 2014) that would guide and reduce the efforts of individuals in complying with data standards.

7 Conclusions

This chapter proposes a set of procedures to build a multimodal urban network model, including transport infrastructure and land use, for the quantitative analysis of the urban regional environment in urban design and strategic planning studies. The general scope and reproducibility of this type of model is much greater than in the past, thanks to the availability of OSM data. In addition, the level of detail afforded by crowd-sourced data sets, with the capabilities of today’s open GIS and statistical analysis platforms, increase the possibilities for the analysis of complex urban regions.

OSM has great potential: its specification offers ‘on paper’ all the features required for this type of network models; and its open nature and worldwide standard availability can turn it into a preferred data source. But there is still some way to go before its feature classification becomes more complete and consistent and before its coverage becomes comprehensive in most geographic regions, either through individual contribution, or through the merging of open and donated official data sets. One should expect this evolution to continue over time, and new urban network models to be built and further contribute to urban form and travel studies, but also that these models become operational and applied in urban design and planning practice.