Private transport

Private transport covers the modes of personal transport: car, bicycle and walking. Walking uses the OpenStreetMap (OSM) network. Cycling uses the OSM network or, as an option, the route network of the Fietsersbond (ModelParameters/Advanced/CyclingNetwork, see Fietsersbond). The car uses the TomTom network or the OSM network (UseTomTomNetworkForCars, default TRUE: TomTom).

This page describes the networks, their preparation, car routing with its time periods, and the front of the direct car trip. How walking and cycling legs and direct trips are computed is on Walking and cycling legs.

Contents

Network sources

OSM

The OSM data are the Geofabrik shapefiles, downloaded per region: the Dutch provinces, Belgium, Niedersachsen and the government districts Düsseldorf, Köln and Münster (ModelParameters/Advanced/OSM_impl). Arnsberg and Detmold, the rest of Nordrhein-Westfalen, do not border the Netherlands and are not needed for trips between Dutch origins and destinations. The extract follows the reference date (OSM_file_date in Advanced/AnalysisMomentPresets).

The regional extracts are merged into one network: duplicate geometries are removed and only the largest connected network is kept. Per road segment the model keeps the road type (the Geofabrik fclass, as roadType_rel), the speed limit (maxspeed) and the direction (oneway). The result is the OSM network cache %LocalDataProjDir%/OSM/Final_Network_<date>_r3.mmd (Make_Final_Network).

Road types

The classification Classifications/OSM/roadType gives every road type a car speed inside and outside built-up areas (CarSpeedInside, CarSpeedOutside), a cycling speed (BikeSpeed) and whether pedestrians are permitted (IsPedestrian). These values decide which segments belong to which network; the travel speeds themselves come from the speed limit for the car and from constant speeds for walking and cycling.

  • The car network: the road types with a CarSpeedInside above 1 km/h (IsPartOfCarNetwork).
  • The bike network: the road types with a BikeSpeed above 1 km/h (IsPartOfBikeNetwork).
  • The pedestrian network: the road types with IsPedestrian.

Tracks (farm and forest roads) are not part of the car network, with or 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 Geofabrik class that is missing from the classification becomes unknown, so an unknown road type never carries cars or bicycles. Read_Roads_shp/NrUnmappedFclass counts such features per region, so that a new class is noticed.

One-way roads

A one-way road whose direction of travel is against its digitising direction (oneway = 'T') is reversed when it is read. Every one-way link then runs from its first to its last point, which is the direction in which the network uses it.

The bike and pedestrian networks treat all roads as two-way, because the oneway of the shapefile does not say whether cyclists are exempt.

Manual connections and ferries

The Geofabrik road layer has no ferries. The network therefore gets manual connections (OSM/NetworkPreperation/preperation/ExtraConnections): missing links and ferries, among them the ferries to the Dutch and German Wadden islands (ExtraBoatConnections) and the ferries across the IJ in Amsterdam.

  • Ferries run at Ferry_Speed (25 km/h), the other manual connections at CarDefaultSpeed (50 km/h).
  • The end points of a connection are attached to the nearest road segment, whatever its distance. A connection is therefore only used when both end points lie within Advanced/ExtraLink_MaxSnapDistance (250 m) of the road network. The Dutch connections lie within 131 m. The ferries to Neuwerk and the North Frisian islands (Pellworm, Hooge, Langeneß, Amrum, Föhr, Sylt) lie outside the OSM regions of the model and are left out.
  • Other ferries, such as Vlissingen to Breskens across the Western Scheldt, are not in the OSM network for walking and cycling.

Speed limits

OSM speed limits are often missing or implausible. The car speed of a segment therefore follows these rules, per road type and country (Merge_Roads_perCountry):

  1. A tagged speed limit above 0 and below 140 km/h is used as it is.
  2. Otherwise the segment gets a quantile of the tagged speed limits of its road type in its country (Advanced/OSM_MaxSpeedQuantile, 0.5: the median). A road type without tags gets CarDefaultSpeed_low (30 km/h).
  3. A motorway with a speed below 80 km/h also gets that quantile.
  4. A speed that is still 0 becomes CarDefaultSpeed (50 km/h), and a speed below 15 km/h becomes 15 km/h.

The quantile is taken over the tagged roads only, and the median describes a typical untagged road. A higher quantile would overrate poorly tagged road types. In OSM 20260601, for example, 6% of the service roads are tagged, mostly the faster ones, and the 90th percentile of their tags would give the untagged ones 50 km/h. The median gives 30 km/h for service and residential roads, 15 km/h for living streets and 50 km/h for tertiary roads.

The OSM car network

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 with the cap of that period, and at the moment MaxSpeed the speed limit capped at CarSpeed_limit_kmhr (100 km/h); see Time periods. The connection links of origins and destinations run at CarDefaultSpeed_low (30 km/h).

TomTom

The TomTom data consist of the road elements (Roads), the junctions (Junctions) and the historical speed profiles by time of day and day of the week (Speednetworks and Speedprofiles). The edition follows the reference date (CarCongestionSpeed_date in Advanced/AnalysisMomentPresets, for example yr2025_12). The data cover the Netherlands and Belgium only, so car routes in Germany are not available.

Speeds

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 row has its own free-flow speed SP_freeflow, the average speeds SP_weekday, SP_weekend and SP_week, and a profile per day of the week (SP_Monday to SP_Sunday). A profile gives the speed per time slot of 5 minutes as a percentage of the free-flow speed.

The model uses the moments morning rush (07:30), noon (12:30) and late evening (19:30) of the day set by CongestionSpeed_DaySelection (monday to sunday, Weekday, Weekend or Week; default tuesday), plus the free-flow speed. The speed of a road element in a direction is:

  • for a day of the week: SP_freeflow times the relative speed of the profile of that direction at that time;
  • for Weekday, Weekend and Week: the average speed of that direction, at every moment;
  • at the free-flow moment: SP_freeflow;
  • without a speed profile row: the travel time of the road network (MultiNet MINUTES);
  • on a ferry: Ferry_Speed (25 km/h).

Both directions of a two-way road have their own row, and so their own speed.

Road selection

TomTom_StreetTypeSelection is an inclusive upper bound on the functional road class (default FuncRoadClass/V/Local_Road_of_Minor_Importance, FRC 7). The selection (Roads_selection) takes only road elements (FEATTYP 4110) and ferry connections (4130), not the address area boundaries (4165). It takes each road element (NW_ID) once: road elements that appear in both the Dutch and the Belgian file would otherwise become two links, which would make an ordinary road point a junction with a penalty.

In edition 2025.12 the road selection has 3,796,881 elements. Of the 759 ferry connections, 259 have FRC 8 and are 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 signature of the car caches carries Impl/CarNetwork_Revision (_r3), so that a change in the construction of the car network leads to a new cache.

Fietsersbond

For cycling the model can use the route network of the Fietsersbond instead of the OSM bike network (ModelParameters/Advanced/CyclingNetwork). How it is read and used, and how it compares with OSM, is on Walking and cycling legs.

Network preparation

Connecting origins and destinations to the network

On the networks built from road segments (Templates/CreateNetwork_Efficient_T: OSM for car, bike and walking, and the Fietsersbond network for cycling), origins and destinations are connected to the nearest point of a connectable road segment with connect_ne; for walking and cycling the stops are connected as well. The Connectable flag excludes motorways and motorway links, because direct access to these roads is not realistic.

On the TomTom network (Templates/CreateNetwork_TomTom_T) origins and destinations are connected to the nearest connectable junction with capacitated_connect. Each location gets a synthetic junction ID, above the highest real JNCTID, and a straight connection link to its junction, which can be used in both directions. A junction is connectable when one of its road elements is not a motorway (functional road class 0), so a location is connected to the nearest accessible junction rather than the physically closest one.

Junction penalties

Every junction that a route passes costs a small time penalty, for the delay at intersections. The penalty depends on the number of road links 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

Walking, cycling and the e-bike have the same values (with_2Links_Walking, with_2Links_Cycling, with_2Links_E_Biking and so on). The parameters are in ModelParameters/Advanced/Junction_Penalties.

  • Each link carries half of the penalty of its start node and half of that of its end node. A route that passes a crossroads therefore pays 5 seconds once: half on the link towards it and half on the link away from it.
  • Only road links count, not the connection links of origins, destinations and stops. On the TomTom network the count is of road elements, so the two directed links of a two-way road count once.
  • On the networks built from road segments, a node where all road links are slow roads (IsSlowTrafficRoad: a road type with a car speed outside built-up areas of at most 30 km/h, such as residential streets, service roads and cycle paths) gets the penalties for slow roads instead (with_3_lowerSpeedLinks_Walking and so on), because in a residential area one need not stop at every side street. These are all 0 s, so such a node costs no time. The TomTom network has no such variant.

Network optimisation

After filtering to the connected network and adding the connection links, a network built from road segments is simplified with an iterative contraction (CreateMoreEfficientNetwork, NumberOfItersForNetworkCleanUp iterations). Nodes that are not junctions are removed and their links merged into single longer links, which makes the network smaller without changing routes or travel times. See Network optimisation.

The TomTom network is not contracted. Its junctions already form a clean topological network, so contraction gains little, and the time-dependent link times need every link to be one road element in one direction.

Routing

Dijkstra’s algorithm

After the network is prepared, impedance_matrix_od64 computes the OD matrix: a Dijkstra search from each origin to all reachable destinations, by impedance, within the maximum travel time (MaxCarTime, MaxCyclingTime_Org2Dest, MaxWalkingTime_Org2Dest).

The impedance of a link is its travel time in seconds: the link length divided by the speed of the time period, plus the junction penalties. On the TomTom network this is LengthKm / Speed_per_ImpedanceType plus the penalties.

One-way restrictions are respected by default (InterpretAllRoadsAsBidirectional, default FALSE). On the TomTom network a two-way road is two directed links, each with the speed of its own direction; the connection links of origins and destinations can be used in both directions. With TRUE all car roads are two-way, which can be useful for analysis but is not realistic for car routing.

Time periods

Three congested time periods are modelled, plus a free-flow reference. They are defined in ModelParameters/Advanced/CongestionTimes and are the same for both car networks:

Period TomTom network OSM car network
Freeflow (TomTom), MaxSpeed (OSM) SP_freeflow, no cap the speed limit, at most CarSpeed_limit_kmhr (100 km/h)
MorningRush the profile at 07:30, at most 100 km/h the speed limit, at most 100 km/h
NoonRush the profile at 12:30, at most 100 km/h the speed limit, at most 100 km/h
LateEveningRush the profile at 19:30, no cap the speed limit

The cap in the morning and noon rush follows the daytime speed limit on Dutch motorways, 100 km/h between 06:00 and 19:00. In the late evening and at free flow some roads allow more, so those periods have no cap.

  • The caps are CongestionTimes/MaxSpeed: 100, 100 and 0 (no cap) km/h.
  • They 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 signature of a car cache carries its cap (_vmax100).

The OSM car network has no congestion data, so its rush-hour speed is the speed limit with the cap. The direct car trip uses the period Car_CongestionMoment_ForDirect, which follows the part of the day (PartOfDay): MorningRush for Ochtendspits, NoonRush for Middag and LateEveningRush for Avond; with OSM it is MaxSpeed.

One snapshot per period

The TomTom speed profiles give a relative speed per time slot of 5 minutes: 288 per day, 1,465 profiles for NL and BE (the same table in the editions 2023.12 and 2025.12), and per road element and direction a profile per day of the week. With a snapshot the model uses one slot per period for every link and every departure moment; in the morning that is Tuesday 07:30 (CongestionSpeed_DaySelection).

The time at which a car reaches a link then plays no part, although trips of up to 90 minutes that leave between 07:00 and 07:45 are on the road up to about 09:15. For example, on the 2023 edition, Tuesday, over the roads of the model, the link minutes relative to 07:30 are:

07:00 07:15 07:30 07:45 08:00 08:15 08:30 08:45 09:00
−2.2% −1.1% 0 +1.0% +1.5% +1.4% +1.0% +0.4% −0.2%

Over the network 07:30 is about the mean of the window from 07:00 to 09:00 (+0.2%), so as one snapshot it is well chosen. Per trip it differs by about 1.5 to 2% over the network, and more on congested corridors. A cache per departure quarter with a snapshot would not solve this, because a trip of 45 minutes leaving at 07:00 would then use the speeds of 07:00 all the way. The time-dependent link times below follow the trip through the profile instead.

With ModelParameters/Impl/CarTimeDependent (default with TomTom; it needs a day of the week as CongestionSpeed_DaySelection) the direct car trip has a cache per departure moment, PublicTransport_Prep/Direct/CarPerMoment/TD<moment> (TD07h00m to TD07h45m in the morning). In it every link gets the speed of the moment at which the trip enters it (#132, engine GeoDMS#1304).

Templates/CreateNetwork_TomTom_T, container TimeDependent, prepares the link times:

  1. Every link of the TomTom network is one road element in one direction, or a connection link, without merging, so a link can have a profile of its own. Only links whose speed changes in the window get one. The window has CarTD_NrSlots (48) slots of 5 minutes from Advanced/CarTD_WindowStart, one hour before the departure hour (06:00 in the morning).
  2. Per link and slot the factor is T_ref / T(slot). T(slot) is the link time as the snapshot of that slot computes it, with the same operations: SP_freeflow times the relative speed of the profile of the day, MINUTES without a speed, the cap, CarDefaultSpeed_low and the junction corrections. T_ref is the snapshot of the congestion moment of the part of the day (Car_CongestionMoment_ForDirect, 07:30 in the morning).
  3. The search takes T_ref as the fixed link time and divides it per slot by the factor. Within a slot the link time is therefore exactly that of the snapshot of that slot; in the slot of the congestion moment every link equals the snapshot, bit for bit (NrRefMismatch is 0). A trip that crosses the border of a slot rides the rest of the link at the speed of the next slot, so that a later entry never leaves earlier.
  4. The departure time on the network is the departure moment plus Car_StartTime.

For Y2023 (TomTom 2023.12) in the morning, 3,444,718 of the 6,172,308 links have a profile. The factors run from 0.45 (the peak, 2.2 times slower than 07:30) to 3.57 (early morning), and the table of 165 million factors takes 6 seconds and 4.8 GB to build.

The search is set by Advanced/CarTD_Search:

  • 'pareto_alt' (default): distance first, as for the snapshot (the shortest route exact, a longer one kept if it is more than CarFrontEpsilon faster; see The (time, distance) front), with the time profile on the second criterion, the travel time (timedependent_alt, the extension of GeoDMS#1304);
  • 'scalar': only the fastest route, with the time profile on the single criterion (timedependent), for tests on an engine without timedependent_alt.

Checks on Dronten to Buurt2023 (5 origin blocks, Y2023):

  • With all factors 1 the time-dependent search at 07:30 gives the snapshot: the same 317,335 pairs with the same time and distance, and with 'pareto_alt' the same 2,036,186 routes in the front.
  • With the real factors and 'scalar', the fastest and slowest of the four departure moments differ for 98% of the pairs, by 1.2 minutes on average (at most 3.7). The median is on average 1.0 minute above the snapshot of 07:30: the trips from Dronten, 72 minutes on average, run into the peak around 08:00.
  • With the real factors and 'pareto_alt', the fastest route per pair in the cache is never faster than that of the scalar search and at most a factor 1/(1 − CarFrontEpsilon) (1.0101) slower, with 6.3 routes per pair on average.

The final trade-off per departure moment thins the front once more (price first, travel time including start and parking time, ChainParetoTimeEpsilon). The fastest option in the output can therefore be up to about 2% slower than the fastest route, as with the snapshot.

In the output step each origin block and departure moment reads the cache of that moment:

  • It takes only the rows of its own origins (PerDepartureMoment_T, CarCache and CarRows, with collect_by_cond per tile of the cache), because a lookup into a column of the cache would first copy the whole column, per block, moment and column.
  • It computes price, front and places for those rows only (DirectCar, CarFront_T).
  • The car trips then join the other direct modes, which stay in Direct_OD, in Direct_OD_M.

Without CarTimeDependent one snapshot per period applies, and the component Car computes one departure moment, that of the congestion moment (Advanced/Components/SingleDepartureMoment, see How to run the model).

Cycling and walking speeds

Walking and cycling use a constant speed on every link: WalkingSpeed_kmhr (4.5 km/h), CyclingSpeed_kmhr (14 km/h), and E_BikingSpeed_kmhr (20 km/h) for the e-bike. How walking and cycling legs and direct trips are computed is on Walking and cycling legs.

Measured cycling speeds from the Fietstelweek (UseActualCyclingSpeeds, OSM only) are used in the cycling travel time exports only (see Output), not in the legs or the direct trips. Only Fietstelweek links with measured trips (INTENS_MEE > 0) count; for links without trips the file contains an imputed speed of 8, 10 or 12 km/h, which is not a measurement. In the OSM network cache of the extract 20260601, 2.45 million bike links have a Fietstelweek speed, on average 15.8 km/h.

Output

Besides the public transport analysis, the model can write an OD matrix per mode, with a row per origin-destination pair (NetworkSetup/PrivateTransport: Export_Car_traveltimes, Export_Cycling_traveltimes, Export_Walking_traveltimes):

  • walking: the travel time and the distance;
  • cycling: the travel time at the cycling and at the e-bike speed, with UseActualCyclingSpeeds also at the Fietstelweek speeds, and the distance;
  • car: the travel time of the fastest route at free flow (MaxSpeed with OSM) and in each of the three rush hours; with Export_TravelledDistance also their distances.

They are csv files in the folder PerBlock of the output folder (Impl/fileNamePrefix). The file name holds the origin set, the destination set, the network, for the car the day selection, and the maximum travel time.

Car costs and the (time, distance) front

The direct car trip in the public transport analysis (see Direct walking, cycling and car) is a Pareto front per origin-destination pair on travel time and distance. The price follows afterwards from the distance (#88):

Price = Car_FixedCosts_PerTrip + distance * Car_CostPerKm        (Car_CostPerKm = 0.24 €/km, Car_FixedCosts_PerTrip = 0)

The price counts in Price with Advanced/IncludeCarCostsInPrice (default TRUE). With one price per km the (time, distance) front is also the (time, price) front. The car exports described under Output are not affected: they keep one row per origin-destination pair, the fastest route, with its distance.

The (time, distance) front per origin-destination pair

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 (as the pareto legs of the regional network): a bi-criteria search that returns one row per Pareto-optimal route.

  • These rows enter Union_with_DirectOD and compete with the public transport chains and the other direct modes in the condensation steps.
  • Each row carries its travel time and its distance in km, so the output has the distance of a car trip: TravelDist_V and, as the last column, TravelDist_Car in the csv, and TravelDist_Car in the parquet of the component Car.

Distance first

The search takes the distance first, because the price is the distance times Car_CostPerKm and the reporting theme is accessibility poverty (Advanced/CarFrontEpsilon, GeoDMS #1282):

  1. impedance_matrix_od64 runs on the link length, with the travel time as the alternative impedance.
  2. pareto(OrgZone_max_imp2,imp2_epsilon) bounds the travel time at MaxCarTime and applies CarFrontEpsilon (0.01) to it. cut(OrgZone_max_imp) bounds the distance at CarFrontMaxDistance, 150 km/h times MaxCarTime, which cuts nothing.
  3. Per destination zone the routes are accepted in the order of distance, the shortest first, and a longer route only when its travel time is more than 1% below that of the fastest route accepted there: time < 0.99 x that time.
  4. Because the travel time is bounded, the engine searches exactly and applies the epsilon per destination zone only. At a node, a partial route that is less than 1% faster can be the only one that stays within the 90 minutes.

The first row per pair is the shortest and cheapest route, exactly. The fastest route stays when it is more than 1% faster than every shorter route that is kept; a route that is longer and at most 1% faster is no real alternative. There are no buckets, so whether a route stays depends only on how much faster it is, and nothing compounds along a route.

For example, on the neighbourhoods of Dronten to all neighbourhoods of 2023 (42 origins, 313,178 pairs) the exact front has 22.6 routes per pair and the front with the rule 6.3, computed in 36 seconds. An epsilon applied per node takes 9 seconds, but makes the cheapest route longer than the exact one for 13.6% of the pairs (up to 40%) and leaves 5,800 pairs unreached.

Reading the front

  • Car/Front (CarFront_T) applies the same rule with pareto_optimal_eps on (distance, travel time) after reading the cache, which changes nothing when the cache was made with the same epsilon.
  • ImpedanceMatrix_with_AltImp_pareto_T gives Car_Time and Car_Distance whatever the search order; the cache holds them as impedance and alt_imp.
  • The epsilon must be relative (GeoDMS #1282), as it is in GeoDMS 20.24.2 and later, the versions that the model accepts.

Without the epsilon

With CarFrontEpsilon 0 the search takes the travel time first and quantises the distance per link to Advanced/CarLegDistanceQuantum (40 m, 1 cent at 0.24 €/km). The quantisation keeps the fronts bounded: without it a road network with continuous lengths makes the label-setting search explode. Because many TomTom links are shorter than the quantum, each link gets a fixed pseudo-random threshold derived from its id and is rounded down after adding it (dithering, ImpedanceMatrix_with_AltImp_pareto_T/AltImp_q), so the sum over a route is unbiased.

Matrices and signatures

The front matrices are in PrivateTransport/Car/Traveltimes as <moment>_<network>_w_AltImp_pareto, next to the scalar _w_AltImp matrices: the fastest route with its distance, which the exports use with Export_TravelledDistance and the direct car trip uses when ParetoLegs_Car is off.

  • The signature of the car caches carries ParetoLegs_Car_FileTag (_paretoCarD-r1pct for distance first with a relative epsilon of 1%, _paretoCarq40m for the quantum per link) and the network revision _r3.
  • The signature of the public transport output carries the same tag and the price tag Car_PriceTag (_car24ctkm).
  • These parameters are also written to the export metadata (ExportSettings).

The cache 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> (DirectCar_T) exists for the three rush hours and the free-flow moment (Freeflow with TomTom, MaxSpeed with OSM) and, with CarTimeDependent, for each departure moment (TD07h00m and so on). It holds:

  • Write_Car: computes the matrix and writes impedance (the travel time), alt_imp (the distance in km), OrgZone_rel and DstZone_rel to %LocalDataProjDir%/IntermediateResults/DirectCar_<network>_<moment>_<origins>_<destinations>_<hash>.mmd (Impl/IntermediateResultsDir).
  • Read_Car: reads that cache. It fails when the signature of the cache is missing or differs; when the cache does not exist, compute Write_Car first.
  • Car (CarFront_T): the rows of the cache with Duration_seconds (including Car_StartTime and Car_ParkingTime), Distance and Price; the summary Summary per origin-destination pair, with Org_Dest, nr_routes (the size of the front, 1 in a scalar run), min_impedance, max_impedance, min_alt_imp and max_alt_imp; the totals stat_rows, stat_od_pairs, stat_front_max and stat_front_mean; and the thinned front Front.

The name of the cache, for example DirectCar_TT2025-12_TD07h00m_b2025_b2025_3dc99b97.mmd, holds:

  • the road network (NetTag): TT and the TomTom edition (TT2025-12 for yr2025_12), or OSM and the extract date;
  • the moment;
  • the origin and destination sets (OrgSet_PathTag, DestSet_PathTag);
  • a hash of the signature, which is in signature.txt in the folder of the cache. The signature holds the moment, the network and edition, the day selection, MaxCarTime, the origin and destination sets, the speed cap, the pareto tag, the tag of the time-dependent search and CarNetwork_Revision. The costs are not in it: the cache holds time and distance, and the price follows when it is read.

Direct/Car, the unit that joins Direct_OD, is Car/Front of the moment Car_CongestionMoment_ForDirect. With CarTimeDependent the car trip is not in Direct_OD; each origin block and departure moment reads the cache of its moment (see Time-dependent link times).

To write or refresh the caches, run batch\UpdateAll.cmd cars, optionally followed by the moments to do, for example UpdateAll.cmd cars MorningRush or UpdateAll.cmd cars TD07h00m TD07h15m TD07h30m TD07h45m. Without moments it writes the caches of the moments the run reads (MakeUnlinkedData/Step4_DirectCar/Moments): the departure moments with CarTimeDependent, otherwise the moment Car_CongestionMoment_ForDirect. Each moment is a separate GeoDmsRun call with its log in batch\log, and the section is skipped when the component of the run has no direct car trip (AllowDirectCar). The other sections of the batch are described under Updating all caches with batch\UpdateAll.cmd.

Table of contents