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 eight groups:
- What the run computes:
AnalysisMoment,AnalysisDay,PartOfDay,OrgsetandDestset(with theOrgset_Single*andDestset_Single*selections),OutputLabel,OutputFormat,Export_TravelledDistance,Export_PriceInformationandMinimiseCriteria. - The variant: the pre-transport types (
PreTransport), the post-transport types (PostTransport) and the direct trips (DirectWalking,DirectCycling,DirectCar) that take part, andGuiComponentfor GeoDmsGui. - Merging the components of the variant:
Merge,MergeCriteriaandMergeRunNr. - 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); andMaxCarTime,UseTomTomNetworkForCarsandCongestionSpeed_DaySelection(car caches). - One origin-destination pair:
OD_Origin,OD_Destination,OD_DepartureTimeandOD_Option; see Routes of an OD pair. - The sources:
AnalysisMomentPresets, a row per analysis moment, and the deliveries that every analysis moment uses (IFF_file_date,Fietsersbond_file_date,Population_Year,NDW_yearandOVFiets_Locations). - The departure moments:
PartsOfDayandPT_DepartureMinutes_All.
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 row of AnalysisMomentPresets (group 7). 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). A run needs an analysis day and a GTFS feed, which Y2023 to Y2026 have. See The GTFS feed.
Default: ''. Another analysis day than that of AnalysisMoment, as yyyymmdd, for example '20251015'. Empty: the analysis day of the preset. The GTFS feed of AnalysisMoment must hold the service days that the part of the day needs on that day; the checks of UpdateAll.cmd say so when it does not (see Starting UpdateAll.cmd). With a direct car trip, the day must also fall on CongestionSpeed_DaySelection, the day of the TomTom speeds. The day is in the name of the output folder and of the chain cache.
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 PartsOfDay, below. PartOfDay sets Impl/PT_DepartureHours, Impl/CongestionMinute and Impl/Car_CongestionMoment_ForDirect.
The departure moments of public transport and of the car, side by side (#125). PartsOfDay has a row per part of the day: DepartureHour, the hour of the departure moments (7, 12 or 19); CongestionMoment, the TomTom congestion moment of the car (MorningRush, NoonRush or LateEveningRush); CongestionMinute, the minute of that moment in the hour (30); and Car_MaxSpeed, the cap on the car speed at that moment (100, 100 and 0 km/h; 0 means no cap), on the TomTom and the OSM network. Free flow has no cap. PT_DepartureMinutes_All holds the minutes of the departure moments within the hour: 0, 15, 30 and 45. CongestionMinute must be one of them. Impl derives the departure moments of a run and the congestion times of the car (Impl/CongestionTimes) from these two tables. See Private transport.
The variant is the set of components that UpdateAll.cmd computes and merges (#133). It is set with switches, TRUE or FALSE:
-
PreTransport, a switch per pre-transport type, 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.
-
-
PostTransport, a switch per post-transport type, 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.
-
-
DirectWalking(WW),DirectCycling(CC) andDirectCar(Car): the whole trip on foot, by bicycle, or by car with start and parking time.
Every pre-transport type that is on, combined with every post-transport type that is on, is a public transport component <pre>_PT_<post>, such as W_PT_W or C_RM_PT_OVf_C. With the direct trips that are on, these are the components of the variant (Classifications/Components/Selected, listed in Impl/VariantComponents). Only the OV-fiets is rented; the other cycling post-transport types use the traveller's own bicycle at the last stop, at the costs of PostTransport_Cycling_Time_Costs.
The defaults are the question of PBL of October 2026: walking or cycling to any stop, walking or the OV-fiets after the last stop, and walking, cycling and the car. That is seven components: WW, CC, Car, W_PT_W, W_PT_OVf_C, C_PT_W and C_PT_OVf_C. Two more examples:
| Variant | On | Components |
|---|---|---|
W_PT of the 2023 delivery |
Org2Stops_Walking, Stops2Dest_Walking, DirectWalking
|
WW, W_PT_W
|
C_PT of the 2023 delivery |
Org2Stops_Cycling, Stops2Dest_Walking, OVF_Stops2Dest_Cycling, DirectCycling
|
CC, C_PT_W, C_PT_OVf_C
|
A pre-transport type without a post-transport type, or the other way round, gives no component; the checks of UpdateAll.cmd stop with a message then. See Components and merging.
How one run computes several components
The model computes one component per GeoDmsRun: Impl/ComponentName, which follows from ConfigSettings/Overridable/RunComponent. UpdateAll.cmd sets that per step in the environment variable GEODMS_Overridable_RunComponent, from the list of components in batch\log\components.txt. Everything the model computes for a component follows from Impl/ComponentName: the pre- and post-transport type, the direct trips that join the front, the output folder and its signature. The name of the component 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: 'W_PT_W'. Only for GeoDmsGui: the component that the GUI shows, a name from Classifications/Components/name, or 'Merged' for the merge of the variant. UpdateAll.cmd does not use it.
Default: TRUE. Does UpdateAll.cmd merge the components of the variant into one Pareto front (NetworkSetup/ComponentMerge), after their output? The merge is the last step, as the component Merged, when the variant has two components or more. Its output goes to <Analysis_date>_<OutputLabel>_Merged<MergeRunNr>.
Default: 1. The number of the merge in the name of its output folder, <Analysis_date>_<OutputLabel>_Merged<MergeRunNr>. A merge with another variant or other MergeCriteria under the same number replaces the earlier one, because UpdateAll.cmd empties the folder when its signature differs. To keep both, give the new merge another number.
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, a subset of the four Pareto attributes separated by commas. The components themselves choose on MinimiseCriteria. You can use any combination of Price (or Price_Augm), Time, Car (NeedsCar) and Bike (NeedsBike), with at least Price or Time; the checks of UpdateAll.cmd stop with a message at another name.
- 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: 'b2025'. The name of the variant in the output folder: 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.
The analysis date at the start of the folder name already gives the year. So do not put the year of the analysis in the label. The label gives what the folder name does not show yet:
- the zone set of
OrgsetandDestset:b2025for'Buurt2025',b2023for'Buurt2023'; - the part of the day, when it is not the morning rush:
_middagfor'Middag',_avondfor'Avond'; - if needed, your own variant at the end, for example
_ebike.
To compare years, keep the label, Orgset, Destset and PartOfDay the same, and change only AnalysisMoment. The folders then differ only in the date:
AnalysisMoment |
Output folder of W_PT_W
|
|---|---|
'Y2023' |
Output/20231010_b2025_W_PT_W |
'Y2024' |
Output/20241008_b2025_W_PT_W |
'Y2025' |
Output/20251014_b2025_W_PT_W |
'Y2026' |
Output/20261013_b2025_W_PT_W |
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. That is why the part of the day must be in the label: the morning and the afternoon under one label would replace each other.
Default: 'parquet'. The format of the output files: 'parquet' or 'csv'. The parquet files are compressed and typed: times in whole seconds as uint16 (int16 in the file), prices in euro as float32, distances in metres as uint32. The csv files have the times in minutes. The departure moment is in the name of the file. The merge 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 The csv files. The model computes and checks prices when this is TRUE, or when MinimiseCriteria has a price criterion.
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.
The neighbourhood sets (#126) compute from neighbourhood to neighbourhood. Each year under SourceData/RegioIndelingen/Divisions has its own neighbourhoods; Buurt2023 and Buurt2025 in Advanced/org_domain_list and Advanced/dest_domain_list point to the years 2023 and 2025. 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; -
Buurt2025: CBS 2025 and the BAG of 1 January 2025, 14,729 neighbourhoods.
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
A neighbourhood set keeps its own CBS year and BAG, whatever AnalysisMoment says, so a run can combine Buurt2025 with Y2023. Impl/BAG_snapshot and Impl/RegioIndelingen_year follow AnalysisMoment only. The first is the BAG of the sets that read the BAG directly (PC4, PC6 and the residential buildings); the second is the CBS year of the sets without a year of their own ('Buurt', the districts, municipalities, COROP regions and provinces), whose centres are weighted with the BAG of 1 January of that year. 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 CentroidWeightType and CyclingNetwork; 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 origin and destination sets (org_domain_list, dest_domain_list). The presets of the analysis moments and the parts of the day are in ModelParameters.dms (groups 7 and 8); the definitions of the components (PreTransportTypes, PostTransportTypes, PT_Components, DirectComponents, Components and DirectModes) are code lists in Classifications, with the settings per component below. 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, Components/BlocksPerPortion and MaxMemoryPerProcess_GB
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 PT_DepartureMinutes_All. The direct trips do not depend on the departure moment, except the time-dependent car trip (#132). The merge reads the one file of such a component for each departure moment.
Default: 50; 10 for the merge. The number of origin blocks per GeoDmsRun in the output step (batch\UpdateAll.cmd output, batch\WriteOutputBlocks.ps1). The table Classifications/Components has a value per component. For a public transport component the value comes from its pre-transport type (Classifications/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. The output of a public transport component does not grow that way: in the morning rush of 2025 the peak of C_PT_W came within the first 16 blocks of each of its portions of 25, and a portion of 28 blocks of W_PT_W peaked as high as one of 50. 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.
Default: 64. The memory in GB that one GeoDmsRun of the output step may use; set it somewhat below the physical memory of the machine. A component whose estimated peak per origin block is higher computes every block in parts of fewer origins (Impl/OrgBlockParts, #133). Each part computes its final set of a departure moment behind its own fence, so that GeoDMS frees the memory of its intermediate results before the next part, and the first part writes the union of all parts as the file of the block. The files and their names stay the same, and so do the rows of a file and the merge; only the order of the rows within a file differs, since they come part by part.
The estimate (Impl/OutputPeak_Estimate_GB) starts from the peak measured for the component on a machine with 128 GB, in the morning rush of 2025 with Buurt2025 to Buurt2025 and 33 origins per block (Advanced/OutputPeak_Measured). It scales the part above the fixed load of 21 GB (Advanced/OutputPeak_FixedLoad_GB: the network, the chain cache and the legs) with the origins per block and the number of destinations. A component without a measurement gets that of C_PT_ with the same post-transport, because the stops of another pre-transport are (nearly) a subset of those of C, cycling to every stop. The peaks are measured without the front before the post-transport (#140), so for the current model they are an upper bound. With the default of 64 GB, the national runs of 2025 compute these components in parts:
| Component | Measured peak | Parts |
|---|---|---|
C_PT_C |
209 GB | 5 |
C_RMT_PT_C, C_Ric_PT_C
|
209 GB, that of C_PT_C
|
5 |
C_PT_RMT_C |
98 GB | 2 |
C_RM_PT_RMT_C, C_RMT_PT_RMT_C, C_Ric_PT_RMT_C
|
98 GB, that of C_PT_RMT_C
|
2 |
The scaling is linear in the origins and destinations of a block, which the measurements of C_PT_C support but do not prove. A set of fewer destinations, such as one COROP area, needs no parts.
ChainParetoTimeEpsilon, PriceMethod, NS_TariffChoice and six more
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: 'Detailed'. 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, IFF_file_date) (#123)? It is part of the name of the chain cache as _iff<date>. See step 4 of Public transport.
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 time-dependent search, OSM speeds, manual connections 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: 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_DepartureHours, PT_DepartureMinutes, CongestionTimes), and the tags, folders and file names of the caches and the output.
GTFS_file_date, Analysis_date, FareTable_year and the types, hour 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 step 1 of From chains to journeys.
The post-transport type of the run: that of PostTransport.
The hour of the departure moments of the run: the DepartureHour of PartOfDay in PartsOfDay (7, 12 or 19).
The minutes of the departure moments within the hour: those of PT_DepartureMinutes_All (0, 15, 30 and 45). A component with Classifications/Components/SingleDepartureMoment has only the minute of the congestion moment. An OD pair with OD_DepartureTime has only that moment.
AllowDirectCar, Car_CongestionMoment_ForDirect, CongestionTimes and CarTimeDependent
Is the component of the run the car trip Car? It follows from the component (Classifications/Components/DirectCar) and is FALSE for every other component. In the merge, it is TRUE when Car is a component of the variant.
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 (PartsOfDay/CongestionMoment), at CongestionMinute in the hour of the departure moments (07:30, 12:30 or 19:30).
The congestion moments of PartsOfDay as the TomTom speeds and the speed cap of the car use them: the name, the clock time as hhmm and the cap.
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