Entur collects data for all Public Transport in Norway and makes this available both as open services for journey planning and as open data. It is required by law that data for all “traditional” Public Transport public transport is sent to Entur and this is already fully implemented today. As the Public Transport Norwegian public transport eco-system develops, new modes becomes a more important part of the Public Transport system become increasingly important and Entur will act continue its role as the a national access point also for mobility datafor all modes of personal travel.
There is no legislation in place in Norway that require 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
Entur expects Expecting a great number of different mobility operators and , Entur will require that the exchange of data happens through standard formats both to ensure common and predictable functionality and being able to scale across many parties.
Entur expects all mobility feeds for both e-scooters, city bikes and car sharing services to be shared through General Bike Share Service v2.1 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.1-RC2.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 specification sets standard defines required fields in the different . JSON files. In addition to these required fieldfields, Entur will put have additional requirements on certain data in order to provide useful and consistent data to end-users across multiple mobility operators.
Separation of data
Gathering 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 should need to follow a strict set ID structure after adhering to the same convention of as all other public transport data in Norway.
IDs
All IDs exchanged with Entur should follow this conventionmust follow the convention of Codespace
+ ObjectType
+ Technical ID
combined into a single String
separated by :
.
Info |
---|
system_id in system_information.json is exempt from this requirement, but should follow the GBFS standard requirement of global uniqueness. |
Example:
Code Block |
---|
<Codespace>:<ObjectType>:<Technical ID> eg. e-scooter from Lime "YLI:ScooterVehicle:PKDVWMOCKA2OZ" |
Codespace:Three
Letter combination set A three-letter combination, or codespace, is defined by Entur for all data providers (Operator and/or Authorities) sending data to Entur. This Codespace definition stays unique for the specific operator and the full list of national defines codespaces are available her - List of current Codespaces
ObjectType:
ObjectType follow Transmodel to show what data object the id belong to
Technical ID:
ID set by the source system
...
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.
Info |
---|
The primary purpose of this ID convention 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 always be handled as a |
ObjectType:
Feeds
In addition, data for several geographic regions and / or for different vehicle types for the same codespace ObjectType
follows Transmodel to show what data object the id belongs to.
The following ObjectType
s should be used:
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, or in separate feeds. In either case, we require that data providers populate system_regions.json and vehicle_types.json to clarify which regions and vehicle types are covered by a specific 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 will aim towards supporting aims to support the full scope of data exchanged through GBFS v2.1 3 and expect expects mobility operators to exchange as rich the richest data as possible. However, Entur will expect require a minimum amount of data in order to integrate any parties feed feeds into the Enturs national mobility hubaccess point.
The following files with their required fields will be expected as are the minimum requirements:
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 intervalaccording 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:
Open GBFS-feeds for 3. third parties to consume - TODO<link> https://api.entur.io/mobility/v2/gbfs/
Open API for direct integration with consumer-clients - TODO<link> https://api.entur.io/mobility/v2/graphql/
Open JourneyPlanner API as integrated part of a TripPattern including mobilityservices for journey planning including mobility services - https://developer.entur.org/pages-journeyplanner-journeyplanner
Change history
Change History |
---|