How to run the model

This page walks through installing the components, configuring the parameters, and running the model end-to-end. If you only need to understand what the model does and how it works internally, see the Public transport and Private transport pages instead.

Contents

With GeoDMS, the NetworkModel_PBL project scripts, and the geographic source data, you can calculate travel time and price matrices for public transport, car (with and without congestion), cycling, e-bike, and walking. You can also inspect and adjust calculation rules, change parameters, and set up different origin and destination sets.

Installing components

GeoDMS software

We recommend using GeoDMS 17.9.2 or a later release. Earlier versions may not support all features used by the model.

For instructions on installing GeoDMS and loading a configuration, see the GeoDMS Academy.

Network model project scripts

Clone the repository with Git:

git clone https://github.com/ObjectVision/NetworkModel_PBL.git

Alternatively, use a Git client such as TortoiseGit, or download a ZIP from here.

Source data

The required geographic source data (GTFS feeds, OSM networks, TomTom road network, BAG, administrative boundaries including the concession areas) are managed in a separate SVN repository at PBL. Contact PBL to obtain access.

The fare data used by the model is part of the project repository itself: the detailed fare tables are inline in cfg/main/SourceData/OVprijzen.dms, and the DOVA overview and NS price tables are in data/. The underlying source documents (operator fare sheets, the DOVA delivery, the fare audit report) are kept in the source data under Infrastructuur/Tarieven.

After checking out the source data, verify that the %NetworkModel_Dir% path variable in your GeoDMS configuration points to the correct location.

Model parameters

All configurable settings are in ModelParameters (ModelParameters.dms). Most users will only need to change the top-level parameters. The Advanced sub-container contains technical parameters that rarely need adjustment.

General settings

Parameter Default Description
AnalysisMoment 'Y2023' Selects a preset year that automatically sets accompanying dataset versions (BAG, administrative boundaries). Choices are defined in Advanced/AnalysisMomentPresets.
Orgset 'Buurt' The origin set to use. Choices are defined in Advanced/org_domain_list.
Destset 'Buurt' The destination set to use. Choices are defined in Advanced/dest_domain_list.
CentroidWeightType 'Addresses' Whether to weight neighbourhood centroids by addresses or population.
Export_TravelledDistance TRUE Whether to include per-mode travel distances in the output.
Export_PriceInformation FALSE Whether to include price information in the public transport output. Prices are computed and checked whenever this is TRUE or MinimiseCriteria contains a price criterion.

For running a subset of origins (useful for testing), the Orgset_Enkele* parameters let you select a single neighbourhood, municipality, province, or COROP region, and the Destset_Enkele* parameters do the same for the destinations. Since 25 September 2026 the destination sets Buurt_enkele_Prov and Buurt_enkele_Corop use Destset_EnkeleProv_Selection and Destset_EnkeleCorop_Selection; before, they used the origin selection and those two parameters had no effect (audit 3.8). The chosen area is part of the origin and destination set in the file names (for example buurt_enkele_corop-kop_van_noord_holland), so two selections no longer share a car store or output file.

Public transport settings

Parameter Default Description
GTFS_file_date '20241001' Download date of the GTFS feed, used to locate the FSS files. Must match the folder name under %NetworkModel_Dir%/Infrastructuur/GTFS/. The year of this date also determines the fare year (see Advanced/FareTable_year).
Analysis_date '20241001' The calendar date for which the timetable is analysed. The feed must have a complete timetable on this day, and on the day before or after when the analysis window needs it; its weekday must match CongestionSpeed_DaySelection. These are checked when the network is built; see Create routable network from GTFS files.
MaxPTTime 90 min Maximum total public transport travel time, including waiting and transfers.
MaxTravelTime 90 min Maximum total journey time including pre- and post-transport legs.
MinimiseCriteria 'Price,Time' Which attributes to include in the Pareto optimisation. Options are 'Price', 'Price_Augm', 'Time', or combinations such as 'Price,Time'; since 25 September 2026 regardless of upper or lower case (before, 'Price_Augm' as written here silently fell back to 'Price', audit 3.7). This value also appears in the intermediate FSS filename, so changing it invalidates the cache.
Transfer_Walking_Time_Costs 0.19 €/min Monetary value assigned to walking time during transfers, used to prevent unrealistically long transfer walks when minimising price.
Transfer_Waiting_Time_Costs 0.05 €/min Monetary value assigned to waiting time at transfer stops.
Advanced/PriceMethod 'DOVA' Price method for regional (non-NS) transport: 'Detailed' (fare table per mode, operator, concession and line; 2023–2026) or 'DOVA' (concession-wide km fares from the DOVA overview; 2013–2026). Feeds before 2023 always use DOVA. See Public transport fares.
Advanced/FareTable_year derived Fare year, derived automatically from the year of GTFS_file_date so that the fare table always matches the agency names in the loaded feed. Do not set it by hand. The DOVA year, NS price year and concession area year are derived from it.
Advanced/NS_TariffChoice 'Price_FullFare' NS tariff class. Options: 'Price_FullFare', 'Price_20pct_Discount', 'Price_40pct_Discount'.
Advanced/Max_transfers 3 Maximum number of transfers allowed. Increasing this significantly increases computation time and memory use.
Advanced/MaxTransferDist 500 m Maximum crow-fly distance allowed for a transfer walk between stops.
Advanced/MaxWaitingTimeAtOrigin (Advanced) Maximum waiting time at the origin before departing.
Advanced/IncludeWaitingAtHomeInTravelTime FALSE Whether waiting time at the origin counts towards total travel time.
Advanced/MaxStopBlockSize 250 Number of origin stops per processing block. Together with NumberOfStopBlocks, this determines peak memory use.
Advanced/NumberOfStopBlocks 200 Number of blocks. Must satisfy MaxStopBlockSize * NumberOfStopBlocks > total number of stops.
Advanced/OV_PreTransport_Typen (Advanced) Which pre-transport connection types to include; see Pre- and post-transport connections on the Public transport page.
Advanced/OV_PostTransport_Typen (Advanced) Which post-transport connection types to include.
Advanced/PT_DepartureHours (Advanced) Hours at which departure moments are evaluated (e.g. 7, 8, 9).
Advanced/PT_DepartureMinutes (Advanced) Minutes within each hour at which departure moments are evaluated (e.g. 0, 15, 30, 45).

Car settings

Parameter Default Description
MaxCarTime 90 min Maximum car travel time.
UseTomTomNetworkForCars TRUE Whether to use the TomTom road network. If false, the OSM network is used instead.
AllowDirectCar TRUE Whether the direct car trip takes part in the Pareto front per origin-destination pair of the public transport analysis (since 23 September 2026), next to AllowDirectWalking and AllowDirectCycling.
Car_CongestionMoment_ForDirect 'MorningRush' Which car travel time the direct trip uses: 'MorningRush', 'NoonRush', 'LateEveningRush' or 'Freeflow' (TomTom); with the OSM network it must be 'MaxSpeed'.
Car_VariableCosts_PerKm, Car_FixedCosts_PerKm 0.20, 0.21 €/km Variable and fixed car costs per km, together the total cost of ownership of 0.41 €/km. The fixed part counts in the price only when Advanced/IncludeCarFixedCostsInPrice is TRUE.
Car_VariableCosts_RoadTypeFactor per road class Factor on the variable cost per TomTom road class; see Private transport.
Car_TurnCosts_PerPenaltyMinute, Car_TurnCosts_RoadTypeFactor 0.60 €/min, per road class Extra fuel for braking and accelerating at junctions, priced per minute of junction penalty and weighted per road class; Car_TurnCosts_UseTimeEquivalent selects per class the time-equivalent factor derived from Car_TypicalSpeed_kmh and the cost per km instead (default: other major roads and secondary roads); see Private transport.
Advanced/OSM_MaxSpeedQuantile 0.5 Quantile of the tagged speed limits per road type and country, used for OSM roads without a usable maxspeed tag; see Private transport.
Advanced/ExtraLink_MaxSnapDistance 250 m Maximum distance between an end point of a manual connection (ferries, missing links) and the road network; a connection with an end point further away is left out.
Advanced/CongestionTimes/MaxSpeed 100, 100, 0 km/h Cap on the car speed in the morning, noon and late-evening rush (0 = none), on the TomTom and the OSM network; free flow has no cap. See Private transport.
Car_FixedCosts_PerTrip 0 € Fixed amount per car trip, for example parking.
Car_StartTime, Car_ParkingTime 2, 3 min Time added to the direct car trip for getting to the car and for parking at the destination.
Advanced/ParetoLegs_Car, Advanced/CarLegCostQuantum TRUE, 0.01 € Whether the direct car trip is a (time, cost) Pareto front per pair instead of the fastest route only, and the per-link quantum of the cost criterion on engines before 20.21.0; see Private transport.
Advanced/CarFrontCostEpsilon, Advanced/CarFrontTimeEpsilon 0.10 €, 60 s Epsilon-dominance of the direct car front (GeoDMS 20.21.0 and later): the cost bucket in the search and, together with the time bucket, the thinning of the front after reading the store; see Private transport.
Advanced/ChainParetoPriceEpsilon, Advanced/ChainParetoTimeEpsilon 10 ct, 60 s Epsilon-dominance in the chain generation (GeoDMS 20.21.0 and later): in the chain joiner on the price criterion of the final front and the remaining times, at block level and in the condensations per departure moment on Price and TravelTime; 0 = exact; see Public transport.

Walking and cycling settings

Maximum travel times for each mode and connection direction are configured separately, for example MaxWalkingTime_Org2Stops, MaxCyclingTime_Org2RMT_Stops, and MaxWalkingTime_Stops2Dest. See ModelParameters.dms for the full list. Time-cost parameters (PreTransport_Walking_Time_Costs, PostTransport_Cycling_Time_Costs, etc.) attach a monetary value to travel time for each mode and connection direction, which matters when MinimiseCriteria includes price.

Parameter Default Description
AllowDirectWalking, AllowDirectCycling TRUE, TRUE Whether the direct walking and cycling trips take part in the Pareto front per origin-destination pair (since 23 September 2026, side by side with each other and with the car).
MaxWalkingTime_Org2Dest, MaxCyclingTime_Org2Dest 90, 90 min Maximum duration of a direct walking or cycling trip.
Advanced/Cycling_StartTime 1 min Added to every cycling trip and cycling leg.
Advanced/Cycling_PreTransport_Penalty, Advanced/Cycling_ParkingTime_IC_Station 0, 3 min Parking time at the end of a cycling pre-transport leg, and the extra parking time at an InterCity station.

Running the model: step by step

The model has several layers of pre-processing that must be completed in order. The GeoDMS GUI will refuse to compute downstream results if upstream pre-processing has not yet been run. After changing any parameter, reload the configuration with Alt+R before continuing.

Step 1: set and verify model parameters

Open ModelParameters_base.dms (or the local override file if one exists) and check all relevant parameters. At minimum, verify AnalysisMoment, Orgset, Destset, GTFS_file_date, and Analysis_date. If you change MinimiseCriteria, Max_transfers, MaxPTTime, or Analysis_date, the intermediate PT chains FSS cache will be invalidated and must be regenerated (step 3).

Reload the configuration after any change: Alt+R.

If prices are needed (a price criterion in MinimiseCriteria or Export_PriceInformation = TRUE), evaluate /ChecksBeforeRunning/PT_CheckPriceCoverage before starting the network build. This check takes seconds and verifies that the active fare table covers every (mode, agency) combination in the loaded GTFS feed and that all fares are filled and plausible. Fix any reported gaps first. Otherwise they only surface as a failing PT_CheckPrices after the network has been built. See Price checks.

Step 2: generate the GTFS store

If the GTFS store for the chosen GTFS_file_date does not yet exist, it must be generated from the raw CSV text files. Activate:

SourceData/Infrastructure/GTFS/LoadFeeds/Write

This converts the GTFS files (agency, calendar, calendar_dates, routes, shapes, stop_times, stops, trips) to an MMD store %NetworkModel_Dir%/Infrastructuur/GTFS/<GTFS_file_date>.mmd. This step only needs to be done once per GTFS feed date; batch\UpdateAll.cmd sources does it together with the other source stores.

Getting a feed. The model uses the national OVapi feed. The current one is gtfs.ovapi.nl/nl/gtfs-nl.zip; gtfs.ovapi.nl/nl/archive/ keeps a copy per day as NL-<yyyymmdd>.gtfs.zip, but only back to 1 January 2026. Older versions are in the Mobility Database (feed mdb-1077), at files.mobilitydatabase.org/mdb-1077/<id>/<id>.zip with <id> = mdb-1077-<yyyymmddhhmm>, the moment of download around midnight UTC; the feed page lists only the last ten, older ones are found through its API or by that name. Unpack the zip into %NetworkModel_Dir%/Infrastructuur/GTFS/<GTFS_file_date>/ with every .txt renamed to .csv. Recent OVapi feeds have no calendar.txt, because every service day is in calendar_dates.txt; the loader expects the file, so put a calendar.csv there with only its header line (copy it from another feed folder).

A feed is the planned timetable as known on the day it was published, including announced engineering works, but without delays or cancellations, which OVapi publishes only as a live GTFS-realtime stream. For comparable results, take the feed published on the analysis day itself (or the day before): a feed published weeks earlier misses the later changes, and one only covers a few weeks completely (see Create routable network from GTFS files).

GTFS_file_date Analysis_date source
20241001 20241001 (Tuesday) OVapi, as delivered with the model
20250930 20250930 (Tuesday) Mobility Database mdb-1077-202509300053
20260316 within three weeks after 16 March 2026 OVapi
20260925 20261006 (Tuesday), provisional OVapi NL-20260925.gtfs.zip; replace by NL-20261006.gtfs.zip once published

The OV nodes (OV_Knooppunten) are derived from the feed and the departures on Analysis_date, so since 25 September 2026 the name of the destination set in the car stores and the walking and cycling output carries that date (Advanced/DestSet_DateTag, for example ov_knooppunten_20241001); a run for another date writes its own car stores instead of reading those of the previous date.

Step 3: generate the PT chains intermediate result

The public transport chain generation is computationally the most demanding step. Its result is stored in an MMD store so that the per-departure-moment analysis (step 4) can read from it without repeating the full computation. The cache filename is automatically derived from the relevant parameters, including Analysis_date, MinimiseCriteria, Max_transfers, and MaxPTTime, so it is safe to keep multiple cached results for different parameter combinations.

To generate or regenerate the PT chains file, activate:

PublicTransport_Prep/x/Write_Result

This triggers the full chain generation pipeline: building OD_R and OD_L, computing all four transfer sets, running ChainGeneration_PerBlock for each block, unioning the results, and writing to the MMD store defined in PublicTransport_Prep/StorageName_Str. The location is:

%LocalDataProjDir%/IntermediateResults/PT_Chains_<time_window>_<analysis_date>[_gtfs<GTFS_file_date>]_min-<criteria>_maxtransf-<max_transfers>_MaxOV-<max_pt_time>min[_paretoR][_chaineps<price>ct<time>s]<chain store tag><revision>.mmd

_gtfs<GTFS_file_date> appears when the feed date differs from Analysis_date. Since 25 September 2026 the name ends with Advanced/ChainStore_ParamTag, the fare, transfer and stop settings the chains depend on, for example _dova_ov500-3750-19-5-0-35_h100-350: the fare method (dova or detailed, with -ns20 or -ns40 for an NS discount and -noprice when prices are not kept), then _ov followed by MaxTransferDist (m), TransferEffectiveSpeed (m per hour), Transfer_Walking_Time_Costs and Transfer_Waiting_Time_Costs (ct per minute), GradeSeparatedTransferPenalty and MaxTransferTimeForBoardingSurcharge (min), _h followed by DistanceStopClusters and DistanceTrainStationsSelection (m), and since 29 September 2026 _v followed by Advanced/PT_Max_V_Time (min), the longest pre-transport leg, which with the last departure moment and MaxWaitingTimeAtOrigin sets the last boarding time of a chain. Before, a change of one of these settings silently read the chains computed with the old value (audit 3.4). A store written before that date is read under the new name only after renaming it; the 07:00 store of 24 September was renamed after checking the settings recorded in its .xml. The revision Advanced/ChainStore_Revision (_r5 since 29 September 2026) is raised when a code change alters the chains; _r2 came with the service days of audit 3.5, which also renumber the stops the chains refer to, so a store without it cannot be reused; _r3 (25 September) and _r4 (26 September) with the criteria of the chain joiner, audit 6.1 to 6.3, and _r5 (29 September) with the last boarding time, see Public transport.

This step requires significant RAM. See the hardware requirements section below.

After Write_Result completes, reload the configuration (Alt+R) so that PublicTransport_Prep/PT reads from the newly written file.

Since 29 September 2026 the chains are stored per stop block (Advanced/ChainStore_PerBlock, default TRUE). Each block writes its own store, <store name>/<n>of<N>.mmd, in a folder with the name above without .mmd (PublicTransport_Prep/StorageBlockDir_Str), and PublicTransport_Prep/PT reads the block stores together. Until 30 September 2026 the folder ended in _blocks and the stores were called Block_<n>of<N>.mmd; the flex setting in the store name (see Public transport) made the longest path 265 characters, and every block failed only when it was written. Write them with batch\UpdateAll.cmd chains, which runs batch\WriteChainBlocks.ps1: it asks for the blocks without a store (PublicTransport_Prep/ChainStore_Blocks/ToDo_List, written to batch\log\chain_blocks_todo.txt; a block counts as done when its 0Dictionary.dms exists, which the MMD writer writes last; it first checks that the longest file path in the block stores stays within the 259 characters Windows allows, ChainStore_Blocks/PathLength) and computes them in portions of 20 blocks per GeoDmsRun (40 until 29 September 2026; a portion only shares the start-up of about 25 seconds, so its size hardly affects the run time). Most blocks take about 40 seconds and at most 85 GB, but about 2% of them need 150 to 200 GB of data at once and are paged to disk on a machine with 128 GB, which makes them take 3 to 7 minutes (measured on 6 October 2026, 29 September 2026). Three things follow from that: the results no longer stay in memory until the end, the memory of a portion is released before the next one starts, and a chain step that is interrupted or fails continues at the first block without a store when it is started again. Before, one Write_Result held all block results until it wrote them in one store, which took 112 to 186 GB at its peak and lost all work when a run was stopped. To write the single store as before, set ChainStore_PerBlock to FALSE and the environment variable CHAINSTORE_SINGLE before UpdateAll.cmd chains; the output of a date whose chains were written in one store (1 October 2024, 30 September 2025) reads that store only with ChainStore_PerBlock set to FALSE.

Step 3b: write the car stores

The direct car trip in the public transport analysis reads a store per congestion moment (see Private transport). Write them once per network edition or cost setting with batch\UpdateAll.cmd cars; the moment selected by Car_CongestionMoment_ForDirect must exist before step 4 runs. Steps 2 to 4 can all be run with batch\UpdateAll.cmd, see Updating all stores.

Step 4: generate output

Once the PT chains file exists and has been loaded via PublicTransport_Prep/PT, per-departure-moment results can be computed and exported. Activate the output generation container for the desired transport mode and origin block. For public transport:

NetworkSetup/PublicTransport/PerDepartureMoment/<moment>/CreateExports/Results_Traveltime

Or trigger the top-level output generation for all departure moments and all origin blocks at once via the relevant Generate_Output container. Output files are written as semicolon-delimited CSV files to %LocalDataProjDir%/Output/PerBlock/, with filenames that encode the analysis date, departure moment, origin and destination sets, transport configuration, and Pareto criteria.

Merging the output. Three items combine the per-block files of the public transport output:

Item Reads Writes
NetworkSetup/ConfigurationPerBlock/Merge_Output/MergeRegions/OUTPUT_Merge_PublicTransport_Regions_fullOD_long_CSVFiles the per-block files of each departure moment one file per departure moment, %LocalDataProjDir%/Output/tt_<Analysis_date>_<moment>_ORG-<origin set><tail>.csv, with the columns OrgName, DestName, Traveltime, ModeUsed, Price, WaitingTime, PretransTime, PTTime and PosttransTime
NetworkSetup/ConfigurationPerBlock/Merge_Output/MergeTimes/OUTPUT_Merge_PublicTransport_Times_fullOD_long_CSVFiles the files per departure moment %LocalDataProjDir%/Output/tt_<Analysis_date>_ORG-<origin set><tail>.csv, all departure moments below each other with a column for the moment
PostAnalysis/FindMedian/Result/MedianTT the file over all departure moments per origin and destination the fastest front row of each departure moment, and the median of those over the departure moments with a connection (NrMoments), for the pairs with a median up to FindMedian/SearchLimit (30 minutes); rows whose ModeUsed is in FindMedian/ExcludedModes (default AA, the direct car trip) do not count

<tail> is ModelParameters/Advanced/PT_OutputFileTail, the part of the name after the origin set (destination set, modes, transfers, criteria, MaxPT and the Pareto tags). Since 25 September 2026 the writer per block and these readers all build their names from it, the readers use the column names of the writer and read Price only when the file has that column, and they read and write through GDAL: one departure moment over the 450 origin blocks is 39 million rows. Before, the readers looked for _ORG-<Orgset>, _DEST-<Destset> and _MaxOV- and for the columns VoortransTime and NatransTime, the file over all moments was named tt__... and FindMedian matched the output against neighbourhoods, so none of the three steps worked on the output of current runs. Since 27 September 2026 FindMedian takes the fastest row per departure moment and leaves out the direct car trip (audit 6.7); before, it took the median over all front rows of all departure moments and modes together, up to SearchLimit, which mixed the slow cheap chains of the front and the car into one number. On the 07:00 file of 1 October 2024 that gave 581,022 pairs within 30 minutes, 466,533 of them only by car; without the car and with the fastest row it gives 114,489 pairs, at 21.0 minutes on average. The merged files are comma-delimited with quoted text. For departure moment 07:00 of 1 October 2024 the merge per moment took 35 minutes (15 GB peak, 3.2 GB of csv), the merge over the moments 30 minutes with that one moment, and FindMedian 7 minutes (581,022 origin-destination pairs). With four departure moments the file over all moments is about four times larger; that has not been measured.

For private transport (car, cycling, walking), the corresponding network setup containers can be activated independently of the PT pipeline.

Updating all stores with batch\UpdateAll.cmd

Since 23 September 2026 the stores of the model are refreshed with one script, batch\UpdateAll.cmd. It runs each step as a separate GeoDmsRun call, in the order in which the stores depend on each other, so that memory is released between the steps, and it stops at the first step that fails. The older scripts (RunAll.cmd, RunKetens*.cmd, RunPrepare.cmd, RunDayGroups.cmd, RunCongestionSpeeds.cmd) referred to item paths from before 2025 and were removed.

batch\UpdateAll.cmd                          all sections: sources, cars, chains, output
batch\UpdateAll.cmd all -nosources           all sections except the named ones: -nosources, -nocars, -nochains, -nooutput
batch\UpdateAll.cmd sources                  the source stores
batch\UpdateAll.cmd cars [moment ...]        the car stores, all four moments or only the named ones
batch\UpdateAll.cmd chains                   the public transport chain store
batch\UpdateAll.cmd output                   the csv output per origin block and departure moment
Section Items Rerun after Duration (Sept 2026, 88,126 origins, 462 nodes)
sources SourceData/Infrastructure/OSM/Make_Final_Network, the four TomTom stores (TomTom/Impl/Merge_Roads, Merge_Junctions, Merge_Speednetworks, Merge_Speedprofiles), GTFS/LoadFeeds/Write, the LISA store a new edition of OSM, TomTom, GTFS or LISA about 15 minutes
cars PublicTransport_Prep/Direct/CarPerMoment/<moment>/Write_Car for MorningRush, NoonRush, LateEveningRush and Freeflow (MaxSpeed on OSM) a change in car costs, speeds, origins, destinations, MaxCarTime or the car front settings 3 to 5 hours per moment, about 5.5 GB peak commit, 1 GB per store
chains the check ChecksBeforeRunning/PT_CheckBlocks with OVprijzen/PrijsDekking/Tabel_OK_DOVA (the step stops when the price coverage is not complete), then the stop blocks without a store, in portions (batch\WriteChainBlocks.ps1, since 29 September 2026; before PublicTransport_Prep/x/Write_Result) a new GTFS feed or Analysis_date, fares, MinimiseCriteria, Max_transfers, MaxPTTime, the departure moments or the chain epsilons 07:00 alone: 3 h 28 min, 37 GB peak, 11.5 GB store; with the four default moments 15 to 24 hours with revision _r4 (up to 186 GB committed, partly in the pagefile); revision _r5 (29 September 2026) is about 2.5 times as fast per block, see Public transport  
output NetworkSetup/ConfigurationPerBlock/Generate_Output/OUTPUT_Generate_PublicTransport_fullOD_long_CSVFiles any of the above 20 minutes per departure moment (29 GB peak, 3.5 GB of csv)

Store names. Each store name encodes the settings that determine its content (moment, network edition, day selection, MaxCarTime, origin and destination sets, the Pareto and cost tags for the car stores; the time window, date, criteria, transfers and Pareto tags for the chain store), so stores for different settings live side by side and a changed setting makes the model look for a new store. A change that is not in the name is not detected, such as a code change like the speed repairs of 25 September 2026. The feed date and the fare, transfer and stop settings of the chain store are in its name since 25 September 2026; the OSM network store carries a revision (OSM/StoreRevision, _r2 since 25 September 2026) that is raised when the network construction changes. After such a change, rename or remove the old store before rerunning, or the model silently reads it. The chain store is read only for the departure moments of PT_DepartureHours and PT_DepartureMinutes, because its time window is in its name.

Logs. Every step writes batch\log\UpdateAll_<step>.log (the GeoDMS log; GeoDmsRun appends to it, so a log can hold several runs) and batch\log\UpdateAll_<step>.txt (the console output). batch\ReportUpdateAll.py [step ...] summarises the last run of each step: start, end, duration, number of result rows, the peak CommitCharge and PeakLiveLarge from the memory summary at the end of the log, the size of the store and the error lines. batch\log is not in git.

Engine. UpdateAll.cmd names the GeoDmsRun.exe it uses in its EXE line. Since 23 September 2026 that is a local build of GeoDMS 20.21 (C:\dev\GeoDMS_2026\bin\Release\x64), because the car front and the chain generation use the epsilon dominance of GeoDMS #1282, which the installed 20.20 does not have; once a 20.21 setup is installed, the EXE line should point to it again. The environment variable GEODMS_EXE overrides the engine for one run. For runs of many hours a copy of the build folder (without the .pdb files) is safer than the build folder itself: a rebuild during the run would then neither fail on files in use nor replace DLLs under the running process.

Running UpdateAll as a scheduled task

A run of many hours should not depend on the window or session it was started from. batch\ScheduleUpdateAll.cmd therefore starts UpdateAll.cmd as a one-off Windows scheduled task, NM_PBL_UpdateAll, and returns immediately:

set GEODMS_EXE=C:\LocalData\GeoDMS_engine\20.21.0_c2f64650\GeoDmsRun.exe
batch\ScheduleUpdateAll.cmd cars Freeflow MorningRush
  • The task runs in a visible console window of the logged-in user (“interactive only”), so the progress is on screen and the run continues when the starting window is closed. It needs the user to stay logged on.
  • The task executes batch\UpdateAllTask.cmd, which writes start ..., engine ... and finally updateall exit=<code> to batch\log\UpdateAll_status.txt and then deletes the task itself. A GEODMS_EXE set before ScheduleUpdateAll.cmd is passed on to the task.
  • Only one such task exists at a time; ScheduleUpdateAll.cmd refuses to start a second one and warns when another GeoDmsRun is running.
  • Its trigger is a single start at 00:00 of the day it was created, which lies in the past, so the task never starts again by itself.
  • Windows stops a scheduled task after 72 hours.
  • To stop a run: close its console window, or schtasks /End /TN NM_PBL_UpdateAll followed by schtasks /Delete /TN NM_PBL_UpdateAll /F.
  • UpdateAll.cmd and UpdateAllTask.cmd must not be edited while a run is going: cmd reads a running batch file line by line from disk.

In September 2026 the same was done with ad hoc tasks named NM_PBL_All, NM_PBL_Chains, NM_PBL_Output, NM_PBL_Freeflow, NM_PBL_DirectWC, NM_PBL_CarSmall, NM_PBL_WriteResult and NM_PBL_Queue, with wrapper scripts outside the repository; they have been removed and are replaced by ScheduleUpdateAll.cmd.

Hardware requirements

  • Operating system: Windows 10 or later.
  • GeoDMS version: 17.9.2 or later.
  • RAM and pagefile: at least 400 GB combined when computing the public transport chains for a full national run (all of the Netherlands, Buurt as origin set). The chain generation is split into blocks (controlled by MaxStopBlockSize and NumberOfStopBlocks) specifically to limit peak memory use; reducing block size lowers peak RAM at the cost of longer computation time. Smaller origin sets (e.g. a single province or COROP region) require substantially less memory.
  • Disk space: at least 350 GB free for source data, FSS intermediate files, and output. The PT chains FSS file alone can be several tens of gigabytes depending on the parameter settings.
  • CPU: the block-based parallelisation in GeoDMS can make use of multiple cores. More cores reduce wall-clock time for the chain generation step.