May 8, 2020 3:28 pm

Du nouveau pour la version 2.0 de GBFS đŸšČ🛮

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

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:

Un grand-bi, la version 1.0 de la bicyclette (source : WikipĂ©dia)

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Ă© 🙌.

Une nouvelle version du GBFS amĂ©liore le partage d’équipements en libre-service.
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:

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

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





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

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





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 :





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 autodiscoverygbfs.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 :






 ont maintenant cet aspect dans la version 2.0 :





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! 👋