Blog

Mobility Data Platform: What It Should Actually Aggregate

By 01/09/2026No Comments
Mobility Data Platform

A “mobility data platform” gets used for two different things, and the mismatch causes most of the disappointed evaluations. Some products mean a dashboard: your fleet’s own data, visualized. Others mean an aggregation layer: your fleet’s data plus every open feed, external context source, and neighboring operator’s public data, joined into one queryable source. If you need the second and buy the first, you’ll spend the first quarter stitching feeds together yourself.

Here’s what a mobility data platform should actually aggregate, why the API matters as much as the interface, and how Myles, SWITCH’s AI agent for mobility and logistics (getswitch.io) is built on this layer rather than sitting on top of it.

What a mobility data platform actually aggregates

Three categories of data belong here, not one. There’s your own fleet’s telemetry: vehicle positions, trip history, bookings, maintenance logs, the data every operator already has, usually scattered across the telematics vendor, the booking system, and a spreadsheet. There are open mobility feeds, standards like GBFS (General Bikeshare Feed Specification, maintained by MobilityData), which publishes real-time vehicle and station availability for shared micromobility, and MDS (Mobility Data Specification, maintained by the Open Mobility Foundation), which cities use to manage permitted operators. These are public, structured, and free to pull, but inconsistent enough across publishers that “structured” doesn’t mean “ready to use.” And there’s external context: weather, local events, traffic conditions, the data that explains why demand moved, not just that it moved.

A platform that only covers the first category is a fleet dashboard with a new name. A platform that covers all three is what “mobility data platform” is supposed to mean.

Why the API matters more than the dashboard

For anyone building on top of mobility data, a MaaS app, an internal BI tool, a planning model, the dashboard is not the product. The mobility data API is. A shared mobility API needs to answer a specific question a developer actually asks: can I query vehicle availability by geography and time window, get trip-level data at a resolution that supports real analysis, and combine that with context data without three separate integrations.

The practical test for evaluating a mobility data platform’s API isn’t the feature list. It’s whether you can build a working query against your own use case in an afternoon, or whether you’re three support tickets deep before the first response comes back.

The data quality problem nobody mentions in the sales deck

Open feeds solve access, not quality. GBFS feeds drift out of spec, publish inconsistent field naming across operators, and go stale without warning when an operator’s backend hiccups. MDS adoption varies by city, some publish rich trip-level data, others the bare minimum the permit requires. A platform that just proxies these feeds inherits every one of those problems. A platform that validates, normalizes, and flags stale or malformed feeds before they reach a query is doing the actual aggregation work the category promises.

How Myles is built on this layer

SWITCH’s data layer ingests 4,002 live mobility feeds across roughly 987 cities, combining fleet telemetry, open standards like GBFS and MDS, and external context data into one queried surface. That’s what lets Myles model close to 350 million trips a month and answer an operational question grounded in that data rather than a static snapshot. The same layer is also exposed directly through the SWITCH API, for teams that want to query it themselves rather than only through the agent interface.

Key takeaways

  • “Mobility data platform” means two different things, a fleet dashboard or a full aggregation layer across your data, open feeds, and context data. Confirm which one you’re evaluating.
  • GBFS and MDS give you access to open mobility data, not quality. Inconsistent formatting and stale feeds are the norm, not the exception.
  • Test the API directly before buying. Can you build a working query against your use case quickly, or does everything route through support.
  • SWITCH’s platform aggregates fleet, open-feed, and context data across 4,002 feeds and roughly 987 cities, and exposes it through both the API and Myles.

Need to query mobility data across your fleet and the open feeds around it? Try Myles free for 14 days and ask it directly.

Clara Field

Author Clara Field

More posts by Clara Field