meubility-workbench/docs/product_vision.md

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:

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.