Print Friendly, PDF & Email

Une telle porte centrale vers les acteurs du marché facilite l'ajout d'autres parties ou applications à la chaîne, également connue sous le nom de MaaS - Mobility As A Service. Néanmoins, de nombreux obstacles doivent encore être surmontés pour qualifier le protocole de mature. Tomp était peut-être un peu trop développé par les techniciens. Il manque des liens importants avec le transport en chaîne étroite et cela est de plus en plus évident maintenant que tout le monde veut adopter Tomp pour la mise en œuvre. L'API TOMP (Transport Operator to Mobility Provider-Application Programming Interface) est une interface standardisée et technique interface entre les prestataires de services MaaS et les opérateurs.

qu'est-ce qu'un lien?

Comparez un lien logiciel entre deux parties mais avec l'utilisation de Google Translate. Vous l'envoyez sur le côté gauche et il sort dans une autre langue sur le côté droit. Mais comme c'est souvent le cas avec Google Translate, ce qui ressort à droite, il vaut mieux ne pas assumer complètement comme vérité et l'utiliser ou le publier de manière inappropriée. Et c'est exactement ce qui manque à de nombreux liens. Il n'y a pas de norme, disons un processus de traduction correct, et le résultat après chaque traduction est ouvert à l'interprétation par l'utilisateur. Il est grand temps de conclure des accords et une norme. Récemment, nous avons vu le dictionnaire pour le transport du groupe cible de la plateforme de connaissances CORBEAU émergent ce qui devrait décrire les caractéristiques du voyageur. Un bon début, mais nous en sommes encore loin. 

un morceau d'histoire

Critique ou pas, il faut écrire que l'API Tomp a fait plus dans le secteur des taxis que tout ce qui l'a précédé. Qu'est-ce qui a mal tourné dans le passé? Les fournisseurs de systèmes logiciels ont créé à plusieurs reprises leurs propres liens pour rendre un client heureux. Chacun avait sa propre vision et surtout ne voulait pas s'appuyer sur ce qui existait déjà. L'idée était un plan strict pour attirer le marché. Il n'est toujours pas question d'une norme ouverte dirigée par le secteur lui-même. Un nouveau lien émerge de chaque appel d'offres, si bien que nous disposons désormais d'une palette de logiciels à maintenir. Mais ce qui est pire, l'innovation est freinée par toutes les limites de «l'ancien» modèle de communication existant entre les parties.

Lire aussi  Vision d'avenir : comment KNV relève les défis de demain

L'association sectorielle KNV, qui, en tant que tournant innovant dans sa politique, veut être leader dans tout ce qui utilise le MaaS comme facteur de connexion, a également été coupable spaghetti de liens. Bien que disposant de son propre comité d'innovation, où des propositions ont été régulièrement soumises au cours des 10 dernières années pour s'attaquer à ce problème, ils ne sont pas allés plus loin que ce que chaque «groupe de soutien» a fait ces dernières années. Occasion manquée, aucune norme ou protocole ne s'est présenté. Raison de plus pour aller de l'avant et rendre TOMP adapté au secteur. 

caractéristiques des voyageurs

Malheureusement, l'API Tomp n'est actuellement pas encore adaptée pour desservir toutes les facettes du transport en taxi. Il manque encore de système de rendez-vous. Pas sur le plan technique, au contraire, chapeau bas. Mais il reste encore beaucoup à faire en termes de caractéristiques des passagers, d'accords budgétaires et de déplacements de chaudières impliquant un taxi. Cela ne veut pas dire que c'est une occasion manquée, car le groupe de travail Tomp fait tout ce qu'il peut pour en faire un succès et écoute principalement les signaux des opérateurs et des acteurs du marché.

Il s'est écoulé longtemps avant l'avènement d'un lien universel dans le secteur du taxi. Le besoin de connecter des centrales électriques existe depuis 20 ans, mais chaque entreprise de TIC a inventé sa propre roue. Le train bat maintenant son plein avec toutes sortes de roues différentes. Les coûts de maintenance de tous ces systèmes montent en flèche.

De écraser Le groupe de travail doit maintenant considérer ce qui est réellement techniquement nécessaire pour réaliser une réservation et ce que les mutuelles doivent organiser elles-mêmes. Un produit de budget alloué à un voyageur par un fournisseur de budget en est un bon exemple. Toutes les caractéristiques du voyageur qui sont enregistrées dans le compte du voyageur, telles que le type de produit budgétaire, le numéro d'autorisation, la période de validité et une référence aux termes et conditions et aux conditions de voyage, ne peuvent pas être trouvées dans l'API Tomp, alors qu'elles sont une partie essentielle de la réservation. Mais d'autres facteurs entrent en jeu, comme la législation sur la protection de la vie privée, où de nombreuses innovations ont atteint leur paroxysme ces dernières années.

Lire aussi  Vision d'avenir : comment KNV relève les défis de demain

Le groupe de travail Tomp est un partenariat public-privé entre les fournisseurs MaaS, les opérateurs de transport, d'autres organisations liées à la mobilité et les gouvernements. Le groupe de travail est convaincu que la version Dragonfly de l'API est désormais stable pendant une période plus longue. L'échange de données via le Tomp comprend toutes les informations relatives à la planification, la réservation, la réservation, le paiement et l'assistance au voyage.

Lire aussi: TOMP doit mettre fin aux spaghettis de connexions

Pack de planification Pitane Mobility également pour les travailleurs à domicile