Du nouveau pour la version 2.0 de GBFS 🚲🛴

Une nouvelle version du GBFS améliore le partage d’équipements en libre-service.

(Depuis cet article, nous avons apporté beaucoup de changements ! Pour plus d’informations sur les versions les plus récentes de GBFS, consultez nos articles sur les v2.2 et v2.3-RC (ainsi que les liens vers les traductions !).)

Avez-vous déjà vu un grand-bi ? Même si le nom vous est inconnu, vous reconnaîtrez sans aucun doute une photo de ce vélo:

Le grand-bi est cette bicyclette du 19e siècle possédant une grande roue en avant et une toute petite roue à l’arrière. Lorsqu’il fit son entrée sur le marché, le grand-bi procurait davantage de vitesse et une plus grande capacité à rouler sur les routes bosselées que ses prédécesseurs. Une révolution à l’époque!

Le grand-bi marqua-t-il l’histoire du cyclisme ? Assurément 👍. La bicyclette “sécurisée” se révéla-t-elle néanmoins meilleure ? Absolument 👍👍.

Lancé en 2015 par NABSA (North American Bikeshare Association), le format de données GBFS (General Bikeshare Feed Specification) est maintenant disponible en version 2.0, permettant de suivre l’usage et la disponibilité de vélos et trottinettes en libre service, apportant également des améliorations majeures à la v1.0, qui était déjà excellente!

En 2019, NABSA a confié à MobilityData le mandat pour coordonner la communauté formée autour du GBFS afin de s’assurer que le format de données soit développé de manière à satisfaire les standards et besoins en constante évolution de l’industrie. Nous sommes très reconnaissants envers les acteurs de cette communauté dont la participation à nos ateliers et sur GitHub aura permis de produire la version 2.0 du GBFS et ainsi aider les utilisateurs à trouver plus facilement que jamais des solutions à leurs besoins de mobilité 🙌.

Les nouveautés de la version 2.0 🎉

La première version de la GBFS fut un grand succès puisque près de 230 opérateurs de vélos et trottinettes l’ont adopté afin de partager en temps réel des informations accessibles via des applications mobiles utilisées par des millions d’utilisateurs partout dans le monde. Cependant, alors que les services de mobilité partagée en libre-service gagnent en popularité, il devenait évident que les fonctionnalités offertes par la v1.0 du GBFS ne parvenaient pas à répondre à tous les besoins des utilisateurs. Nous avons également remarqué qu’il était utile de clarifier l’utilisation de certains champs dans le format d’échange. Voici donc les différentes améliorations proposées par la v2.0 du GBFS.

Liens intégrés 🔗

L’une des fonctions de base du GBFS consiste à rendre visible pour l’utilisateur les engins qu’il peut louer dans les applications des fournisseurs de services de mobilité partagée. Quand un utilisateur aperçoit un vélo (ou une trottinette) auquel il souhaite accéder, l’étape suivante consiste à cliquer sur l’icône représentant ce dernier afin de le louer 👆. Toutefois, et c’était une lacune de la v1.0, le GBFS ne permettait pas à des intégrateurs comme Transit ou Google Maps d’utiliser cette information. L’utilisateur devait quitter le calculateur d’itinéraire, lancer l’application du service de mobilité partagée et chercher de nouveau le véhicule en question dans ladite application.

La v2.0 du GBFS corrige ce problème en proposant de nouveaux champs permettant l’ajout de liens intégrés (deep links). Cela permet à l’utilisateur d’accéder directement à l’application d’un fournisseur de service, tout en gardant en mémoire l’emplacement du véhicule qu’il cherche à louer.

Les liens intégrés (deep links) sont adaptés de différentes manières, décrites dans les paragraphes suivants.

App Links sur Android et Universal Links sur iOS 📱

La méthode préférée par les fournisseurs de services de mobilité partagée (utilisant le GBFS) pour adapter les liens intégrés se nomme ‘’Android App Links’’ pour Android et ‘’Universal Links’’ pour iOS. Ces formats de liens intégrés requièrent une configuration chez l’intégrateur et chez le fournisseur, mais permettent de nombreux avantages comparativement à des systèmes de liens intégrés plus anciens :

• Lorsqu’un utilisateur utilise l’icône pour accéder à un véhicule, il est immédiatement redirigé vers l’application du fournisseur de service; il n’y a donc plus de dialogue intermédiaire demandant à l’utilisateur s’il souhaite ouvrir le lien vers le site Internet ou vers l’application.
• Les intégrateurs n’ont plus à vérifier manuellement si l’application du fournisseur de service en question est déjà installée sur le smartphone et le rediriger vers la page de téléchargement de l’application si ce n’est pas le cas; cette situation est automatiquement prise en charge par le système d’exploitation.
• Il est désormais possible de créer des liens intégrés qui fonctionnent que l’on utilise le site (via le navigateur internet), ou l’application du fournisseur de services de mobilité partagée.

Dès qu’un fournisseur de GBFS implémente des Android App Links ou des Universal Links dans son application et sur son site Internet, il lui faut ajouter une sectionrental_apps et discovery_uris dans le fichier system_information.json du GBFS.

system_information.json

{
  "last_updated": 1572447999,
  "data": {
    "system_id": "abc_cityname",
    "short_name": "ABC Bike Rental",
    "rental_apps": {
      "android": {
        "discovery_uri": "com.abcrental.android://"
      },
      "ios": {
        "discovery_uri": "com.abcrental.ios://"
      }
    }
  }
....

discovery_uris est une URL (Universal Resource Identifiers) pouvant être utilisée afin de savoir si l’application d’un fournisseur de services en mobilité partagée est installée sur Android ou iOS, par exemple, en utilisant, respectivement, PackageManager.queryIntentActivities et UIApplication canOpenURL. Ce champ permet à un intégrateur de prioriser les applications de location de services de mobilité partagée qui sont déjà installées sur l’appareil de l’utilisateur. Par exemple, si on retrouve trois fournisseurs de services de location de vélos dans une ville et que l’utilisateur a déjà installé l’application du fournisseur ‘’X’’, un intégrateur devrait donner la priorité aux options de trajet vers les équipements du fournisseur ‘’X’’.

Ensuite, pour chaque station (dansstation_information.json) ou un équipement est disponible (dans free_bike_status.json), un lien intégré unique devrait être créé dans rental_uris qui mènera l’utilisateur à la page de la station ou de l’équipement en libre-service dans l’application du fournisseur de service de mobilité partagée.

Voici un exemple pour une station : station_information.json

"stations": [
  {
    "station_id": "425",
    "name": "Coppertail",
    "lat": 27.9563335328521,
    "lon": -82.430436084371,
    "rental_uris": {
      "android": "https://www.abc.com/app?sid=1234567890&platform=android",
      "ios": "https://www.abc.com/app?sid=1234567890&platform=ios"
    }
  }
…

Le lien intégré peut être de n’importe quel format utile à l’implémentation spécifique d’un fournisseur de service en mobilité partagée et peut contenir de nombreux paramètres qu’il considère pertinents. Dans l’exemple ci-dessus, le fournisseur de services de mobilité partagée utilise le paramètre sidpour identifier la station, paramètre que l’application du fournisseur peut ensuite utiliser afin de montrer cette station à l’utilisateur. Certains paramètres, réservés pour la communication entre un intégrateur et l’application d’un fournisseur, permettent de générer des données à des fins d’analyses ; ceci sera expliqué plus en détail un peu plus loin.

L’intégrateur peut alors ouvrir le champ rental_uris en tant que lien intégré sur la plateforme appropriée; par exemple android.intent.action.VIEW sur Android. Les intégrateurs devraient consulter la documentation portant sur les liens intégrés “Deep Links” sur Android et “Communicate with Other Apps” sur iOS pour plus de détails.

Le consensus concernant les meilleures pratiques à maintenir dans l’industrie suggère aux fournisseurs de services de mobilité partagée de changer l’identifiant attribué à un équipement dans un lien intégré après chaque location afin d’éviter que l’on puisse par inadvertance retracer le point de départ et la destination de l’utilisateur s’étant servi de cet équipement. Consultez la section « Protection de la vie privée de l’utilisateur » plus bas pour en savoir plus sur les thématiques de vie privée et le paramètre bike_id.

Format de lien intégré de base 📱

Des applications plus anciennes n’ont peut-être pas la capacité technique d’utiliser ‘’Android App Links’’ sur Android et ‘’Universal Links’’ sur iOS, mais peuvent néanmoins utiliser des liens intégrés “Deep Links”.

Afin de permettre aux intégrateurs d’utiliser des liens intégrés, les fournisseurs de services de mobilité partagée doivent produire un champ store_uri pour chaque système d’exploitation, en plus du champ discovery_uri. Ceci permet de rediriger l’utilisateur vers la page de téléchargement appropriée de leur application si elle n’est pas déjà installée.

system_information.json

{
  "last_updated": 1572447999,
  "data": {
    "system_id": "abc_cityname",
    "short_name": "ABC Bike Rental",
    "rental_apps": {
      "android": {
        "discovery_uri": "com.abcrental.android://"
        "store_uri": "https://play.google.com/store/apps/details?id=com.abcrental.android",
      },
      "ios": {
        "store_uri": "https://apps.apple.com/app/apple-store/id123456789",
        "discovery_uri": "com.abcrental.ios://"
      }
    },
…

Si vous êtes un fournisseur de services de mobilité partagée, vous pouvez trouver le numéro d’identification au sein du champ store_urien utilisant la documentation pour iOS et Android.

De façon similaire à la précédente méthode permettant d’implémenter des liens intégrés, les fournisseurs de services de mobilité partagée devront spécifier un lien intégré unique dans rental_uris pour chaque station ou équipement en libre-service. Ici, la principale différence réside dans le fait que votre URL sera fort probablement propriétaire plutôt que de commencer par http. Dans l’exemple plus bas, le fournisseur de services de mobilité partagée a défini son URI comme étant com.abcrental.android:// pour Android et com.abcrental.ios:// pour iOS :

station_information.json

"stations": [
  {
    "station_id": "425",
    "name": "Coppertail",
    "lat": 27.9563335328521,
    "lon": -82.430436084371,
    "rental_uris": {
      "android": "com.abcrental.android://open.abc.app/app?sid=1234567890",
      "ios": "com.abcrental.ios://open.abc.app/app?sid=1234567890"
    }
  },
…

Avant d’ouvrir le lien intégré, l’application de l’intégrateur devra d’abord vérifier si l’usager a préalablement installé l’application en utilisant le champ discovery_uri. Si ce n’est pas le cas, l’intégrateur devra utiliser le champ store_uri pour ouvrir la page de téléchargement de l’application de l‘intégrateur.

Applications Internet 🌐

Pour finir, la v2.0 du GBFS permet d’incorporer des liens intégrés à des sites Internet (qui ne sont pas conçues pour Android ou iOS) pour les stations et les équipements en libre-service via l’URL de location web :

"stations": [
  {
    "station_id":"425",
    "name":"Coppertail",
    "lat":27.9563335328521,
    "lon":-82.430436084371,
    "rental_uris": {
      "web":"https://www.abc.com/app?sid=1234567890",
    }
  },
…

Les applications des fournisseurs de services de mobilité partagée peuvent envoyer les utilisateurs consulter cette URL pour visualiser une station en particulier à l’aide d’un navigateur Internet.

Données générées à des fins d’analyses 📊

Les applications d’intégrateurs peuvent utiliser certains paramètres afin de générer des données dans le but d’effectuer des analyses. La version 2.0 du GBFS permet déjà de générer des données en utilisant les paramètres listés ci-dessous; alors que d’autres seront probablement ajoutés éventuellement:

• client_id ; le nom de domaine d’un intégrateur. (e.g., google.com pour Google)
• ad_id ; Advertising ID produit pour l’intégrateur (e.g., Identifier pour Advertiser (IFDA) sur iOS ou Google Advertising ID (AAID) sur Android.
• token ; un identifiant produit par l’application du fournisseur de services de mobilité partagée pour l’intégrateur

Consultez la documentation GBFS Deep Links Analytics documentation pour plus d’information.

Faciliter la recherche et la communication au travers des champs 🤝

La version v2.0 du GBFS donne la possibilité de trouver différents fichiers à travers les données; le fichier de recherche autodiscovery, gbfs.json, qui contient les liens vers tous les autres fichiers est dorénavant requis dans la version v2.0. Le champ “nom” de chaque fichier dans gbfs.json a également été normalisé. Cela permet à l’application d’un consommateur de données de suivre un seul lien vers gbfs.json, au lieu de plusieurs URL vers différents fichiers pour un seul flux.

Afin de faciliter les communications entre les consommateurs et les producteurs, un nouveau champ courriel feed_contact_email a été ajouté au system_information.json. Ce dernier permet à l’utilisateur de facilement contacter l’opérateur afin de lui signaler des problèmes techniques.

Clarifications des caractéristiques 🛠️

Quelques clarifications ont été effectuées dans les champs de la version 2.0 de la GBFS.

Dans la version 1.0, la signification exacte de num_bikes_available et num_docks_available n’était pas claire en fonction de la disponibilité des places en station. Par exemple, s’il y avait physiquement cinq vélos à une station, mais que la valeur attribuée à is_renting était fausse, est-ce que num_bikes_available devrait être 0 ou 5?

Dans la v2.0, les définitions de num_bikes_available etnum_docks_available ont été précisées en spécifiant qu’il s’agit de l’état physique du nombre de vélos présent et de places vides disponibles à une station, indépendamment de la possibilité d’emprunter ou de retourner un vélo. Par conséquent, un utilisateur doit maintenant consulter le champ is_renting pour savoir si un vélo ‘’disponible’’ peut être loué, et le champ is_returningpour savoir si un vélo peut être retourné à une borne vide.

Autre modification nouvelle à v2.0 : des valeurs booléennes JSON canoniques true oufalse remplacent0 et1 utilisé précédemment.

Ainsi, les données obtenues dans la version 1.0 :

{
  "station_id": "2721922",
  "is_installed": 1,
  "is_renting": 1,
  "is_returning": 1,
  …
},

… ont maintenant cet aspect dans la version 2.0 :

{
  "station_id": "2721922",
  "is_installed": true,
  "is_renting": true,
  "is_returning": true,
  …
},

Protection de la vie privée de l’usager🕵️🔒

Afin de réduire les risques de transmettre des données d’ordre privé, le changement de l’identifiant bike_id après chaque location pour les véhicule en libre-service est maintenant requis dans la version 2.0 du GBFS. Cela signifie que l’identifiant d’un véhicule produit par le GBFS au moment de sa location doit être différent de l’identifiant qui lui est attribué une fois la location terminée. Cette technique rend beaucoup plus difficiles les tentatives de traçage du trajet de l’utilisateur à partir des données brutes.

Faciliter la transition vers la version 2.0 😌

La version 2.0 du GBFS est une mise à jour majeure, ce qui signifie que certains changements produiront des conflits entre la version de l’application qu’emploient encore certains fournisseurs et la nouvelle version de l’application de leur fournisseur de services de mobilité partagée. Par exemple, quand un producteur de données changera des valeurs booléennes de 0/1 àfalse/true, la version de l’application qui n’a pas été mise à jour ne fonctionnera pas normalement.

Par conséquent, à mesure que les fournisseurs de services de mobilité partagée mettent à jour leur flux, il est important de s’assurer que l’ancienne version soit encore supportée parallèlement à la plus récente en leur attribuant différentes URLs. Le GBFS définit les pratiques suivantes :

• Les producteurs de GBFS doivent fournir des “points d’accès”” permettant de supporter la spécification actuelle (la v1.0) ainsi que et la version courante (ici la v2.0) dans un délai d’au moins 3 mois à compter de la sortie d’une nouvelle version MAJOR ou MINOR. Il ne sera pas requis de supporter plus d’une version MINOR de la même version MAJOR parce que les versions partielles (minor) seront compatibles et rétroactives.
• Les utilisateurs du GBFS devraient à minima être en mesure de maintenir le support à long terme (LTS). Il est fortement recommandé que les utilisateurs du GBFS puissent supporter les versions subséquentes.
• Les URLs par défaut du GBFS (e.g. https://www.example.com/data/gbfs.json ou https://www.example.com/data/fr/system_information.json) doivent diriger les consommateurs vers les données conformes à la documentation LTS en vigueur (couramment la v1.0).

Si les développeurs ne sont pas prêts à supporter les multiples versions du GBFS simultanément, mais souhaitent néanmoins ajouter certaines fonctionnalités de la v2.0 compatibles avec la v1.0, une mise à jour partielle, la version 1.1 du GBFS, est disponible. Ceci permet aux développeurs d’ajouter des liens intégrés et un courriel feed_contact_email à leur flot d’information, sans mise à jour.

Pour plus d’information sur les spécifications des versions du GBFS, consultez la documentation prévue à cet effet (Specification Versioning documentation.)

Vous pouvez consulter toutes les spécifications de la v2.0 du GBFS ici.

Que nous réserve l’avenir ? 💫

Nous avons mis en place les bases des futures évolutions du GBFS de manière à maintenir une continuité dans le format tout en augmentant nettement ses fonctionnalités. Nous travaillons déjà à une mise à jour partielle, la version 2.1, laquelle permettra de délimiter des zones par géolocalisation (geofencinig) et de spécifier différents types de véhicules (ex : trottinettes). La version 3.0 du GBFS présentera également de nouvelles fonctionnalités, dont la nécessité pour les fournisseurs de créer une licence pour leur flux de données.

Enfin, nous vous invitons à vous impliquer dans le processus de développement du GBFS. Rendez-vous sur le GitHub du GBFS afin de prendre part à des discussions ouvertes sur diverses problématiques ainsi que sur les changements proposés dans la section ‘’pull requests’’. Cela nous fera plaisir de vous y retrouver! 👋