Mobility Data Collection - GBFS

Entur collects data for all Public Transport in Norway and makes this available as open services for journey planning and as open data. It is required by law that data for all “traditional” public transport is sent to Entur and this is already fully implemented today. As the Norwegian public transport eco-system develops, new modes become increasingly important and Entur will continue its role as a national access point for all modes of personal travel.

There is no legislation in place in Norway that requires 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

Expecting a great number of different mobility operators, Entur will require that the exchange of data happens through standard formats to ensure common and predictable functionality and being able to scale across many parties.

Entur expects all mobility feeds for e-scooters, city bikes and car sharing services to be shared through General Bike Feed Specification (GBFS), version 2.2, 2.3 or 3.0.

https://github.com/NABSA/gbfs/blob/v2.2/gbfs.md

https://github.com/NABSA/gbfs/blob/v2.3/gbfs.md

https://github.com/MobilityData/gbfs/blob/v3.0/gbfs.md

Note that v3.0 is now the current version of GBFS, and we encourage producers to migrate their feeds.

All data producers should study MobilityData’s implementation guide for producers.

Expected data

The GBFS standard defines required fields in the JSON files. In addition to these required fields, Entur will have additional requirements on certain data in order to provide useful and consistent data to end-users across multiple mobility operators.

Separation of data

When gathering data across many operators separation of data is a key factor for success. To ensure uniqueness on all ID’s, data provided in the GFBS feeds need to follow a set ID structure adhering to the same convention as all other public transport data in Norway.

IDs

All IDs exchanged with Entur must follow the convention of Codespace + ObjectType + Technical ID combined into a single String separated by :.

system_id in system_information.json is exempt from this requirement, but should follow the GBFS standard requirement of global uniqueness.

Example:

<Codespace>:<ObjectType>:<Technical ID> eg. e-scooter from Lime "YLI:Vehicle:PKDVWMOCKA2OZ"

Codespace:

A three-letter combination, or codespace, is defined by Entur for each data provider. This codespace definition remains unique for each specific data provider and can be used to identify data after being merged into the national dataset.

The primary purpose of this ID convention is to guarantee uniqueness for all ID’s in Enturs National Access Point (NAP) for public transport and mobility data. The full ID should always be handled as a String in any implementation.

ObjectType:

ObjectType follows Transmodel to show what data object the id belongs to.

The following ObjectTypes should be used:

Feed

Field

ObjectType

Feed

Field

ObjectType

vehicle_types.json

vehicle_type_id

VehicleType

station_information.json

station_id

Station

free_bike_status.json / vehicle_status.json

bike_id / vehicle_id

Vehicle

system_regions.json

region_id

Region

system_pricing_plans.json

plan_id

PricingPlan

system_alerts.json

alert_id

Alert

Technical ID:

The technical ID has no specific requirements other than that it has to be unique within the dataset. It is commonly the ID from the source data.

Feeds

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.

Language

Feeds should be provided with a Norwegian language code (no, nb or nn) in the discovery file (gbfs.json) and system information file (system_information.json), and all human-readable strings should be in Norwegian.

Minimum requirements

Entur aims to support the full scope of data exchanged through GBFS v2.3 and expects mobility operators to exchange the richest data possible. However, Entur will require a minimum amount of data in order to integrate feeds into the national mobility access point.

The following files with their required fields are the minimum requirements:

File

Comment

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 according to the ttl and last_updated fields of each file. for files with 0 ttl Entur will pull data at least every 30 seconds.

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.

Data will be exposed through 3 different services:

Change history

Version Date Comment
Current Version (v. 30) 17. Apr 2024 09:03 Tom Erik Støwer
v. 29 13. Sept 2023 18:34 Tom Erik Støwer
v. 28 22. Jun 2023 08:51 Tom Erik Støwer
v. 27 22. Jun 2023 08:50 Tom Erik Støwer
v. 26 06. Apr 2022 11:48 Tom Erik Støwer
v. 25 28. Mar 2022 10:26 Tom Erik Støwer
v. 24 16. Mar 2022 07:41 Andreas Tryti
v. 23 12. Aug 2021 11:43 Tom Erik Støwer
v. 22 12. Aug 2021 11:33 Tom Erik Støwer
Add note to exempt system_id from Transmodel ID requirement.
v. 21 03. Aug 2021 14:02 Tom Erik Støwer
Added list of Object Types to be used in IDs.
v. 20 21. Apr 2021 06:31 Tom Erik Støwer
v. 19 21. Apr 2021 06:29 Tom Erik Støwer
Add language requirement. All data operators should provide feed in Norwegian language.
v. 18 25. Mar 2021 14:13 Tom Erik Støwer
Changed GBFS version references from v2.1 to v2.2. v2.2 contains all and only the changes from the original v2.1 release candidate, but the release itself was split into two separate releases.
v. 17 25. Mar 2021 14:08 Tom Erik Støwer
Added change history section
v. 16 05. Mar 2021 11:29 Andreas Tryti
v. 15 26. Jan 2021 15:33 Johan Wiklund
v. 14 26. Jan 2021 11:44 Andreas Tryti
v. 13 25. Jan 2021 12:04 Johan Wiklund
v. 12 25. Jan 2021 09:28 Andreas Tryti
v. 11 18. Dec 2020 08:01 Andreas Tryti
v. 10 27. Nov 2020 07:13 Tom Erik Støwer
v. 9 26. Nov 2020 13:38 Andreas Tryti
v. 8 25. Nov 2020 12:38 Andreas Tryti
v. 7 25. Nov 2020 10:07 Andreas Tryti
v. 6 25. Nov 2020 10:03 Andreas Tryti
v. 5 18. Nov 2020 13:36 Andreas Tryti
v. 4 18. Nov 2020 13:31 Andreas Tryti
v. 3 17. Nov 2020 19:22 Tom Erik Støwer
v. 2 17. Nov 2020 14:01 Andreas Tryti
v. 1 12. Nov 2020 14:35 Andreas Tryti