One of the central technological stakes of Novoville Mobility is interoperability: the platform's ability to communicate with any mobility service, regardless of the provider. This is achieved through the adoption of internationally recognized open standards.
The strategic choice of open standards means that the Municipality can change its bicycle, bus, or parking provider without changing the application used by the citizen.
The Standards Adopted by Novoville Mobility
GBFS — General Bikeshare Feed Specification
The de facto standard for shared bicycles and e-scooters. It provides real-time data for vehicle availability, docking station locations, and fleet characteristics. Used by Cyclopolis/Brainbox to integrate shared bicycles in partner municipalities.
GTFS / GTFS-RT — General Transit Feed Specification
The global standard for public transport data. Static GTFS describes lines, schedules, and stops. GTFS-RT adds real-time: delays, vehicle positions, alerts. The basis for GMV ticketing integration.
OCPI — Open Charge Point Interface
Communication protocol between Charge Point Operators (CPO) and e-Mobility Service Providers (eMSP). It allows finding and paying for charging through the Novoville app.
NeTEx — Network Timetable Exchange
CEN European standard for exchanging public transport data, richer than GTFS at a semantic level. It is mainly used in European systems and is supported for future expansion.
MDS — Mobility Data Specification
Micromobility data specification that allows local authorities to receive anonymized movement data from e-scooter and bicycle providers. The basis for the mobility behavior statistical analysis algorithms (D6.6).
SIRI — Service Interface for Real Time Information
European standard for real-time public transport information. It complements GTFS-RT in systems using European architectures.
Example: NextBike/GBFS Integration
To understand how integration works in practice, we present a real example from the NextBike API used as an implementation reference in D4.2:
// Response — feeds catalog
{
"data": {
"feeds": [
{ "name": "station_information", "url": "...stations.json" },
{ "name": "station_status", "url": "...status.json" },
{ "name": "free_bike_status", "url": "...bikes.json" }
]
}
}
The same structure works for any GBFS-compatible provider — Cyclopolis, Donkey Republic, TIER, etc. The integration code does not change, only the base URL changes. This is the essence of a vendor-agnostic architecture.
The Role of the Canonical Data Model
Each standard has its own data structure. For the application to handle them uniformly, Novoville Mobility introduces a Canonical Data Model (CDM) — an internal representation standard into which all external sources are transformed before being utilized by user applications or algorithms.
The CDM allows the citizen interface to display a unified view of mobility — across bicycles, buses, parking, and electric vehicles — as if it were a single system.
Why Open Standards?
The choice is not only technical — it is strategic and political:
- Avoidance of vendor lock-in — the Municipality maintains its flexibility
- Future scalability — new services are integrated without changing the architecture
- Alignment with European legislation — EU Regulation 2017/1926 requires open transport data
- Transparency towards municipalities — data belongs to the municipality, not the provider