Running the model step by step

The model has several layers of pre-processing that must be completed in order: the source caches (the OSM network and the GTFS feed), the pre- and post-transport caches, the chain cache and the car caches, and then the output. All caches are in %LocalDataProjDir%; the model only reads the folders of the source data. In GeoDmsGui these steps are under MakeUnlinkedData, in order: Step1_Sources, Step2_PrePostTransport, Step3_PT_Chains and Step4_DirectCar. A cache is read only when its signature matches the current settings (see Cache names), so the GeoDMS GUI refuses to compute downstream results when the chain cache or a car cache is missing; a missing pre- and post-transport cache is computed in the run instead (see step 3). After changing any parameter, reload the configuration with Alt+R before continuing. Outside the GUI, batch\UpdateAll.cmd runs the same steps; see Updating all caches with batch\UpdateAll.cmd.

Step 2 is needed once per edition of the source data; which of steps 3 to 6 a run needs depends on its component:

Component Steps
WW, CC 6
Car 5 and 6
a public transport component (<pre>_PT_<post>) 3, 4 and 6
MergeOutput 6, after the output of the merged components

Step 1: set and verify model parameters

Open cfg/main/ModelParameters.dms and check the parameters of the run, at least AnalysisMoment, PartOfDay, Orgset, Destset, Component (with PreTransport and PostTransport) and OutputLabel. Impl/GTFS_file_date and Impl/Analysis_date follow from AnalysisMoment.

The assumptions in group 5 at the top of ModelParameters are in the signatures of the caches: a change makes the model compute the pre- and post-transport caches, the chain cache or the car caches again (steps 3 to 5). The chain cache also depends on AnalysisMoment, PartOfDay and Advanced/MinimiseCriteria. The assumptions in group 4 only change the output (step 6). See Model parameters.

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 source caches

The source caches are made once per edition of the source data: in GeoDmsGui under MakeUnlinkedData/Step1_Sources, or in batch with batch\UpdateAll.cmd sources, which makes both (see the sources section).

The OSM network

The OSM network cache, %LocalDataProjDir%/OSM/Final_Network_<OSM_file_date><revision>.mmd, is made from the Geofabrik extract in %NetworkModel_Dir%/Infrastructuur/OSM/<OSM_file_date>: update OSM_Network (SourceData/Infrastructure/OSM/Make_Final_Network). The extract date comes from the preset of AnalysisMoment. Walking always uses this network, cycling with Advanced/CyclingNetwork 'OSM' (the default), and the car with UseTomTomNetworkForCars FALSE. For 2025 it takes 2 to 5 minutes and 3.1 GB.

The GTFS feed

The GTFS cache holds the feed of GTFS_file_date as an MMD cache, %LocalDataProjDir%/GTFS/<GTFS_file_date>.mmd, made from the text files of the feed in %NetworkModel_Dir%/Infrastructuur/GTFS/<GTFS_file_date>/ (agency, calendar, calendar_dates, routes, shapes, stop_times, stops, trips). It is made once per feed:

  1. Get the 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, 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.
  2. Unpack the zip into %NetworkModel_Dir%/Infrastructuur/GTFS/<GTFS_file_date>/ and rename every .txt 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).
  3. Generate the cache: in GeoDmsGui, update MakeUnlinkedData/Step1_Sources/GTFS_Feed (or SourceData/Infrastructure/GTFS/LoadFeeds/Write_All); in batch, run batch\UpdateAll.cmd sources, which also makes the other source caches.
  4. Reload the configuration (Alt+R).

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 a feed only covers a few weeks completely (see Create routable network from GTFS files).

Each reference date has its own feed and analysis day in the preset of AnalysisMoment (#125). Coverage is the share of the trips of the busiest day with the same weekday in the feed, for D-1, D and D+1 (LoadFeeds/ServiceDays, minimum Advanced/MinServiceDayTripShare 0.95):

AnalysisMoment Analysis_date GTFS_file_date coverage D-1, D, D+1 source
Y2015 20151013 none   no feed; Y2015 does not run
Y2023 20231010 20231003 100%, 100%, 100% in the source data
Y2024 20241008 20241001 100%, 100%, 100% OVapi, as delivered with the model
Y2025 20251014 20250930 97%, 97%, 97% Mobility Database mdb-1077-202509300053
Y2026 20261013 20260925 98%, 98%, 98%, provisional OVapi NL-20260925.gtfs.zip; the feed of the analysis day, NL-20261013.gtfs.zip (or the day before), is to replace it

The OV nodes (OV_Knooppunten) are derived from the feed and the departures on Analysis_date, so as a destination set they carry that date in the names and signatures of the caches (Impl/DestSet_DateTag, for example ov_knooppunten_20251014_gtfs20250930). A run for another date therefore writes its own car caches instead of reading those of another date.

Step 3: generate the pre- and post-transport caches

The walking and cycling legs of pre- and post-transport are stored once per reference date, origin set and destination set, as a cache per base set; the output step of every public transport component reads them. With Advanced/PrePostTransportDecoupled (TRUE) a run reads the cache of a base set when it has the signature of the current settings, and otherwise computes that base set itself. batch\UpdateAll.cmd output writes the missing caches before its portions, so that each portion, a GeoDmsRun of its own, reads them instead of computing them again. How they are computed is on Walking and cycling legs.

  1. In GeoDmsGui, open MakeUnlinkedData/Step2_PrePostTransport in the tree, right-click Generate_All and choose Update TreeItem (see TreeView). It writes all base sets without a cache. To write one base set, update Org2Stops_Walking, Org2Stops_Cycling or Stops2Dest_Cycling instead.
  2. Or, in batch, run batch\UpdateAll.cmd legs; batch\UpdateAll.cmd output does the same before its portions.
  3. The result is a parquet file per base set in %LocalDataProjDir%/IntermediateResults, such as Legs_B2025toStops_Walking_<hash>.parquet, with its signature in <name>.signature.txt. For Buurt2025 to Buurt2025 a cache takes a few minutes and less than 10 GB.
  4. Reload the configuration (Alt+R), so that the items that read the legs are computed again.

When the cache of a base set with the signature of the current settings is missing, the run computes that base set itself: NetworkSetup/PublicTransport_Prep/PrePostTransport/<base set>/Connections is then Calc instead of Read. That takes a few minutes per base set, in every process that needs it. The pre- and post-transport caches have to be made again after a change in the walking or cycling network or speed, a maximum pre- or post-transport time, the origins, the destinations, or the feed and reference date.

Step 4: generate the chain cache

The public transport chains are the most demanding step. The result is the chain cache, one MMD cache per stop block, which the output step reads; see Chain generation.

  1. Check the blocks and the fares. In GeoDmsGui, under MakeUnlinkedData/Step3_PT_Chains, view Check_Blocks (do all stops fit in the stop blocks?) and Check_PriceCoverage (does the fare table cover every mode and operator of the feed?). Both should say PASS.
  2. Generate the cache, in one of two ways:
    • batch\UpdateAll.cmd chains computes the blocks without a cache in portions of 20 blocks, each portion in its own GeoDmsRun, so that memory is released between the portions. Use this for a complete cache.
    • In GeoDmsGui, Generate_ToDo computes all blocks without a cache in one request, and PerBlock/<block>/Write one block.
  3. Follow the progress: BlocksWritten shows how many blocks have a cache, for example 500 of 500 stop blocks have a cache. An interrupted chain step resumes at the first block without a cache.
  4. Reload the configuration (Alt+R).

For the morning of 2025 (Buurt2025) the complete cache takes about 5.5 hours and up to 48 GB; see Hardware requirements.

The cache is the folder %LocalDataProjDir%/IntermediateResults/PT_Chains_<analysis date>_<first moment>-<last arrival>_<hash>, for example PT_Chains_20251014_07h00m-09h29m_1686bf65, with a cache <n>of<N>.mmd per block and signature.txt. The signature (PublicTransport_Prep/PT_Chains_Signature) holds everything the chains depend on: the reference date and feed, the time window, the Pareto criteria, Max_transfers, MaxPTTime, the chain epsilon, the flex and train surcharge settings, the fare method and the transfer settings (Impl/PT_Chains_ParamTag), the longest pre-transport leg, the IFF transfer times and the revision of the chain code. A cache whose signature does not match is not read; see Cache names.

Step 5: generate the car caches

The component Car reads the car caches, with the front of routes on travel time and distance; see Private transport. Other components do not need them.

  1. In batch, run batch\UpdateAll.cmd cars. It asks the model which moments the run reads (MakeUnlinkedData/Step4_DirectCar/Moments) and writes a cache for each:
    • on the TomTom network the direct car trip is time-dependent (Impl/CarTimeDependent) and reads a cache per departure moment: TD07h00m, TD07h15m, TD07h30m and TD07h45m for the morning rush (TD12h00m to TD12h45m for 'Middag', TD19h00m to TD19h45m for 'Avond');
    • on the OSM network it reads the cache of MaxSpeed.

    With moments, for example batch\UpdateAll.cmd cars MorningRush Freeflow, the script writes the caches of those moments instead. Each cache takes hours.

  2. Or, in GeoDmsGui, update MakeUnlinkedData/Step4_DirectCar/Generate_All for all moments of the run, or NetworkSetup/PublicTransport_Prep/Direct/CarPerMoment/<moment>/Write_Car for one, for example TD07h00m.
  3. Reload the configuration (Alt+R).

A car cache depends on the road network (the TomTom edition), the origins, the destinations and the car settings, not on the reference date: Y2025 and Y2026 share their car caches.

Step 6: generate output

The output step computes, per origin block and departure moment, the options of the component for each origin-destination pair, keeps the Pareto front and writes it; see Per-departure-moment analysis. A public transport component reads the pre- and post-transport caches and the chain cache, Car reads the car caches, and WW and CC compute their trips in this step.

  1. In batch, run batch\UpdateAll.cmd output. It writes the missing pre- and post-transport caches, empties the output folder of the files of the model and computes the origin blocks in portions; see the output section.
  2. Or, in GeoDmsGui, update NetworkSetup/GenerateOutput/Generate_Output for all blocks in one request, or NetworkSetup/ConfigurationPerBlock/Block_<n>of<N>/PublicTransport/Generate_Output/Traveltime_ForEachDepTime_Fence/Generate for one block. With MergeOutput, NetworkSetup/GenerateOutput/Generate_Output merges the components (NetworkSetup/ComponentMerge/Generate).

The files per block and departure moment go to

%LocalDataProjDir%/Output/<Analysis_date>_<OutputLabel>_<component>/PerBlock/tt_<moment>_<n>of<N>.parquet

or, with OutputFormat 'csv', to semicolon-delimited .csv files; for example Output/20251014_basis_W_PT_W/PerBlock/tt_07h00m_163of450.parquet. The file names carry only the departure moment and the origin block; the date and the component are in the name of the folder, to keep the paths short. A component with one departure moment (Advanced/Components/SingleDepartureMoment) writes one file per block, at the congestion moment of the part of the day (07h30m in the morning). A component that cycles over the Fietsersbond network (Advanced/CyclingNetwork 'Fietsersbond') gets _fb after the name of its folder, and a merge (MergeOutput) writes to <Analysis_date>_<OutputLabel>_Merged<MergeRunNr>, with _fb when one of the merged components cycles over that network.

Everything else that sets the content is in the signature of the folder, signature.txt (NetworkSetup/GenerateOutput/Output_Signature, #118): the origin set and ModelParameters/Impl/PT_Output_ParamTag (destination set, modes, transfers, criteria, MaxPT and the Pareto tags), the exported columns and the format, and the signatures of the chain cache and of the car cache; see Cache names. The writer per block writes the signature when the folder has none and stops when it has another one; choose another OutputLabel for another set of parameters. batch\UpdateAll.cmd output empties the folder first.

The travel time tables of car, cycling and walking alone, for other analyses, are in NetworkSetup/PrivateTransport (Export_Car_traveltimes, Export_Cycling_traveltimes, Export_Walking_traveltimes); they can be computed independently of the chain cache and the output step.