Add auditable GTFS repair and enrichment before MOTIS import #295

What problem would this solve?

Some structurally valid GTFS feeds still lack the fares, platform links, walking transfers or stop-time detail needed for good routing. OpenMapX needs an explicit, auditable way to make approved feed-specific repairs before MOTIS imports them.

What would you like to be able to do?

Insert a governed transformation stage between source validation and MOTIS import. Repairs must be opt-in, deterministic, feed-scoped, versioned, observable, and reversible. Preserve the original artifact and produce a transformed artifact plus a machine-readable report.

Initial rule families:

1. Lossless Fares v1 to Fares v2 conversion where semantics permit it.
2. Platform/station connector synthesis from defensible GTFS and OSM relationships.
3. Stop-time interpolation for explicitly configured subway segments.
4. Computed walking transfers.txt entries with accessibility and distance limits.
5. Declarative backfills for known stop areas, route patterns, station links, and missing references.

Acceptance criteria

• The pipeline has an explicit repair stage before MOTIS import and re-validates its output.
• Rules have stable IDs, versions, schemas, declared inputs, and documented safety conditions.
• Reapplying a rule set is idempotent.
• Original/transformed checksums, rule versions, row counts, warnings, and validation deltas are retained.
• A bad repair quarantines the candidate and cannot replace promoted data.
• Per-feed/region allowlists prevent speculative global heuristics.
• The initial rule families have fixtures, negative tests, and MOTIS probe coverage.
• Fares conversion refuses lossy cases and explains why manual mapping is needed.
• Synthesized rows carry provenance and never overwrite authoritative source rows.
• Admin job details expose the rule set and concise before/after report.
• Operator documentation explains adding, disabling, and rolling back a rule.

Alternatives or workarounds

Upstream corrections remain preferred, but deployments need predictable behavior while fixes are pending. Ad-hoc scripts are difficult to audit and roll back; relaxed validation does not improve routing semantics.

Additional context

Reported starting point

• services/data-manager/src/jobs/transitous/ fetches, validates, imports, stages, probes, and promotes feeds.
• The MOTIS adapter already requests and surfaces Fares v2 when a feed publishes it.
• Platform, accessibility, park-and-ride, fare-zone, and transfer concepts exist in the contracts and UI.
• Existing Transitous tooling includes gtfsclean; mirror mode downloads already-cleaned archives. This request concerns the additional rule IDs, provenance, reports and rollback controls below, not the absence of all feed cleanup.

Area

Transit data engineering, Transitous pipeline, MOTIS operations.

Non-goals

Do not invent fares, accessibility attributes, or geometry where no defensible source exists.

Existing cleanup is visible in services/data-manager/src/jobs/transitous/pipeline.ts and services/motis/tools/transitous/build-gtfsclean.sh. The rule families below still need their own design and validation.