diff --git a/Repo-docs-product-vision.-.md b/Repo-docs-product-vision.-.md new file mode 100644 index 0000000..57e08f1 --- /dev/null +++ b/Repo-docs-product-vision.-.md @@ -0,0 +1,95 @@ + + +> Mirrored from `/mnt/DATA/git/meubility-workbench/docs/product_vision.md`. +> Origin: `repository`. +> Active tasks and changing state belong in Gitea issues; this wiki page is durable project context. + +--- +# Meubility Product Vision + +Last updated: 2026-07-06 + +Meubility should become an EU-wide mobility platform that combines harmonized mobility data, clear visual representation, routing, comparison, and analysis tooling. + +The platform should support both traveller-facing use cases and institutional planning use cases. The shared foundation is a canonical, auditable mobility dataset: sources are discovered, licensed, imported, validated, harmonized, matched to map evidence, versioned, and exposed through stable APIs and visual tools. + +## Product Goal + +The long-term product goal is to answer: + +```text +How can a person or organization get from A to B, what options exist, how do those options compare, how reliable are they, what do they cost, what emissions do they produce, and what can be booked or reserved? +``` + +The answer should be explainable. Every route, price, emission estimate, reliability prognosis, and availability signal needs provenance and confidence metadata. + +## Target Audiences + +- General public travellers who need understandable route options across public transport, walking, biking, driving, and shared mobility. +- Public institutions, municipalities, states, and governments analyzing network quality, coverage gaps, accessibility, emissions, car dependency, and improvement potential. +- Companies planning employee travel, business travel, mobility budgets, or commuting alternatives. +- Municipalities, venues, and event agencies offering "car-free travel to destination" guidance. +- Data teams and transport planners who need a workbench for source review, harmonization, QA, and publication. +- Third-party developers and researchers consuming harmonized mobility data through APIs. + +## Mobility Coverage + +The canonical data model should eventually cover all relevant mobility options: + +- Public transport: rail, regional rail, subway, tram, bus, coach, ferry, cableways, and demand-responsive services where available. +- Active mobility: walking and biking. +- Shared mobility: rental bikes, e-scooters, car sharing, station-based rental cars, free-floating vehicles, and similar services. +- Commercial individual transport: taxi, ride-hailing, chauffeur, rental car, and transfer services. +- Private car comparison: routing, duration, cost, parking assumptions, and emissions. + +Booking and reservation support should be treated as a separate layer from route plausibility. The platform can show a plausible itinerary before it can guarantee or sell the full connection. Where booking exists, it should be clear whether the result is a deep link, a partner booking, multiple independent bookings, or a protected through-ticket. + +## Traveller Comparison + +Routing results should compare options by: + +- Duration and arrival/departure time. +- Number of changes and transfer complexity. +- Walking/biking distance and accessibility constraints. +- Price or estimated cost. +- Emissions. +- Reliability prognosis, including connection risk and disruption sensitivity. +- Booking or reservation availability. +- Comfort and policy flags where available, such as local-transport-only, bike carriage, wheelchair accessibility, or company travel rules. + +Missed-connection simulation should be a first-class analysis capability: if a transfer fails, the platform should estimate the likely delay, fallback options, booking consequences, and whether the route remains acceptable. + +## Institutional Analytics + +The same harmonized dataset should support analysis for public bodies and organizations: + +- Coverage and accessibility by region, municipality, station, stop, venue, or event site. +- Route and timetable gaps. +- Missing map or timetable evidence. +- Reliability weak points and fragile transfers. +- Emissions and modal-shift potential. +- Car-free access plans for events, public buildings, tourism, campuses, and large employers. +- Source-quality reporting: freshness, license confidence, validation errors, route matching confidence, stop matching confidence, and coverage by authority level. + +## Platform Architecture Direction + +The product should be split into clear layers: + +1. Source discovery and licensing. +2. Raw source snapshots and update history. +3. Validation and QA reports. +4. Harmonization and deduplication. +5. Map/GTFS matching workbench and persistent reviewer decisions. +6. Active canonical mobility snapshots for routing and analysis. +7. Routing, comparison, reliability, pricing, emissions, and booking-readiness services. +8. Public UI, institutional dashboard, and third-party API surfaces. + +GTFS harmonization remains the next critical sprint because high-quality routing, comparison, and analytics depend on stable canonical timetable data. Shared mobility, pricing, emissions, reliability, and booking layers should build on that canonical base rather than bypassing it. + +## Near-Term Product Implications + +- Keep prioritizing the GTFS harmonization and Map/GTFS workbench tracks. +- Treat routing improvements as a parallel technical track, especially RAPTOR/CSA routing, durable caches, transfer graph precomputation, and route diagnostics. +- Add cost, emissions, reliability, and booking-readiness as explicit future data layers in the roadmap. +- Keep API readiness in view: harmonized GTFS and canonical mobility snapshots should become useful outputs even before the public traveller app is complete. +- Keep institutional analytics in scope from the start, because the workbench already stores the provenance, confidence, and quality evidence that public bodies and planners need.