Private transport

Private transport refers to all modes of personal transportation, including car, bicycle, and walking. For cycling and walking, the OpenStreetMap (OSM) network is used. For car travel, the TomTom network is used by default, though the OSM network remains available as an alternative via the UseTomTomNetworkForCars parameter.

Network sources

OSM

OpenStreetMap (OSM) data are downloaded per region in shapefile format. The coverage includes all Dutch provinces, adjacent German regions (Niedersachsen, Düsseldorf, Köln, Münster), and Belgium. All regional extracts are merged into a single national network and cleaned for overlapping geometries. Relevant attributes are extracted per road segment, including road type (wegtype), speed limit, and directionality.

Each OSM road type has predefined speeds for car travel (inside and outside built-up areas), cycling, and whether pedestrians are permitted. These are defined in the classifications and determine which segments are included in each modal network:

Car network: all segments where CarSpeedInside > 1 km/h
Bike network: all segments where BikeSpeed > 1 km/h
Pedestrian network: all segments flagged as IsPedestrian

Because OSM speed limits are often missing or implausible, they are corrected using empirical rules. If the recorded speed is positive and below 140 km/h, it is accepted. Otherwise, the 90th percentile speed per road type is applied; if that is unavailable, a parameterised default speed (e.g., 30 km/h) is used. For motorways with speeds below 80 km/h, the 90th percentile is also enforced. If the resulting speed remains zero, the parameterised default car speed (e.g., 50 km/h) is applied, and if still below 15 km/h, it is set to 15 km/h.

TomTom congestion data may be integrated into the OSM car network. Because TomTom segments do not directly correspond to OSM segments, spatial linking is performed using a configurable search distance (ConnectSearchDist). To avoid mismatching motorway segments with nearby local roads, the network is first partitioned into motorways, major roads (primary and secondary), and streets before linking.

Note: An iterative gravity-based congestion model for OSM (using simulated link flows) was developed and remains in the codebase (Determine_CongestedSpeeds_T), but is no longer used in practice. It has been superseded by the TomTom speed profiles, which are based on empirical observations rather than simulated flows. See Congestion modelling (legacy) below for documentation.

TomTom

The TomTom dataset consists of roads (Roads), junctions (Junctions), and historical speed profiles by time of day and day type. Speed profiles are available for morning rush hour (07:30), noon (12:30), and late evening (19:30), as well as a freeflow reference speed. The day type used for the congestion analysis is configurable via CongestionSpeed_DaySelection (options: monday, tuesday, …, Weekday, Weekend, Week; default: tuesday).

The road type selection can be restricted via TomTom_StreetTypeSelectie, which allows excluding very minor road classes (e.g., local roads of minor importance) from the analysis network.

Network preparation

Connecting origins and destinations to the network

OSM (car, bike, walking): origin and destination points are connected to the nearest network node using the connect operator. The Connectable flag ensures that motorways and motorway links cannot be used as connection points, since direct access to these roads is not realistic.

TomTom (car): origins and destinations are connected to the nearest connectable junction using capacitated_connect. Each OD point is assigned a synthetic junction ID (offset from the highest real JNCTID) and connected to its nearest junction by a straight-line OD-link. Motorways and motorway links are marked as non-connectable here as well, so connections are made to the nearest accessible junction rather than the physically closest one.

Junction penalties

When travelling through the network, every node crossing incurs a small time penalty to reflect the realistic delay at intersections. The penalty depends on the number of links connected at the node:

Connected links	Car penalty (per side)
≤ 2 (bend or dead end)	0 s
3 (T-junction)	2 s
4 (crossroads)	5 s
> 4 (complex junction)	6 s

These values apply for walking and cycling as well (with equivalent defaults). The penalty is added at both the entry node (F1) and exit node (F2) of each link, so traversing a crossroads costs up to 10 seconds for a car. Parameters are configurable under ModelParameters/Advanced/Junction_Penalties.

There is also a variant for junctions where all connected roads are slow roads (≤ 30 km/h, IsLangzaamRijdendVerkeerWeg), where a lower or zero penalty may be more appropriate (e.g., residential areas where stopping at every side street is unnecessary). This logic is implemented but currently set to 0 s for all slow-road junction types.

Network optimisation

After filtering to the connected subnetwork and adding OD connection links, the network is simplified using an iterative contraction algorithm. This removes intermediate nodes that are not junctions and merges their links into single longer links, reducing the network size without affecting routing results. See the Network optimisation page for a detailed description.

For the TomTom network, this contraction step is not applied. TomTom junctions already form a cleaner topological network, and contraction yields less benefit there.

Routing

Dijkstra’s algorithm

After the network is prepared, an OD-matrix is computed using impedance_matrix_od64, which implements a bidirectional Dijkstra algorithm. For each origin, the algorithm finds the shortest path (by impedance) to all reachable destinations within the configured maximum travel time (MaxCarTime, MaxCyclingTime_Org2Dest, MaxWalkingTime_Org2Dest).

The impedance per link is computed from the link length and the applicable speed, converted to travel time in seconds. For TomTom links, this is LengthKm / Speed_per_ImpedanceType, with junction penalties added on top.

By default, one-way restrictions are respected (InterpretAllRoadsAsBidirectional = FALSE). Setting this to TRUE treats all roads as bidirectional, which can be useful for certain analytical purposes but is not realistic for car routing.

Time periods

Three congested time periods are modelled, in addition to a freeflow reference:

Label	Time of day
Freeflow	— (no congestion, theoretical maximum speed)
MorningRush	07:30
NoonRush	12:30
LateEveningRush	19:30

For OSM networks, the congested speeds are derived from TomTom data that has been spatially linked to the OSM segments. For TomTom networks, the speeds come directly from the TomTom speed profiles. The set of time periods is defined in ModelParameters/Advanced/CongestionTimes and is the same for both network sources.

For the final OD-matrix export, a single time period is selected: for TomTom the Freeflow speed is used as the primary export (with congested periods available as join columns), and the export is controlled via ModelParameters/Export_AfgelegdeAfstand and UseTomTomNetworkForCars.

Cycling and walking speeds

For cycling and walking, constant speeds are used by default:

Mode	Default speed
Walking	4.5 km/h
Cycling	14 km/h
E-bike	20 km/h

Actual observed cycling speeds from Fietstelweek data can optionally be used instead (UseActualCyclingSpeeds = TRUE). A constant speed is then replaced by the measured segment-level speed where available.

Output

The model can produce two types of output per mode:

OD-matrix: a table of origin–destination pairs with travel time (in minutes) and, optionally, the travelled distance in km (Export_AfgelegdeAfstand = TRUE). For car travel, all four time periods are included as separate columns.

Accessibility indicator (D_i): a gravity-weighted sum of destinations for each origin. See Decay for a detailed description.

Both outputs are written to CSV files. The filename encodes the relevant parameter choices (origin set, destination set, network type, congestion scenario, maximum travel time).

Congestion modelling (legacy)

An iterative gravity-based congestion model for the OSM network was developed and is still present in the codebase as Determine_CongestedSpeeds_T. It works as follows:

A freeflow reference is established by running a doubly-constrained gravity model (Furness balancing) on the freeflow network to produce an equilibrium link-flow distribution.
An impedance iteration then compares simulated flows against the freeflow reference. Where a link’s flow exceeds the freeflow flow by more than a configurable margin (imp_margin), the link impedance is increased proportionally (up to imp_step per iteration). This is repeated until convergence.
The resulting per-link impedances are stored in an FSS file and can be read back for routing.

This approach was replaced by the TomTom speed profiles because those are based on actual empirical measurements rather than modelled flows, and provide reliable time-of-day variation without requiring calibration. The OSM congestion model code remains available for reference or potential reuse, but is not part of the standard workflow.