Municipalités, le GBFS v2.2 est là pour vous aider
Tout ce qu’il vous manque si vous êtes encore coincé avec des données en v1.0.
(Après vous être familiarisés avec la v2.2, allez voir ce que la v2.3-RC contient!)
Tous les utilisateurs du GBFS (General Bikeshare Feed Specification) tireront parti des mises à jour de la spécification. Toutefois, notre toute dernière née aura une saveur particulière pour les villes. Avec tous les nouveaux projets pilotes de trottinettes et vélo-partage que nous voyons éclore ici et là, nous revenons sur les raisons pour lesquelles les municipalités devraient exiger des données en v2.2 de leurs opérateurs. La réponse ultime est: la valeur ajoutée pour les villes ainsi que pour les voyageurs, mais voyons ça en détail.
GBFS v2.2 — ce qu’il faut savoir en 1 minute ⏲️
L’information fondamentale à retenir sur GBFS v2.2.
Un usager vous demande le coût de son trajet, le type de véhicule disponible, et les limites géographiques dudit trajet. Une réponse simple et claire est maintenant possible avec le GBFS v2.2 !
4 ajouts majeurs de la v2.2 :
- L’information tarifaire 💸
- La représentation de différents types de véhicule de mobilité partagée 🚲🛴
- L’inclusion du géorepérage 🗺️
- La description des stations virtuelles et le service de “voiturier” (valet)
Si les opérateurs de mobilité partagée de votre municipalité s’expriment toujours en v1.0, vous passez à côté d’informations essentielles ! Comment faire pour déterminer la version des données ? Bonne question ! La réponse est toute simple : ouvrez n’importe lequel de vos fichiers GBFS, par exemple gbfs.json, et cherchez le numéro de version :
{
"last_updated": 1609866247,
"ttl": 0,
"version": "2.2",
"data": {
Si vous ne voyez pas du tout la ligne, vous êtes quasi certain d’être encore en v1.0.
Plus d’information et de transparence = un choix éclairé pour le voyageur.
La majorité de cet article brosse un aperçu des nouvelles fonctionnalités de chaque version du GBFS. Jetez un coup d’œil au GitHub pour vous tenir au courant et n’oubliez pas de nous contacter pour plus d’informations. Nous ne sommes jamais très loin → sharedmobility@mobilitydata.org
Court historique
Le GBFS a été initialement développé comme un standard pour représenter le vélo en libre partage avec station. La v1.0 est sortie fin 2015. Depuis, l’industrie de mobilité a énormément changé. Au rythme des transformations de l’industrie, le GBFS s’est adapté pour mieux prendre en compte et décrire de nouveaux types de véhicules, services, et technologies.
En 2019, la NABSA a engagé MobilityData pour gouverner et améliorer le GBFS. En mars 2020, le partenariat entre les deux organisations a été officialisé dans le but de maintenir le travail existant sur le GBFS. Dès lors, MobilityData a doté la spécification de nouvelles extensions, lui offrant de nouvelles capacités et une adoption plus large.
Depuis sa création, le GBFS est devenu le standard de facto des données ouvertes pour la mobilité partagée, utilisé par des centaines de systèmes dans plus de 45 pays à l’échelle mondiale.
v1.1 — Liens profonds, courriel de contact, et gestion de versions
La v1.1 a ajouté trois nouvelles fonctionnalités qui ont préparé le terrain en vue d’une expérience améliorée pour les usagers, les régulateurs, ainsi que les producteurs et consommateurs de GBFS.
Liens profonds 📲
Les liens profonds : si vous êtes le genre de personne à aimer avoir toutes vos options réunies en un seul endroit, les liens profonds sont faits pour vous. Ils vous permettent d’utiliser une seule application agrégatrice pour visualiser tous les véhicules partagés existant dans votre ville. Quand vous êtes fin prêt à vous déplacer, vous n’avez qu’à simplement sélectionner le véhicule ou la station désirée et… comme par magie, vous êtes téléporté dans l’application de l’opérateur pour finaliser la transaction. Si vous ne la possédez pas, vous serez automatiquement redirigé vers votre «magasin» d’applications pour la télécharger.
Les liens profonds sont optionnels dans le GBFS, mais nous encourageons les municipalités à exiger que les opérateurs de mobilité partagée les incluent dans leurs jeux de données GBFS publics. La majorité des applications de planification de trajet exigent des liens profonds pour leur intégration. Les exiger est donc la méthode la plus efficace pour s’assurer que tous les voyageurs aient vue sur toutes les offres de mobilité partagée de votre municipalité.
Courriel de contact 📥
La v1.1 a aussi ajouté un courriel de contact pour le flux de données. Cela peut paraître bien mince comme changement, mais, si un flux de données tombe en panne, vous ne voulez pas que votre seul recours soit le numéro du service client de l’opérateur. Le courriel de contact pour le flux de données vous donne exactement le moyen de contacter la bonne personne chez votre opérateur de mobilité partagée.
Suivi des versions #️⃣
Enfin, la v1.1 a jeté les bases nécessaires pour des changements plus importants à venir, notamment avec la mise en place du suivi des versions. Cette amélioration définit non seulement le cadre des changements majeurs de la spécifications apportés par MobilityData et les parties prenantes du GBFS, mais pose aussi la base nécessaire pour que les régulateurs soient capables d’exprimer plus spécifiquement leurs exigences en termes de données.
Pour plus de détails au sujet des liens profonds et autres améliorations mentionnées, consultez cet article.
v2.0 — Visibilité améliorée, clarté, et protection de la vie privée
Augmentation de la visibilité 👀
Avec le GBFS v2.0, le fichier de découverte automatique gbfs.json a passé d’optionnel à requis. Ce fichier fonctionne comme un index, donnant aux consommateurs de données les emplacements de tous les autres fichiers dans le jeu de données. Cela veut dire que lorsque vous publiez les emplacements des jeux de données GBFS, vous n’avez qu’à simplement publier l’URL du fichier de découverte automatique gbfs.json.
Confidentialité des voyageurs 🔒
Le GBFS v2.0 contient également de nombreuses clarifications et raffinements, mais le plus grand changement effectué a été de protéger la vie privée des voyageurs. En effet, le GBFS v2.0 exige la rotation du champ bike_id pour tous les véhicules. Pourquoi est-ce si révolutionnaire ? Sans la rotation, il est possible de suivre les véhicules et d’en identifier les utilisateurs. Si vous publiez encore des identifiants de véhicules statiques, vous devrez mettre à jour vos jeux de données dès que possible pour faire pivoter les identifiants. Ceci est un changement significatif par rapport aux versions précédentes, et nous sommes conscients que ceci a affecté un nombre des cas d’utilisations. MobilityData s’attache à répondre à ces préoccupations tout en cherchant des solutions de partage de d’autres types de données qui gagneraient à l’être de façon privée (par exemple, les informations de véhicules très spécifiques qui peuvent être assimilées à un identifiant).
v2.1 — Support pour multiples types de véhicules et géorepérage
La v2.1 était une énorme mise à jour (qui a officiellement vécu 24 heures seulement puisque v2.2 a été implémentée la journée suivante!) avec plusieurs fonctionnalités utiles permettant une meilleure représentation des différents types véhicules de mobilité partagée et modèles opérationnels qui sont devenus communs dans le monde entier.
Types de véhicules 🚲🛴
Antérieurement à la v2.1, tous les véhicules dans un jeu de données de GBFS étaient modélisés de la même façon, rendant impossible de distinguer un vélo d’un vélo électrique ou d’une trottinette. Avec l’ajout des descriptions des types de véhicules, les opérateurs peuvent publier des informations détaillées sur tous les véhicules de leurs flottes. Prenons l’exemple d’un voyageur qui cherche un vélo, avec une nette préférence pour un vélo électrique: il voudra s’assurer que la batterie du vélo est suffisamment chargée pour se rendre à sa destination. C’est là que réside toute l’utilité de l’information sur les types de véhicules présente dans la v2.1.
Géorepérage
La v2.1 s’est dotée de la prise en charge du géorepérage (geofencing en anglais). Et là, vous vous dites qu’on a pondu un néologisme. Peut-être. L’idée du géorepérage est de créer une frontière virtuelle autour d’une région géographique donnée. En traversant cette frontière invisible, l’utilisateur peut déclencher toute une série d’événements tels que les notifications de changement de zone tarifaire ou encore la désactivation du véhicule. Le géorepérage peut aussi être utilisé pour délimiter des zones de prise en charge et de dépôt, pour limiter les débuts et fins de trajets, pour renforcer les limites de vitesse, pour décrire les restrictions de stationnement, ou encore pour définir des zones d’équité.
Stations virtuelles et service de valet
La v2.1 permet également la prise en charge des stations virtuelles et celles avec service de “voiturier” (valet). Les stations virtuelles permettent aux opérateurs de définir des zones dans lesquelles les véhicules doivent obligatoirement être stationnés. Les stations virtuelles partagent plusieurs fonctionnalités avec les stations traditionnelles connectées, mais peuvent aussi prendre n’importe quelle forme allant du simple marquage de la chaussée aux porte-vélos et trottinettes. Chacune des stations virtuelles et physiques peut maintenant être rattachée à un service de “voiturier” (valet) qui se traduit sous la forme d’une capacité illimitée d’entreposage grâce à ce service.
La v2.1 ne s’arrête pas là (oui, ce fut une très grosse mise à jour !) : en plus des types de véhicules, du géorepérage, des stations virtuelles et des services de valet, elle permet aussi de définir le nombre de véhicules et bornes disponibles par type de véhicule agrégé. Vous avez un système hybride avec un mélange de vélos traditionnels, vélos électriques et trottinettes? Pas de problème, maintenant quand vous sélectionnez une station, le nombre total de véhicules disponibles par type pourra être affiché ainsi que le nombre de bornes disponibles pour chaque type.
v2.2 — la tarification plus flexible
Finalement, nous voilà arrivés à la toute dernière v2.2. Vous souvenez-vous encore qu’il s’agissait du sujet principal de cet article ? Cette version se dote d’une seule extension, mais très importante car elle traite de la tarification. Tout le monde veut savoir combien leurs trajets en mobilité partage vont leur coûter, nous sommes d’accord. Toute version antérieure à la v2.2 du GBFS ne pouvait détailler la tarification appliquée. Désormais, l’information tarifaire peut représenter une grande variété de schémas de tarification, ce qui devrait simplifier la vie des voyageurs qui planifient leurs trajets.
Il est désormais possible pour le GBFS de donner le coût final d’un déplacement qu’il soit déterminé en fonction du temps d’usage, de la distance parcourue, voire des deux dans certains cas. Seront affichés les prix moyens et bornes de tarification.
Cerise sur le gâteau🤩
La seconde partie du processus de gouvernance peut sembler lourd: l’obligation d’implémentation dans un jeu de données public est difficile à tenir dans une industrie qui fait face à des enjeux de protection des données confidentielles des usagers et de concurrence très forte. Cependant…
Toutes les améliorations apportées au GBFS ont permis de l’ancrer dans le présent. Bien qu’il soit toujours possible de faire plus, de faire mieux, savoir qu’il est possible de représenter de manière standardisée tous les services de mobilité partagée à travers le monde est un pas de géant au service des voyageurs. Aujourd’hui, nous avons besoin que les villes exigent des données de qualité, que les opérateurs les produisent, que les planificateurs de trajets et les applications de mobilité les consomment et facilitent leur intégration.
Continuant son soutien à la communauté GBFS, MobilityData travaille sur de nouveaux outils et de nouvelles ressources pour tous. Suivez-notre actualité ou, encore mieux, rejoignez-nous sur Slack !
