feat: respect GTFS transfers.txt min_transfer_time in footpath generation

[bveluetch]

Problem

When building footpaths, connect_components() in build_footpaths.cc clears all preprocessing footpaths (line 209) and recomputes them via Dijkstra. This erases the GTFS transfers.txt min_transfer_time values that were correctly parsed and stored in read_transfers() (stop.cc).

As a result, all inter-stop transfer times are computed solely from walking distance, ignoring operator-provided minimum transfer times. For example, at Paris Gare de Lyon, IDFM specifies 6-8 minutes between metro platforms and mainline platforms in their transfers.txt (206,187 entries), but MOTIS returns 0 minutes.

Root Cause Analysis

In src/loader/gtfs/stop.cc, read_transfers() correctly parses transfer_type=2 entries and stores them as footpaths (lines 192-200):

auto& footpaths = from_stop_it->second->footpaths_;
footpaths.emplace_back(to_stop_it->second.get(), duration_t{*t.min_transfer_time_ / 60});

These are written to preprocessing_footpaths_out_ (lines 347-352).

However, connect_components() in build_footpaths.cc then:

1. Clears all preprocessing footpaths (line 209): tt.locations_.preprocessing_footpaths_out_.clear()
2. Recomputes everything via Dijkstra using only walking distances
3. The GTFS min_transfer_time values are lost

Proposed Fix

In connect_components(), before clearing the preprocessing footpaths, save the GTFS-provided footpath durations. Then after the Dijkstra computation, ensure the final duration is at least the GTFS minimum:

// Before clear: save GTFS footpath durations
hash_map<std::pair<location_idx_t, location_idx_t>, duration_t> gtfs_min_durations;
for (auto l = location_idx_t{0U}; l != tt.locations_.preprocessing_footpaths_out_.size(); ++l) {
  for (auto const& fp : tt.locations_.preprocessing_footpaths_out_[l]) {
    auto const key = std::make_pair(l, fp.target());
    auto it = gtfs_min_durations.find(key);
    if (it == gtfs_min_durations.end() || fp.duration() > it->second) {
      gtfs_min_durations[key] = fp.duration();
    }
  }
}

// ... existing clear + Dijkstra code ...

// When writing footpaths (around line 294), add:
auto const gtfs_it = gtfs_min_durations.find({from_l, to_l});
auto const gtfs_min = (gtfs_it != gtfs_min_durations.end())
    ? gtfs_it->second : duration_t{0};
auto const duration = std::max({
    std::chrono::duration_cast<u8_minutes>(fp.duration()),
    tt.locations_.transfer_time_[from_l],
    tt.locations_.transfer_time_[to_l],
    gtfs_min  // NEW: respect GTFS min_transfer_time
});

This ensures the computed footpath is at least as long as the GTFS-specified minimum, while still allowing the Dijkstra-computed time to be longer if the walking distance warrants it.

Additionally: respect transfer_type=3

Currently, transfer_type=3 (not possible) entries are simply skipped (line 150-152). They should also prevent footpath creation between those stop pairs, even if they are geographically close.

Impact

This would fix:

• Overwrite transfer times from transfers.txt if Motis' own pedestrian routing yields a different time motis#1324
• More realistic interchange times public-transport/transitous#812

Operators like IDFM (Ile-de-France Mobilites) publish detailed transfer times in their GTFS that account for platform layout, elevators, corridors, and fare gates - information that pure walking distance cannot capture.

Test Case

A minimal GTFS with two stops at 50m distance and a transfers.txt entry with min_transfer_time=600 (10 min) should produce a footpath of 10 min, not the ~1 min computed from walking distance.

[felixguendling]

Hi and thank you for your proposal.

In general we focus on routed footpaths because there, we have

• different profiles including accessible routing for wheelchairs
• we can update transfer times based on elevator status

But this doesn't mean that we can't improve the "default" transfer times.

hash_map<std::pair<location_idx_t, location_idx_t>, duration_t> gtfs_min_durations;

I'm sure this map will explode for Transitous (and potentially even for smaller datasets like Germany). A local lookup on the from location should be sufficient.

[bveluetch]

Thanks for the quick feedback!

Good point about the global map. Here's a revised approach using local lookup only:

Since read_transfers() already stores GTFS footpaths in preprocessing_footpaths_out_[l] before connect_components() clears them, we can save them per-location in a compact structure before the clear:

// Before clear: save GTFS footpath durations per location (local lookup)
// Only stores entries that came from transfers.txt (non-zero, non-default)
auto gtfs_footpaths = vecvec<location_idx_t, footpath>{};
gtfs_footpaths.resize(tt.locations_.preprocessing_footpaths_out_.size());
for (auto l = location_idx_t{0U}; l != tt.locations_.preprocessing_footpaths_out_.size(); ++l) {
  for (auto const& fp : tt.locations_.preprocessing_footpaths_out_[l]) {
    if (fp.duration() > duration_t{2}) {  // skip default 2-min links
      gtfs_footpaths[l].emplace_back(fp);
    }
  }
}

Then when writing footpaths after Dijkstra (~line 294):

// Local lookup: check if GTFS specifies a minimum for this pair
auto const& gtfs_bucket = gtfs_footpaths[from_l];
auto const gtfs_it = std::find_if(
    gtfs_bucket.begin(), gtfs_bucket.end(),
    [&](auto const& gfp) { return gfp.target() == to_l; });
auto const gtfs_min = (gtfs_it != gtfs_bucket.end())
    ? std::chrono::duration_cast<u8_minutes>(gtfs_it->duration())
    : u8_minutes{0};

auto const duration = std::max({
    std::chrono::duration_cast<u8_minutes>(fp.duration()),
    tt.locations_.transfer_time_[from_l],
    tt.locations_.transfer_time_[to_l],
    gtfs_min
});

This keeps memory proportional to the number of GTFS transfer entries per location (typically small — IDFM has ~5-15 entries per stop, not millions), and the lookup is a linear scan on a small per-location vector.

Would you prefer this as a PR, or would you rather implement it yourself given you know the codebase internals better?

[felixguendling]

Before clear

Wouldn't it be sufficient to clear the data a bit later?

If you make a PR with a test case, I can look at it.