...
There is no legislation in place in Norway that require mobility operators to provide this data to Entur, however it is expected this will be a requirement in the future and we will start to collect this data on a voluntary basis. This document will describe requirements Entur will put on mobility operators for integrating their services in Enturs national platform.
Standard
Entur expects a great number of different mobility operators and will require exchange of data through standard formats both to ensure common functionality and being able to scale across many parties. Entur expects all mobility feeds for both e-scooters, city bikes and car sharing services through General Bike Share Service v2.1 (GBFS)
https://github.com/NABSA/gbfs/blob/v2.1-RC2/gbfs.md
Expected data
The GBFS specification sets required fields in the different .JSON files. In addition to these required field, Entur will put additional requirements on certain data to provide useful and consistent data to end-users across multiple mobility operators.
Separation of data
Gathering data across many operators, separation of data is a key factor. To ensure uniqueness on all ID’s, data provided in the GFBS feeds should follow a strict ID structure after the same convention of as all other public transport data in Norway.
IDs
All IDs exchanged with Entur should follow this convention:
| Code Block |
|---|
<Codespace>:<ObjectType>:<Technical ID>
eg. e-scooter from Lime
"YLI:Scooter:PKDVWMOCKA2OZ" |
Codespace:
Three Letter combination set defined by Entur for all data providers (Operator and/or Authorities) sending sharing their data to Entur. This Codespace definition stays unique for the specific operator and the full list of national defines defined codespaces are available her - List of current Codespaces
...
| Info |
|---|
This ID conventions primary purpose is to guarantee uniqueness for all ID’s in Enturs National Access point Point (NAP) for public transport and mobility data. The full ID should in any implementation be handled as a String |
Feeds
In addition, data Data for several geographic regions (i.e. cities) should be delivered in separate feeds.
Data for different vehicle types may be delivered in the same GBFS feed. Data providers should always specify which vehicle types are supported by the system in vehicle_types.json.
Minimum requirements
Entur will aim towards supporting the full scope of data exchanged through GBFS v2.1 and expect mobility operators to exchange as rich data as possible. However, Entur will expect a minimum amount of data to integrate any parties feed into the Enturs national mobility hub.
...
File | Comment |
|---|---|
gbfs.json | |
system_information.json | |
vehicle_types.json | |
station_information.json | Only for dock-based systems |
station_status.json | Only for dock-based systems |
free_bike_status.json | Optional for dock-based system |
system_pricing_plans.json |
Exchange of data
Entur will pull data data from all providers at a minimum of 60 seconds interval
Use and redistribution of data
All data exchanged with Entur will be distributed as open data under the NLOD-license. Read more about this on developer.entur.org.
...
Open GBFS-feeds for 3. parties to consume - TODO<link>
Open API for direct integration with consumer-clients - TODO<link>
Open JourneyPlanner API as integrated part of a TripPattern including mobilityservices - https://developer.entur.org/pages-journeyplanner-journeyplanner (Work in progress)