Network

The network provided by Creario is ready for MATSim simulations, i.e. it is fully connected, contains all essential link attributes as well as a series of additional attributes, such as road type, gradient, curvature, bike infrastructure, tunnels and bridges. The network is derived from publicly available data. This data self-evidently still contains errors and inaccuracies. Creario aims to algorithmically address as many of them as possible. For further manual corrections specific to the study area, the user is provided with a validation report with indications as to were special attention of the user might be required.

Scope

Since agents are allowed to choose activities outside the study area, a buffer zone of 35km is created around the study area. For this buffer zone the network is generated the same way as for the study area in order to obtain more realistic travel diaries. The analysis in the report are calculated for the entire network including the buffer zone, if not specified otherwise.

Input data

The MATSim network provided by Creario is derived using the following three sources listed in Table 1:

Name	Version
OpenStreetMap Data Extract (OSM)	2024-10-10
AWS Terrain Tiles	regularly updated
Global Human Settlement Layer (GHSL)	R2022

Table 1: Input Data for the Network Generation

The main data source is OpenStreetMap (OSM). The AWS Terrain Tiles provide the elevation data used to determine road gradients. The Global Human Settlement Layer provides information about build-up areas which is used to differentiate between urban and rural roads. All three data sets are available worldwide. However, it has to be noted that the data quality varies significantly depending on the study area. This is especially true for the OSM network data since it is user generated. But the advantage of a dynamic user generated data set such as OSM is that it is constantly updated, thereby leading to improvements for the resulting MATSim networks as well.

OSM Tags

The OSM tags used to derive the MATSim network are listed in Table 2. For all attributes, the forward and backward tags are used taking into account the coding direction of the OSM way. The attribute length is calculated as the two-dimensional distance between start node and end node.

OSM Tag	Used to derive attributes
name	osm:name
ref	osm:ref
highway	roadType, capacity
railway	roadType, modes
aerialway	roadType, modes
ferry	roadType, modes, capacity
service	roadType, modes, capacity
construction	roadType, modes, capacity
tracktype	roadType, modes, capacity
route	roadType, modes, capacity
access	modes, capacity
bicycle	modes, capacity
foot	modes, capacity
vehicle	modes, capacity
motor_vehicle	modes, capacity
motorcar	modes, capacity
junction	modes, capacity
sidewalk	modes, capacity
cycleway	modes, capacity, cycleway, infrastructureFactorBike
oneway	modes, lanes, capacity, cycleway, infrastructureFactorBike
oneway:bicycle	modes, lanes, capacity, cycleway, infrastructureFactorBike
lane	modes, lanes, capacity
turn:lanes	modes, lanes, capacity
maxspeed	freespeed
tunnel	osm:tunnel, zCoord, gradient
bridge	osm:bridge, zCoord, gradient
surface	surface, comfortFactorBike
smoothness	smoothness, comfortFactorBike

Table 2: Utilised OSM Tags

Overview Processing

The procedure to prepare the MATSim network from the data sources described in Section Input data starts with converting the nodes, ways and relations of the OSM network into nodes and links for the MATSim network. Since MATSim links are directional and OSM ways are not, two MATSim links are created for each relevant way in the OSM network. During this step, several attributes such as roadType, allowed transport modes, number of lanes, freespeed and bike specific attributes are determined based on OSM tags. Subsequently, the network is reprojected from WGS84 to the coordinate system defined by the user. Then, the network is cleaned and parallel links are merged. In the next step, the links are grouped into so-called network segments, i.e. the set of links between two intersections. Afterwards, the elevation of each node is determined based on the AWS Terrain Tiles and the segment gradients are calculated based on node elevations. The curvature is calculated for each segment and, subsequently, the location class is derived from the GHSL data. Since the capacity depends on several of the link attributes determined in the previous steps, it is the last attribute to be assigned. Finally, the network is simplified and thinned out and the network is cleaned once more ensuring a fully connected network for each mode specified by the user.

In the following sections the procedures each of the bold attributes and processing steps are described in more detail.

RoadType

The attribute roadType is mainly based on the OSM tag highway. However, some OSM highway types are merged (e.g. pedestrian and footway are merged to footway) and others are further differentiated based on allowed transport modes, freespeed and a few other variables. The rules used for this are specified in the following Table 3.

highway	modes	freespeed	others	roadType
motorway	*	*	*	motorway
motorway_link	*	*	*	motorway_link
trunk	*	*	*	trunk
trunk_link	*	*	*	trunk_link
primary	*	*	*	primary
primary_link	*	*	*	primary_link
secondary	*	*	*	secondary
secondary_link	*	*	*	secondary_link
tertiary, tertiary_link	*	*	*	tertiary
residential	*	*	*	residential
service	*	*	*	service
living_street	*	*	*	living_street
pedestrian, footway	*	*	*	footway
steps	*	*	*	steps
track	*, car	*	*	service
track, path	walk	*	*	footway
	bike	*	*	cycleway
	bike-walk	*	*	footcycleway
cycleway	*	*	*	cycleway
unclassified, road	*	*	cylceway=designated	cycleway
	walk, bike, bike-walk	>= 50km/h	*	tertiary
	walk, bike, bike-walk	*	bus=yes, psv=yes, motorvehicle = forestry, motorvehicle = agricultural, access = private	service
	bike	*	none of the above	cycleway
	walk	*	none of the above	footway
	bik-walk	*	none of the above	footcycleway
	walk	*	opposite direction of of one-way street	roadType of one-way direction
	*, car	<= 20 km/h	*	service
	*, car	20-50 km/h	*	residential
	*, car	>= 50 km/h	*	tertiary
	*	*	route=ferry	ferry

Table 3: Road Type Classification Rules

Roads under construction (highway = construction) are marked with prefix «c_» (e.g. c_motorway, c_residential etc.) and proposed roads (highway = proposed) with the prefix «proposed_».

Allowed transport modes

The attribute allowed transport modes is determined using default values for the OSM highway tag and access restrictions in the following OSM tags:

• access
• vehicle
• motor_vehicle
• motorcar
• bicycle
• foot

The default values used in Creario are given in the following Table 4.

roadType	Default modes
motorway	car
motorway_link	car
trunk	car
trunk_link	car
primary	car,bike,walk
primary_link	car,bike,walk
secondary	car,bike,walk
secondary_link	car,bike,walk
tertiary	car,bike,walk
residential	car,bike,walk
service	car,bike,walk
service	car,bike,walk
living_street	car,bike,walk
track	bike,walk
track:grade1	car,bike,walk
track:grade2	bike,walk
track:grade3	bike,walk
track:grade4	walk
track:grade5	walk
road	car,bike,walk
cycleway	bike
footway	walk
steps	walk
crossing	walk
path	walk
corridor	walk
elevator	walk
ferry default	bike,walk
ferry:trunk, primary, secondary, tertiary	car,bike,walk
construction	-
proposed	-

Table 4: Default Modes by Road Type

After the default modes are assigned, the following rules are used to correct the allowed transport modes:

• Bike is permitted where car is permitted unless explicitly tagged otherwise (bicycle = no) or roadType is motorway or motorway_link.
• Car is removed from allowed transport modes if access tag is no, private, forestry, agricultural unless otherwise specified in vehicle or motor_vehicle/motor_car.
• One-way streets:
  • Car is removed from allowed transport modes for the closed direction.
  • Bike is removed from allowed transport modes for the closed direction unless specified otherwise in OSM tag oneway:bicycle.
• bicycle=use_sidepath is currently ignored because it is not consistently attributed in OSM, and it only applies to bikes and slow e-bikes, but not to fast e-bikes.

Number of lanes

The attribute number of lanes in a MATSim network resulting from Creario reflect the number of lanes available to private motor-vehicles (cars, motorbikes, etc.) including turn lanes in front of intersections and merge lanes. Not included are bike lanes and lanes reserved for public transport such as bus lanes. The number of lanes attribute is derived based on the following OSM tags in order of their priority:

1. motor_vehicle:lanes
2. vehicle:lanes
3. access:lanes
4. oneway
5. lanes

Link direction indicators (e.g. lanes:forward, lanes:backward) are taken into account. Links in the opposite direction of one-way streets are by default assigned one lane.

Freespeed

The attribute freespeed in MATSim represents the speed the agents can travel along a link when they are not impeded by other agents travelling on the same link or subsequent links. The freespeed is not necessarily the same as the speed limit. Especially in dense urban areas there can be constraints on the driving speed that are independent of the amount of traffic such as pedestrian crossings, delivery trucks or on-street parking. However, data on these constraints and their effects is still not readily available. The best approximations are so-called “speed profiles” that can be purchased from different companies. Speed profiles show the average speed actually driven on a road segment usually per hour of the day. If such data becomes more freely accessible in the future, it can be integrated in Creario. In the meantime, the freespeed attribute is derived from the OSM maxspeed tag and road type specific default values. If the OSM maxspeed tag is set, the freespeed of a link is set to the maxspeed. The freespeed for links where walk is the only allowed transport mode is set to 1.111 m/s (4 km/h), unless the roadType is steps. Then, freespeed is set to 0.556 m/s (2 km/h). For links with modes bike or bike, walk the freespeed is set to 4.167 m/s (15 km/h). For all other links the following default values are used:

roadType	Freespeed [m/s]	Freespeed [km/h]
motorway	33.333	120
motorway_link	22.222	80
trunk	27.778	100
trunk_link	19.444	70
primary	16.667	60
primary_link	16.667	60
secondary	16.667	60
secondary_link	16.667	60
tertiary	13.889	50
unclassified	13.889	50
residential	8.333	30
service	5.556	20
track	5.556	20
living_street	2.778	10
construction	2.778	10
ferry	4.167	15

Table 5: Default Values for Freespeed by Road Type

In reality, speed limits often vary depending on whether the link lies within a built-up area or out of town. This has not yet been taken into account in the freespeed attribute, but it will be in the future.

Bike specific attributes

Bike routing is influenced by a variety of factors such as the steepness of the road, available bike infrastructure or the amount of car traffic. Next to the gradient, as described in Section Gradients, this converter provides the following bike specific attributes:

• cycleway
• infrastructureFactorBike
• surface
• smoothness
• comfortFactorBike

The attributes cycleway, surface and smoothness are derived from OSM attributes of the same name. The attributes infrastructureFactorBike and comfortFactorBike are based on cycleway and smoothness, respectively. They provide factors that can be used in the scoring of bicycle trips. The rules for deriving these factors are similar to those in the MATSim bycicle contrib, but not identical. They are described below.

Cycleway and infrastructureFactorBike

The attribute cycleway is derived from the OSM attribute cycleway. The default value is not_specified. In general, the value of the OSM attribute is applied. Exceptions are:

• When osm:cycleway=yes without any further specification, it is assumed that the cycleway is a lane.
• When osm:cycleway=opposite / opposite_lane / opposite_track and the road is a one-way road, then in one-way direction cycleway is set to not_specified and in the opposite direction cycleway is set to lane / lane/ track, respectively.
• When osm:cycleway=opposite / opposite_lane / opposite_track and the road is a not one-way road, it is assumed that for safety reasons the cycleway on the wrong side of the road is always a track. This is, however, not a common case because usually these separate cycleways are coded in OSM as their own links.

The attribute infrastructureFactorBike has a value between 0 and 1, with 1 representing very good bike infrastructure and 0 very bad bike infrastructure. Table 6 presents the rules for the resulting infrastructure factor value.

roadType	cycleway	infrastructure factor
motorway, motorway_link	*	0.05
trunk, trunk_link	not_specified, shared, shared_lane	0.05
	shoulder	0.40
	lane, soft_lane	0.75
primary, primary_link	not_specified, shared, shared_lane	0.10
	shoulder	0.60
	lane, soft_lane	0.80
secondary, secondary_link	not_specified, shared, shared_lane	0.50
	shoulder	0.60
	lane, soft_lane	0.85
tertiary	not_specified, shared, shared_lane	0.60
	shoulder	0.70
	lane, soft_lane	0.85
service, living_street, residential	*	0.90
cycleway	*	1.00
footway, footcycleway	*	0.90
ferry	*	0.85
steps	*	0.05
*	track	1.00
*	share_busway	0.70

Table 6: Classification Rules Infrastructure Factor Bike

Surface, smoothness and comfort factor Bike specific attributes

The attributes surface and smoothness are directly derived from OSM. If the surface type is not specified in OSM, it is assumed to be asphalt. If the smoothness is not specified it is marked as not_specified and it is assumed to be no particular issue, i.e. not needing a malus in the comfort factor.

The attribute comfortFactorBike also has a value between 0 and 1, with a 0 representing a link that is not suitable for bike and 1 very high comfort for cyclists. The comfort factor bike is derived from the attributes surface and smoothness. Table 7 presents the rules for deriving its value.

surface	smoothness	comfort factor
paved, asphalt, concrete	excellent, good, not_specified	1.00
	intermediate	0.80
	other	0.60
	lane, soft_lane	0.75
concrete:lanes	excellent	1.00
	good, not_specified	0.95
	intermediate	0.75
	other	0.55
concrete:plates	excellent	0.95
	good, not_specified	0.90
	intermediate	0.70
	other	0.50
paving_stones	excellent	0.90
	good, not_specified	0.80
	intermediate	0.65
	other	0.40
bricks	*	0.60
cobblestone:flattened	*	0.50
cobblestone	*	0.40
unpaved, gravel, ground	excellent	0.90
	good	0.80
	intermediate	0.70
	not_specified	0.60
	bad	0.40
	impassable	0.00
	other	0.30
compacted, fine_gravel	excellent	0.90
	good	0.80
	intermediate, not_specified	0.70
	bad	0.40
	impassable	0.00
	other	0.30
dirt, earth, wood, pebblestone, grass	*	0.30
sand, stone	*	0.20

Table 7: Classification Rules Comfort Factor Bike

Network segments

Not all nodes in a MATSim network represent intersections in the real world. Nodes can also be added when link attributes, e.g. number of lanes or freespeed, change or to more accurately emulate the geometry of a road (since MATSim links are by definition straight lines). However, for some analyses it is more usesful to look at the whole road segment between two intersections and not individual links. Therefore, the concept of network segments is used here. A network segment is defined as the set of links between two intersections as illustrated in Figure 1 where each colour represents a different network segment.

Figure 1: Network Segments

In Creario, network segments are mainly used for the calculation of gradients and curvatures. They are identified after a first round of network cleaning and merging of parallel links. Each network segment contains a list of the links belonging to the network segment. Each link can only be assigned to one network segment. For the identification of network segments the following approach is used:

• For each link in a network that is not yet part of a network segment, first search backwards until an intersection or a dead end is reached. This node is the start node.
• From the start node search forwards until another intersection or dead end is reached. This node is the end node of the network segment. The links in between start node and end node are stored in a list in the correct order.
• A node is considered a dead end, if it has either no inLinks or no outLinks or one inLink and one outLink that are opposite links (i.e. the start node of link 1 is the end node of link 2 and vice versa).
• A node is considered an intersection if
  • it has more than two inLinks or more than two outLinks
  • its number of inLinks does not equal the number of outLinks
  • it has two inLinks and two outLinks and at least one of the inLinks does not have an opposite outlink and vice versa.

Elevation data

Elevation data is necessary to calculate link gradients but, unfortunately, OSM usually does not provide elevation data. Therefore, the elevation has to be added from a different data source. There are currently several digital elevation models (DEM) available for public usage. Table 8 lists the publicly available DEM that were considered for Creario.

Name	Publisher	Resolution	Coordinate System	Formats
Space Shuttle Radar Topography Mission (SRMT)	United States Geological Survey (USDS)	1 arcSecond	WGS 84 (EPSG:4326)	GeoTIFF, DTED, BIL
Global Multi-resolution Terrain Elevation Data 2010 (GMTED2010)	United States Geological Survey (USDS)	7.5 arcSecond	WGS 84 (EPSG:4326)	GeoTIFF
terradactile	Sparkgeo	varying	WGS 84/Pseudo-Mercator (EPSG:3857)	GeoTIFF
AWS Terrain Tiles	Amazon Web Services	5 m	WGS 84/Pseudo-Mercator (EPSG:3857)	png, GeoTIFF

Table 8: Digital Elevation Models

After testing each of the DEM listed above, it was concluded that the AWS Terrain Tiles provide the most suitable data since they provide the highest resolution, combine different data sources and have already undergone some initial processing and cleaning leading to more realistic elevation values. However, the elevation data in the AWS terrain tiles still contains inaccuracies, for example due to large buildings, extensive (transport) infrastructure etc. This can lead to unrealistically high link gradients, especially for short links. Therefore, the elevation data derived for each node in the network is smoothed using a Gauss Kernel Smoother. For this, elevation data is sampled around the node in question in a radius of 200 m. Then, the smoothed elevation for the node in question is calculated using a weighted average of the sampled elevation data using the following equation as the weight function:

$$w(e) = \exp \left(\frac{- dist(n, e)^2}{2 \sigma^2}\right)$$

where
$w(e)$ weight of the elevation data sample point
$n$ node for which the elevation is determined
$e$ elevation data sample point in the DEM
$dist(n,e)$ (2-dimensional) distance between node $n$ and location of the elevation data sample point $e$
$\sigma$ width of the Gauss kernel, here 100m

The effect of the smoothing is illustrated in Figure 2. The left column shows the node elevations and the right column the resulting link gradients. The first row shows the node elevations and gradients before smoothing and the second row after smoothing. Blue links indicate link gradients of 8% or smaller, red links indicate link gradients of 40% and higher. Before smoothing, there are quite a few links with very high gradients around the river that are not realistic. They are caused by the lower elevation of the river which runs several meters below street level in this part of town. With the smoothing, the nodes close to the river and on bridges crossing the river are drawn up resulting in more realistic node elevations and gradients as can be seen in the second row of Figure 2.

Figure 2: Node Elevations and Link Gradients Before and After Smoothing

Another issue regarding the elevation of network nodes concern nodes within tunnels, especially through the base of a mountain. The elevation of these nodes cannot be directly derived from the elevation data since this would result in too steep gradients. Therefore, they are imputed using an approach based on the concept of spring forces. First, all tunnels are identified and each is stored in an object with an Id, a list of links, a list of portal nodes and a list of internal nodes. Portal nodes are all nodes where vehicles can enter or leave a tunnel. The nodes in between the portals are internal nodes. The elevation for the portal nodes is derived from the DEM and considered fixed. The elevation of the internal nodes is corrected using the spring force approach. Therefore, for each internal node the resulting force $force_i$ is calculated using the following formula:

$$force_i = \sum_j \frac{(Z_i - Z_j)}{dist_3(i,j) \cdot (dist_3(i,j) - refLength(i,j)) \cdot k}$$

where
$force_i$ force affecting node $i$ due to all nodes $j$ with a link between $i$ and $j$
$Z_i$ elevation of node $i$
$dist_3(i,j)$ 3-dimensional distance between node $i$ and node $j$, i.e. the distance considering latitude, longitude and elevation

$refLength (i, j)$ reference length between nodes $i$ and $j$; here $refLength(i,j)=1.5 \cdot dist_2(i,j)$
$k$ spring constant; here k=1

$force_i$ is then used to recalculate the elevation of node $i$ using the following formula:

$$Z_i^{new} = Z_i^{old} + \frac{force_i}{m} \cdot c$$

where
$Z_i^{new}$ new elevation of node i
$Z_i^{old}$ old elevation of node i
$m$ mass of the spring; here m=1
$c$ adaptation rate for the elevation of node $i$; here c=0.05
This is done iteratively, until the resulting node elevations do not change significantly anymore.

Gradients

The gradient attribute is calculated as the average gradient of all links in a segment. This is preferred to calculating the gradient for each link individually since the elevation jumps described in the previous section could not be eliminated completely by the smoothing algorithm. Hence, the segmentGradient provides additional smoothing. The gradient is stored in the network as a percentage value.

When the network is simplified or thinned after the gradient calculation, the link gradients and segment gradients are recalculated. For this, first the segments are re-calculated and then the link and segment gradients.

Curvature

The curvature of a road describes the ratio of angular changes in its geometry in relation to its length. The curvature influences the achievable driving speed of a road and its capacity. For example, two-lane roads with a high curvature make it difficult for road users to overtake and lead to a higher variety in speeds since drivers unfamiliar with the road tend to drive at slower speeds. Both effects, in turn, reduce the capacity of the road.

In MATSim, links are by definition straight lines without curvature. The geometry of a road with curves is emulated by creating a series of short(er) straight links. Therefore, the attribute curvature is calculated for network segments instead of links. The curvature $c$ of network segment $j$ is calculated as the sum of all angle changes divided by the length of the network segment. The unit is [gon/km].

$$c_j = \frac{\sum_i \gamma_i}{L_j}$$

where
$i$ node in network segment $j$ (excluding start and end node)
$L_j$ length of network segment $j$
$\gamma_i$ angle change between link a and link b at node $i$, i.e. the absolute difference between the angle between the two links and a straight line

Location class

Some link attributes, e.g. capacity or freespeed, are influenced by the location of a link especially if the link lies within a built-up area or out of town. To indicate this, the link attribute location class is added to the MATSim network. Basis for this attribute is the Global Human Settlement Layer (GHSL) published by the European Commission. The GHSL is a spatial raster dataset that depicts the distribution of built-up surfaces based on satellite data. The European commission offers different types of layers. For determining the location class, the layers GHS_BUILT_S and GHS_BUILT_C are used. The two layers contain different classifications of the built-up environment and have some differences in coverage. Therefore, they are joined to obtain a better coverage of the built-up area.

The location class is determined in three steps. First, for each node the settlementAreaClass is determined by checking if the node lies within a raster cell that is marked as build environment in either of the two GHS-Layers. If this is the case, the settlementAreaClass is set to 1, otherwise to 0. Second, the location class of each link is determined using the start and end node of each link. For links longer than 200 - the middle point of the link is treated like an additional node.
For each node, the area class of the node and of several sampling points within a buffer of 40 metres around the node are determined. If more than two thirds of these sampling points have a settlementAreaClass of 1, the link location class is set to “urban” otherwise to “rural”. Third, the location class is corrected based on two heuristics. The first heuristic is based on road type and freespeed. For primary, secondary and tertiary roads the location class is set to “urban” if the speed is lower than 50 km/h and to “rural” if it is higher than 60 km/h. The second heuristic concerns short links of less than 100 m. If all the adjoining links have a different location class than the short link in question, the location of the short link is adapted. An example of the results of the location class assignment is shown in Figure 3.

Figure 3: Example for Location Class Assignment; blue=urban, pink=rural

Capacities

The link capacity is set analogously to the capacity in macroscopic models such as the Swiss national transport model. In test runs with a MATSim example scenario for Zurich, these capacities lead to more realistic results than the capacities used by the OSM network converter so far. The capacities are based on the Swiss norms VSS 640 018a und VSS 640 020a, the SVI research study SVI 2017/007 (Knoten in makroskopischen Verkehrsmodellen) and additional assumptions based on expert knowledge. A lot of factors influence the capacity of a road. Here, the following link attributes are used:

• road type
• number of lanes
• location class
• gradient
• curvature
• freespeed
• osm turn lanes

High performance roads

The Swiss norm VSS 640 018a provides capacities for high performance roads such as motorways and trunks as depicted in Figure 4 (Image taken from NPVM 2017: Zonenstruktur und Verkehrsnetze). It depends on the speed limit and the share of heavy vehicle traffic. Since the amount of heavy vehicle traffic is not known at the point of network conversion, this effect is ignored. Since the norm does only give evidence based capacities for high performance roads with two or three lanes in each direction the following assumptions are made for roads with more or less lanes:

• Links with one lane per direction are assigned their capacity analogously to main roads based on VSS 640 020a.
• Links with more than three lanes: the capacity of each additional lane is calculated from the difference between the capacity for three and for two lanes. For each additional lane, this difference is added.

Figure 4: Capacity of High Performance Roads According to Swiss Norm VSS 640 018a.

Main roads

The Swiss norm VSS 640 020a provides capacities for main roads outside of settlement areas. This norm is applied to primary and secondary roads as well as motorway and trunk roads with one lane. As can be seen in Figure 5 (Image taken from NPVM 2017: Zonenstruktur und Verkehrsnetze), the capacity for these roads depends on the gradient and the curvature of the road. With regard to the share of heavy vehicle traffic the same considerations as for high performance roads apply. Since the norm does only give evidence based capacities for main roads with one lane, assumptions have to be made for the capacity of additional lanes. It is assumed, that additional lanes provide 15% less capacity than the first lane due to lane changes, inefficient usage of multiple lanes etc.

Figure 5: Capacity of Main Roads According to Swiss Norm VSS 640 020a

Roads within an urban environment have a considerably lower capacity than roads outside of settlement areas due to factors such as more frequent intersections, reduced visibility, pedestrian crossings, adjacent driveways etc. Thus – following the assumptions made in Swiss National Transport Model – main roads with the location class “urban” are assigned only a capacity of 1100 vehicles/h for the first lane and 85% of this for each additional lane.

Other roads

For the other road types the following assumptions are made:

• Tertiary roads: 1100 vehicles/h for the first lane and 85% of this for each additional lane, independent of location class
• Residential and service roads: 600 vehicles/h
• Living streets: 300 vehicles/h
• Ferries: 200 vehicles/h

Intersections and turn lanes

The capacities described above have been determined for links without any consideration of intersections. In general, this does work well for MATSim’s queue-based traffic simulation. However, the additional capacity provided by turn lanes at intersections is likely to be overestimated, especially for lanes that turn off the main road and have to yield to oncoming traffic (e.g. left turn lanes in right-hand traffic systems) or for lanes that merge onto a main lane. Therefore, the capacity for links with these kinds of turn lanes is reduced based on the findings of the research study SVI 2017/007: Knoten in makroskopischen Verkehrsmodellen. These lanes are identified based on the turn:lanes tag in OSM. The capacity of left turn lanes is reduced by 25%, the capacity of joined left-and-through lanes by 15% and the capacity of merge lanes by 50%.

Network cleaning, simplification and thinning

The goal of Creario is to provide users a network that is ready for MATSim simulations, contains all relevant information and has been algorithmically validated. In order to do this, the network has to be fully connected, i.e. every node can be reached from every other node for each simulation mode. In addition, the network should only contain the nodes and links relevant for the simulation to save memory and run time. Links not relevant for the simulation might be links that run parallel to other links, short dead ends and loops. Besides that, the most common type of nodes not relevant for the simulation are nodes whose only function is to describe the geometry of the road and do not represent junctions/intersections or changes in relevant link attributes (e.g. number of lanes oder freespeed). These issues are addressed in three steps: network cleaning, network simplification and network thinning, which are described below. All three procedures are repeated several times during the network processing.

Network cleaning

The network cleaning ensures that the network is fully connected. This is done mode specific, i.e. the car network is fully connected in itself as is the bike network. Since the OSM tags for bike are not as reliable as for the car network walk is used as a connecting mode when checking thhe connectivity of the bike network.

To clean a network for a specific mode, the network cleaner determines the biggest cluster of nodes that is fully connected when only considering the respective mode and possible connecting modes. For all links that do not belong to this cluster, the concerned mode is removed from the list of allowed transport modes. If consequently, the list of allowed transport modes is empty, the link is removed from the network, as are its nodes if they are not connected to any other links.

One feature of the network cleaning is that it removes all nodes that are so-called sources or sinks. Sources are nodes with only outgoing and no incoming links and sinks are links with only incoming and no outgoing links. While this is a good thing for the network as a whole, it might lead to removing links at the boarder of the network that represent high-level directional links such as motorways. Therefore, before the network cleaning all source nodes with outgoing links with a free-speed of at least 80 km/h are identified. If there is a sink node connected to ongoing links with a free-speed of at least 80 km/h within 50 m, these two nodes are connected via special links with the road type “connectorMW”.

Network simplification

The goal of the network simplification step is to remove all nodes whose only function is to describe the geometry of a link. To achieve this, each node is examined to determine whether it can be deleted. A node can be deleted if

• it is not an intersection,
• is not the end of a dead end road,
• there is no relevant attribute change between the adjoining links and
• deleting the node does not creat a loop link.

After the node is removed, the adjoining links are joined together. Since the deleted nodes enable a more realistic representation of the network geometry, they are stored in so-called NetworkGeometries which can be used in displaying the accurate network geometry (e.g. in Simunto Via). The attribute curvature is not affected by the simplification. The new link is assigned the same curvature as the old links, which has anyway been calculated for the network segment and not the individual links.

The relevant attributes, for which links are not simplified are:

• capacity
• freespeed
• allowed transport modes
• number of lanes
• roadType
• osm:tunnel
• osm:bridge
• osm:oneway
• cycleway
• surface
• smoothness

Network thinning

The network thinner comprises a number of methods to thin out the network. The methods used for Creario are:

• remove dead ends that are shorter than 50 m
• remove loop links, i.e. nodes that start and end at the same node
• merge parallel links, i.e. links that have the same start and the same end node

When merging parallel links, there are several approaches to obtain the relevant attributes for the combined link. Here, this is based on the attribute roadType. Each roadType is assigned a priority as depicted in Table 9. The joined link obtains the attributes of the link with the lower priority value, i.e. if a tertiary road and a service road are merged, the joined link obtains the attributes (incl. Id) of the tertiary road. The only exceptions are length and modes. The length is calculated as the average length of the two links. The modes of both links are combined.

roadType	priority	roadType	priority
motorway	1	c_motorway	31
motorway_link	2	c_motorway_link	32
trunk	3	c_trunk	33
trunk_link	4	c_trunk_link	34
primary	5	c_primary	35
secondary	6	c_secondary	36
primary_link	7	c_primary_link	37
tertiary	8	c_tertiary	38
secondary_link	9	c_secondary_link	39
ferry	10	c_ferry	40
residential	11	c_residential	41
living_street	12	c_living_street	42
service	13	c_service	43
footcycleway	14	c_footcycleway	44
cycleway	15	c_cycleway	45
steps	16	c_steps	46
footway	17	c_footway	47
unknown	60	c_unknown	61

Table 9: Road Type Priorities for Thinning