Skip to content

Fix transfer buffer enforcement and accent-insensitive search - #7

Merged
IgnacioLD merged 1 commit into
masterfrom
2-fix-that-waiting-buffer-is-suspiciously-too-good-to-be-true
Jul 31, 2026
Merged

Fix transfer buffer enforcement and accent-insensitive search#7
IgnacioLD merged 1 commit into
masterfrom
2-fix-that-waiting-buffer-is-suspiciously-too-good-to-be-true

Conversation

@IgnacioLD

Copy link
Copy Markdown
Owner

Transfer buffer fix

Transfer wait times were always showing FGV's min_espera (platform-walk estimate), which happens to equal the real schedule gap. The old code padded tight transfers with fabricated departure/arrival times.

Now:

  • Wait is computed from actual hora_llegada / hora_salida times via timeDiffMinutes
  • When the real gap < user's buffer, enforceTransferBuffer re-calls planificador-online2 from the transfer station to the destination with hora_salida = arrival + buffer, finding the real next train (not a padded time)
  • Cascades through multiple tight transfers; falls back gracefully if re-planning fails
  • Duration computed from actual first-departure → last-arrival

Accent-insensitive search

The planner station picker required exact accent matching ("turia" wouldn't find "Túria"). Extracted the normalization logic from SearchViewModel into a shared stripDiacritics() utility in core, now used by both search and planner.

Test plan

  • Unit tests for mapper (timeDiffMinutes, addMinutesToTime, planificador journey with real waits)
  • App builds and installs
  • Verified Benimaclet → Túria: buffer enforcement re-routes to later train when buffer > real gap
  • Accent-insensitive search works in planner station picker

Transfer wait times now reflect the real schedule gap instead of FGV's
min_espera platform-walk estimate. When the gap is shorter than the
user's buffer, the repository re-plans the sub-journey from the transfer
station to find the real next train after arrival + buffer, rather than
padding times with fabricated values.

Also adds accent-insensitive search to the planner station picker
(typing "turia" matches "Túria"), extracting the normalization logic
into a shared stripDiacritics utility.

Signed-off-by: IgnacioLD <nadeloyeda@gmail.com>
@IgnacioLD IgnacioLD linked an issue Jul 31, 2026 that may be closed by this pull request
@IgnacioLD
IgnacioLD merged commit e394a99 into master Jul 31, 2026
1 check passed
@IgnacioLD
IgnacioLD deleted the 2-fix-that-waiting-buffer-is-suspiciously-too-good-to-be-true branch July 31, 2026 11:17
@github-project-automation github-project-automation Bot moved this from Todo to Done in Planning TransitOS Jul 31, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

Fix that waiting buffer is suspiciously too good to be true

1 participant