89 lines
5.4 KiB
Markdown
89 lines
5.4 KiB
Markdown
# 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.
|