Repository navigation
Model parameters
All settings of the model are in ModelParameters, in two files:
-
cfg/main/ModelParameters.dms: at the top the settings of a run, which are all that most users need. Below them is the containerModelParameters/Advanced, with the choices agreed with PBL, technical settings, and tables that PBL can extend. -
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.
The settings of a run are in eight groups at the top of cfg/main/ModelParameters.dms:
- What the run computes:
AnalysisMoment,AnalysisDay,PartOfDay,OrgsetandDestset(with theOrgset_Single*andDestset_Single*selections),OutputLabel,OutputFormat,Export_TravelledDistance,Export_PriceInformationandMinimiseCriteria. A call ofUpdateAll.cmdcan giveAnalysisMoment,PartOfDay,Orgset,DestsetandOutputLabelitself, with-set(Impl/Given). When the call gives none, the value inModelParameters.dmsapplies: the one at the end of the line, afterImpl/Given/<name> != '' ? Impl/Given/<name> :. - 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,MergeCriteria,MergeRunNrand the merge variants,MergeVariants. - Assumptions that only change the output:
MaxTravelTime,MaxWalkingTime_Org2Dest,MaxCyclingTime_Org2Dest, the time costs of walking,Cycling_CostPerKmand the time costs of cycling that follow from it,OVFiets_RentalPrice, and the costs, start time and parking time of the car. The caches stay valid. These settings are in the signature of the output of the components that use them, so output with another value gets a folder of its own (see Output folder and departure moments). - Assumptions that are in the signature of a cache. The name of the cache holds a hash of its signature, so after a change the model makes that cache again. These are the walking and cycling speeds and the maximum times of the four base sets,
MaxWalkingTime_Org2Stops,MaxWalkingTime_Stops2Dest,MaxCyclingTime_Org2StopsandMaxCyclingTime_Stops2Dest(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). The group also holds the maximum times of the other pre- and post-transport types, such asMaxCyclingTime_Org2RM_Stops. These are not in the signature of the pre- and post-transport caches: they apply when the model reads the legs of the base set, and they are in the signature of the output. - One OD pair:
OD_Origin,OD_Destination,OD_DepartureTime,OD_OptionandOD_CompareLabel, the label of the run of the whole model that the options of the pair are compared with; 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,BAG_file_date,NDW_yearandOVFiets_Locations). - The departure moments:
PartsOfDayandPT_DepartureMinutes_All.
Two exceptions
Car_StartTime is in group 4, but it is also in the signature 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. The largest maximum time over the pre-transport types of the variant sets the longest pre-transport leg of the chains (Impl/PT_Chains_Max_V_Time). That leg sets 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 date, the GTFS feed, the editions of OSM, TomTom, the CBS area division and the OV-fiets locations, and the date of the BAG (BAG_date). The analysis date 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 date and a GTFS feed, which Y2015 and Y2023 to Y2026 have. See The GTFS feed.
Default: ''. An analysis date other than that of AnalysisMoment, as yyyymmdd, for example '20251015'. Empty means the analysis date of the preset. The GTFS feed of AnalysisMoment must hold the service days that the part of the day needs on that date. The checks of UpdateAll.cmd say so when the feed does not (see What a run does). With a direct car trip, the date must also fall on CongestionSpeed_DaySelection, the day of the TomTom speeds. The date is in the name of the output folder and of the chain cache.
Default: 'Morning'. The part of the day of the departure moments: 'Morning' (07:00, 07:15, 07:30 and 07:45), 'Afternoon' (12:00 to 12:45) or 'Evening' (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 is the hour of the departure moments (7, 12 or 19). The name of a row (Morning, Afternoon or Evening) is also the name of the TomTom congestion moment of the car, and CongestionMinute is the minute of that moment in the hour (30). Car_MaxSpeed is 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. NS_OffPeak says whether the departure moments fall in the off-peak hours of NS (all but the morning rush hour). It decides whether Advanced/NS_TariffChoice applies (see below). PT_DepartureMinutes_All holds the minutes of the departure moments within the hour: 0, 15, 30 and 45. CongestionMinute must fall on a time slot of 5 minutes of the TomTom speed profiles (0, 5, ..., 55). Between two slots no profile is found, and every road would get its travel time without profile (#137). 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; -
Org2R_Stops_Cycling(Cr): cycling to a train station, of any rail operator; -
Org2RM_Stops_Cycling(Crm): cycling to a rail or metro stop; -
Org2RMT_Stops_Cycling(Crmt): cycling to a rail, metro or tram stop.
-
-
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; -
R_Stops2Dest_Cycling(rC): cycling from a train station, the stations ofCr; -
RM_Stops2Dest_Cycling(rmC): cycling from a rail or metro stop; -
RMT_Stops2Dest_Cycling(rmtC): cycling from a rail, metro or tram stop; -
OVF_Stops2Dest_Cycling(ovfC): 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 Crm_PT_ovfC. With the direct trips that are on, these are the components of the variant (Classifications/Components/Selected, listed in Impl/VariantComponents). A merge variant of MergeVariants names its components itself, and the switches then do not count. 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.
In ModelParameters.dms the switches Org2Stops_Walking, Org2Stops_Cycling, Org2R_Stops_Cycling, Org2RM_Stops_Cycling, Stops2Dest_Walking, Stops2Dest_Cycling, OVF_Stops2Dest_Cycling, DirectWalking, DirectCycling and DirectCar are on: walking or cycling to any stop, cycling to a train station or to a rail or metro stop, walking, cycling or the OV-fiets after the last stop, and the three direct trips. Their 15 components are WW, CC, Car, W_PT_W, W_PT_C, W_PT_ovfC, C_PT_W, C_PT_C, C_PT_ovfC, Crm_PT_W, Crm_PT_C, Crm_PT_ovfC, Cr_PT_W, Cr_PT_C and Cr_PT_ovfC. The checks of UpdateAll.cmd list the components of the variant before a run (ChecksBeforeRunning/Check_Variant). 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_ovfC
|
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. It also runs when the variant has one component, so that every variant has its final table, with the same columns, in <Analysis_date>_<PartOfDay>_<OutputLabel>_Merged<MergeRunNr>_<hash>.
Default: 1. The number of the merge in the name of its output folder, <Analysis_date>_<PartOfDay>_<OutputLabel>_Merged<MergeRunNr>_<hash>. The hash of the signature of the merge already gives a merge with other components or other MergeCriteria a folder of its own, so the number only labels the merge. With a merge variant the number is that of its row in MergeVariants.
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 hash of the signature of each component).
Default: 'Price,Time', or with a merge variant the criteria of its row in MergeVariants. 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. At any other name, the checks of UpdateAll.cmd stop with a message.
- 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 date 14 October 2025), departure moment 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 OD 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.
The merge variants: per row a name, the components of the merge (Components, names from Classifications/Components separated by commas), its MergeCriteria and its MergeRunNr. UpdateAll.cmd -variant <name> makes the merge of that row. It takes the components of the row instead of the switches of the variant, and the criteria and number of the row instead of MergeCriteria and MergeRunNr (Impl/HasVariant, Impl/Variant_rel). -variant all makes the merges of every row, one after the other. The rows, how to add one, and the checks are on Merge variants and settings per call.
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. The public transport nodes ('OV_Knooppunten') are derived from the GTFS feed and the departures on Analysis_date. As destinations, they therefore carry that date in the names and signatures of the caches (Impl/DestSet_DateTag, for example ov_knooppunten_20251014_gtfs20250930). So a run for another date writes its own car caches instead of reading those of another date.
Default: 'b2025'. The name of the variant in the output folder: 1 to 20 characters, without spaces, /, : or ., which the IntegrityCheck of OutputLabel tests. Keep to letters, digits, - and _, as the labels below do. The checks of the settings read the label (ChecksBeforeRunning/Check_OutputLabel), so a label that breaks these rules stops the first step of UpdateAll.cmd. The output goes to %LocalDataProjDir%/Output/<Analysis_date>_<PartOfDay>_<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 after it. At the end comes the hash of the signature of the output, for example _02407d15. WW and CC carry only the origin set, in place of the part of the day and OutputLabel (Impl/OrgSet_PathTag, for example 20251014_b2025_WW_<hash>). Their output does not depend on the part of the day, so the runs of every part of the day and every label share it. See Where the results are.
The analysis date at the start of the folder name already gives the year, and the part of the day follows it. So do not put the year or the part of the day in the label. The label gives what the folder name does not show yet:
- the origin set (
Orgset, andDestsetwhen it is the same set):b2025for'Buurt2025',b2023for'Buurt2023'; - if needed, your own variant at the end. A setting that is in the signature of the output needs no label of its own. With the same label, an e-bike gets folders of its own for the components with cycling, and reuses the output of the other components.
To compare years, keep the label, Orgset, Destset and PartOfDay the same, and change only AnalysisMoment. The readable part of the folder names then differs only in the date; the hash differs too, because the date is in the signature:
AnalysisMoment |
Output folder of W_PT_W
|
|---|---|
'Y2023' |
Output/20231010_Morning_b2025_W_PT_W_<hash> |
'Y2024' |
Output/20241008_Morning_b2025_W_PT_W_<hash> |
'Y2025' |
Output/20251014_Morning_b2025_W_PT_W_<hash> |
'Y2026' |
Output/20261013_Morning_b2025_W_PT_W_<hash> |
Other settings under the same label give a folder of their own, because the hash of the signature is in the folder name. Switching back finds the earlier output again. A label of its own still makes a variant easy to recognise in the folder name; that is why the part of the day goes in the label. To see which settings a folder holds, read its signature.txt. The model does not remove output that is no longer needed; delete its folder by hand.
Default: 'parquet'. The format of the output files: 'parquet' or 'csv'. The parquet files are compressed and typed. Prices are in euro as float32 and distances in metres as uint32. The times of a component are in whole seconds as uint16 (int16 in the file), and those of the merge in minutes as float32. 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 cannot be derived from its other columns (Impl/ExportClass):
-
WWandCC:TraveltimeandTravelDist_V; -
Car:TraveltimeandTravelDist_Car; - a public transport component:
Traveltime,Price,Price_Augm,ModeUsed,WaitingTime,PretransTime,PosttransTime,TravelDist_Bus,_Metro,_Tram,_Railand_Ferry, and the distance and price of the pre- and post-transport leg (TravelDist_V,TravelDist_N,PretransPrice,PosttransPrice), and the walking and waiting at transfers (TransferWalkTime,PTWaitTime).
PTTime is Traveltime minus the pre- and post-transport time, InVehicleTime is PTTime minus TransferWalkTime and PTWaitTime, and PTPrice is Price minus the price of the pre- and post-transport leg. The merge writes them, and the split per mode; see The parquet files. 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 of the pre-transport leg, of the public transport per mode and in total, and of the post-transport leg, and the distances 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 in the signature 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 signature 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.
With the neighbourhood sets (#126), the model computes 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 mean of its dwelling addresses when that point lies in the neighbourhood. Otherwise, and for a neighbourhood without dwellings, it is the centroid of its area, or a point in the middle of the area when the centroid falls outside it (centroid_or_mid).
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_date and Impl/RegioIndelingen_year follow AnalysisMoment only. Impl/BAG_date is the date of the BAG for the sets that read the BAG directly (PC4, PC6 and the residential buildings). Impl/RegioIndelingen_year is the CBS year of the sets without a year of their own ('Buurt', the districts, municipalities, COROP regions and provinces). Their 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.
Every BAG the model uses comes from one delivery, BAG_file_date (group 7). BAG-Tools converts it into files with all voorkomens of the verblijfsobjecten (vbo's), panden and nummeraanduidingen (#142). From these files, SourceData/BAG_T makes the BAG on a date: for Impl/BAG_date, for 1 January of each CBS year and for the years of the UAI. Per object it takes the voorkomen that is valid on the date: begun on or before it and not ended on or before it. Of more than one such voorkomen, it takes the one with the highest voorkomenidentificatie, the rule of MakeSnapshot in BAG-Tools. So every year is made in the same way from the same delivery, and any date can be used.
The model then selects the stock itself. It keeps the vbo's and panden in use, in use but not measured, out of use, or in renovation, and of the panden only those whose polygon is smaller than 1 km in both directions. A dwelling is a vbo in the stock with a residential function. A vbo in more than one pand counts once, in the first pand in the order of the BAG. PC4 and PC6 are the postcode of the main address of the dwelling, valid on the same date.
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, with b for buurt (Impl/OrgSet_PathTag and DestSet_PathTag, for example b_enkele_corop-kop_van_noord_holland), and of the signature of the output. So two selections do not share a cache or an output folder.
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. In the OD pair mode it is at most 3, because OD_Chains follows a chain of at most four rides back to its parts; ChecksBeforeRunning/Check_MaxTransfers stops a run of an OD pair with 4.
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 The TomTom caches.
Default: 'tuesday'. The day of the TomTom speeds of the car. A day of the week, 'monday' to 'sunday', has a speed profile over the day; 'Weekday', 'Weekend' and 'Week' have an average speed, the same at every moment. The analysis date must fall on this day, or for 'Weekday', 'Weekend' and 'Week' on a day of that kind. The time-dependent car trip (Impl/CarTimeDependent, the default with TomTom) follows the trip through the profile of the day, so it needs a day of the week. ChecksBeforeRunning/Check_CarDay tests both before a run with the car (#154). The day is in the signature of the TomTom car caches. See Speeds on the Private transport page.
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 speeds and the maximum times of the four base sets (
MaxWalkingTime_Org2Stops,MaxWalkingTime_Stops2Dest,MaxCyclingTime_Org2StopsandMaxCyclingTime_Stops2Dest) are in the signature of the pre- and post-transport caches. After a change,batch\UpdateAll.cmdmakes the missing caches before the output, orbatch\UpdateAll.cmd legsmakes only those. - The maximum time of another type, such as
MaxCyclingTime_Org2RM_Stops, applies when the model reads the legs of its base set, and it may not exceed the maximum time of the base set. It is in the signature of the output, not in that of the pre- and post-transport caches. - 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 in the signature of the pre- and post-transport caches, and in that of the output of every component with a walking or cycling leg or trip.
Default: 0.09 € per km. The cost of cycling on an own bicycle. The time costs of cycling (Direct_Cycling_Time_Costs, PreTransport_Cycling_Time_Costs and PostTransport_Cycling_Time_Costs) are this amount per minute at CyclingSpeed_kmhr.
An e-bike is not a mode of its own but a run with other cycling values: CyclingSpeed_kmhr 20 km/h instead of 14, and a Cycling_CostPerKm that you choose. The model has no cost of its own for an e-bike. The junction penalties of cycling apply to an e-bike too. In ModelParameters.dms the comment next to CyclingSpeed_kmhr gives the value for the ordinary bicycle and for the e-bike, and the comment next to Cycling_CostPerKm gives the value for the ordinary bicycle, 0.09 € per km. Going back means putting the values of the ordinary bicycle back.
The cycling speed is in the signature of the cycling legs, and in that of the output of every component with a cycling leg or trip. The time costs of cycling are in the signature of the output of the public transport components with cycling. For CC they are in the signature of the merge, which computes its price (with csv also in that of CC). With the same OutputLabel, a run with e-bike values therefore writes CC and the public transport components with cycling to output folders of their own, with another hash, next to those of the ordinary bicycle. The output of WW, Car and the components that only walk keeps its name and is used again, and so does the chain cache. W_PT_ovfC also keeps its output when only the cost per km changes, because the OV-fiets costs its rental price. A merge reads the folders that fit its own settings. So merges with and without the e-bike can be made one after the other without calculating anything again.
Default: the NS tariff of the fare year (Impl/FareTable_year, the year of the GTFS feed) in the table OVFiets_Tariffs. It is the rental price of the OV-fiets (ovfC) for the first 24 hours. A fare year takes the tariff of the latest year in the table up to it, and an earlier fare year the first one. The rent is paid, so it always counts in Price, also with Advanced/IncludeCyclingCostsInPrice off (#108).
Year in OVFiets_Tariffs
|
Rent for the first 24 hours |
|---|---|
| 2016, also for Y2015 | 3.35 € |
| 2023 | 4.45 € |
| 2024 | 4.55 € |
| 2025 | 4.65 € |
| 2026 | 4.80 € |
Default: 1 min. Added to each cycling trip and each cycling leg.
Default: 3 min. The extra parking time when a cycling leg to the first stop ends at an intercity station (a stop in PublicTransport_Prep/Impl/Ric_Stops), on top of Advanced/Cycling_PreTransport_Penalty. It holds for every type of cycling pre-transport. Like Cycling_StartTime, it is in the signature of the chain cache, because it lengthens the longest pre-transport leg (see the two exceptions under The settings of a run).
The container Advanced, below the settings of a run in cfg/main/ModelParameters.dms, holds three kinds of settings: the choices agreed with PBL, such as 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
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 the settings of a run (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 also holds the maximum walking times of the pre- and post-transport types that no component uses (MaxWalkingTime_Org2RMT_Stops, _Org2RM_Stops, _Org2Ric_Stops, _Org2R_Stops, _Org2RML_Stops, _OVF_Stops2Dest, _RMT_Stops2Dest and _RM_Stops2Dest). They are equal to MaxWalkingTime_Org2Stops or MaxWalkingTime_Stops2Dest.
The centres of the neighbourhoods and the other region sets are weighted by the residential addresses of the BAG.
Components/SingleDepartureMoment, Components/BlocksPerPortion and MaxMemoryPerProcess_GB
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). WW and CC do not depend on the part of the day either (Classifications/Components/TimeInvariant). Their file per origin block, tt_alle_<n>of<N>, holds for every departure moment of every part of the day, in an output folder that carries the origin set instead of OutputLabel. Car without CarTimeDependent names its file after the congestion moment, such as tt_07h30m_<n>of<N>. The merge reads the one file of such a component for each departure moment.
Default: 50; 10 for the merge (Advanced/MergeBlocksPerPortion). The number of origin blocks per GeoDmsRun in the output step of batch\UpdateAll.cmd (batch\WriteOutputBlocks.ps1). The table Classifications/Components has a value per component. A direct trip takes it from Classifications/DirectComponents/BlocksPerPortion, and a public transport component 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: it reads the network, the chain cache and the legs before its first block, which takes minutes. GeoDMS frees the memory only between portions. A smaller portion therefore keeps the peak lower only when the memory grows from block to block. The merge grows that way, which is why it uses 10. The output of a public transport component does not, so a smaller portion would add start-up time without lowering its peak. For one run, the environment variable OUTPUT_BATCHSIZE replaces the value (set OUTPUT_BATCHSIZE=20 before UpdateAll.cmd). 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. GeoDMS then frees the memory of its intermediate results before the next part. The first part writes the union of all parts as the file of the block. The files and their names are the same as without parts, and so are 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. A component with rC, for which C_PT_rC has no measurement either, gets that of C_PT_C, cycling to and from every stop. The peaks are those of whole portions of the output step; the Source of OutputPeak_Measured names the runs. Those of W_PT_W, W_PT_C, W_PT_ovfC, C_PT_W, C_PT_C and C_PT_ovfC come from runs with the front before the post-transport (#140). Those of the other public transport components, such as C_PT_rmtC and C_PT_rmC, come from runs without that front, so for the current model they are an upper bound (#141). C_PT_C (39.5 GB) computes in one part, like Crmt_PT_C, Cr_PT_C and the components with rC, which take its peak. With the default of 64 GB, the national runs of 2025 compute these components in parts:
| Component | Measured peak | Parts |
|---|---|---|
C_PT_rmtC |
98 GB | 2 |
Crm_PT_rmtC, Crmt_PT_rmtC, Cr_PT_rmtC
|
98 GB, that of C_PT_rmtC
|
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 seven 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 the travel time is a criterion there. That is the case with a time penalty: Advanced/GradeSeparatedTransferPenalty above 0, extra waiting time on flex rides (Advanced/FlexExtraWaitingTime, on by default), or extra time on a ride with a trip surcharge. 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: 10 €, 50 € and 0.60 €/km. The highest boarding fare or fixed fare of a row of the fare table, plus its surcharge per ride, the same for a ferry, and the highest price per km, that the check of the fare tables takes as plausible. A row with a higher price gives a WARN, which does not stop the run, because some fares are that high, such as the ferry to Terschelling. See Price checks.
Default: 'Price_FullFare', the standard NS fare for a traveller without a discount subscription (#169). The NS fare in a part of the day that falls in the off-peak hours of NS: 'Price_FullFare', 'Price_20pct_Discount' or 'Price_40pct_Discount'. The last is the NS price for a traveller with Dal Voordeel. In a part of the day in the NS peak hours, where PartsOfDay/NS_OffPeak is FALSE (the morning rush hour), the model always uses the full fare (Impl/NS_FareClass, #119). The full fare is also in the signature of the chain cache, so every run in the morning rush hour reads the chain cache with the full fare. A call of UpdateAll.cmd can give another value with -set NS_TariffChoice <value> (see Merge variants and settings per call).
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 in the signature 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. For an OD pair it also decides the number of blocks.
Default: 500. The number of stop blocks of the whole model. MaxStopBlockSize times NumberOfStopBlocks must be larger than the number of stops (ChecksBeforeRunning/PT_CheckBlocks). This setting does not apply to an OD pair: a pair uses as many blocks as the stops its origin reaches need, with at most MaxStopBlockSize stops per block (PublicTransport_Prep/impl/NrStopBlocks, see Routes of an OD pair).
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. It is in the signature of the OSM network cache, as are CarDefaultSpeed, CarDefaultSpeed_low, Ferry_Speed and ExtraLink_MaxSnapDistance, so a change gives a new cache (see OSM network cache).
Default: 250 m. The largest distance between an end of a manual connection (a ferry or a missing link) and the road network. A manual 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; 150 km/h. 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: the distance at CarFrontMaxSpeed in MaxCarTime, wide enough to cut nothing, while MaxCarTime limits the travel time. See Private transport.
Cycling_PreTransport_Penalty and CyclingNetwork
Default: 0 min. The parking time at the end of every cycling leg to the first stop, for every type of cycling pre-transport. When the leg ends at an intercity station, Cycling_ParkingTime_IC_Station comes on top of it.
Default: 'OSM'. The network of all cycling legs and of the direct 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. With the Fietsersbond, ferries up to Advanced/Fietsersbond_MaxFerryLength (2 km) take part, with Advanced/Fietsersbond_FerryExtraTime (5 min) extra. The signature of the output of a component that cycles then has _fb<date>-veer<m>m<min>min<revision> (Impl/CyclingNetwork_FileTag, _fb20250525-veer2000m5min_r2), and its 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_date), 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: AnalysisDay when it is set, otherwise the analysis 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. The model checks this when it builds the network; see Create routable network from GTFS files. With the car in the variant, its weekday must also match CongestionSpeed_DaySelection, which ChecksBeforeRunning/Check_CarDay tests before the run.
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 component of the run (Impl/Component_PreTransport, from Classifications/Components/PreTransport), not the switches of PreTransport, which choose the components of the variant. A direct trip and the merge have no pre-transport and get walking, so that the selection is not empty. See step 1 of From chains to journeys.
The post-transport type of the component of the run (Impl/Component_PostTransport), in the same way; not the switches 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. With TomTom it is the congestion moment with the name of PartOfDay: 'Morning', 'Afternoon' or 'Evening', at CongestionMinute in the hour of the departure moments (07:30, 12:30 or 19:30). With the OSM network it is 'MaxSpeed'. With CarTimeDependent it is the reference moment of the time-dependent caches, and it gives their speed cap.
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 Congestion moments and Time-dependent link times on the Private transport page. It needs TomTom, a day of the week as CongestionSpeed_DaySelection (not 'Weekday', 'Weekend' or 'Week'), and for Advanced/CarTD_Search 'pareto_alt' an engine with timedependent_alt.
NetworkModel PBL documentation