Repository navigation
Model parameters
All settings of the model are in ModelParameters, in three files:
-
cfg/main/ModelParameters.dms: the settings of a run. Most users only need this file. -
cfg/main/ModelParameters/Advanced.dms: the choices agreed with PBL, technical settings, and tables that PBL can extend. In the configuration this isModelParameters/Advanced. -
cfg/main/ModelParameters/Impl.dms: settings that follow from the others. You do not set them. In the configuration this isModelParameters/Impl.
A name below that starts with Advanced/ or Impl/ is in that part. How to run the model is on How to run the model.
cfg/main/ModelParameters.dms has six groups:
- What the run computes:
AnalysisMoment,PartOfDay,OrgsetandDestset(with theOrgset_Single*andDestset_Single*selections),OutputLabel,OutputFormat,Export_TravelledDistanceandExport_PriceInformation. - The component:
Component,PreTransportandPostTransport. - Merging:
MergeOutput,MergeComponents,MergeRunNrandMergeCriteria. - Assumptions that only change the output:
MaxTravelTime,MaxWalkingTime_Org2Dest,MaxCyclingTime_Org2Dest, the time costs of walking and cycling,OVFiets_RentalPrice, and the costs, start time and parking time of the car. - Assumptions that are part of the names of the caches. After a change, the model makes those caches again. These are the maximum pre- and post-transport times and the walking and cycling speeds (pre- and post-transport caches);
Cycling_StartTime,Cycling_ParkingTime_IC_Station,MaxPTTime,Max_transfersand the time costs of transfers (chain cache); andMaxCarTimeandUseTomTomNetworkForCars(car caches). - One origin-destination pair:
OD_Origin,OD_Destination,OD_DepartureTimeandOD_Option; see Routes of an OD pair.
Two exceptions
Car_StartTime is in group 4, but it is also part of the names of the time-dependent car caches, because it shifts the departure time on the network. The maximum pre-transport times and the start and parking time of cycling also count for the chain cache: they set the longest pre-transport leg (Impl/PT_Max_V_Time), and with it the last moment at which a chain can board.
Default: 'Y2025'. The reference year (peildatum). It is a preset in Advanced/AnalysisMomentPresets. The preset sets the analysis day, the GTFS feed, and the editions of OSM, TomTom, the CBS area division, the BAG and the OV-fiets locations. The analysis day is the second Tuesday of October (#125): Y2015 (13 October 2015), Y2023 (10 October 2023), Y2024 (8 October 2024), Y2025 (14 October 2025) and Y2026 (13 October 2026). See The GTFS feed.
Default: 'Ochtendspits'. The part of the day of the departure moments: 'Ochtendspits' (07:00, 07:15, 07:30 and 07:45), 'Middag' (12:00 to 12:45) or 'Avond' (19:00 to 19:45). Each has four moments, a quarter of an hour apart. The table is Advanced/PartsOfDay. PartOfDay sets Advanced/PT_DepartureHours and Impl/Car_CongestionMoment_ForDirect.
Default: 'PT'. What the run computes (#117):
-
'WW': the whole trip on foot; -
'CC': the whole trip by bicycle; -
'Car': the whole trip by car, with start and parking time; -
'PT': a public transport journey:PreTransport, then public transport, thenPostTransport.
More about the components
The direct trips are separate components, because they treat some Pareto attributes and the front differently. The name of the component (Impl/ComponentName: WW, CC, Car or <pre>_PT_<post>, such as W_PT_W or C_RM_PT_OVf_C) comes after the label in the name of the output folder. It is not in the names of the files in that folder, to keep the paths short.
Default: Classifications/TimeInvariantTypes/V/Org2Stops_Walking. With Component 'PT': how the traveller gets to the first stop.
-
Org2Stops_Walking(W): walking to any stop; -
Org2Stops_Cycling(C): cycling to any stop; -
Org2RM_Stops_Cycling(C_RM): cycling to a rail or metro stop; -
Org2RMT_Stops_Cycling(C_RMT): cycling to a rail, metro or tram stop; -
Org2Ric_Stops_Cycling(C_Ric): cycling to an InterCity station.
The options are also in comments below the parameter. The table is Advanced/PreTransportTypes.
Default: Classifications/TimeInvariantTypes/V/Stops2Dest_Walking. With Component 'PT': how the traveller gets from the last stop to the destination.
-
Stops2Dest_Walking(W): walking; -
Stops2Dest_Cycling(C): cycling from any stop; -
RM_Stops2Dest_Cycling(RM_C): cycling from a rail or metro stop; -
RMT_Stops2Dest_Cycling(RMT_C): cycling from a rail, metro or tram stop; -
OVF_Stops2Dest_Cycling(OVf_C): the OV-fiets, only from a stop near an OV-fiets location.
Only the OV-fiets is rented. The other cycling types use the traveller's own bicycle at the last stop, at the same costs as in the pre-transport (PostTransport_Cycling_Time_Costs). The table is Advanced/PostTransportTypes.
Default: FALSE. With TRUE, the run does not compute a component. It merges the output of the components in MergeComponents (NetworkSetup/ComponentMerge). The output goes to <Analysis_date>_<OutputLabel>_Merged<MergeRunNr>. Component, PreTransport and PostTransport do not count then.
Default: 'WW,W_PT_W,CC,C_PT_W,C_PT_OVf_C,Car'. The components that the merge combines, separated by commas. The names are in Advanced/Components/name. The default gives the options of the 2023 delivery: W_PT (WW and W_PT_W), C_PT (CC, C_PT_W and C_PT_OVf_C) and Car. The output of these components must exist as parquet (OutputFormat 'parquet'), with the same OutputLabel, reference date, part of the day, origins and destinations.
Default: 1. The number of the merge in the name of its output folder, <Analysis_date>_<OutputLabel>_Merged<MergeRunNr>. Give each set of MergeComponents or MergeCriteria its own number. Under the same number, the run stops at the signature of the folder.
Where the merged components are listed
The merged components are not in the name of the folder, because the name would get too long. They are in signature.txt in that folder (_samen-<components>, with the signature of each component).
Default: 'Price,Time,Car,Bike'. The criteria of the merge. The components themselves choose on Advanced/MinimiseCriteria. You can use any combination of Price (or Price_Augm), Time, Car (NeedsCar) and Bike (NeedsBike), with at least Price or Time.
- With
'Time'or'Price'alone, each pair and departure moment keeps one row: the fastest or the cheapest. - With
'Price,Time', an option that needs a car or a bicycle can push out an option without one. -
CarandBikeonly count when a merged component needs a car or the traveller's own bicycle.
An example: what the criteria Car and Bike keep
This example merges WW, W_PT_W, CC and Car for Y2025 (analysis day 14 October 2025), departure 07:30, over the first 20 of the 450 origin blocks of Buurt2025. The table shows how many options each component has in its own output. It also shows which share of them stays in the merged front.
| Component | Options in its own output | Kept with 'Price,Time,Car,Bike'
|
Kept with 'Price,Time'
|
|---|---|---|---|
W_PT_W (public transport, walking to and from the stops) |
1,690,963 | 98.0% | 11.6% |
WW (walking) |
42,386 | 100% | 100% |
CC (cycling) |
254,222 | 99.7% | 99.7% |
Car |
25,990,938 | 98.0% | 97.9% |
Without Car and Bike, public transport loses almost 90% of its options. A public transport option is often slower than the car or the bicycle. It then stays only if it is cheaper than every faster option. With Car and Bike, an option that needs a car or a bicycle cannot push out an option that needs neither. A public transport option with walking then only drops out when walking is at least as fast.
This matters for the groups of travellers. In these 20 blocks, 463,680 origin-destination pairs have an option without car and bicycle. With 'Price,Time', only 115,929 of them keep such an option. For the other 75%, the merged output would show no way to travel without a car or a bicycle.
The car also keeps a few more options with the criteria. An extra criterion can only keep more options: an option that no other option beats on price and time is not beaten either when car and bicycle count as well. Without Car and Bike, a bicycle trip that is as fast and as cheap pushes out a car trip. In a merge of only CC and Car with 'Price,Time', the bicycle pushes out 468,331 car options (1.8%). Most of these are short trips, where walking or public transport also beats the car. In the merge of all four components the difference is therefore only 22,470 car options.
Default: 'Buurt2025'. The origins, from the list Advanced/org_domain_list. The neighbourhood sets 'Buurt2023' and 'Buurt2025' are described below (#126).
Default: 'Buurt2025'. The destinations, from the list Advanced/dest_domain_list. 'Buurt2023' and 'Buurt2025' are in it too.
Default: 'basis'. A short name for the run: at most 20 characters, only letters, digits, - and _. The output goes to %LocalDataProjDir%/Output/<Analysis_date>_<OutputLabel>, followed by the component: for example _W_PT_W or _WW, or _Merged<MergeRunNr> for a merge. A component that cycles over the network of the Fietsersbond gets _fb at the end. See Where the results are.
Give each set of parameters its own label. In GeoDmsGui, a run with other parameters under the same label stops at the signature of the folder. UpdateAll.cmd output empties the folder first, and so replaces the earlier output.
Default: 'parquet'. The format of the output files: 'parquet' or 'csv'. The parquet files are compressed and typed: times in minutes and prices in euro as float32, distances in metres as uint32. The departure moment is in the name of the file. Merging (MergeOutput) reads the parquet files of the components and writes its result in this format.
The columns of each format
The parquet files have, per kind of component, only the columns that vary within the component and do not follow linearly from other columns (Impl/ExportClass):
-
WWandCC:Traveltime; -
Car:TraveltimeandTravelDist_Car; - a public transport component:
Traveltime,Price,Price_Augm,ModeUsed,WaitingTime,PretransTime,PosttransTime, andTravelDist_Bus,_Metro,_Tram,_Railand_Ferry.
PTTime is Traveltime minus the pre- and post-transport time. The price parts follow from Price and those times. The csv files have all columns that Export_TravelledDistance and Export_PriceInformation include, each with the departure moment after its name.
Default: TRUE. Does the csv include the distances? These are the distances per leg (pre-transport, public transport per mode and in total, post-transport) and per mode (walking, cycling, car). The parquet files do not depend on it.
Default: TRUE. Does the csv include the prices? These are Price, Price_Augm, Price split into pre-transport, public transport and post-transport (PretransPrice, PTPrice, PosttransPrice), and the price per mode (WalkingPrice, CyclingPrice, CarPrice). See step 7 of Public transport. The model computes and checks prices when this is TRUE, or when MinimiseCriteria has a price criterion.
The neighbourhood sets (#126) compute from neighbourhood to neighbourhood. Advanced/NeighbourhoodSets has two of them. Each uses the CBS neighbourhoods and the BAG of the same year:
-
Buurt2023: CBS 2023 and the BAG of 1 January 2023, 14,421 neighbourhoods, for the reference dates 2015, 2023 and 2024; -
Buurt2025: CBS 2025 and the BAG of 1 January 2025, 14,729 neighbourhoods, for 2025 and 2026.
The point of a neighbourhood, as origin and as destination, is the centre of its dwelling addresses. A neighbourhood without dwellings gets the middle of its area.
More about the neighbourhood sets
When Orgset or Destset is a neighbourhood set, Impl/BAG_snapshot and Impl/RegioIndelingen_year take its years, whatever AnalysisMoment says. Origins and destinations cannot be different sets. The presets of the reference dates have the same years, so 'Buurt' and the BAG cells follow the set of the reference date too. With a neighbourhood set as origins, Advanced/MaxOrgBlockSize is 33: 450 blocks of at most 33 neighbourhoods.
For a test, you can take a part of the origins or the destinations. The Orgset_Single* parameters select one neighbourhood, municipality, province or COROP region as origins. The Destset_Single* parameters select one neighbourhood, province or COROP region as destinations. The chosen area is part of the names of the caches and the output (for example buurt_enkele_corop-kop_van_noord_holland), so two selections do not share a car cache or an output file.
Default: 90 min. The longest public transport part of a journey, with waiting and transfers.
Default: 90 min. The longest journey, with the pre- and post-transport legs.
Default: 0.19 €/min. The cost of a minute of walking during a transfer. It prevents very long transfer walks when the model minimises the price.
Default: 0.05 €/min. The cost of a minute of waiting at a transfer stop.
Default: 3. The largest number of transfers, 1 to 4. More transfers make the computation much longer and need more memory.
Default: 90 min. The longest car trip.
Default: TRUE. Does the car use the TomTom road network? With FALSE, it uses the OSM network. The TomTom network needs the TomTom caches; see Source data.
Default: 0.24 €/km. The cost of the car per kilometre (#88). The price of a car trip is its distance times this, plus Car_FixedCosts_PerTrip; see Private transport.
Default: 0 €. A fixed amount per car trip, for example for parking.
Default: 2 and 3 min. Time added to each car trip: to get to the car, and to park at the destination.
All parameters of walking and cycling are on Walking and cycling legs. In short:
- Each pre- and post-transport type has its own maximum time, for example
MaxWalkingTime_Org2Stops,MaxCyclingTime_Org2RM_StopsorMaxCyclingTime_Stops2Dest. - The maximum times and the speeds are part of the names of the pre- and post-transport caches. After a change, run
batch\UpdateAll.cmd legsagain, oroutput, which makes the missing caches first. - The time costs (
PreTransport_Walking_Time_Costs,PostTransport_Cycling_Time_Costsand so on) give a minute of walking or cycling a price. They matter whenMinimiseCriteriahas a price criterion. - The network of cycling, OSM or the Fietsersbond, is
Advanced/CyclingNetwork(see below).
Default: 90 and 90 min. The longest trip on foot or by bicycle, from origin to destination.
Default: 4.5 and 14 km/h. The speed of walking and of cycling on every link. They are part of the names of the pre- and post-transport caches.
Default: 4.45 €. The rental price of the OV-fiets (OVf_C) for the first 24 hours.
Default: 1 min. Added to each cycling trip and each cycling leg.
cfg/main/ModelParameters/Advanced.dms holds three kinds of settings: the choices agreed with PBL, such as MinimiseCriteria and CentroidWeightType; technical settings that you rarely need to change; and tables that PBL can extend. A normal run does not need them. Open a panel to see the parameters of a group.
The tables and the other settings in Advanced.dms
The tables are the presets of the reference dates (AnalysisMomentPresets), the origin and destination sets (org_domain_list, dest_domain_list, NeighbourhoodSets), the parts of the day (PartsOfDay), and the definitions of the components (PreTransportTypes, PostTransportTypes, PT_Components, DirectComponents and Components). Advanced.dms also holds the maximum walking times of the pre- and post-transport types that no component uses (MaxWalkingTime_Org2RMT_Stops, _Org2RM_Stops, _Org2Ric_Stops, _OVF_Stops2Dest, _RMT_Stops2Dest and _RM_Stops2Dest). They are equal to MaxWalkingTime_Org2Stops or MaxWalkingTime_Stops2Dest.
CentroidWeightType, Components/SingleDepartureMoment and Components/BlocksPerPortion
Default: 'Addresses'. Are the centres of the neighbourhoods weighted by addresses or by population?
Default: TRUE for WW, CC and Car; FALSE for the public transport components, and for Car with CarTimeDependent. Does the component compute only one departure moment? That moment is the congestion moment of the part of the day (Impl/CongestionMinute, 07:30 in the morning). Otherwise it computes the four quarters of an hour of Advanced/PT_DepartureMinutes_All. The direct trips do not depend on the departure moment, except the time-dependent car trip (#132). The merge (MergeOutput) reads the one file of such a component for each departure moment.
Default: 50; 25 for the public transport components that cycle to the first stop; 10 for MergeOutput. The number of origin blocks per GeoDmsRun in the output step (batch\UpdateAll.cmd output, batch\WriteOutputBlocks.ps1). The table Advanced/Components has a value per component. For a public transport component the value comes from its pre-transport type (Advanced/PreTransportTypes/BlocksPerPortion), because the pre-transport decides the memory. 0 puts all blocks in one portion.
Each portion starts up again, which takes a few minutes (2.5 to 6 minutes for Y2023, Buurt2023 to Buurt2023). A smaller portion keeps the memory lower when it grows per block: a merge in one request grows by about 7 GB per block, hence 10. For one run, the environment variable OUTPUT_BATCHSIZE replaces the value (set OUTPUT_BATCHSIZE=20 before UpdateAll.cmd output). OUTPUT_MAXBLOCKS computes at most that many blocks, for a test.
MinimiseCriteria, ChainParetoTimeEpsilon, PriceMethod, NS_TariffChoice and seven more
Default: 'Price,Time'. The criteria of the Pareto front of a component, agreed with PBL: 'Price', 'Price_Augm', 'Time', or a combination such as 'Price,Time'. Upper and lower case do not matter. The price and time criteria are part of the name of the chain cache: after a change, the model makes a new chain cache.
'Car' and 'Bike' make owning a car or a bicycle a criterion of the final selection per departure moment. They change the name of the output (MinCrit-Price_Time_A_C), but not the chain cache; see Car and bicycle ownership as criteria. Each component chooses on price and time. The ownership criteria belong to the merge, which has its own criteria, MergeCriteria.
Default: 0.01. The relative margin on the travel time (GeoDMS #1282). The model uses it in the final selection per departure moment, in the merge of the components, and in the chain joiner when a leg has a time penalty (flex). The price comes first, because the model reports on accessibility poverty. The cheapest option always stays. A more expensive option only stays when it is more than 1% faster than the fastest cheaper option that stays. Prices, and the other times in the chain joiner, are compared exactly. With 0, the travel time is compared exactly too. See Public transport.
Default: 'DOVA'. How the model prices regional transport (not NS): 'Detailed' (a fare table per mode, operator, concession and line; 2023 to 2026) or 'DOVA' (km fares per concession from the DOVA overview; 2013 to 2026). Feeds before 2023 always use DOVA. See Public transport fares.
Default: 'Price_FullFare'. The NS fare: 'Price_FullFare', 'Price_20pct_Discount' or 'Price_40pct_Discount'.
Default: 500 m. The longest transfer walk between two stops, in a straight line.
Default: TRUE. Does a transfer between two platforms of the same NS station take at least the transfer time of that station in the NS timetable (IFF, Advanced/IFF_file_date) (#123)? It is part of the name of the chain cache as _iff<date>. See Transfers.
Default: 899 s. The longest wait at the origin before the journey starts.
Default: FALSE. Does the wait at the origin count as travel time?
Default: 104. The number of stops per stop block of the chain step. Together with NumberOfStopBlocks, it decides the peak memory.
Default: 500 (1 for an OD pair). The number of stop blocks. MaxStopBlockSize times NumberOfStopBlocks must be larger than the number of stops (ChecksBeforeRunning/PT_CheckBlocks).
The hour of the departure moments: that of PartOfDay (7, 12 or 19). For more hours in one run, raise its nrofrows and give the hours as a list.
The time-dependent search, OSM speeds, manual connections, the speed cap and the car front
Default: 'pareto_alt'; one hour before the departure hour; 48. The search of the time-dependent car trip: 'pareto_alt' takes distance first and the time profile on the travel time; 'scalar' takes only the fastest route, for tests. The window has 48 slots of 300 seconds: 4 hours, from 06:00 in the morning.
Default: 0.5. For an OSM road without a usable maxspeed tag, the model takes this quantile of the speed limits of the same road type and country; see Private transport.
Default: 250 m. The largest distance between an end of a manual connection (a ferry or a missing link) and the road network. A connection with an end further away is left out.
Default: 100, 100 and 0 km/h. The highest car speed in the morning, noon and late-evening rush; 0 means no limit. It holds on the TomTom and the OSM network. Free flow has no limit. See Private transport.
Default: TRUE and 0.04 km. Is the car trip a Pareto front of time and distance per pair, instead of only the fastest route? The quantum is the step of the distance criterion per link, with CarFrontEpsilon 0; see Private transport.
Default: 0.01; 2.5 km per minute of MaxCarTime. The relative margin of the car front (GeoDMS #1282). Per destination, the routes are taken in the order of distance (the price), the shortest first. A longer route only stays when it is more than 1% faster than the shorter routes that stay. The search is exact, because the travel time has a limit. CarFrontMaxDistance is the limit on the distance that the engine needs; it is wide enough to cut nothing, while MaxCarTime limits the travel time. See Private transport. It needs an engine that applies the margin relatively, as GeoDMS 20.24.2 and later versions do.
Cycling_PreTransport_Penalty, Cycling_ParkingTime_IC_Station and CyclingNetwork
Default: 0 and 3 min. The parking time at the end of a cycling leg to the first stop, and the extra parking time when that leg ends at an InterCity station (a stop in PublicTransport_Prep/Impl/Ric_Stops). They hold for every type of cycling pre-transport.
Default: 'OSM'. The network of all cycling legs and of the cycling trip: 'OSM' or 'Fietsersbond' (#124). OSM is the default at the request of PBL: the network of the Fietsersbond, of 2024, gets no new versions, and PBL first compares it with OSM. With the Fietsersbond, ferries up to Advanced/Fietsersbond_MaxFerryLength (2 km) take part, with Advanced/Fietsersbond_FerryExtraTime (5 min) extra. When cycling is part of a run, the name of the output has _fb<date>-veer<m>m<min>min, and the output folder gets _fb. See Walking and cycling legs.
cfg/main/ModelParameters/Impl.dms holds settings that follow from the others. You do not set them. They are the dates and years that apply (GTFS_file_date, Analysis_date, FareTable_year, BAG_snapshot), the choices of the run (AllowDirectWalking, AllowDirectCycling, AllowDirectCar, Car_CongestionMoment_ForDirect, CarTimeDependent, PT_DepartureMinutes), and the tags, folders and file names of the caches and the output.
GTFS_file_date, Analysis_date, FareTable_year and the types and minutes of the run
The download date of the GTFS feed, from the preset of AnalysisMoment. It is the name of the folder of the feed under %NetworkModel_Dir%/Infrastructuur/GTFS/, and of its cache %LocalDataProjDir%/GTFS/<date>.mmd. Its year also sets the fare year (see Impl/FareTable_year).
The day for which the model analyses the timetable: the reference date of AnalysisMoment. The feed must have a complete timetable on this day, and on the day before or after when the time window needs it. Its weekday must match CongestionSpeed_DaySelection. The model checks this when it builds the network; see Create routable network from GTFS files.
The fare year. It follows from the year of GTFS_file_date, so that the fare table always matches the operator names in the feed. Do not set it by hand. The DOVA year, the NS price year and the year of the concession areas follow from it.
The pre-transport type of the run: that of PreTransport; see Pre- and post-transport connections on the Public transport page.
The post-transport type of the run: that of PostTransport.
The minutes of the departure moments within the hour: those of Advanced/PT_DepartureMinutes_All (0, 15, 30 and 45). A component with Advanced/Components/SingleDepartureMoment has only the minute of the congestion moment. An OD pair with OD_DepartureTime has only that moment.
AllowDirectCar, Car_CongestionMoment_ForDirect and CarTimeDependent
Does the car trip take part in the Pareto front per pair, next to AllowDirectWalking and AllowDirectCycling? It follows from Component (Advanced/Components/DirectCar). With MergeOutput, it is TRUE when a merged component has the car.
Which car travel time the car trip uses: 'MorningRush', 'NoonRush', 'LateEveningRush' or 'Freeflow' (only with TomTom). With the OSM network it is 'MaxSpeed'. It follows PartOfDay: the middle of the hour of the departure moments (07:30, 12:30 or 19:30).
Default: equal to UseTomTomNetworkForCars. Does the car trip use link times that depend on the time of day, with a cache per departure moment (#132)? In the morning these caches are TD07h00m to TD07h45m, which UpdateAll.cmd cars makes. See Time periods on the Private transport page. It needs TomTom, a weekday as CongestionSpeed_DaySelection, and for Advanced/CarTD_Search 'pareto_alt' an engine with timedependent_alt.
NetworkModel PBL documentation