API de taxi de la ville de Montréal

Image :

Description en une ligne : API de taxi de la ville de Montréal

Description :

Ce que fait l'API

La ville de Montréal offre une API pour faciliter la commande de taxis à Montréal et permettre la possibilité de nouvelles innovations avec les applications de transport multimodal. Plus précisément, cet API trouve le taxi le plus près du point de départ d'un trajet, donne une estimation de l'heure à laquelle ce taxi pourra venir chercher l'utilisateur, donne une estimation du prix pour effectuer le trajet, et donne des indications pour contacter la compagnie de taxi.

L'API se base sur la spécification GTFS-OnDemand, aussi appelée GOFS, que l'on peut trouver ici.

Limitations de l’API

L’API ne permet pas de connaître la position des taxis dans la ville. Le registre de taxi connaît la position de tous les taxis, mais il ne rend pas cette information publique. Cette information n'est pas publique à la fois pour assurer l'anonymisation des données, et pour donner une chance équitable à chaque opérateur de taxi d'être sélectionné.

Le pricing API donne toujours un résultat en temps réel. En d'autres mots, l'estimation du prix et de la durée du trajet se fait toujours uniquement pour l'instant même auquel l'API est appelé. Il n'est pas possible d'avoir des estimations pour un trajet que l'on voudrait effectuer plus tard dans la journée, voire un autre jour.

Intégration de l'API au Planificateur de la Fabmob

Pour intégrer l'API au Planificateur de la Fabmob, la Fabrique des Mobilités Québec a conçu un proxy qui se place entre le frontend et OpenTripPlanner. Celui-ci est utilisé pour faire le lien entre OpenTripPlanner et l'API de taxi.

Les étapes pour installer le planificateur sont indiquées sur autre page : Planificateur FabMob. Cette page donne aussi les liens pour accéder au code.

Description du proxy

Lorsque l'utilisateur sélectionne les fonctionnalités de taxi, le frontend appelle le proxy plutôt que d'appeler directement OpenTripPlanner. Le proxy appelle alors à la fois l'API de taxi et OpenTripPlanner. Il ajoute ensuite les informations de taxi à la réponse de OpenTripPlanner.

Le trajet de taxi est construit à partir d'un trajet de voiture. Pour ce faire, le proxy demande à OpenTripPlanner un trajet de voiture. Il modifie ensuite ce trajet afin de lui ajouter les informations de taxi fournies par l'API.

Utiliser un proxy nous évite d'avoir à modifier directement OpenTripPlanner. OpenTripPlanner est une application complexe, et le modifier aurait requis beaucoup plus de travail. Le modifier directement aurait également complexifié la tâche de le mettre à jour avec les améliorations apportées par la communauté.

Développements futurs

Trajets multimodaux et support natif par OpenTripPlanner

Le proxy utilisé en ce moment n'est pas très adapté à l'ajout de trajets multimodaux. Construire des trajets, c'est la tâche de OpenTripPlanner.

OpenTripPlanner a récemment ajouté la fonctionnalité Ride Hailing service. Cette fonctionnalité permet de prendre en compte, dans le calcul d’un trajet multimodal, le temps que prendra un service de taxi, de Uber ou de Lift, pour aller chercher l’utilisateur. En ce moment la fonctionnalité ne supporte que Uber, mais elle est conçue pour que d'autres API soient éventuellement supportés. Étant donné que l'API de taxi utilise le standard GOFS, il suffirait d'ajouter ce format au Ride Hailing service pour que l'API de taxi soit nativement supporté par OpenTripPlanner.

Il faut toutefois rappeler que l'API de taxi est conçu seulement pour donner des résultats en temps en réel. L'API n'est pas conçu pour fournir des estimations pour plus tard dans la journée. Cela signifie que, pour son utilisation optimale, le taxi ne devrait être proposé que pour la première étape des trajets multimodaux. Il faudra questionner la pertinence des estimations de l'API si l'on veut les utiliser pour la dernière étape d'un trajet ou bien les étapes intermédiaires.

Autres informations :