Promote mobility data thanks to GTFS and other formats

Opendatasoft is designed to help you provide, share, and enrich data. It is designed so that organizations can allow non-experts to explore and make the most of their data.

It is not intended as a pass-through between two systems that produce or consume transportation data with complex formats, nor to replace a more specific mobility data solution. However, it is possible to share and showcase mobility data using Opendatasoft, publicly or even just within your organization.

This article dives deeper into what Opendatasoft allows you to do with mobility data.

You can make static data from your internal systems available for reuse by local actors and mobility stakeholders. This might be information on parking facilities, the location of self-service bike stations, or public transportation routes, and be made available in a variety of formats, such as CSV, JSON, Excel, SHP, and others.

Examples:

• Paris Velib bike-sharing stations

• Pau's bus lines (Idelis)

• Nantes' car-sharing stations

• Toulouse's tram stations

The lines and stops of a transport network (bus, tram, metro, train, etc.) can be made available from a GTFS file thanks to the GTFS connector. Contact our support if you wish to activate this connector on your account.

You won't see any change in the interface, though when importing a GTFS (.zip), but the data will be recognized and the connector selected by default. You can select for either stops or routes, as seen in the example below:

You can provide real-time availability for self-service bicycles, parking spots, upcoming events, etc.

Examples:

• MEL upcoming bus and tram API

• Parking lots in Bordeaux

• Rennes' real-time bike-sharing availability

Provide historical data on bike counts, pass validations at different stations, etc.

Examples:

• Paris bike counts

• Pass validations on the IDFM rail network

As explained above, Opendatasoft is not designed to handle real-time transport information data and to make it usable at scale and with specialized transportation tools.

The real-time data provided for a bike-sharing stations, for example, is generally for at most several hundred stations, and does not update every few seconds. Typical GTFS or NeTEx data is on an entirely different level of scale and timeliness that justifies its specialized format and treatment, for example tracking the location every few seconds of every train or bus in an entire city's transportation network.

As such, it's not possible to create a tabular Opendatasoft dataset from the data contained within a GTFS-RT, SIRI, or NeTEx file. Indeed, these formats are used by transportation applications to exchange data related to network disruptions and to update route planners. The data is structured in very specific ways and cannot be ingested as is by Opendatasoft. What's more:

1. Processing this data in Opendatasoft would necessarily involve a delay between the production of the real-time data and the provision of the ODS dataset in the portal, defeating the purpose of having real-time data in the first place.

2. Put simply, these formats are standards at a European or even global level, but the ODS Explore API is not. So if a developer has a service able to handle GTFS data, using the Opendatasoft Explore API to add further data would require further development.

Opendatasoft isn't trying to compete with a standard, but rather allow for as much interoperability as possible. Hence, it is still possible to make these files downloadable, as explained below.

To expose transport data files and APIs, we suggest the following process:

1. Create a dataset with a simple CSV as a source, listing the different type of files and APIs you're using.

2. For the files (GTFS, NeTEx), add them as alternative exports either manually or, in the case where your file is automatically updated, you should provide the URL to download the file.

   Note that for transport.data.gouv.fr (the French National Access Point), there is a specific naming rule required to provide the data: The file name is not constrained, but the file's description must be either "Fichier GTFS" or "Fichier NeTXe".

3. For the APIs you can add an alternative export and put the link to the API.

   Note that here again there is a naming rule for transport.data.gouv.fr: The description of the API should be "API GTFS-RT", "API GBFS", "API SIRI", or "API SIRI Lite".