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
Since 25 September 2026 the Geofabrik road classes track_grade1 to track_grade5, busway and unknown have their own rows in the classification (audit 4.8). Tracks (farm and forest roads) are not part of the car network, like track without a grade; track_grade1 (paved) and track_grade2 (gravel) are part of the bike network, track_grade3 to track_grade5 (unpaved) only of the pedestrian network. busway is treated like bus_guideway and unknown like FIXME: pedestrians only. A class that is missing from the table becomes unknown, and Read_Roads_shp/NrUnmappedFclass counts such features per region. Before, these classes were missing from the table and every such segment became a connectlink, part of the car, bike and pedestrian network with the default car speed of 50 km/h: 620,107 features and 197,104 km of the 1,075,982 km in OSM 20260601, most of them tracks. In the network store (39.3 million links) the car network went from 23,962,408 to 19,545,142 links (−18%), the bike network from 31,341,474 to 28,646,765 (−9%), and the pedestrian network stayed at 38,753,395 links.
One-way roads whose direction of travel is against their digitising direction (oneway = 'T') are reversed when read, so that every one-way link runs from its first to its last point, which is the direction the network uses. Until 25 September 2026 these roads (512 segments, 53 km in OSM 20260601) could only be driven against the direction of travel (audit 4.9). The bike and pedestrian networks treat all roads as two-way, because the shapefile’s oneway does not say whether cyclists are exempt.
The Geofabrik road layer has no ferries. The network therefore gets manual connections (OSM/NetworkPreperation/ExtraVerbindingen): missing links and the ferries to the Wadden islands, Dutch and German. Since 25 September 2026 (audit 4.11) the ferries among them run at Ferry_Speed (25 km/h, before 50), two empty series that ended up as a link without points are gone, and a connection is only used when both end points lie within Advanced/ExtraLink_MaxSnapDistance (250 m) of the road network, because the end points are attached to the nearest road segment whatever its distance. The Dutch connections lie within 131 m; the ferries to the North Frisian islands (Pellworm, Hooge, Langeneß, Amrum, Föhr, Sylt), which lie outside the OSM regions of the model, were attached to a road more than 1 km away and are left out. The manual connections include the ferries across the IJ in Amsterdam; other ferries, such as Vlissingen–Breskens across the Western Scheldt, are not in the OSM network for walking and cycling. The OSM regions are the Dutch provinces, Belgium, Niedersachsen and the government districts Düsseldorf, Köln and Münster; Arnsberg and Detmold, the rest of Nordrhein-Westfalen, do not border the Netherlands and are not needed for trips between Dutch origins and destinations.
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 median of the tagged speed limits of that road type in that country is applied (Advanced/OSM_MaxSpeedQuantile, 0.5); if that is unavailable, a parameterised default speed (e.g., 30 km/h) is used. For motorways with speeds below 80 km/h, that value is also enforced. Since 25 September 2026 the quantile is taken over the tagged roads only; before, it was the 90th percentile over all roads including the 75% without a tag (maxspeed 0), which for well-tagged road types was the 90th percentile of the tags and for poorly tagged ones a value in the middle (audit 4.10). The 90th percentile of the tagged roads would give untagged service roads (6% tagged, mostly the faster ones) 50 km/h; the median gives 30 km/h for service and residential roads, 15 for living streets and 50 for tertiary roads. In the OSM network store of 1 June 2026 the average speed limit of the car links went from 41.0 to 40.4 km/h and the share at 30 km/h from 49% to 60%. 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.
The OSM car network has no congestion data of its own: its speed in the morning, noon and late-evening rush is the speed limit of the road with the cap of that period (see Time periods), and the connection links of origins and destinations run at CarDefaultSpeed_low (30 km/h). Until 25 September 2026 all three rush-hour matrices of the OSM car network and every connection link ran at 130 km/h: the rush-hour speeds were empty and the fallback picked CarSpeed_kmhr, because the template compared the network type case-sensitively with 'Car' while the car networks are created with 'car' (audit 3.3 and 4.7). With UseTomTomNetworkForCars = TRUE, the default, this affected only the car accessibility of the public transport nodes, which always uses OSM.
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. The speed profile network (Speednetworks) has a row per road element and direction (VAL_DIR 2 for the direction from the start to the end junction, 3 for the opposite one), each with its own free-flow speed SPFREEFLOW, the average speeds SPWEEKDAY, SPWEEKEND and SPWEEK, and a profile per day of the week; a profile gives the speed per quarter of an hour as a percentage of SPFREEFLOW. The model uses the moments morning rush hour (07:30), noon (12:30) and late evening (19:30) of the day type set by CongestionSpeed_DaySelection (options: monday, tuesday, …, Weekday, Weekend, Week; default: tuesday), plus the free-flow speed.
Since 25 September 2026 the speed of a road in a direction is SPFREEFLOW times the relative profile speed of that direction at that time, and on the free-flow moment SPFREEFLOW itself (Weekday, Weekend and Week use their average speed). Without a speed profile row the travel time of the road network (MultiNet MINUTES) is used. Before, three things were wrong (audit 4.1 to 4.3): the free-flow and average speeds were looked up as if they were profile numbers, so every road got the factor of an arbitrary other profile (0.90 on average); both directions of a road got the profile of the first row; and the relative speed was applied to the MultiNet travel time, which on 64% of the roads is faster than SPFREEFLOW. The free-flow moment was therefore slower on average than the rush hours, and reached fewer origin-destination pairs. After the repair the average speed on the road selection is 33.7 km/h at free flow and 31.7, 31.8 and 32.4 km/h in the morning, noon and evening rush (Tuesday), and free flow is the fastest moment on all but 0.1% of the roads.
The road type selection can be restricted via TomTom_StreetTypeSelection, an inclusive upper bound on the functional road class (default: local roads of minor importance, FRC 7). Since 25 September 2026 the selection takes only road elements (FEATTYP 4110) and ferry connections (4130), and each road element once (audit 4.4 and 4.5). The 375 address area boundaries (4165) in the data used to drop out only through an overflow in the road class; and 4,078 road elements that appear in both the Dutch and the Belgian file (identical copies) became two links, which made an ordinary road point a junction with a penalty. The road selection of edition 2025.12 has 3,796,881 elements. Of the 759 ferry connections 259 have FRC 8 and are therefore outside the selection; all of these are closed to cars (ONEWAY = 'N'), like 308 of the other 500, so the car network uses the 192 car ferries. The TomTom data cover the Netherlands and Belgium only, so car routes in Germany are not available; the car stores carry Advanced/CarNetwork_Revision (_r2) in their name.
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 road links | Car penalty per passed junction |
|---|---|
| ≤ 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). Each link carries half of the penalty of its start node and half of that of its end node, so a route that passes a crossroads pays 5 seconds once: half on the link towards it and half on the link away from it. The number of connected links counts road links only, not the connection links of origins and destinations; on the TomTom network it counts road elements, so the two directed links of a two-way road count once. Parameters are configurable under ModelParameters/Advanced/Junction_Penalties.
Since 25 September 2026 (audit 5). Before, the full penalty was added at both ends of each link, so a crossroads cost 10 seconds, and the connection links were counted, so every point where an origin or destination was attached became a junction with a penalty for the through traffic. On a test set of 535 neighbourhoods in the Kop van Noord-Holland the average fastest car trip in the morning rush became 3.3 minutes shorter by this change and the speed repairs together.
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). On the TomTom network a two-way road is represented by two directed links, each with the speed of its own direction (since 25 September 2026); the connection links of origins and destinations can be used in both directions. 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 | the TomTom free-flow speed SPFREEFLOW |
| MorningRush | 07:30 |
| NoonRush | 12:30 |
| LateEveningRush | 19:30 |
Since 25 September 2026 the car speed in the morning and noon rush is capped at 100 km/h, because on Dutch motorways the daytime speed limit (06:00 to 19:00) has been 100 km/h since 2020; in the late evening and at free flow some roads allow more, so those periods are not capped. The caps are ModelParameters/Advanced/CongestionTimes/MaxSpeed (100, 100 and 0 for none) and apply to the TomTom and the OSM car network alike: the travel time of a link is at least its length divided by the cap. The name of the car store carries the cap (_vmax100). On the TomTom road selection the highest speed in the morning and noon rush was 134.7 km/h before and is 100 km/h now.
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, in the cycling travel time matrices only; pre- and post-transport of public transport and the direct bike trip always use the constant speed. Since 25 September 2026 only Fietstelweek links with measured trips (INTENS_MEE > 0) are used: for all 1.68 million links without trips the file contains an imputed speed of 8, 10 or 12 km/h, which was used as a measurement and made the linked OSM links slower than the constant speed (audit 4.14). In the OSM network store of 1 June 2026, 2.45 million bike links have a Fietstelweek speed (before 4.93 million), on average 15.8 km/h (before 12.3).
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).
Car costs and the (time, cost) front
Since 23 September 2026 the direct car trip in the public transport analysis (see Direct walking, cycling and car) is priced per link, and the car OD matrix used there is a Pareto front on travel time and route cost. The car exports described under Output are not affected: they keep one row per origin-destination pair, the fastest route, with its distance.
Cost per link
On the TomTom network every link carries its road class (FRC_rel, TomTom’s functional road class) and a cost in euro (CreateNetwork_TomTom_T, LinkSet/LinkCost):
CostPerKm = Car_VariableCosts_PerKm * Car_VariableCosts_RoadTypeFactor[road class]
+ Car_FixedCosts_PerKm (only if IncludeCarFixedCostsInPrice)
TurnCost = (half the junction penalty of the start node + half that of the end node, in minutes)
* Car_TurnCosts_PerPenaltyMinute * Car_TurnCosts_RoadTypeFactor[road class]
LinkCost = LengthKm * CostPerKm + TurnCost
The price of a trip is Car_FixedCosts_PerTrip plus the sum of LinkCost over the route. The junction penalties are the ones described under Junction penalties; the turn cost puts a price on the fuel that braking and accelerating again at a junction costs. Both factor tables live in ModelParameters and are first assumptions, to be set by PBL:
| Road class (TomTom FRC) | Typical speed | Car_VariableCosts_RoadTypeFactor | Car_TurnCosts_RoadTypeFactor |
|---|---|---|---|
| Not applicable (also the origin/destination access links) | 1.00 | 1.00 | |
| Motorway, freeway or other major road (0) | 100–130 km/h | 1.05 | 0.00 |
| Major road less important than a motorway (1) | 100 km/h | 0.95 | 0.00 |
| Other major road (2) | 80 km/h | 0.85 | 0.84, time-equivalent |
| Secondary road (3) | 70 km/h | 0.90 | 0.76, time-equivalent |
| Local connecting road (4) | 60 km/h | 0.95 | 1.44 |
| Local road of high importance (5) | 50 km/h | 1.00 | 1.00 |
| Local road (6) | 40 km/h | 1.10 | 0.64 |
| Local road of minor importance (7) | 30 km/h | 1.20 | 0.36 |
| Other road (8, outside the road selection) | 30 km/h | 1.20 | 0.36 |
The variable cost factors follow fuel consumption, which is lowest at 60–80 km/h and rises on the motorway (air drag) and in town (low gears): the WLTP phases low, medium, high and extra high are about 7.5, 5.5, 5.0 and 6.5 l/100 km for an average petrol car. The town factors are moderate because the stop-and-go part of urban consumption is priced separately through the turn costs. The factors are scaled so that the kilometre-weighted average (roughly 45% motorway, 30% regional, 25% urban) is 1, so Car_VariableCosts_PerKm (0.20 €/km) remains the average variable cost and, with Car_FixedCosts_PerKm (0.21 €/km), the total cost of ownership of 0.41 €/km.
The turn cost factors of the local road classes (FRC 4 to 8) follow the kinetic energy that has to be rebuilt after a stop, (typical speed / 50 km/h)². Car_TurnCosts_PerPenaltyMinute is 0.60 €/min, i.e. 1 cent per penalty second at 50 km/h: a crossroads (5 s) costs 5 cent, a T-junction (2 s) 2 cent. It was 0.30 €/min until 25 September 2026, when the junction penalty was still counted twice; the cost per junction stayed the same. On motorways and major roads (FRC 0 and 1) the factor is 0: the junction penalty counts every node with three or more links, so through traffic pays it at every ramp it passes without braking. With the kinetic-energy value of 6.76 every passed ramp cost 13.5 cent and every alternative that avoided one became a member of the front; on a test set of 535 neighbourhoods in the Kop van Noord-Holland to the 462 public transport nodes (morning rush, 1 cent quantum, 23 September 2026) that gave 55.7 routes per reachable origin-destination pair, and 0 on FRC 0 and 1 brought it to 23.0. On other major roads and secondary roads (FRC 2 and 3) the factor is time-equivalent (Car_TurnCosts_UseTimeEquivalent): a junction costs exactly what the distance driven during its penalty time on that road would cost, (typical speed / 60) km/min × cost per km / Car_TurnCosts_PerPenaltyMinute, with the typical speed from Car_TypicalSpeed_kmh and the cost per km of the road class including the fixed part when that is in the price (Car_TurnCosts_RoadTypeFactor_TimeEquivalent: 0.84 and 0.76 at the default parameters). A detour that avoids such a junction then costs as much per second as the junction itself, so the time lost weighs as much as the money saved and the detour does not enter the front. On the test set this narrowed the fronts from 23.0 to 19.0 routes per pair (maximum 203 to 182) and the average cost span of a pair from 1.45 to 1.27 €.
On the OSM car network the road type and the junction penalty of a link are not available after the network contraction (see Network optimisation), so there the link cost is length × Advanced/Car_CostsInPrice_PerKm without road class or turn costs.
The (time, cost) front per origin-destination pair
Travel time depends on the road class and the speed profile of each link, so time and cost are not proportional: a motorway route is fast and expensive, a local route slow and cheap. The scalar Dijkstra returns only the fastest route per pair. With Advanced/ParetoLegs_Car (default TRUE) the direct car trip uses the pareto option of impedance_matrix_od64 (available since GeoDMS 20.18, see the pareto legs of the regional network): a bi-criteria search on (travel time, link cost) that returns one row per Pareto-optimal route, the first row per pair still being the fastest. These rows enter Union_with_DirectOD and compete with the public transport chains and the other direct modes in the condensation steps.
Since GeoDMS 20.21.0 (Advanced/EngineHasParetoEpsilon, GeoDMS #1282) the search itself applies epsilon-dominance on the cost: with the option pareto(imp2_epsilon) and Advanced/CarFrontCostEpsilon (10 cent) as the extra argument after the link cost, a label is accepted at a node, per destination zone, only when its cost lies in a strictly lower 10 cent bucket than the cheapest label accepted there. Each pair therefore keeps at most one route per cost bucket, the fastest of that bucket, the first row per pair is still the fastest, and the link costs are passed unquantised, so there is no dither noise. After reading the store, Car_Front thins the front once more with pareto_optimal_eps on (travel time, cost), with Advanced/CarFrontTimeEpsilon (60 s) and the same cost epsilon: routes of a pair in the same minute bucket count as equally fast and only the cheapest cost bucket among them survives, the fastest route of the pair always staying. The store keeps the full front; the public transport output file name carries _carfront60s10ct. On the test set of 535 neighbourhoods to the 462 nodes (morning rush) the search epsilon brought the store from 19.0 to 4.2 routes per pair with the fastest route of every pair unchanged, the run from 3 minutes to 39 seconds, and the median step between neighbouring front members from 7 s and 2 cent to 36 s and 20 cent; the thinning after reading leaves 2.9 routes per pair.
On an older engine the second criterion is quantised per link to Advanced/CarLegCostQuantum (1 cent) to keep the fronts bounded: without quantisation a road network with continuous costs makes the label-setting search explode, and the number of labels per node scales with the maximum trip cost divided by the quantum. Measurements on 23 September 2026 (morning rush, 88,126 origins) showed that the size of the fronts is set by the lumpy turn costs rather than by the quantum: with flat turn cost factors 1 cent gave 2.3 routes per pair, with the (v/50)² factors on all road classes 12 routes per pair and a counting pass of 12 hours, and 10 cent with those factors still 6.8. Hence the turn cost factor 0 on motorways and major roads, and the quantum stays at 1 cent. Because many TomTom links are short (87 m on average, 3.6 cent), rounding to the nearest multiple is not an option (everything under half a quantum would vanish; 6% of the network at 4 cent). Each link therefore gets a fixed pseudo-random threshold derived from its id and is rounded down after adding it (dithering, ImpedanceMatrix_with_Cost_T/Cost_q): the sum over a route is unbiased, with a noise of about half a quantum times the square root of the number of links, some 9 cent on a trip of 300 links, so the front distinguishes cost differences from about ten cent upwards.
The matrices live in PrivateTransport/Car/Traveltimes as <moment>_<network>_w_Cost (scalar) and <moment>_<network>_w_Cost_pareto (front), next to the _w_AltImp matrices with the distance that the exports use. The public transport output file name carries the tag _paretoCare10ct (engine epsilon) or _paretoCarq1ct (per-link quantum on an older engine) when the front is on. All these parameters are written to the export metadata.
The store per congestion moment
Computing the car matrix takes 40 minutes (scalar) or more (front), so the direct car trip is stored, like the public transport chains. PublicTransport_Prep/Direct/CarPerMoment/<moment> exists for the three rush hours and the free-flow moment (Freeflow with TomTom, MaxSpeed with OSM) and holds:
Write_Car: computes the matrix and writesimpedance,alt_imp,OrgZone_relandDstZone_relto%LocalDataProjDir%/IntermediateResults/DirectCar_<moment>_<network and edition>_MaxTime-<n>min_ORG-<origins>_DEST-<destinations><pareto tag><cost tag>.mmd. The cost tag (Advanced/Car_CostTag) summarises the cost parameters, so a run with other costs writes a new store instead of silently reusing an old one.Car_store: reads that store; it fails with “MMD storage … does not exist” untilWrite_Carhas run.Car: the rows of the store withDuration_seconds(including start and parking time) andPrice, and the summarySummaryper origin-destination pair:Org_Dest,nr_routes(the size of the front, 1 in a scalar run),min_impedance,max_impedance,min_alt_impandmax_alt_imp, with the totalsstat_rows,stat_od_pairs,stat_front_maxandstat_front_mean.
Direct/Car, the unit the chain builder uses, refers to the moment selected by Car_CongestionMoment_ForDirect. To write or refresh the stores run batch\UpdateAll.cmd cars, optionally followed by the moments to do (for example UpdateAll.cmd cars MorningRush); each moment is a separate GeoDmsRun call with its log in batch\log. The same batch has the sections sources (OSM network, TomTom, GTFS and LISA stores) and chains (the public transport chain store after the pre-flight checks), and runs all three without an argument.
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 toimp_stepper 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.