From f5f5883cbed48944b6a30bae14bb750659a12efa Mon Sep 17 00:00:00 2001 From: zemion Date: Mon, 6 Jul 2026 20:38:46 +0200 Subject: [PATCH] Sync Repo-docs-backlog from project files --- Repo-docs-backlog.-.md | 36 +++++++++++++++++++++++++++++++++--- 1 file changed, 33 insertions(+), 3 deletions(-) diff --git a/Repo-docs-backlog.-.md b/Repo-docs-backlog.-.md index 0a73b1e..2da9271 100644 --- a/Repo-docs-backlog.-.md +++ b/Repo-docs-backlog.-.md @@ -1,4 +1,4 @@ - + > Mirrored from `/mnt/DATA/git/meubility-workbench/docs/backlog.md`. > Origin: `repository`. @@ -11,6 +11,8 @@ Last updated: 2026-07-02 This backlog reflects the current Germany-scale PostGIS prototype. The target remains a Europe-scale mobility data workbench that builds canonical stops, stations, routes, route geometry, timetable links, transfer rules, routing graph data, address search, and coverage evidence from many public sources. +The broader product vision is documented in `docs/product_vision.md`: an EU-wide mobility platform with harmonized data, clear map/routing representation, route comparison by price, emissions, duration, changes, and reliability, booking-readiness where possible, missed-connection simulation, and institutional analytics for public bodies, companies, municipalities, event agencies, and third-party API consumers. + OSM-derived geometry is the preferred visual authority. GTFS, NeTEx, realtime, and official APIs are timetable, validation, routing, and gap-detection inputs. GTFS shapes are still valuable evidence, especially for missing OSM relations and temporary detours. ## Current State @@ -28,7 +30,7 @@ OSM-derived geometry is the preferred visual authority. GTFS, NeTEx, realtime, a - Route-layer rebuild runs through the queue, but it is still coarse-grained and can take minutes on national datasets. - The route-layer builder links canonical GTFS stops, OSM stops, OSM route relations, GTFS route patterns, and trip-pattern links. - Journey search is progressive and can publish intermediate results, but the underlying routing algorithm is still a prototype. -- Walk and drive routing use the OSM-derived routing layer when available. +- Walk, bike, and drive routing use the OSM-derived routing layer when available. ## Current Caveats @@ -131,7 +133,35 @@ These items directly address slow or failed searches such as `Berlin, Alexanderp - Add arrive-by search. This is important for route quality and for comparing against operator/DB route planners. - Add route profile controls in the UI. - `fastest`, `earliest arrival`, `fewest transfers`, `local only`, `walk`, `drive`, `arrive by`, `via`, `avoid`, and transfer buffer controls. + `fastest`, `earliest arrival`, `fewest transfers`, `local only`, `walk`, `bike`, `drive`, `arrive by`, `via`, `avoid`, and transfer buffer controls. + +## P1: Traveller Comparison, Reliability, and Booking Readiness + +- Add comparison fields to every itinerary. + Target dimensions: duration, arrival/departure time, changes, walking/biking distance, estimated price, emissions, reliability, accessibility flags, and booking/readiness state. +- Add emissions estimates. + Start with configurable mode/operator/country factors, then add more precise energy/fuel/source-specific factors where data exists. +- Add fare and price estimate placeholders. + Store fare-source provenance, confidence, currency, validity, passenger profile assumptions, and whether the value is exact, estimated, or unknown. +- Add booking-readiness metadata. + Distinguish unbookable route guidance, operator deep link, partner booking, multiple independent bookings, and protected through-ticket. +- Add reliability prognosis. + Start with transfer buffer, historical/current delay evidence where available, disruption sensitivity, and fragile transfer detection. +- Add missed-connection simulation. + Given an itinerary and delay scenario, estimate fallback options, likely arrival delay, extra cost, and booking consequences. +- Add shared mobility and commercial mobility as future source layers. + Model taxi, ride-hailing, rental car, car sharing, rental bike, e-scooter, and similar options without blocking the public-transport core. + +## P1: Institutional and API Product Surface + +- Add coverage and potential dashboards for public bodies. + Analyze route/timetable gaps, car-free access, coverage by municipality/venue/event, source freshness, license confidence, match confidence, and accessibility. +- Add company travel-management views. + Compare policy-compliant options by cost, emissions, duration, changes, booking readiness, and reliability. +- Add event and venue access reports. + Generate "car-free travel to destination" summaries, weak-point analysis, fallback routes, and communications-ready access guidance. +- Design the public API surface for harmonized mobility data. + Start with canonical stops/stations, canonical routes, feed/source provenance, active snapshots, coverage metrics, and route comparison outputs. ## P0: Queue and Rebuild Robustness