[Medformatik]

Summary

Part of #401. Station boards showed the wrong platform in two ways.

• HAFAS platform changes never showed. hafas-client gives the current platform as platform and the planned one as plannedPlatform. Our mapping read them the other way round, which has been the case since the first transit commit. It also dropped the planned platform, so a board couldn't flag a change.
• A merged row kept the first source's platform. That's usually Transitous. Around Köln, DELFI's timetable uses internal platform numbers rather than the tracks on the signs. At Köln Messe/Deutz, the trains on tracks 1–10 appear as 84–92 (live checks; Köln-Mülheim shows the same). Every HAFAS source (ÖBB, KVB, RMV, VSN) gives the real track. For some trains, Transitous pairs DELFI's planned number with the real current track. Production then shows a change that isn't one: "Pl. 86 → 6 (changed)".

Changes:

• HAFAS mapping (normalizeFptfDeparture and the stopovers of the dynamic registry, transport.rest and DB providers): platform is the current platform, and scheduledPlatform is the planned one. A cancelled departure keeps its planned platform.
• Merged rows choose their platform from all sources (choosePlatform):
  • The planned platform is the one the most sources plan. Each source counts once, however many of its stops list the departure.
  • A source's platform change counts when it moves the departure off both its own plan and that majority plan. A source that only knows the plan can't report a change, so a reported change wins over a majority that agrees on the plan.
  • Otherwise the row shows the platform the most sources give. A tie keeps the first source's, as before.
  • The scheduled platform is only set where a source states it, so a row can't show a "change" between two sources' numbering.
• Added sections are no change. KVB plans "10" and later gives "10 A-B". The new platformChanged in @openmapx/mobility-core/platform treats that as the same platform. The merge, PlatformBadge and navigation's platform-change announcement all use it. Without it, this PR would have introduced a false "changed" badge.

Köln Messe/Deutz, same departures. Before (main, openmapx.com): DELFI's numbers.

After: the tracks on the signs.

Köln Hbf, ICE 512 moved from track 5 to 6. Before: the change is shown from DELFI's "86".

After: from the planned track.

The after views come from a local web build of this branch against openmapx.com, through a local proxy (not committed) that builds the place boards with this branch's merge code. HAFAS stops go through this branch's adapter; the other stops' departures come from production. In the same setup, boards showed live changes that main drops: six at Frankfurt (Main) Hbf (e.g. RB33 20 → 19), three at München Hbf and two at Berlin Hbf.

Known limits:

• A departure only Transitous lists still shows DELFI's numbers, and its own false changes: two night ICEs at Köln Hbf showed "86 → 4" and "87 → 5". The board has no other source to compare them with. HAFAS boards cover a shorter window than Transitous, so later rows are often Transitous-only. The numbering is DELFI's data, which a merge rule can't convert.

Not changed: the geocoding package's undeclared @openmapx/mobility-core dependency. I listed it as a problem earlier, but it isn't one. 33 packages, apps/web among them, import mobility-core without declaring it. They resolve it through the shared tsconfig paths (tsx at runtime, Next and Vitest), and transitively through @openmapx/core, which declares it. So Turbo's task hashing still covers them. Declaring it in one of the 33 would change nothing.

Validation:

• New tests cover:

  • the HAFAS mapping, both for a change and for no change, and the cancelled case;
  • the stopover's planned platform;
  • platformChanged;
  • PlatformBadge with added sections;
  • the merged row's platform: majority over the first source, a reported change, no false change between two numberings, a change in one source's numbering against the others' plan, added sections, one vote per source, and a tie.

  Seven of these fail against main's code.

• Full Vitest run: 24,541 passed, 1 failed. The failure was the guard against bare fetch() in integrations, tripped by my uncommitted local proxy; it passes once the proxy is removed.

• check-types passes for apps/api, apps/web and packages/core, and Biome is clean.

• Not run locally: the docs build.

Release and upgrade impact

Product impact: ordinary
No package release: the built @openmapx/extension-cli and @openmapx/extension-contracts packages are byte-identical to main (both built and compared, 42 files); the changed shared code is the FPTF departure mapping in @openmapx/core and the new platform helper in @openmapx/mobility-core, which they don't ship.