---
name: geodms-travel-times-and-distances
description: Calculate network travel distances, travel-time tables and timetable-based public-transport accessibility with GeoDMS impedance functions. Use for origin-destination matrices, nearest destinations, road routing, and departure- or arrival-time scenarios with GTFS service data.
---

# Travel-time tables, distances and timetables with GeoDMS

Produce an origin-destination result with explicit units, routing assumptions, unreachable-pair handling and reproducible input dates. Distinguish a table of static travel costs from a timetable-dependent journey calculation.

## Select the workflow

- **Road, walking or cycling network:** start with [Academy Module 6a](https://github.com/ObjectVision/GeoDMS_Academy/wiki/Module-6a,-Working-with-networks-over-a-road-network) and [networks_car/cfg/result.dms](https://github.com/ObjectVision/GeoDMS_Academy/blob/main/networks_car/cfg/result.dms). The calculations are in `result/Analysis.dms`; `result/templates.dms` constructs the network. The project includes historical sample GeoPackages under `networks_car/data`.
- **Scheduled public transport:** start with [Academy Module 6b](https://github.com/ObjectVision/GeoDMS_Academy/wiki/Module-6b,-Working-with-networks-in-a-public-transport-setting) and [networks_publictransport/cfg/result.dms](https://github.com/ObjectVision/GeoDMS_Academy/blob/main/networks_publictransport/cfg/result.dms). Inspect `result/SourceData/GTFS/LoadFeeds.dms`, `result/Templates/StaticNetsCreator.dms` and `result/NetworkSetup/PublicTransport.dms` before adapting it.

Download the relevant project with its included files, not just the root `.dms`. Prefer the completed `result` configurations to the partly filled `exercise` configurations. The examples are starting points and require input and release-compatibility checks.

Read [impedance options](https://github.com/ObjectVision/GeoDMS/wiki/Impedance-options) and [impedance_matrix](https://github.com/ObjectVision/GeoDMS/wiki/impedance_matrix) for the installed release. The options string determines the additional argument order and which result attributes exist; do not add an option without its matching arguments.

## Define what is measured

Establish origin and destination IDs, mode, travel direction, network/data date, output units and whether the user wants a full matrix, a cutoff-limited set, a nearest destination or a reachable opportunity total. For scheduled travel also establish the service date, timezone and departure-at or arrive-by time.

- A shortest-distance route and the distance along a fastest route are different questions. Use distance as the primary impedance for the former. For the latter, minimize time and accumulate distance as an alternative impedance using the documented `alternative(link_imp):alt_imp` option and the corresponding OD result option.
- Include access and egress costs when origins/destinations are off-network. Record snapping distances and disconnected locations.
- Do not assume an OD matrix is symmetric. One-way links, mode restrictions and schedules can make A-to-B differ from B-to-A.
- Estimate the number of output pairs before computing all origins times all destinations. Use cutoffs or nearest-only queries when they answer the user's question; disclose that a cutoff result is incomplete beyond its bound.

## Static network workflow

1. Inspect node relations `F1` and `F2`, link geometries, link costs and units. Require defined, nonnegative costs and a topology that respects grade-separated crossings. For time, verify the length/speed conversion rather than assuming the supplied cost is seconds.
2. Connect origins and destinations through the network-building template. Check its connection rules against the current [connect documentation](https://github.com/ObjectVision/GeoDMS/wiki/connect). Inspect direction flags: the Academy road example uses a simplified road-type rule for bidirectionality, not a complete replacement for actual one-way and mode restrictions.
3. Adapt `/Analysis/Dijkstra_cut`, `/Analysis/Dijkstra_fullOD`, `/Analysis/Dijkstra_limit` or `/Analysis/Dijkstra_nearest` from the example to the question. Names are illustrative: check which domain is used as the starting set before describing a nearest-destination result. Reverse the graph when necessary for the requested direction.
4. For a numeric OD table, request `od:impedance,OrgZone_rel,DstZone_rel`. Keep numeric costs and stable IDs in the export. Avoid the example's rounded string representation when further analysis needs precision.
5. Export a long table first: origin ID, destination ID, cost, unit and optional alternative distance. Pivot to a dense matrix only with explicit row/column IDs and a missing-pair policy; do not assume that lists assembled per origin have identical destination ordering or completeness.

## Timetable workflow

The Academy model turns scheduled stop events, waiting and transfer connections into a directed space-time network. A static stop graph weighted only by in-vehicle time does not reproduce that model.

1. Inspect data dependencies before downloading or running. The supplied loader expects six prepared GeoPackages under `%SourceDataDir%/GeoDMS_Academy/GTFS_feed/<FileDate>/`: `calendar`, `calendar_dates`, `routes`, `stop_times`, `stops` and `trips`. A raw GTFS ZIP is not a drop-in input. Module 6b links a separate source-data download; check its availability. If using another feed, adapt the import explicitly and verify its schema and ID relations.
2. Set `ModelParameters/FileDate`, `AnalysisDate`, `Arrival_or_Departure_at_time` and the chosen measurement moments coherently. The sample dates are historical. Its `Advanced/Today` is hardcoded, and `PrevDate` subtracts one from a YYYYMMDD integer: replace or verify these for the chosen date, especially month/year boundaries. Do not carry these sample assumptions into a new analysis.
3. Validate service calendars and exceptions, service-day times beyond 24:00, previous-day trips and the model's time range. Preserve service-day meaning instead of reducing all times modulo 24 hours. Verify timezone assumptions and overnight journeys on a small known schedule.
4. Retain the scheduled, waiting, transfer, access and egress links. Check transfer feasibility and walking/biking speeds, and verify whether supplied transfer rules are supported or require adaptation. Include direct walking or cycling when it is an allowed alternative; some journeys need no transit leg.
5. Inspect `PerMeasureMoment` calculations and the `CreateODs` results under the public-transport configuration. Check units at every conversion and cutoff: comments and parameter names in the historical example are not sufficient evidence of seconds versus minutes.
6. Compute one small service area and measurement moment first. Compare a departure just before a service with one just after it, a missed transfer, an overnight trip and an unreachable destination. Only expand after these agree with the input timetable.

## Execute, check and deliver

Locate a compatible installed `GeoDmsRun.exe`, or use [official releases](https://github.com/ObjectVision/GeoDMS/releases) and [installation instructions](https://github.com/ObjectVision/GeoDMS/wiki/Installation-Instructions). Resolve source-data and local-output placeholders without changing the user's source files. Record the release, network snapshot and timetable snapshot.

Follow the [Run guide](https://github.com/ObjectVision/GeoDMS/wiki/User-Guide-GeoDMS-Run). Put an absolute `/L` argument first; use root-relative item paths and `@statistics` or dependent `IntegrityCheck` items to force the requested data calculation. A bare item request need not calculate its data. Inspect logged errors as well as exit status, and reopen configured output storage to verify the export. `@sourcedescr <item>` lists the storages a result actually reads — useful before relying on downloaded feeds — and `@valueinfo <row>` traces one od-pair's cost; the [geodms-run skill](https://raw.githubusercontent.com/wiki/ObjectVision/GeoDMS/ai/.skills/geodms-run/SKILL.md) in this catalog covers the full GeoDmsRun contract, including unattended installation.

Check a manually traceable route, a one-way reverse trip, a disconnected pair and the cutoff boundary. Depending on options, an unreachable pair can be absent or carry the impedance type's maximum-value sentinel; alternative impedance can be null. Normalize these intentionally in the export and never report an unreachable journey as zero time. Verify costs against route components and account for access, waiting and egress.

Deliver the configuration, numeric OD table, assumptions and validation report. Include departure/arrival time and service date for timetable results. Describe these as scheduled/modelled costs, not live traffic or real-time transit predictions unless those inputs were actually incorporated. State clearly if a data dependency prevented execution.