FR3084949A1 - Procede de generation d'un ensemble d'itineraires par une interrogation limitee de bases de donnees - Google Patents

Procede de generation d'un ensemble d'itineraires par une interrogation limitee de bases de donnees Download PDF

Info

Publication number
FR3084949A1
FR3084949A1 FR1857412A FR1857412A FR3084949A1 FR 3084949 A1 FR3084949 A1 FR 3084949A1 FR 1857412 A FR1857412 A FR 1857412A FR 1857412 A FR1857412 A FR 1857412A FR 3084949 A1 FR3084949 A1 FR 3084949A1
Authority
FR
France
Prior art keywords
routes
graph
transport
route
transport service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
FR1857412A
Other languages
English (en)
Inventor
Alienor DIDIER
Serena ROCCONI
Camille GARELLO
Florian BRIY
Lionel Perez
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Amadeus SAS
Original Assignee
Amadeus SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Amadeus SAS filed Critical Amadeus SAS
Priority to FR1857412A priority Critical patent/FR3084949A1/fr
Priority to US16/530,352 priority patent/US11676233B2/en
Publication of FR3084949A1 publication Critical patent/FR3084949A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/04—Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"
    • G06Q10/047—Optimisation of routes or paths, e.g. travelling salesman problem
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/26—Government or public services
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34—Route searching; Route guidance
    • G01C21/3407—Route searching; Route guidance specially adapted for specific applications
    • G01C21/343—Calculating itineraries, i.e. routes leading from a starting point to a series of categorical destinations using a global route restraint, round trips, touristic trips
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/29—Geographical information databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/953—Querying, e.g. by the use of web search engines
    • G06F16/9537—Spatial or temporal dependent retrieval, e.g. spatiotemporal queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06316—Sequencing of tasks or work
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • Databases & Information Systems (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Remote Sensing (AREA)
  • Development Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Game Theory and Decision Science (AREA)
  • Primary Health Care (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Educational Administration (AREA)
  • Automation & Control Theory (AREA)
  • Navigation (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Un procédé est fourni pour gérer une requête d'un client pour une origine/destination et/ou une heure de départ/d'arrivée. Des données sont collectées à partir de plateformes de fournisseurs de contenu et des graphes de services de transport, correspondant à des réseaux de transports publics, sont générés dont les nœuds représentent des arrêts dans un réseau de transport public correspondant et leurs bords internes représentent des correspondances. Un graphe de correspondances incluant les graphes de services de transport est généré. Des nœuds d'origine/destination sont sélectionnés dans les graphes de correspondances ainsi que des routes entre ces nœuds. À l'intérieur, des segments successifs pour une route correspondant à des correspondances de transport entre des nœuds d'un graphe de service de transport sont reliés. Des interrogations concernant le prix, la disponibilité, les horaires de départ/arrivée basés sur l'heure de départ/d'arrivée de la demande et la durée de voyage estimée pour un segment de route sélectionné sont envoyés aux plateformes de fournisseurs de contenu. Des réponses aux interrogations sont agrégées pour construire un ensemble d'itinéraires et pour renvoyer une offre comprenant cet ensemble au client.

Description

PROCÉDÉ DE GÉNÉRATION D’UN ENSEMBLE D’ITINÉRAIRES PAR UNE INTERROGATION LIMITÉE DE BASES DE DONNÉES
DOMAINE DE L'INVENTION
La présente invention concerne de façon générale la technologie de l'information et l'échange d'information. Plus spécifiquement, elle vise un mécanisme pour fournir des informations à des clients demandeurs à partir d'une pluralité de plateformes de fournisseurs de contenu en utilisant des normes d'échange de données.
CONTEXTE
EP 2 897 344 B1 concerne un système informatique pour interconnecter des clients demandeurs de contenu avec une pluralité de plateformes de fournisseurs de contenu offrant du contenu en utilisant des protocoles de communication spécifiques aux fournisseurs de contenu. Elle dispose d'un module d'exécution agencé pour mapper des formats de données spécifiques aux fournisseurs de contenu et des flux de messages spécifiques aux fournisseurs de contenu en formats de données et en flux de messages utilisés par l'interface du client. Par ailleurs, elle inclut une pluralité de plugiciels (plug-ins) liés au fournisseur de contenu. Chaque plugiciel lié à un fournisseur de contenu définit des règles pour un mappage entre les formats des données spécifiques au fournisseur de contenu et les flux de messages spécifiques au fournisseur de contenu pour au moins une de la pluralité des plateformes de fournisseurs de contenu ainsi que les formats des données et des flux de message utilisés par l'interface du client.
RÉSUMÉ DE L’INVENTION
Selon un premier aspect, il est fourni un procédé de gestion de requêtes de la part d’un client demandeur de contenu en interrogeant une pluralité de plateformes de fournisseurs de contenu. Une requête comprend une origine et une destination, et au moins une heure de départ et une heure d'arrivée. Le procédé comprend un graphe qui génère un processus mis en œuvre par un module de routes avant la réception d’une requête de la part du client demandeur de contenu.
Le procédé comprend par ailleurs un processus de sélection de routes effectué par le module de routes après réception de la requête du client demandeur de contenu et un processus de construction d'offre effectué par un module d’offre après la mise en œuvre du processus de sélection de routes. Le processus de génération de graphes comprend la collecte de données d'une pluralité de plateformes de fournisseurs de contenu et la génération d'une pluralité de graphes de services de transport. Chaque graphe de service de transport comprend une pluralité de nœuds et de bords internes qui connectent les nœuds. Les nœuds représentent des arrêts dans un réseau de transport public correspondant et les bords internes représentent des correspondances entre les arrêts. Le procédé comprend par ailleurs la génération d'un graphe de correspondances comprenant la pluralité des graphes de services de transport. Le processus de sélection de routes comprend la sélection d'un nœud d'origine et d'un nœud de destination dans le graphe de correspondances selon l'origine et la destination respectivement. Le processus de sélection de routes comprend par ailleurs la sélection d’une ou de plusieurs routes entre le nœud d'origine et le nœud de destination comprenant l’assemblage d’un nombre de segments successifs pour une route. Un segment est une correspondance de transport entre deux nœuds d'un seul graphe de service de transport par un ou plusieurs bords internes. Le processus de construction d'offre comprend l'envoi à une plateforme respective de fournisseur de contenu d'au moins une interrogation demandant un prix et une disponibilité d'un segment des routes sélectionnées par le processus de sélection de routes. L'interrogation comprend au moins une heure de départ et une heure d'arrivée du segment sur la base d'au moins une des heures de départ et des heures d'arrivée de la requête et sur la base de la durée estimée de voyage des segments précédents et suivants respectivement. Le processus de construction d'offre comprend par ailleurs l'agrégation de réponses provenant des plateformes de fournisseurs de contenu interrogées afin de construire un itinéraire pour chaque route sélectionnée, construisant ainsi un ensemble d'itinéraires et envoyant une offre comprenant l'ensemble des itinéraires au client demandeur de contenu.
Selon un second aspect, il est fourni un système informatique distribué pour gérer des requêtes d’un client demandeur de contenu en interrogeant une pluralité de plateformes de fournisseurs de contenu. Chaque plateforme de fournisseur de contenu est associée à au moins un réseau de transport public et offre un contenu de transport. Le système informatique distribué est agencé pour collecter des données associées à la pluralité des plateformes de fournisseurs de contenu. Le système informatique distribué est par ailleurs agencé pour générer un nombre de graphes représentant des corrélations des données collectées et pour stocker au moins un graphe sur au moins un dispositif de stockage. Le système informatique distribué comprend une interface client agencée pour échanger des messages orientés-itinéraire avec le client demandeur de contenu. Le système informatique distribué comprend par ailleurs un module de routes qui est agencé pour collecter les données associées à la pluralité des plateformes de fournisseurs de contenu et pour générer au moins un graphe de service de transport et un graphe de correspondances représentant les corrélations des données collectées avant la réception d'une requête du client demandeur de contenu, dans lequel ledit au moins un graphe de service de transport comprend des bords internes. Le module de routes est par ailleurs agencé pour sélectionner une ou plusieurs routes du graphe de correspondances après la réception de la requête du client demandeur de contenu comprenant l'assemblage d'un nombre de segments successifs pour une route. Un segment est une correspondance de transport entre deux nœuds dun seul graphe de service de transport par un ou plusieurs bords internes. Le système informatique distribué comprend par ailleurs un module d'offre agencé pour obtenir les routes sélectionnées et pour interroger au moins une plateforme de fournisseur de services sur un prix et une disponibilité pour au moins un segment des routes sélectionnées. Le module d'offre est par ailleurs agencé pour agréger des réponses de ladite au moins une plateforme de fournisseur de contenu interrogée afin de construire un itinéraire pour chaque route sélectionnée construisant ainsi un ensemble d'itinéraires. Le système informatique distribué est par ailleurs agencé pour envoyer 1 ensemble des itinéraires au client demandeur de contenu via l'interface client sous la forme d'une offre.
Selon un troisième aspect, il est fourni un produit-programme d'ordinateur comprenant des instructions de code de programme stockées sur un support lisible par ordinateur pour mettre en œuvre les étapes du procédé selon le premier aspect lorsque ledit programme fonctionne sur un ordinateur.
DESCRIPTION GÉNÉRALE, ÉGALEMENT D’EXEMPLES SUPPLÉMENTAIRES
Un client demandeur de contenu, p. ex. un consommateur final utilisant une application sur un dispositif portable, tel que par exemple un smartphone, un ordinateur portable ou autre dispositif de ce genre, demande l'affichage d’un ensemble d'itinéraires de son côté. Le client détermine une tâche devant être résolue par le présent procédé. Pour cette tâche, le client, p. ex.
un utilisateur détermine une origine qui pourrait être le lieu actuel de l'utilisateur et une destination qui pourrait être un arrêt intermédiaire au cours du voyage ou un arrêt final, par exemple un hôtel où l'utilisateur veut passer ses vacances. De cette façon, une requête comprend une origine et une destination. La requête du client comprend par ailleurs au moins une heure de départ et une heure d'arrivée.
Une requête du client demandeur de contenu est gérée en interrogeant une pluralité de plateformes de fournisseurs de contenu, chacune peut être associée à au moins un réseau de transport public. Un réseau individuel de transport public est géré par un opérateur de transport, par exemple la SNCF, Air France, DB, MVV (le système de transport public de Munich), Trenitalia ou autre opérateur de ce genre. Les graphes de services de transport sont générés en connectant des données de routes associées à des plateformes de fournisseurs de contenu et en stockant les données dans une ou plusieurs bases de données de graphes.
Le procédé comprend un processus de génération de graphes effectué par un module de routes avant la réception d'une requête de la part du client demandeur de contenu, un processus de sélection de routes effectué par le module de routes avant la réception de la requête du client demandeur de contenu et un processus de construction d'offre effectué par un module d'offre après la mise en œuvre du processus de sélection de routes.
L’ensemble des itinéraires qui est ensuite calculé et transmis au client pour affichage peut être classé selon un ou plusieurs paramètres, c.-à-d. que tous les itinéraires commençant à l'origine sélectionnée et se terminant à la destination sélectionnée ne sont pas calculés et transmis par la suite au client.
Seule une sélection d'itinéraires est envoyée au client demandeur de contenu. En fait, seule une sélection limitée d’itinéraires de la pluralité des itinéraires possibles est calculée. Les itinéraires contiennent des Informations de routes, p. ex. des routes possibles ou des trajectoires par lesquelles on pourrait se rendre de A à B, des informations d'horaires, ainsi que des informations de prix, p. ex. combien coûterait le déplacement de A à B, qui pourraient varier en fonction du temps de voyage.
Le processus de génération de graphes effectués avant la réception d'une requête de la part du client demandeur de contenu comprend la collecte de données à partir de la pluralité des plateformes de fournisseurs de contenu. Les plateformes de fournisseurs de contenu peuvent être fournies par les opérateurs de transport ou peuvent autrement être fournies par un tiers qui gère les données de routes d’un ou de plusieurs opérateurs de transport.
Le procédé comprend la génération d'une pluralité de graphes de services de transport. Chacun de ces graphes de service de transport correspond à un réseau de transport public géré par un opérateur de transport avec un mode de transport donné, par exemple « avion », « train », « autobus ». Pour fournir un exemple, deux compagnies aériennes opérant dans le même aéroport sont des opérateurs de transport d'un même mode de transport.
Les graphes de services de transport sont générés en connectant des données de routes associées à des plateformes de fournisseurs de contenu et en stockant les données dans une ou plusieurs bases de données de graphes. Une base de données de graphes est une base de données qui utilise des structures de graphe pour des interrogations sémantiques avec des nœuds, des bords et des propriétés pour représenter et stocker les données. Un concept d'un tel système est que le graphe (ou le bord ou la relation) est directement lié à des éléments de données. Les relations permettent aux données dans la base de données d'être reliées ensemble directement et dans beaucoup de cas permettent aux données d’être récupérées eu une seule opération.
Chaque graphe de service de transport comprend une pluralité de nœuds et de bords internes qui connectent les nœuds, dans lequel les nœuds représentent des arrêts dans un réseau correspondant de transport public et les bords internes représentent des correspondances avec le mode de transport donné entre les arrêts ; Les arrêts correspondent donc, à différentes gares de train, par exemple d'un réseau de rail desservi par un opérateur de transport particulier, tel que DB ou la SNCF.
Chaque nœud d'un graphe de service de transport peut être atteint par au moins un des autres nœuds par l'intermédiaire d'un ou de plusieurs bords internes. Ceci signifie que les graphes de services de transport sont, au sens mathématique, des graphes fermés.
Le procédé comprend par ailleurs la génération d'un graphe de correspondances comprenant la pluralité des graphes de services de transport. Le graphe de correspondances est ainsi composé d'une pluralité de graphes de services de transport, chacun représentant un réseau individuel de transport public géré par un opérateur de transport.
Le processus de sélection de routes comprend la sélection d’un nœud d'origine et d’un nœud de destination dans le graphe de correspondances. Le nœud d'origine représente un arrêt qui est associé à une origine de voyage. L’origine de voyage telle qu'elle est demandée par un client n'est habituellement par la même que l'arrêt associé à l'origine de voyage. L'origine de voyage pourrait par exemple être située à une adresse de rue particulière ou à un lieu d'intérêt, p. ex., la “Sagrada Familia”, alors que l’arrêt associé à l'origine de voyage pourrait être une station de métro à proximité de cette adresse ou de ce lieu d'intérêt, dans cet exemple, la « station de Métro Sagrada Familia”. Le même principe s'applique pour la destination de voyage et l'arrêt associé à la destination de voyage.
Les arrêts associés à l’origine et à la destination de voyage sont représentés par les nœuds des graphes de services de transport et donc par les nœuds du graphe de correspondances.
La sélection d'une ou de plusieurs routes entre le nœud d'origine et le nœud de destination comprend l'assemblage d'un nombre de segments successifs pour une route. Un segment est une correspondance de transport entre deux nœuds d’un seul graphe de sendee de transport par un ou plusieurs bords internes. Plus spécifiquement, un segment est une correspondance de transport entre deux nœuds d'un seul graphe de sendee de transport par un ou plusieurs bords internes dudit seul graphe de service de transport. À titre d'exemple, un segment de route d'un nœud d'origine, la « station de Métro Sagrada Familia », vers le nœud de destination, la « station de Métro Bradenburger Tor », est un bord interne entre le nœud « aéroport de Barcelone » vers le nœud « aéroport de Paris » qui est associé au mode de transport « aérien ». Dans certains modes de réalisation, plusieurs réseaux individuels de transport public avec des modes de transport différents, mais similaires, sont gérés par le même opérateur de transport, p. ex., MW gère les métros, les bus, les tramways. Par conséquent, un segment de service de transport géré par un opérateur de transport peut comprendre plusieurs segments avec des modes de transport congénèriques.
Le processus de construction d'offre comprend l’envoi d'au moins une interrogation demandant au moins une donnée horaire, une donnée de prix et une donnée de disponibilité pour un segment des routes sélectionnées au cours du processus de sélection de routes vers une plateforme respective de fournisseur de contenu.
Les données de prix et les données de disponibilité pour les routes sélectionnées sont collectées à partir des plateformes qui fournissent le contenu, p. ex., à partir de bases de données dédiées à la tarification. L'interrogation est par exemple une interrogation de base de données telle qu'une interrogation SQL ou autre interrogation de ce genre.
L'interrogation pour des données horaires comprend au moins une heure de départ et une heure d’arrivée du segment sur la base d'au moins une des heures de départ et des heures d'arrivée de la requête et sur la base de la durée estimée de voyage des segments précédents et suivants respectivement.
Aussi, une interrogation relative aux heures de départ et d'arrivée est faite, par exemple, aux plateformes de fournisseurs de contenu, p. ex. directement à partir des pages d'accueil ou des bases de données dédiées des services de transport associés. Dans certains exemples, les données d'horaires détaillées peuvent être interrogées pour deux à cinq routes qui sont les seules routes restantes à la fin du processus de sélection de routes. Dans certains autres exemples, il peut y avoir davantage de routes restantes et une interrogation est faite concernant les prix/disponibilité ainsi que les horaires de départ et d'arrivée pour toutes ces routes.
Puisque l'interrogation concernant les données d'horaires n’est effectuée que pour les routes sélectionnées, d'autres routes peuvent être écartées réduisant le nombre d'interrogations à la plateforme respective de fournisseur de contenu.
L'heure de départ du premier segment de route est collectée conformément à une heure de départ associée à la requête de contenu du client demandeur à partir d'au moins une de la pluralité des plateformes de fournisseur de contenu. Cela signifie que pour le segment de route commençant au nœud d'origine, l'horaire de départ faisant l'objet d'une interrogation pour ce segment doit être proche de l'heure de départ, du voyage dans sa globalité, demandée par le client demandeur de contenu.
De façon générale, l’heure de départ et l'heure d'arrivée des segments sont basées sur l'heure de départ et l'heure d’arrivée de la requête et sur une durée estimée de voyage des segments précédents et suivants respectivement.
Puisque la durée estimée de voyage pour chaque segment précédent et suivant est connue, une heure de départ/heure d'arrivée estimée peut être obtenue pour chaque segment. De cette façon, l'heure de départ pour, p. ex. le deuxième segment d'une route, peut être obtenue en additionnant la durée estimée de voyage du premier segment à l'heure de départ du premier segment faisant l'objet d'une interrogation à la plateforme de fournisseur de contenu associée au premier segment.
Par conséquent, les interrogations pour les horaires de départ et/ou d'arrivée associés à un segment spécifique ne sont nécessaires que pour les horaires proches des horaires de départ/d'arrivée du segment, calculés sur la base de l'heure de départ/d’arrivée de la requête et des durées estimées de voyage des segments précédents et suivants.
Correspondant à l'heure de départ faisant objet d'une interrogation pour le segment commençant au nœud d'origine, l'heure d'arrivée faisant l'objet d'une interrogation pour le segment se terminant au nœud de destination doit rester proche de l'heure d'arrivée demandée pour le voyage dans sa globalité.
Dans certains exemples, la durée estimée de voyage des segments est déterminée par le module de routes, par conséquent le (logiciel) module qui met en œuvre le processus de génération de graphes.
Le nombre d'interrogations adressées aux plateformes de fournisseurs de contenu est par ailleurs réduit car les interrogations relatives au prix/disponibilité ne se font que pour l’heure d'arrivée/heure de départ calculée sur la base de l'heure de départ/d'arrivée de la requête et lesdites durées estimées de voyage pour les segments suivants et précédents.
Les données tarifaires peuvent faire l'objet d'une interrogation parallèlement avec les données d'horaires ou autrement une interrogation pour les données tarifaires peut être effectuée au cours d'une activité subséquente. Une procédure parallèle d'interrogation de données pourrait achever la tâche plus rapidement, cependant les données tarifaires peuvent varier en fonction de l'heure exacte à laquelle un segment doit être complété. Un billet de train pendant les heures de grande affluence, c.-à-d. une heure à laquelle beaucoup d'individus, p. ex. des travailleurs essayant de rejoindre leur lieu de travail, utilisent le sendee de transport, peut être beaucoup plus cher qu'un billet de train sur la même route quelques heures plus tard lorsque le trafic est réduit sur ce segment particulier de la route.
Dans certains exemples, une pluralité d’interrogations associées à un ou plusieurs segments, 5 adressées <1 une seule plateforme de fournisseur de contenu, sont groupées en une seule interrogation à la plateforme respective de fournisseur de contenu.
Le processus de construction d offre comprend par ailleurs l'agrégation des réponses provenant des plateformes de fournisseurs de contenu interrogées afin de construire un itinéraire pour 10 chaque route sélectionnée. Ainsi, un ensemble d'itinéraires est construit.
En agrégeant les réponses, l'heure de départ/heure d'arrivée et le prix correspondant sont collectés pour chaque segment. Ces données collectées sont utilisées pour générer les itinéraires finals. Ceci est fait en assemblant les données collectées pour chaque segment suivant des routes 15 sélectionnées.
En d autres termes, une route sélectionnée avec des segments pour lesquels un prix et des horaires de départ et d'arrivée respectifs sont associés, forme un itinéraire. Un ensemble avec un itinéraire pour chaque route qui a été sélectionnée au cours du processus de sélection de 20 routes forme un ensemble d’itinéraires.
Une offre comprenant 1 ensemble d'itinéraires est envoyé au client demandeur de contenu — comme réponse à la requête provenant du client demandeur de contenu. Par exemple ceci se fait via une interface client.
Dans certains exemples, la génération du graphe de correspondances comprend la connexion d un premier nœud d'un premier graphe de service de transport et d'un deuxième nœud d'un deuxième graphe de service de transport, en réponse au fait que le premier nœud et le deuxième nœud représentent des arrêts situés à une courte distance à pied l'un de l'autre et appartiennent 30 à des modes de transport différents, comme par exemple le bus et le rail.
Par conséquent, les graphes de services de transport sont interconnectés à l'intérieur du graphe de correspondances par un bord connecteur qui représente une option pour changer d'un premier réseau de transport, géré par le premier opérateur de transport, à un deuxième réseau de transport, géré par le deuxième opérateur de transport. Les réseaux de transport respectifs sont représentés par les graphes respectifs de service de transport compris dans le graphe de correspondances. L'option de changer via le bord connecteur représente parcourue à pied la distance entre les deux arrêts représentés par les nœuds respectifs des graphes de services de transport. Les opérateurs de transport peuvent avoir connaissance des arrêts qui peuvent être connectés par une distance parcourue à pied acceptable sur la base des données d'expérience du voyageur.
A titre d'exemple, un nœud dans un graphe de service de transport représentant une station de tramway qui est un arrêt dans un réseau de fournisseur de transport urbain peut être connecté à un nœud représentant une gare de train qui est un arrêt dans un réseau de fournisseur de transport par rail, par un bord connecteur dans le graphe de correspondances, si la station de tramway et la gare de train sont situées à quelques pas l'une de l'autre.
On peut supposer qu'une distance entre deux arrêts peut être parcourue à pied, par exemple, si les deux arrêts sont séparés l'un de l'autre par moins de mille mètres. Dans certains exemples, la distance actuelle couverte par un bord connecteur peut excéder une distance moyenne de marche d'environ un ou deux kilomètres et implique qu'un train, un bus ou une autre mode de transport dédié aide les voyageurs à atteindre leurs correspondances dans un délai imparti.
Dans certains exemples, la génération du graphe de correspondances comprend la fusion d’un troisième nœud d'un troisième graphe de service de transport et d'un quatrième nœud d'un quatrième opérateur de transport en réponse au fait que le troisième nœud du troisième graphe de service de transport et le quatrième nœud du quatrième opérateur de transport appartiennent au même mode de transport, ayant la même position géographique.
Dans certains modes de réalisation, le troisième nœud du troisième graphe de service de transport peut être le même nœud que le premier nœud du premier graphe de service de transport. Réitéré différemment, un nœud d'un graphe de service de transport peut être fusionné avec un autre nœud d'un graphe de service de transport différent et en même temps, ce nœud est connecté à un bord connecteur à un énième autre nœud d'un énième autre graphe de service de transport.
À titre d'exemple, un graphe de service de transport pour DB et un graphe de service de transport pour la SNCF sont des nœuds de graphes de service de transport du même mode de transport. Ainsi, p. ex. à Strasbourg, où la gare centrale de trains est desservie par DB ainsi que par la SNCF, le nœud représentant la gare centrale de Strasbourg dans le graphe de service de transport pour DB et le nœud respectif représentant la gare dans le graphe de service de transport pour la SNCF sont fusionnés dans le graphe de correspondances qui comprend les deux graphes de services de transport.
Dans certains exemples, la sélection d’une ou de plusieurs routes comprend un classement de ladite une ou plusieurs routes selon au moins un paramètre de routage, dans lequel ledit au moins un paramètre de routage comprend la durée de voyage estimée pour au moins un des segments d'une route sélectionnée.
Lorsqu un client renvoie une requête, les routes sont classées selon un ou plusieurs paramètres de routage. Dans certains exemples, ledit au moins un paramètre de routage comprend la durée estimée de voyage, car dans tous les cas, le but est de fournir une sélection de routes avec des routes classées en fonction de leur durée estimée de voyage. La durée estimée globale de voyage pour une route est calculée, par exemple comme une somme de toutes les durées estimées de voyage pour des segments de la route ainsi que tous les temps de correspondance entre deux segments subséquents de la route.
Dans certains exemples, ledit au moins un paramètre de routage comprend une fréquence d options de transport pour au moins un segment d’une route sélectionnée. La fréquence des options de transport indique combien de fois une partie de la route est desservie par un opérateur de transport public (p. ex. une fois toutes les heures, 3 fois par jour, etc.)
Dans certains exemples, ledit au moins un paramètre de routage comprend un .temps minimum de correspondance entre deux segments subséquents, une distance de voyage d'une route, un nombre d’opérateurs de transport, et autres informations de ce genre.
Dans certains exemples, un temps minimum de correspondance entre segments, les services de transport, ou autres éléments de ce genre peuvent être, de surcroît, ajustables individuellement par un paramètre de préférence d'un utilisateur. Les personnes âgées, peuvent par exemple vouloir augmenter le temps de correspondance minimum entre des segments subséquents car elles sont souvent plus lentes à se déplacer que le voyageur lambda pour qui le calcul du temps de correspondance est habituellement effectué, ou un passager arrivant dans un aéroport, par exemple, peut avoir besoin de temps supplémentaire pour effectuer d'autres actions telles que des procédures d'enregistrement et autres actions de ce genre.
Les heures d'arrivée/départ associées aux segments de routes sont par exemple choisies qu’un temps de correspondance donné entre l'heure de départ d’un deuxième (subséquent) segment et l'heure d'arrivée du premier (précédent) segment est retenu, De cette façon, on peut s'assurer qu'il y a par exemple au moins 10 minutes de temps de correspondance entre deux segments subséquents.
Les deux arrêts les plus proches de l'origine et de la destination données dans la requête du client sont respectivement sélectionnés dans le graphe de correspondances, c.-à-d. un nœud d'origine et un nœud de destination sont déterminés dans le graphe de correspondances sur la base de la localisation relative de l'origine et de la destination données par rapport aux arrêts disponibles de tous les opérateurs de transport disponibles.
Par la suite, des routes différentes commençant au nœud d'origine et se terminant au nœud de destination sont récupérées à partir du graphe de correspondances. Par conséquent, les bords du graphe de correspondances sont traversés du nœud d’origine au nœud de destination. Les routes ainsi obtenues peuvent ensuite être optimisées en fonction d'un ou de plusieurs paramètres de routage.
Les routes peuvent être ensuite classées sur la base des paramètres de routage donnés en utilisant l'algorithme de Martin. Typiquement, par exemple, des données supplémentaires pour former un itinéraire, telles que l'heure de départ/l'heure d'arrivée des segments des routes et les données de prix respectives, ne sont interrogées que pour seule une fraction des routes classées (p. ex. les dix premières routes du classement).
Dans certains exemples, la sélection d'une ou de plusieurs routes comprend de sélectionner des routes avec au moins une durée de voyage minimale estimée et une fréquence maximale d'options de transport.
Dans certains exemples, le processus de sélection comprend de sélectionner des routes avec une durée estimée minimale de voyage et de sélectionner des routes avec une fréquence maximale d’options de transport. Le classement a pour but, par exemple, de trouver des routes qui globalement (d'un nœud d'origine à un nœud de destination) ont une fréquence maximum d’options de transport et un temps de voyage estimé minimum. Le résultat de ce classement n’est pas, par exemple, une seule route optimale avec une durée estimée de voyage minimum et la fréquence maximum d'options de transport, mais c'est un ensemble de routes qui comprennent un nombre de routes donné avec des durées estimées de voyage et une fréquence d'options de transport qui sont plus hauts dans le classement par rapport à ces critères que d’autres routes.
Dans certains exemples, le processus de génération de graphes comprend par ailleurs la génération d'un métagraphe comprenant une pluralité de nœuds de métagraphe et de bords de métagraphe, dans lequel chaque nœud de métagraphe représente un graphe de service de transport et les bords du métagraphe représentent des options de changement d’un premier réseau de transport public associé à un premier graphe de service de transport à un deuxième réseau de transport public associé à un deuxième graphe de services de transport.
Le métagraphe est généré par exemple sur la base du graphe de correspondances en mappant chaque graphe de service de transport à un nœud et en mappant chaque bord connectant un premier graphe de service de transport à un second graphe de services de transport, c.-à-d. des bords qui connectent un nœud d'un premier graphe de service de transport à un nœud d'un deuxième graphe de services de transport, à un bord du métagraphe.
Le métagraphe et le graphe de correspondances sont par exemple stockés tous les deux sur des dispositifs de stockage du système informatique distribué sur lequel le processus est mis en œuvre. Ils peuvent être stockés sur les mêmes dispositifs de stockage ou sur des dispositifs de stockage différents.
Au cas où un nœud serait compris par un premier graphe de service de transport et par un deuxième graphe de service de transport (par conséquent un nœud fusionné comme décrit cidessus), ce qui est le cas si les deux graphes de service de transport sont associés au même mode de transport et que les deux nœuds représentent des arrêts ayant une même situation géographique, ce nœud commun des graphes de services de transport est par exemple compris une fois par le nœud du métagraphe représentant le premier graphe de service de transport et compris une fois par le nœud du métagraphe représentant le deuxième graphe de service de transport.
S’il s'avère que les nœuds du premier et du deuxième graphe de service de transport représentent des arrêts situés à une distance à pied l'un de l'autre, ils sont connectés par un bord de connexion dans le graphe de correspondances comme décrit ci-dessus. Une telle connexion est mappée sur le métagraphe, par exemple, en mappant chaque bord de connexion à un bord correspondant du métagraphe.
Les bords du métagraphe représentent donc, par exemple, des options de changement entre un premier opérateur de transport et un deuxième opérateur de transport. C’est par exemple, un changement d’« Air France » pour « Lufthansa » ou un changement de «Lufthansa » pour la « SNCF ». L'option de changement entre les graphes de service de transport «Lufthansa » et la 15 « SNCF » est par exemple représentée par un bord de connexion mappé sur le métagraphe si arrêt dans le réseau «Lufthansa » et l'arrêt dans le réseau « SNCF » sont situés à une distance à pied l'un de l'autre.
Dans certains exemples, le métagraphe comprend des données relatives à au moins un des 20 nœuds et des bords du graphe de correspondances.
La sélection du premier et du deuxième nœud comprend, par exemple, l'identification des nœuds du métagraphe qui sont associés au nœud d'origine du graphe de correspondances et au nœud de destination du graphe de correspondances, respectivement. Pour permettre cette 25 identification, chaque nœud du métagraphe comporte des données indiquant quel nœud du graphe de correspondances est compris dans quel nœud du métagraphe. Ceci est accompli par exemple, en fournissant une liste avec des arrêts (correspondant aux nœuds du graphe de correspondances) associés à un nœud de métagraphe, pour chaque nœud de métagraphe.
Le métagraphe comprend aussi, par exemple, des données concernant les bords du graphe de correspondances, telles que le nombre de bords (concordant avec les intercorrespondances) dans un graphe de service de transport représenté par un nœud de métagraphe
Dans certains exemples, la selection de ladite une ou plusieurs routes comprend l'application d un algorithme d optimisation de trajectoire à au moins un du graphe de correspondances et du métagraphe.
Les bords d au moins un du graphe de correspondances et du métagraphe sont pondérés selon au moins un des paramètres de routage afin d’appliquer l'algorithme d'optimisation de trajectoire.
Par exemple, lorsque 1 algorithme d optimisation de trajectoire est appliqué au graphe de correspondances, chaque segment représenté par un bord d'un graphe de service de transport compris est pondéré selon la durée estimée de voyage pour ce segment et peut de surcroît être pondéré également selon d'autres paramètres de routage comme, par exemple, la fréquence d'options de transport susmentionnée.
De façon similaire, les bords du métagraphe pourraient être pondérés selon ledit au moins un paramètre de routage.
Dans certains exemples, la selection de ladite une ou plusieurs routes comprend donc la formation d une ou de plusieurs metaroutes en traçant des trajectoires le long de nœuds successifs du métagraphe comprenant le nœud d'origine jusqu'au nœud du métagraphe comprenant le nœud de destination. Le traçage des trajectoires le long des nœuds successifs du métagraphe peut être réalisé en appliquant un algorithme d’optimisation de trajectoire sur le métagraphe (pondéré).
La métaroute trouvée determine ainsi un ensemble de graphes de services de transport fournissant au moins un segment de la route ente le nœud d'origine et le nœud de destination. Ainsi que mentionné ci-dessus, ces graphes de services de transport sont compris dans le graphe de correspondances.
L algorithme d optimisation de trajectoire appliqué à au moins un du graphe (pondéré) de correspondances et du métagraphe (pondéré) peut être une variante de Martin de l'algorithme de Dijkstra.
En déterminant 1 ensemble des graphes de services de transport et en appliquant un algorithme d optimisation de trajectoire, le nombre de routes qui alimentent l'algorithme d'optimisation de trajectoire est réduit (autrement toutes les routes seraient traitées par cet algorithme). Ainsi, la puissance de traitement requise pour la sélection de routes est fondamentalement réduite.
Dans certains exemples, la sélection d'une ou de plusieurs routes comprend de déterminer au moins un d'un nœud d'entrée et d’un nœud de sortie d'un graphe de service de transport représenté par un nœud de métagraphe qui est englobé dans la métaroute.
Le nœud d'entrée d'un graphe de service de transport est par exemple, le nœud d'origine d'une route, mais pourrait aussi bien être un nœud de sortie d’un autre graphe de service de transport, lorsque les nœuds de deux graphes de service de transport sont fusionnés à des nœuds correspondant à des arrêts dans des graphes de services de transport ayant le même mode de transport et ayant la même position géographique. Un nœud d'entrée d'un graphe de service de transport pourrait aussi bien être un nœud d'un graphe de service de transport connecté à un nœud d'un autre graphe de service de transport par un bord connecteur, si les arrêts représentés par les nœuds sont situés à une distance à pied l’un de l'autre et ont des modes de transport différents, p. ex. un transport aérien et un transport urbain
Un nœud de sortie représente un arrêt permettant un changement à un arrêt correspondant à un nœud d’entrée d'un graphe de service de transport successif.
Dans certains exemples, la sélection de ladite une ou plusieurs routes comprend de tracer des trajectoires le long des bords internes à partir du nœud d'entrée jusqu'au nœud de sortie du graphe de service de transport.
Une fois que le nœud de sortie et les nœuds d'entree des graphes de services de transport, représentés par des nœuds de métagraphe englobés par la métaroute, sont obtenus, une correspondance (optimale) entre ces nœuds d'entrée et nœuds de sortie est recherchée. Ceci est accompli par exemple en pondérant les bords internes des graphes de services de transport respectifs selon ledit au moins un paramètre de routage et en appliquant un algorithme d optimisation de trajectoire sur le graphe de service de transport. De cette façon, par exemple, une trajectoire avec une durée estimée de voyage minimale et une fréquence maximum d'options de transport entre lesdits nœuds d'entrée et nœuds de sortie, est trouvée.
Une route entre un nœud d'origine et un nœud de destination comprend une pluralité de trajectoires entre les noeuds d'entrée et les nœuds de sortie des graphes successifs de services de transport représentes par des nœuds successifs du métagraphe de la métaroute obtenue.
Dans certains exemples, la sélection de ladite une ou plusieurs routes est basée sur un paramètre de préférence d'un utilisateur.
Dans certains exemples, les routes sont sélectionnées (aussi) sur la base d'un paramètre de 10 préférence d'un utilisateur, en particulier un paramètre de préférence d'un utilisateur concernant usage et/ou la prohibition de services de transport spécifiques disponibles pour les routes. De tels paramètres de préférences d'utilisateur pourraient par exemple être : « rail uniquement », « aucun vol », « aucun autobus » ou autre paramètre de ce genre,
Dans certains exemples, les routes qui ne sont pas conformes avec ledit au moins un paramètre de préférence d'un utilisateur sont écartées.
Lors de la sélection d'une ou de plusieurs routes entre le nœud d'origine et le nœud de destination, les routes qui ne sont pas conformes avec ledit au moins un paramètre de préférence 20 d utilisateur peuvent être écartées. Pour accomplir ceci, soit (i) la sélection de routes qui ne sont pas conformes avec ledit au moins un paramètre de préférence de l'utilisateur pourrait être évitées en amont (elles ne sont pas prises en considération dans la sélection) ou (ii) une sélection de routes est effectuée et les routes qui ne sont pas conformes aux paramètres de préférence de 1 utilisateur pourraient être rejetées de sorte qu'au final elles ne sont pas incluses lors de la 25 construction d itinéraires sur la base des routes sélectionnées.
Dans certains exemples, le processus de construction, d'offre comprend par ailleurs l'écartement d une route sélectionnée en réponse au fait qu'un segment de cette route est indisponible. Une route pourrait être déterminée comme étant « indisponible » si par exemple, des travaux de 30 maintenance sont effectués sur une section d'un réseau de rail ou d'un réseau de transport urbain ou si, par exemple, un vol est déjà complet. Alors que la route est écartée, aucun itinéraire n'est forme pour cette route est donc aucune offre relative a cette route n'est construite
Les ressources de calcul requises pour le traitement, décrit ci-dessus, des requêtes de clients i8 demandeurs de contenu sont réduites, en particulier, (i) la puissance de traitement pour la sélection de ladite une ou plusieurs routes et (ii) les taux de transfert de données pour construire ritinéraire, comparés aux procédés conformes à la technologie de pointe. Ainsi que décrit cidessus, le nombre de nœuds dans le graphe de correspondances devant être traité par l'algorithme d'optimisation de trajectoire pour la sélection de routes est réduit par une telle présélection de l'ensemble des graphes de services de transport, ce qui constitue un sous-graphe du graphe de correspondances. En outre, en écartant certaines des routes potentielles, par exemple des routes avec une durée de voyage élevée et/ou de nombreux changements, le nombre de routes faisant l'objet d'interrogations des bases de données est réduit. Le nombre d'interrogations adressées aux plateformes de fournisseurs de contenu est par ailleurs réduit car les interrogations relatives au prix/disponibilité ne se font que pour les heures d'arrivée/heures de départ calculées sur la base de l'heure de départ/d'arrivée de la requête et lesdites durées estimées de voyage pour des segments subséquents et précédents.
Un système informatique distribué avec un plusieurs processeurs et des mémoires non volatiles peut être utilisé comme base pour exécuter les activités décrites ci-dessus.
Lorsqu'un code de programme exécutable est exécuté par un processeur d'un système informatique distribué, le processeur amène le système à mettre en œuvre les activités décrites ci-dessus de la requête d'un client demandeur de contenu jusqu'à la génération d'une réponse sous la forme d’un ensemble d’itinéraires.
Dans certains exemples, le système informatique distribué comprend une interface fournisseur agencée pour échanger des messages orientés-itinéraire avec la pluralité des plateformes de fournisseurs de contenu.
Les informations d'heure de départ/d'heure d’arrivée, les informations de disponibilité et les données de prix peuvent être interrogées et agrégées à partir des plateformes foumisseuses de contenu via ladite une ou plusieurs un interfaces) fournisseur qui permettent que des requêtes/réponses soient envoyées par le système informatique distribué aux plateformes foumisseuses de contenu et vice versa.
Dans certains exemples, l'interface client est par ailleurs agencée pour communiquer avec un dispositif portable géré par un client demandeur de contenu.
La réponse sous forme d’un ensemble d'itinéraires est transmise au client demandeur de contenu via 1 interface client et est par la suite affichée sur l'écran du client, p. ex. l'ensemble des itinéraires est affiché à l'intérieur d'une application « Travel Companion» sur le dispositif portable d'un utilisateur, tel qu'un smartphone.
Par exemple, 100 routes potentielles peuvent être déterminées par le processus de sélection de routes. Pat la suite, certaines de ces 100 routes potentielles sont écartées en fonction du seuil (p. ex. plus de 3 changements). Le résultat peut être 30 routes formant l'ensemble réduit de routes. Par la suite, un ensemble d’itinéraires est généré sur la base de ces 30 routes. Ces itinéraires sont ensuite envoyés au client demandeur de contenu via l'interface client. Au moins certains de ces 30 itinéraires sont par la suite affichés sur un dispositif du client, p. ex. 10 à la fois, sur la base d'un réglage de classement pouvant être ajusté individuellement. Un tel réglage de classement pourrait être la route la plus courte, le prix le moins cher, le temps de voyage le plus court, le moins de changements entre les services de voyage, ou autre réglage de ce genre.
Par ailleurs, un programme informatique est fourni. Le produit programme d'ordinateur comprend des instructions de code de programme stockées sur un support lisible par ordinateur pour mettre en œuvre les étapes du procédé lorsque ledit programme fonctionne sur un ordinateur.
BRÈVE DESCRIPTION DES FIGURES
Des exemples de l'invention sont maintenant décrits également par référence aux dessins qui les accompagnent, dans lesquels
FIG.l est un diagramme bloc schématique d'un système distribué sur lequel un procédé de génération de graphes, de recherche de routes et de construction d’offre est effectué conformément à la requête d’un client ;
FIG. 2 montre le générateur d'itinéraire de la FIG 1 de façon plus détaillée ;
FIG. 3 a illustre de façon schématique un graphe de correspondances exemplaire et un métagraphe exemplaire ;
FIG. 3b illustre le traçage le long des bords d'un métagraphe exemplaire ;
FIG. 3 c illustre une route schématique d’un nœud d'origine à un nœud de destination, les deux nœuds sont compris par le graphe de correspondance exemplaire de la Fig. 2a;
FIG. 3d illustre un. résultat d'un processus exemplaire de génération de route et d'identification d’itinéraire ;
FIG. 4 est un extrait d'un code xml exemplaire, montrant l'information en cours de collection à partir d’une plateforme de fournisseur de contenu ;
FIG. 5a est un organigramme illustrant un procédé exemplaire pour la sélection de routes ;
FIG. 5b montre la dernière étape de l'organigramme illustré dans la Fig. 5a de façon plus détaillée ;
FIG. 6 est un organigramme illustrant le procédé de génération de graphes, de sélection de routes et de construction d'une offre ;
FIG. 7 montre la fusion d’interrogations adressées une seule plateforme de fournisseur de contenu ;
FIG. 8 illustre un système informatique exemplaire conforme aux serveurs de la FIG. 1 ;
FIG. 9 illustre un dispositif portable exemplaire.
Les dessins et la description des dessins sont des exemples de l’invention et ne représentent pas l’invention en elle-même. Des signes de référence similaires font référence à des éléments similaires tout au long de la description suivante des exemples.
DESCRIPTION DES EXEMPLES
Un diagramme bloc schématique d'un système distribué sur lequel un procédé de génération de graphes, de recherche de routes et de construction d'offre en fonction d'une requête d'un client - est montré dans la Fig. 1.
De façon générale, le procédé comprend un processus de génération de graphes 17, mis en œuvre avant une requête d’un client demandeur de contenu 2 Le processus de génération de graphes 17 est effectué par- un module de routes exemplaire 8 sur un serveur B. Le processus de génération de graphes 17 implique la construction d'un graphe de correspondances qui construit un graphe de correspondances basé sur des données de routes 13 associées aux plateformes des fournisseurs de contenu. Le constructeur de graphe de correspondances est mis en œuvre par le processus de génération de graphes 17. Une interrogation relative aux données de routes 13 est faite, par exemple, par le processus de génération de graphes 17 à partir d'une base de données 4 et est par la suite transférée de la base de données 4 à l'instance de module de routes exemplaire 8, comme indiqué par la ligne en tirets et la ligne pointiliée de la base de données 4 au processus de génération de graphes 17. Les données de routes 13 peuvent comprendre des informations concernant quels arrêts sont connectés les uns aux autres par des réseaux de transport public gérés par un opérateur de transport spécifique.
Le processus de génération de graphes 17 construit un graphe de correspondances 88 en mappant les arrêts des réseaux de transport public gérés par un opérateur de transport spécifique et les correspondances entre ces arrêts à des nœuds et des bords internes respectifs de ces graphes de services de transport, générant ainsi les graphes de services de transport. Ces graphes de services de transport sont connectés à des nœuds représentant des options de changement entre les réseaux représentés par les graphes pour former le graphe de correspondances 88. Le graphe de correspondances 88 est stocké après sa génération sur un dispositif de stockage 9.
Le processus de génération de graphes 17 est un processus à long terme qui consomme beaucoup de puissance de calcul. C'est pourquoi l'instance du module de routes exemplaire 8 fonctionne sur un serveur B et le graphe de correspondances est stocké sur un serveur C séparé du serveur D sur lequel fonctionne un module d'offre exemplaire 10. L'instance de module de routes 8 effectue au moins certains de ses processus sur la base de données, notamment les données de routes 13, récupérées à partir de la base de données 4 qui est hébergée sur un serveur A. Les serveurs A, B, C et D forment ensemble un système distribué 100.
Lors de la réception d'une requête de la part d'un client demandeur de contenu 2, via l'interface client 5, une réponse incluant un ensemble d'itinéraires 68 est créée et envoyée au client demandeur de contenu 2 au cours d'un processus de sélection de routes 18 et d'un processus de construction d’offre 19 mis en œuvre par un générateur d'itinéraire IL Une requête d'un client pourrait par exemple être : « de l'arrêt A (p. ex. « Sagrada Familia », à Barcelone) à l'arrêt B (p. ex. «Brandenburger Tor », à Berlin) le samedi 7 avril 2018 à 15 heures »).
Le générateur d'itinéraire 11 - montré de façon plus détaillée dans la Fig. 2 - met en œuvre ces processus. Le générateur d'itinéraire 11 fait appel à une instance du module de routes exemplaire 8 qui fonctionne sur un serveur D et à une instance du module d’offre exemplaire 10 qui fonctionne aussi sur un serveur D.
Un ensemble de routes 64 (montré dans la Fig. 2) est obtenu à partir du graphe de correspondances 88 par le processus de sélection de routes 18. Les routes sont sélectionnées au cours d'un processus de sélection de routes 18 qui requiert les données du graphe de correspondances du serveur C, comme indiqué par la flèche solide du processus de sélection de routes 18 vers le dispositif de stockage 9.
Dans le cadre du processus de sélection de routes 18, le ou les paramètre(s) de préférence de l'utilisateur 121, indiquant par exemple, quel mode de transport ne pas utiliser, sont pris en compte afin d'obtenir l'ensemble des routes 64 qui sont ensuite classées en fonction des paramètres de routage 122. Le processus de sélection de routes 18 est exécuté par une instance du module de routes 8.
L'ensemble des routes 64 est obtenu à partir du graphe de correspondances sur la base d'un métagraphe 99 (non illustré) comprenant des nœuds de métagraphe qui représentent les graphes de service de transport du graphe de correspondances 88. Dans le métagraphe 99 seuls les nœuds qui représentent les graphes de services de transport, pour lesquels un changement du réseau de transport public représenté un autre réseau de services de transport public représenté est possible, sont connectés. En traversant le métagraphe 99, une décision est prise concernant les réseaux de transport public qui doivent être utilisés pour le voyage de l'arrêt A à l'arrêt B, p.
ex. le réseau de transport urbain de Barcelone, le réseau d'Air France, et ensuite le réseau de transport urbain de Berlin. Par conséquent un sous-graphe 77 du graphe de correspondances 88 est extrait du graphe de correspondances 88 incluant tous les graphes de services de transport associés à ces réseaux de transport public.
Dans certains exemples, le métagraphe est également généré par le module de routes 8 sur le serveur B et est aussi stocké sur le dispositif de stockage 9 sur le serveur C (ceci n’est pas illustré dans les Figs. 1 ou 2). Dans d'autres exemples, le métagraphe peut être généré par un autre serveur (non illustré) et peut par la suite être stocké sur un dispositif de stockage supplémentaire 10 (non illustré).
Un classement de I ensemble des routes est effectué en appliquant un algorithme d'optimisation de trajectoire sur le sous-graphe 77 ou sur chacun des graphes de service de transport inclus dans le sous-graphe. Les paramètres de routage 122 selon lesquels le classement est effectué 15 comprennent une durée de voyage estimée 124 pour un segment donné de routes et une fréquence d'options de transport 126 sur un segment donné.
Typiquement, lorsqu’on applique l'algorithme d’optimisation de trajectoire, les bords du graphe sur lesquels il est appliqué sont pondérés selon la fréquence d'options de transport 126 et la 20 durée estimée de voyage 124. À titre d’exemple, l’algorithme d'optimisation de trajectoire choisi pour l'optimisation pourrait être une variante de Martin de l'algorithme de Dijkstra.
De plus, les paramètres de préférences d’utilisateur 121, relatifs à l'usage et/ou à la prohibition de services de transport disponibles spécifiques pour les routes, sont pris en compte dans la 25 sélection de routes. Si un tel paramètre de préférence d'utilisateur 121 indique par exemple, « rail uniquement » ou « sans correspondances de vol » seules les routes correspondant au transport en rail où seules les routes sans correspondances de vol (avion, etc.) sont prises en compte, d'autres routes possibles sont rejetées. Les paramètres de préférences d'utilisateur 121 sont par exemple, inclus dans la requête du client demandeur de contenu 2.
Le paramètre de préférence d'utilisateur 121 et les paramètres de routage 122 sont, dans cet exemple, situés sur le même serveur D que le générateur d'itinéraire 11, ce qui montre ces données après leur récupération de serveurs externes (dans le cas des paramètres de routage) ou de la requête de l'utilisateur (dans le cas du paramètre de préférence de I'utilisateur).
Le résultat du classement global est qu'un nombre de routes est écarté. L’écartement peut être effectué en comparant le rang d'une route avec une valeur de seuil donnée qui pourrait être, dans certains exemples, définie par l'utilisateur. De cette façon, par exemple, seules meilleurs 5 routes sont sélectionnées.
En d autres termes, le module de routes 8 transforme un ensemble de routes 64 en un ensemble de routes classées 66 avec un nombre de routes réduits, en écartant une pluralité de routes au cours du classement. Autrement, l'algorithme d'optimisation de trajectoire peut être arrêté dès qu'un nombre de routes a été généré conformément à un seuil donné, p. ex. après la génération 10 de 10 routes.
Un ensemble d'itinéraires 68 est créé uniquement pour les routes contenues dans cet ensemble de routes classées 66. Un itinéraire dans l’ensemble des itinéraires 68 comprend des horaires 15 de départ et des horaires d'arrivée pour les segments d'une route comprise dans l'ensemble des routes classées 66.
Ces horaires de départ et d'arrivée représentent une partie des données horaires 32 interrogées, puis par la suite récupérées, par la plateforme de fournisseur de contenu 3, via une interface de 20 fournisseur 7. De plus, les données tarifaires 34 et les données de disponibilité 36 sont également interrogées et récupérées de la plateforme de fournisseur de contenu 3 de manière analogue. Dans certains modes de réalisation, la disponibilité d'un segment donné de routes est vérifiée avant que les données horaires 32 soient interrogées pour le segment correspondant.
L'interface fournisseur 7 peut être programmée pour avoir la capacité de collecter des données d'une pluralité de fournisseurs de voyage offrant un contenu sous forme d’une pluralité de différents types de données.
Pour chaque segment d’une route comprise par l'ensemble des routes classées 66 il y a une durée 30 estimée de voyage 124 disponible et la date de départ d'un voyage est habituellement connue à partir de la requête du client- une heure de départ et une heure d'arrivée estimées peuvent être calculées pour chaque segment Dans certains modes de réalisation, les données horaires 32 pour un segment ne sont collectées qu’à partir d’une heure d'arrivée estimée d'un segment précèdent ultérieur. Par conséquent, seules des demandes proches de ces heures de départ et d’arrivée estimées doivent être adressées à la plateforme de fournisseur de contenu 3.
De toute façon seules des interrogations pour des routes qui sont comprises par l'ensemble de routes classées 66 doivent être encore adressées à la plateforme du fournisseur de contenu 3.
Par ailleurs, les informations tarifaires 34 sont récupérées pour chaque route dans l'ensemble des routes classées 66, une fois que les horaires de départ et d'arrivées ont été déterminés pour chaque segment de route.
L'ensemble des routes classées 66 avec les données horaires 32 (p. ex. les heures de départ et d'arrivée) et les données de prix récupérées 34 (et les données de disponibilité 36) forme I ensemble des itinéraires 68. L’ensemble des itinéraires 68 est envoyé au client demandeur de contenu 2 via l'interface client 5 (voir Fig. 1) sous forme d’une offre.
Dans ta Fig. 3a un graphe de correspondances 88 et un métagraphe 99, formé sur la base du graphe de correspondances 88, sont illustrés. Le graphe de correspondances exemplaire 88 montrées dans ta Fig. 3a comprend quatre graphes de services de transport 81, 83, 85, 87. Un premier graphe de sendee de transport aérien 81 est illustré par des nœuds en forme de diamant connectés par des bords et un deuxième graphe de service de transport aérien 83 est illustré par des nœuds en forme de cercle connectés par des bords. Parallèlement, un premier graphe de service de transport de transport urbain 85 est illustré par des nœuds en forme de triangle connectés par des bords et un deuxième graphe de service de transport de transport urbain 87 est illustré par des nœuds en forme de bouclier connectés par des bords. Les nœuds représentent des arrêts dans le réseau de service de transport desservi par l'opérateur de transport (p. ex. DB, Air France etc.). On note que pour un et même arrêt il peut y avoir une pluralité d'opérateurs de transport, chacun représenté par un nœud différent dans le graphe, comme par exemple les mêmes gares de train pourraient être desservies par une pluralité d'opérateurs de rail différents (p. ex. DB, Meridian etc.).
Il y a des nœuds d'entrée/nœuds de sortie dans le graphe de correspondances 88 qui connectent un graphe de service de transport 81, 8j, 85, 87 a un autre graphe de service de transport 81, 83, 85, 87, tels que les nœuds SP6 (nœud d'entrée du graphe de service de transport 85) et SP7 (nœud de sortie du graphe de service de transport 81). Le nœud d’entrée/sortie SP1 est par exemple, partagé entre le graphe de service de transport 81 et le graphe de service de transport 83 et sert donc à connecter ces deux graphes de services de transport 81, 82. Dans la Fig. 3a ceux-ci est illustré par le demi-diamant et la demie forme circulaire du nœud SP1. Le nœud SP1 est partagé entre ces graphes, car les nœuds représentent le même mode de transport, notamment 5 aérien, et ont la même position géographique (coordonnées GPS).
Les nœuds d'entrée/sortie SP6 et SP7 connectent le graphe de sendee de transport aérien 81 au graphe de service de transport de transport urbain 85. Les nœuds d'entrée/sortie SP2 et SP3 connectent le graphe de service de transport aérien 83 au graphe de service de transport de 10 transport urbain 85. Les nœuds de correspondance SP5 et SP4 connectent le graphe de service de transport 83 au graphe de service de transport de transport urbain 87. Ces correspondances également appelées « bords connecteurs » dans le graphe de correspondances, représentent dans certains modes de réalisation des épisodes de marche lors d’un changement d'un mode de transport (dans ce cas : aérien) un autre (dans ce cas : transport urbain).
Sur la base du graphe de correspondances 88, un métagraphe 99 est généré (le processus de construction/génération est illustré par la flèche 89). Les nœuds du métagraphe représentent les graphes de services de transport du graphe de correspondances 88. Les bords du métagraphe représentent des connexions entre les graphes de service de transportai (soit par des nœuds 20 partagés, ou par des « bords connecteurs » comme décrit ci-dessus). Une liste avec tous les arrêts dans le réseau de transport public géré par l'opérateur de transport, représentés par un nœud de métagraphe 81', 83‘, 85', 87' du métagraphe 99 est associé aux nœuds de métagraphe correspondants 8Γ, 83', 85', 87’. Ceci est illustré dans la Fig. 3a par les listes à côté des nœuds de métagraphe respectifs 8Γ, 83', 85', 87' vers lesquels pointent des flèches creuses partant de 25 ces nœuds de métagraphe 81', 83', 85', 87’. Les illustrations des listes incluent des nœuds d'entrée/nœuds de sortie des graphes respectifs de services de transport comme des entrées de liste représentatives.
Un résumé global de l'obtention d'un ensemble de routes 64 à partir du graphe de 30 correspondances 88 et d'un ensemble de routes classées 66 de l'ensemble de routes 64 est fourni dans ce qui suit :
Les premiers nœuds d'origine et de destination 40, 42 sont identifiés, sur la base de l'origine de voyage et de la destination de voyage pour le voyage conformément à la requête du client demandeur de contenu 2 (non illustré dans la Fig. 3a). Ensuite, en utilisant la liste contenant tous les arrêts dans un réseau de transport public géré par un opérateur de transport spécifique associé à un nœud de métagraphe, il est identifié sur quel nœud du métagraphe reposent les nœuds d'ongine et de destination 40, 42. Dans cet exemple, les nœuds respectifs sont le nœud de métagraphe 8 Γ et le nœud de métagraphe 87'.
Successivement, des métaroutes possibles à l'intérieur du métagraphe 99 sont recherchées par un algorithme de recherche exécuté sur le métagraphe 99. Le but étant d’identifier les réseaux de transport public et les nœuds d'entrée et nœuds de sortie qui relient les réseaux de transport public.
La traversée du métagraphe 99 (une recherche dans le métagraphe) est illustrée schématiquement dans la Fig. 3b : Une trajectoire C2 — C3, entre le nœud de métagraphe 81' représentant le graphe de service de transport 81 et le nœud de métagraphe 87’ représentant le graphe de service de transport 87, est trouvée via les bords du métagraphe.
Les bords du métagraphe représentent des options de changement entre deux réseaux de transport public, soit par un bord connecteur dans le graphe de correspondances 88 (« distance à pied » entre deux réseaux de transport public), ou par deux réseaux de transport public partageant un arrêt commun (les nœuds des graphes de services de transport correspondants ont été fusionnés).
La métaroute entière, du nœud d’origine 40 compris par le graphe de service de transport 81 au nœud de destination 42 compris par le graphe de service de transport 87, va de Cl (un segment de route à l'intérieur du graphe de service de transport 81) via C2 et C3 à C4 (un segment de route à l'intérieur du graphe de service de transport 87).
Par l'activité montrée dans la Fig. 3b, les nœuds de métagraphe pertinents - et par conséquent les graphes de services de transport pertinents - sont obtenus. Dans certains modes de réalisation, les bords du métagraphe - indiquant l'option de changement entre les réseaux de transport public - ont comme attributs les nœuds d'entrée et de sortie des graphes correspondants de services de transport connectés par ces bords.
Un exemple d’une première trajectoire possible connectant le nœud d’origine 40 et le nœud de destination 42 est :
Le réseau de service de transport aérien 81 (nœuds en forme de diamant)->Ie réseau de service de transport aérien 83 (nœuds en forme de cercle)~>le graphe de service de transport de transport urbain 87 (nœuds en forme de bouclier). Cet exemple couvrant trois réseaux différents de services de transport est illustré par la Fig. 3b.
Une deuxième trajectoire possible est dans cet exemple :
Un réseau de service de transport aérien 81 (nœuds en forme de diamant) ->un réseau de service de transport urbain 85 (nœuds en forme de triangle) ~>un réseau de service de transport aérien 83 (nœuds en forme de cercle) un graphe de service de transport de transport urbain 87 (nœuds en forme de bouclier). Une route via le graphe de correspondances couvrant cette trajectoire est illustrée par la Fig. 3c.
Les nœuds pertinents sur le graphe de correspondances 88 sont :
Le nœud d'origine 40, le nœud SP 1 : le nœud SP7 ; le nœud SP1 ; le nœud SP5 ; le nœud SP2 ;
le nœud SP6 ; le nœud SP3 ;
le nœud SP4 ; le nœud de destination 42 ;
Les sous-graphes 77 sont formés selon les métaroutes. Pour l'exemple donné ci-dessus, illustré dans la Fig. 3b, la œétaroute indiquée par les trajectoires Cl, C2, C3, et C4 conduirait à sousgraphe 77 contenant les graphes de services de transport 81, 83, 87. Par conséquent, les métaroutes supplémentaires et/ou d'autres nœuds de métagraphe conduiraient à un sous-graphe 77 contenant les graphes de services de transport correspondants.
Selon un mode de réalisation, un algorithme d'optimisation de trajectoire est appliqué aux sousgraphes 77 d'après les métaroutes déterminées. Selon un autre mode de réalisation, l'algorithme d optimisation de trajectoire est appliqué aux graphes de service de transport contenus par· un sous-graphe 77 individuellement
Dans certains modes de réalisation, des segments avec une fréquence peu élevée d’options de transport (p. ex. « aérien », « rail ») sont résolus en premier et les segments avec une fréquence plus élevée d’options de transport (p. ex. les transports urbains comme le « Métro ») sont résolus après.
Lorsque les routes pour le premier sous-graphe 77, basé sur la métaroute : réseau de service de transport aérien 81 ->réseau de transport — service aérien 8 3graphe de service de transport de transport urbain 87 sont classés, un algorithme d'optimisation de trajectoire résout les trajectoires des routes qui reposent sur le réseau de service de transport aérien 81 et des réseaux de service de transport aérien 83 en premier.
Le deuxième sous-graphe 77 est basé sur la métaroute : graphe de service de transport aérien graphe de service de transport de transport urbain 8 S'-t’· graphe de service de transport aérien 83 ->graphe de service de transport de transport urbain 87. L'algorithme d'optimisation de trajectoire résout les parties des routes qui reposent sur le réseau de service de transport aérien 81 et le réseau de service de transport aérien 83 en premier - avec des parties manquantes 15 devant être résolues plus tard - au milieu.
Les segments de service de transport (des segments successifs gérés par le même opérateur de transport) avec une fréquence peu élevée d'options de transport du premier sous-graphe 77 qui sont résolus sont :
Le nœud d'origine 40 -Me nœud SP1 + le nœud SP1 nœud SP1 (changement du graphe de service de transport aérien 81 au graphe de service de transport aérien 83; en tenant compte du temps de correspondance entre les deux réseaux) + le nœud SP1 ~>le nœud SP5.
Les segments de service de transport pour le deuxième sous-graphe 77 partent du nœud d'origine 40 au nœud SP7 et du nœud SP2 au nœud SP5, avec une partie manquante - devant être résolu plus tard - au milieu. Les segments de service de transport (les segments successifs gérés par le même opérateur de transport) avec une fréquence peu élevée d'options de transport du deuxième sous-graphe 77 qui sont résolus sont :
Le nœud d’origine 40 ->ie nœud SP7 + le nœud SP7 ->le nœud SP6 -> SP3 (non résolu à ce stade) + le nœud SP3 -Me nœud SP2 + le nœud SP2 -Me nœud SP5.
Après avoir résolu les segments de service de transport, les segments de service de transport ayant une fréquence élevée d'options de transport, c.-à-d. des parties des routes allant au-delà des graphes de service de transport 85, 87 (transport urbain), des routes sont résolus.
Les segments de service de transport requis pour aller du nœud d'origine 40 au nœud de destination 42 (« fréquence élevée » et « fréquence peu élevée ») sont agglomérés en une route.
En appliquant l'algorithme d'optimisation de trajectoire au sous-graphe 77 (ou aux graphes individuels de service de transport du sous-graphe 77) l'ensemble des routes 64 est obtenu. Dans certains exemples, un processus de classement est effectué pendant l'application de l'algorithme pour obtenir directement un ensemble de routes classées 66. Dans un autre exemple, un processus de classement séparé est effectué sot l’ensemble obtenu de routes 64 pour classer et écarter certaines des routes et obtenir ainsi l'ensemble de routes classées 66.
Une vraie route telle qu'elle pourrait être obtenue par le procédé décrit ci-dessus est montrée dans la Fig. 3d. Le client demandeur de contenu définit une origine de voyage et une destination de voyage pour un voyage dans une requête envoyée par le client 2. Dans cet exemple, l'origine de voyage est la « Sagrada Familia » et la destination de voyage est « Brandenburger Tor ». De cette origine de voyage et de cette destination de voyage, un nœud d'origine 40 représentant l’arrêt « station de Métro Sagrada Familia » et un nœud de destination 42 représentant l'arrêt « arrêt de bus Brandenburger Tor » résultent de la sélection. La route comprend un segment de service de transport A qui est desservi par le service de transport urbain de Barcelone. Le segment de service de transport A inclut un segment de métro et un segment de bus de la « station de Métro Sagrada Familia » à la « station de Métro aéroport BCN » qui sont tous deux gérés par l'opérateur de transport A. Il y a ensuite un temps de marche de la « station de Métro aéroport BCN » à « l'aéroport BCN », dans un graphe de correspondances 88 cela aurait été représenté par un bord connecteur. Ensuite, il y a un segment de service de transport B qui inclut un segment aérien couvrant un premier vol de « l'aéroport BCN » à « l’aéroport CDG » et un deuxième segment de vol de « l'aéroport CDG » à « l'aéroport BER ». Les deux vols sont, p. ex. effectués par le même opérateur de transport B, p. ex. Lufthansa, Air France. Il y a un autre temps de marche de « l'aéroport BER » à « l'arrêt de bus de l'aéroport BER » qui aurait aussi pu être représenté par un bord connecteur dans un graphe de correspondances 88. De « l'arrêt de bus de l'aéroport BER » à « l'arrêt de bus de Brandenburger Tor » il y a un segment de service de transport C qui est un segment de bus desservi par le sendee de transport urbain de Berlin. De « l'arrêt de bus de « Brandenburger Tor » à [« Brandenburger Tor »] il y a un dernier temps de marche.
Fig. 4 montre un extrait d'un document xml exemplaire qui contient des données exemplaires utilisées pour générer le graphe de correspondances 88. Ces données, contenant les arrêts, p. ex. les gares de train ou les aéroports et les routes de liaison entre les arrêts dans le réseau demandé, sont collectées à partir d’une plateforme de fournisseur de contenu 3. Ces données incluent également des données statistiques, telles que la fréquence d'options de transport et la durée estimée de voyage qui sont utilisées comme paramètres de routage 122 dans la sélection incluant le classement.-Les arrêts sont transformés en nœuds, les routes de liaison en bords. Les données statistiques sont implémentées comme des attributs des bords. L'extrait de la Fig.4 fournit des informations sur deux aéroports, l’aéroport de Barcelona-El Prat et l'aéroport d'Amsterdam Schiphol ainsi que leurs routes de liaison dans l'une et l'autre direction. Par exemple il est possible par ailleurs d'extraire de ce document xml qu'un temps de voyage moyen entre ces aéroports par avion (correspondant à la durée estimée de voyage) est de 145 minutes.
Cependant, comme une large variété de nonnes différentes et de protocoles de communication propriétaires, des mécanismes d'échange de messages, des formats et des types de données ainsi que des applications d’échange d’informations conduisent à une hétérogénéité dans l’échange d'informations, les données collectées des données de la plateforme de fournisseur de contenu peuvent avoir un format de données différent que celui qui est nécessaire pour générer le graphe de correspondances.
Par conséquent, si les données collectées de la plateforme de fournisseur de contenu ne sont pas conformes au format de données requis pour construire le graphe de correspondances 88, elles sont automatiquement converties dans un format de données utilisable par le procédé. Le format de données montré dans la Fig.4 est un format XML. Par exemple, ce format est utilisé car d'autres types et formats de données peuvent être aisément convertis dans ce format.
Un organigramme d'un procédé exemplaire de génération d'un ensemble de routes basé sur des données d'une pluralité de plateformes de fournisseurs de contenu estmontré dans la Fig. 5a.
Dans l'activité SI, des données sont collectées à partir des plateformes de fournisseurs de contenu 3. Dans l'activité S2, un ou plusieurs graphes de services de transport 81, 83, 85, 87 sont générés. Dans l'activité S3, un graphe de correspondance 88 est généré à partir des graphes de services de transport 81, 83, 85, 87 en connectant les graphes de services de transport. Dans l'activité S4, un métagraphe 99 est généré à partir du graphe de correspondances 88.
Dans l'activité S5, un utilisateur 2 sélectionne une origine de voyage et une destination de voyage d'un voyage. L’origine de voyage et la destination de voyage sélectionnées font typiquement partie de la requête envoyée par l'utilisateur 2.
Dans l'activité S6, une origine et une destination correspondant à l'origine de voyage et à la destination de voyage fournies par le client demandeur de contenu 2 sont déterminées dans les graphes générés (le graphe de correspondances 88 et le métagraphe 99). L'activité S6 comprend une activité S6a, notamment la sélection d'une d'origine 40 et du nœud de destination 42 dans le graphe de correspondances 88. Comme décrit ci-dessus, les arrêts représentés par le nœud d'origine 40 et le nœud de destination 42 sont typiquement des stations de transport public proches de l'origine de voyage et de la destination de voyage demandées par l'utilisateur 2. L'activité S6 comprend par ailleurs une activité 6b, notamment l'identification des nœuds de métagraphe 8Γ, 87’ (selon un exemple illustré dans la Fig. 3a) associés au nœud d’origine 40 et au nœud de destination 42 du graphe de correspondances 88.
Dans l'activité S7, des trajectoires dans le métagraphe 99 sont tracées à partir d’un nœud de métagraphe contenant le nœud d'origine 40 vers le nœud de métagraphe contenant le nœud de destination 42. Ainsi, les métaroutes entre les nœuds d'origine et de destination sont formées.
Dans l'activité S8, un sous-graphe 77 est extrait à partir du graphe de correspondances 88 selon les métaroutes formées.
Dans l'activité S9, des routes sont sélectionnées entre le nœud d'origine 40 et le nœud de destination 42 en connectant le nœud d'origine 40 et le nœud de destination 42 sur des bords du sous-graphe 77.
Fig. 5b montre l'activité S9 de la Fig. 5a de façon plus détaillée. La sélection des routes inclut le classement des routes selon des paramètre de routage 122 (activité S9b). Les paramètres de routage 122 comprennent la durée estimée de voyage 124 et peuvent par ailleurs comprendre d'autres entrées.
Avant le classement, les routes incluses dans l'ensemble de routes 64 obtenues au cours de l’activité S9a qui ne sont pas conformes aux paramètres de préférences de d’utilisateur 121 (p. ex. l'usage de services de transports spécifiques) sont rejetées dans le cadre de l'activité S10. Elles pourraient cependant être également rejetées dans des activités ultérieures.
L'activité S9b englobe l'application d'un algorithme d'optimisation de trajectoire, p. ex. l'algorithme de Martin mentionné ci-dessus. L'activité S9bi) englobe l'application de l'algorithme d'optimisation de trajectoire à chaque graphe de services de transport de l'ensemble déterminé de graphes de services de transport contenus dans le sous-graphe 77. Autrement, à l’activité S9bii), l’algorithme d'optimisation de trajectoire est appliqué sur le sous-graphe 77.
Par conséquent, l'algorithme d’optimisation de trajectoire peut être appliqué soit une fois sur un large ensemble de données ou plusieurs fois sur une pluralité d'ensembles de données plus petits, selon ce qui est le plus efficace pour résoudre le problème.
En appliquant l'algorithme d’optimisation de trajectoire conformément aux activités S9bi) ou S9bii) les routes sont classées selon la durée estimée de voyage et/ou la fréquence d'options de transport à l'activité S9biii). Dans un autre mode de réalisation, les routes sont classées en aPP^Quanl iln seul algorithme tenant compte à la fois des paramètres de routage 122 et des paramètres de préférences d'utilisateur 121.
L'ensemble des routes 64 est classé jusqu'à une valeur de seuil définie qui pourrait être donnée par le client demandeur de contenu 2 ou être prédéfinie dans l'algorithme. Les routes dont le rang est plus élevé que cette valeur de seuil sont écartées.
Ainsi, un ensemble de routes classées 66 - avec un nombre de routes moindre ou égal à l'ensemble des routes 64 - est obtenu au cours de l’activité S9biv).
Un organigramme d'un procédé exemplaire de génération de graphes et de gestion de requêtes subséquentes pour obtenir une offre incluant un ensemble d'itinéraires conformes à la requête envoyée par le client demandeur de contenu, est montré dans la Fig. 6.
Le processus de génération de graphes 17 exécuté par une instance du module de routes 8 fonctionnant sur le serveur B, conformément à l'exemple montré dans la Fig. 1, est divisé en un processus de génération de graphe de correspondances 17a et un processus de génération de métagraphe 17b illustrés dans la Fig. 6 par Tl et T2 respectivement.
Une première activité Tl, un processus de génération de graphe de correspondances 17a est mis en œuvre. Le processus de génération de graphe de correspondances comprend les activités Tl a à Tld. À l’activité Tla, des données de routes 13 comprenant, par exemple, les noms et la localisation des arrêts de transport public, en particulier les réseaux de sendees de transport et des informations concernant les correspondances entre ces arrêts, sont collectées à partir d'une base de données 4. Les données de routes 13 comprennent, par exemple, des données statistiques comprenant une durée estimée de voyage entre les arrêts représentés par les nœuds du graphe. Les données de routes 13 sont typiquement collectées à partir d'une base de données externe, par exemple, d’un d’opérateur de transport et/ou d'un fournisseur de données statistiques. Ces données sont récupérées, par exemple, une fois uniquement au début du procédé et ensuite à chaque fois qu'un changement survient dans les données de routes.
Sur la base de ces données, les graphes de transport 81, 83, 85, 87 sont créés au cours de l'activité Tic. Chaque graphe de service de transport correspond au réseau de services de transport d'un opérateur de transport spécifique, ainsi que mentionné ci-dessus.
En connectant les graphes de services de transport 81, 83, 85, 87 aux arrêts auxquels un changement entre un premier réseau de services de transport représenté par un premier graphe de service de transport et un deuxième réseau de services de transport représenté par un deuxième graphe de service de transport est possible, un graphe de correspondances 88 est ainsi généré à partir des graphes de services de transport 81, 83,85, 87 dans l’activité Tic. Le graphe de correspondances 88 est stocké sur un dispositif de stockage 9 en cours de l'activité Tld.
Suivant l'activité Tl qui représente le processus de génération du graphe de correspondances 17a, un processus de génération de métagraphe 17b est mis en œuvre à l'activité T2. L'activité T2 comprend les activités T2a et T2b. Dans l'activité T2a, le métagraphe 99 est généré à partir du graphe de correspondances 88. Comme décrit ci-dessus, les nœuds de métagraphe correspondent aux réseaux de services de transport du graphe de correspondances 88 et les bords du métagraphe correspondent aux connexions entre ces réseaux de services de transport.
Le métagraphe 99 est, pour ainsi dire, une abstraction du graphe de correspondances 88. Néanmoins, par exemple les nœuds de métagraphe peuvent contenir des informations telles qu'une liste des arrêts contenus dans le réseau de services de transport que les nœuds représentent. Au cours de l'activité T2b, le métagraphe 99 est stocké sur le dispositif de stockage 9.
Dans l'activité T3, l'utilisateur 3 demande des itinéraires entre une origine et une destination (qui sont par exemple des lieux réels tels que « Brandenburger Tor », « Sagrada Familia » comme décrit ci-dessus). Ainsi qu'on peut le constater dans l'organigramme, les activités Tl et T2, c.-à-d. le processus de génération de graphe de correspondances et le processus de génération de métagraphe sont effectués avant qu'un utilisateur envoie une requête.
En réponse à la requête de l'utilisateur 2, le processus de sélection de routes 18 est mis en œuvre à l'activité T4. L'activité T4 comprend les activités T4a et T4c. Dans l'activité T4a, un ensemble de routes 64 entre un nœud d'origine 40 et un nœud de destination 42 est sélectionné à partir du graphe de correspondances 88. Avant cette activité, des routes qui ne sont pas conformes à un paramètre de préférence de l'utilisateur, tel que « train uniquement », « pas de vol », sont rejetées au cours de l'activité T4b. L'activité T4b peut être considérée comme une contrainte appliquée sur l'activité de sélection T4a et est donc illustrée en dehors du processus de sélection de routes 18.
Le paramètre de préférence d’utilisateur 121 est, par exemple, inclus dans la requête de l'utilisateur pour des itinéraires. L'ensemble des routes 64 est, par exemple, généré à partir du graphe de correspondances 88 (plus spécifiquement le sous-graphe 77) en traversant le métagraphe 99 pour trouver une ou plusieurs métaroutes entre un nœud de métagraphe qui comprend un arrêt à proximité de l’origine voulue par l’utilisateur 2 et un nœud de métagraphe qui comprend un arrêt à proximité de la destination de voyage voulue par l’utilisateur 2, et aussi en tenant compte des paramètres de préférences de l'utilisateur 121. Dans cet exemple, seules certaines parties du graphe de correspondances 88 (= sous-graphe 77) sont utilisées pour classer les routes sélectionnées qui font partie des métaroutes.
Par cette traversée de métagraphe et la génération du sous-graphe subséquent, le nombre de routes qui alimentent l'algorithme d'optimisation de trajectoire au cours de l’activité T4c est réduit (sinon toutes les routes seraient traitées par cet algorithme). Ainsi, la puissance de traitement requise pour la sélection de routes est fondamentalement réduite.
Dans l'activité T4c, l'ensemble des routes 64 est classé selon un ensemble de paramètres de routage 122. Le classement comprend une activité T4ci) qui indique l'application de l'algorithme d’optimisation de trajectoire sur les graphes de service de transport sélectionnés (ou sur le sous-graphe 77). Avant l'application de l'algorithme d'optimisation de trajectoire, par exemple. les bords du sous-graphe 77 des graphes de service de transport sélectionnés sont pondérés selon une durée estimée de voyage obtenue à partir des données statistiques contenues dans les données de route 13. En plus de la durée estimée de voyage, la fréquence d'options de transport entre deux arrêts, représentés par des nœuds correspondants dans le graphe respectif, pourrait également être utilisée pour obtenir lesdits poids. La durée estimée de voyage et la fréquence d'options de transport correspondent aux paramètres de routage 122 dans cet exemple.
En appliquant l'algorithme d’optimisation de trajectoire, les routes qui ne sont pas optimales (par conséquent des routes dont le rang est supérieur à une valeur de seuil donnée, p. ex. dix, c.-à-d. les routes ayant un rang de onze ou plus, sont écartées au cours de l'activité T4d.
Finalement, dans l'activité T4cii) un ensemble optimisé de routes 66 est obtenu.
Sur la base de l’ensemble des routes classées 66 un ensemble d'itinéraires 68 est construit conformément à l'activité T5. L'activité T5 représente un. processus de construction 19 qui englobe les activités T5a-T5f.
Dans les activités T5a, T5b, T5c qui sont effectuées essentiellement de façon simultanée, les données horaires 32 et les données tarifaires 34 ainsi que les données de disponibilité 36 sont collectées pour l'ensemble des routes classées. Dans certains modes de réalisation, une des données récupérées et collectées en premier, par exemple les données de disponibilité 36, est vérifiée d'abord puisque pour les routes indisponibles il n'est pas nécessaire d'interroger les données tarifaires et les données horaires. Dans d’autres modes de réalisation, un ordre différent de récupération peut être utilisé.
Les données horaires 32 collectées correspondent essentiellement aux heures de départ et d'arrivée associées aux segments de routes compris par l’ensemble de routes optimisé 66. Lorsque les données horaires 32 et les données tarifaires 34 sont récupérées, seules les données de l'ensemble de routes classées 66 ont besoin d’être obtenues, et non les données pour toutes les routes dans l’ensemble de routes d'origine 64. Aussi, seules les données horaires 32 qui sont conformes à la durée estimée correspondante de voyage d'un segment précédent vers un segment subséquent ont besoin d'être obtenues, car cette durée estimée de voyage implique une heure d'arrivée estimée pour un premier segment et par conséquent elle réduit aussi le nombre d'heures de départ possibles pour un deuxième segment qui est connecté au premier segment. Il en va de même des données de prix 34.
Les données horaires collectées 32, les données tarifaires 34 et les données de disponibilité 36 sont agrégées au cours de l'activité T5d.
Dans l'activité T5e, un ensemble d'itinéraires 68 est généré sur la base de l'ensemble des routes classées 66 et des données collectées 32, 34, 36. Un itinéraire comprend une heure de départ pour chaque segment du voyage et une heure d'arrivée pour chaque segment du voyage ainsi qu'un prix associé à ce segment.
Finalement, au cours de l'activité T5f, une offre 69 englobant l'ensemble des itinéraires est générée. Dans certains modes de réalisation, les itinéraires de l'ensemble des itinéraires 68 sont classés selon leur prix total (ceci correspond à un reclassement des routes - au sens d'une chaussée). A titre d'exemple, un itinéraire avec une route plus longue (correspondant à un rang plus élevé), mais un prix bas pourrait être classé plus bas (= mieux) dans l'offre finale 69.
Fig. 7 montre la fusion d'interrogations adressées à une seule plateforme de fournisseur contenu
3. Au cas où plusieurs interrogations 300, 302, 304 auraient besoin d'être adressées à cette plateforme unique de fournisseur de contenu 3, telles que des interrogations concernant des données horaires 32, des données tarifaires 34, des données de disponibilité 36, ces interrogations seraient fusionnées en une seule interrogation 306 qui à son tour serait envoyée à la plateforme de fournisseur de contenu correspondante 3. Par conséquent, le transfert de données vers et de la plateforme de fournisseur de contenu externe 3 peut être réduit, car moins de paquets TCP sont requis. Par ailleurs, une seule connexion TCP peut être utilisée pour traiter plusieurs des interrogations immédiatement.
Une représentation schématique d'un système informatique exemplaire 100 est montrée dans la Fig. 8. Le système informatique 100 est agencé pour exécuter un ensemble d’instructions sur le processeur 102 afin d’amener le système informatique 100 à effectuer une tâche, ainsi que décrit dans les présentes. Les serveurs A, B, C et D pourraient être des systèmes informatiques comme le système informatique 100.
Le système informatique 100 inclut un processeur 102, une mémoire principale 104 et une interface de réseau 108. La mémoire principale 104 inclut un espace pour l’utilisateur qui est associé à des applications exécutées par l’utilisateur et un espace noyau qui est réservé au système d'exploitation- et aux applications associées au matériel. Le système informatique 100 inclut par ailleurs une mémoire statique 106, p. ex. inamovible flash et/ou un disque à état solide et/ou une carte amovible micro ou mini SD qui stocke de façon permanente le logiciel permettant au système informatique 100 d’exécuter les fonctions du système informatique 100. Par ailleurs, il peut inclure un écran 110, une unité de contrôle d’interface utilisateur 114 et/ou un dispositif et un curseur de saisie alphanumérique 112. En option, des interfaces LO supplémentaires 116, telles qu'un lecteur de carte et des interfaces USB peuvent être présentes. Les composants du système informatique 102 à 109 sont interconnectés par un bus de données 118.
Dans certains exemples, le logiciel programmé pour mettre en œuvre le procédé décrit dans les présentes est stocké sur la mémoire statique 106 ; dans d'autres exemples des bases de données externes sont utilisées. Le processus de génération de graphes 17, le processus de sélection de routes 18 et le processus de construction d'offre 19 sont, par exemple, traités par les serveurs B et D comme illustré dans la Fig. 1 et les paramètres de routage et les données de routes sont transmis sous forme d'onde propagée via le dispositif d’interface de réseau 108 vers les serveurs A et D.
Un ensemble d’instructions exécutables (c.-à-d. un logiciel) représentant un quelconque ou toutes les méthodologies décrites dans les présentes, réside entièrement, ou au moins partiellement, de façon permanente dans la mémoire non volatile 106. Lorsqu’elles sont exécutées, les données de traitement résident dans la mémoire principale 104 et/ou le processeur 102. L'ensemble exécutable d'instructions amène le processeur à mettre en œuvre un quelconque des procédés décrits ci-dessus.
Fig. 9 illustre un dispositif portable 200, tel qu’une tablette ou un téléphone mobile. Sur ce dispositif portable 200, une application est en cours d'exécution dans laquelle l'utilisateur 2 saisit l'origine et la destination de son voyage désiré dans un champ d'origine 202 et un champ 5 de destination 206 montré sur l'écran 210 du dispositif portable 200. L'origine dans cet exemple est la « Sagrada Familia » et la destination est « Brandenburger Tor ». Également un arrêt intermédiaire désiré être saisi dans le champ « Via » 204. Par l'intermédiaire de l'application « Travel Companion », la requête est envoyée pour déclencher les processus comme décrit cidessus. Un ensemble d'itinéraires est envoyé au dispositif portable 200 de l'utilisateur 2 par le 10 système informatique distribué 100 lorsque les procédés décrits ci-dessus sont exécutés sur le système informatique distribué 100. L’ensemble des itinéraires est affiché à l'utilisateur 2 sur un écran 210 du dispositif portable 200.
Merci de noter qu'une requête d’un utilisateur pourrait être envoyée à partir d'un quelconque 15 dispositif capable d'envoyer une requête, incluant aussi un PC de bureau, etc. La mention du dispositif portable ne doit pas être interprétée dans un sens limitatif.

Claims (21)

  1. Revendications :
    1. Un procédé pour traiter des requêtes d'un client demandeur de contenu en interrogeant une pluralité de plateformes de fournisseurs de contenu, dans lequel une requête comprend une origine, une destination et au moins une d'une heure de départ et une heure d'arrivée. dans lequel le procédé comprend un processus de génération de graphes mis en œuvre par un module de routes avant la réception d'une requête d'un client demandeur de contenu, un processus de sélection de routes mis en œuvre par le module de routes après la réception de la requête du client demandeur de contenu et un processus de construction d'offre réalisé par un module d'offre après la mise en œuvre du processus de sélection de routes.
    Dans lequel le processus de génération de graphes comprend :
    la collecte de données à partir de la pluralité des plateformes de fournisseurs de contenu ;
    la génération d'une pluralité de graphes de services de transport, dans laquelle chaque graphe de service de transport comprend une pluralité de nœuds et de bords internes connectant les nœuds, dans lequel les nœuds représentent des arrêts dans un réseau correspondant de transport public et les bords internes représentent des correspondances entre les arrêts ;
    la génération d'un graphe de correspondances comprenant la pluralité des graphes de service de transport;
    dans lequel le processus de sélection de route comprend :
    la sélection d'un nœud d'origine et d'un nœud de destination dans le graphe de correspondances selon l’origine et la destination respectivement ;
    la sélection d'une ou de plusieurs routes entre le nœud d'origine et le nœud de destination comprenant l'assemblage d'un nombre de segments successifs pour une route, un segment étant une correspondance de transport entre deux nœuds d'un seul graphe de service de transport par un ou plusieurs bords internes ;
    dans lequel le processus de construction d’offre comprend :
    l’envoi à une plateforme respective de fournisseur de contenu d’au moins une interrogation demandant un prix et une disponibilité d'un segment des routes sélectionnées par le processus de sélection de routes, dans lequel l'interrogation comprend au moins une d'une heure de départ et d'une heure d'arrivée du segment sur la base d'au moins une des heures de départ et des heures d'arrivée de la demande et sur la base d'une durée de voyage estimée des segments précédents et suivants, respectivement.
    l'agrégation des réponses des plateformes de fournisseurs de contenu interrogées afin de construire un itinéraire pour chaque route sélectionnée, construisant ainsi un ensemble d'itinéraires ;
    la génération d'une offre comprenant l'ensemble d'itinéraires devant être envoyé au client demandeur de contenu.
  2. 2. Le procédé de la revendication 1, dans lequel chacune de la pluralité des plateformes de fournisseurs de contenu est associée à au moins un réseau de transport public.
  3. 3. Le procédé de la revendication 2, dans lequel chacun des graphes de services de transport correspond à un réseau de transport public géré par un opérateur de transport avec un mode de transport donné.
  4. 4. Le procédé d'une quelconque des revendications 1 à 3, dans lequel chaque- nœud est atteignable par au moins un des autres nœuds par l'intermédiaire d'un ou de plusieurs des bords internes.
  5. 5. Le procédé d'une quelconque des revendications 1 à 4, dans lequel la durée de voyage estimée des segments est déterminée par le module de routes.
  6. 6. Le procédé d'une quelconque des revendications 1 à 5, dans lequel la sélection d'une ou de plusieurs routes comprend un classement de ladite une ou plusieurs routes selon au moins un paramètre de routage, dans lequel ledit au moins un paramètre de routage comprend la durée de voyage estimée pour au moins un des segments d'une route sélectionnée.
  7. 7. Le procédé selon la revendication 6S dans lequel ledit au moins un paramètre de routage comprend une fréquence d’options de transport pour au moins un segment d'une route sélectionnée.
  8. 8. Le procédé selon l'une quelconque des revendications 1 à 7, dans lequel la sélection de ladite une ou plusieurs routes comprend la sélection des routes avec au moins une durée de voyage estimée minimale et une fréquence maximale d'options de transport.
  9. 9. Le procédé d'une quelconque des revendications 1 à 8, dans lequel l'offre comprend par ailleurs le rejet une route sélectionnée en réponse au fait qu'un segment de cette route est indisponible.
  10. 10. Le procédé selon une quelconque des revendications 1 à 9, dans lequel le processus de génération de graphe comprend par ailleurs la génération d'un métagraphe comprenant une pluralité de nœuds de métagraphe et de bords de métagraphe, dans lequel chaque nœud de métagraphe représente un graphe de service de transport et les bords du métagraphe représentent des options de changement d'un premier réseau de transport public associé à un premier graphe de service de transport pour un deuxième réseau de transport public associé à un deuxième graphe de service de transport.
  11. 11. Le procédé selon la revendication 10, dans lequel le métagraphe comprend des données relatives à au moins un des nœuds et des bords du graphe de correspondances.
  12. 12. Le procédé selon la revendication 10 ou 11, dans lequel la sélection d'une ou de plusieurs routes comprend l'application d'au moins un algorithme d'optimisation de trajectoire à au moins un graphe de correspondances et au métagraphe.
  13. 13. Le procédé selon Tune quelconque des revendications 1 à 12., dans lequel la sélection de ladite une ou plusieurs routes est basée sur au moins un paramètre de préférence d’utilisateur.
  14. 14. Le procédé selon la revendication 13, dans lequel les routes qui ne sont pas conformes avec ledit au moins un paramètre de préférence d'utilisateur sont écartées.
  15. 15. Le procédé selon l'une quelconque des revendications 6 à 14, dans lequel ledit au moins un paramètre de routage comprend un minimum de temps de correspondance entre deux segments subséquents.
  16. 16. Le procédé selon l'une quelconque des revendications 1 à 15, dans lequel une pluralité d'interrogations associées à un ou plusieurs segments adressés à une seule plateforme de fournisseur de contenu sont groupées en une seule interrogation à la plateforme respective du fournisseur de contenu.
  17. 17. Un système informatique distribué pour gérer des requêtes d'un client demandeur de contenu en interrogeant une pluralité de plateformes de fournisseurs de contenu offrant du contenu de transport, dans lequel le système informatique distribué est agencé pour collecter des données associées à la pluralité des plateformes de fournisseurs de contenu, et pour générer un nombre de graphes représentant des corrélations des données collectées et pour stocker au moins un graphe sur au moins un dispositif de stockage, le système informatique distribué comprenant :
    une interface client agencée pour échanger des messages orientés-itinéraire avec le client demandeur de contenu ;
    Un module de routes qui est agencé pour collecter des données associées à la pluralité des plateformes de fournisseurs de contenu, agencé pour générer au moins un graphe de service de transport et un graphe de correspondances représentant les corrélations des données collectées avant la réception d'une requête de client demandeur de contenu, dans lequel ledit au moins un graphe de service de transport comprend des bords internes, et agencé pour sélectionner une ou plusieurs routes d'un graphe de correspondances après la réception de la requête du client demandeur de contenu, comprenant l'assemblage d'un nombre de segments successifs pour une route, un segment étant une correspondance de transport entre deux nœuds d'un seul graphe de service de transport par un ou plusieurs bords internes;
    un module d'offre agencé pour obtenir les routes sélectionnées, interroger au moins une plateforme de fournisseur de contenu pour un prix et une disponibilité d'au moins un segment des routes sélectionnées, et agréger les réponses de ladite au moins une plateforme de fournisseur de contenu interrogée pour construire un itinéraire pour chaque route sélectionnée, construisant ainsi un ensemble d'itinéraires ;
    et dans lequel le système informatique distribué est par ailleurs agencé pour renvoyer l’ensemble d'itinéraires au client demandeur de contenu via l’interface client.
  18. 18. Le système informatique distribué de la revendication 17, dans lequel l'interface client est par ailleurs agencée pour communiquer avec un dispositif portable géré par un client demandeur de contenu.
  19. 19. Le système informatique distribué de la revendication 17 ou 18 comprenant une interface fournisseur agencée pour échanger des messages orientés-itinéraire avec la pluralité des plateformes de fournisseur de contenu.
  20. 20. Le système informatique distribué d’une quelconque des revendications 17 à 19, étant par ailleurs agencé pour mettre en œuvre le procédé d’une quelconque des revendications 1 à 16.
  21. 21. Un produit-programme d'ordinateur comprenant des instructions de code de programme stockées sur un support lisible par ordinateur pour mettre en œuvre les étapes du procédé selon les revendications 1 à 16 lorsque ledit programme fonctionne sur un ordinateur.
FR1857412A 2018-08-09 2018-08-09 Procede de generation d'un ensemble d'itineraires par une interrogation limitee de bases de donnees Pending FR3084949A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR1857412A FR3084949A1 (fr) 2018-08-09 2018-08-09 Procede de generation d'un ensemble d'itineraires par une interrogation limitee de bases de donnees
US16/530,352 US11676233B2 (en) 2018-08-09 2019-08-02 Method of generating a set of itineraries by limited querying of databases

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1857412A FR3084949A1 (fr) 2018-08-09 2018-08-09 Procede de generation d'un ensemble d'itineraires par une interrogation limitee de bases de donnees

Publications (1)

Publication Number Publication Date
FR3084949A1 true FR3084949A1 (fr) 2020-02-14

Family

ID=65443918

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1857412A Pending FR3084949A1 (fr) 2018-08-09 2018-08-09 Procede de generation d'un ensemble d'itineraires par une interrogation limitee de bases de donnees

Country Status (2)

Country Link
US (1) US11676233B2 (fr)
FR (1) FR3084949A1 (fr)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11733049B2 (en) 2019-10-07 2023-08-22 Lyft, Inc. Multi-modal transportation system
US10914600B1 (en) * 2019-10-07 2021-02-09 Lyft, Inc. Transportation proposal filtration, comparison, and inconvenience measurement
US11226208B2 (en) 2019-10-07 2022-01-18 Lyft, Inc. Transportation route planning and generation
US11733046B2 (en) 2019-10-07 2023-08-22 Lyft, Inc. Multi-modal transportation proposal generation
US10746555B1 (en) 2019-10-07 2020-08-18 Lyft, Inc. Multi-modal transportation route deviation detection and correction
US10969232B1 (en) 2019-12-06 2021-04-06 Ushr Inc. Alignment of standard-definition and High-Definition maps
CN113496317B (zh) * 2020-03-18 2024-08-02 深圳云天励飞技术有限公司 一种多轨迹碰撞分析方法、装置、电子设备及存储介质
JP7310752B2 (ja) * 2020-08-19 2023-07-19 トヨタ自動車株式会社 情報処理装置、情報処理システム、プログラム及び情報処理方法

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8700328B1 (en) * 2011-09-13 2014-04-15 Google Inc. Better diversity for transit routing
US8738286B2 (en) * 2009-11-11 2014-05-27 Google Inc. Transit routing system for public transportation trip planning
DE102014102035A1 (de) * 2013-08-13 2015-02-19 Deutsches Zentrum für Luft- und Raumfahrt e.V. Computereinrichtung, System mit einer Computereinrichtung und Computerprogramm
US8972185B1 (en) * 2012-10-01 2015-03-03 Google Inc. Constructing a transit transfer network from transit data
US8972190B1 (en) * 2013-05-14 2015-03-03 Google Inc. Systems and methods for generating transit trips
EP2897344B1 (fr) 2014-01-21 2016-07-27 Amadeus S.A.S. Structure d'intégration de contenu
WO2016153426A1 (fr) * 2015-03-23 2016-09-29 Nestia Pte Ltd Procédé et appareil pour la création de données cartographiques pour calculer le temps de trajet en utilisant des informations de transport public
US20170059341A1 (en) * 2015-08-31 2017-03-02 Sap Se Diversified route planning for public transportation network

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2217880B1 (fr) * 2007-11-24 2015-02-18 Routerank Ltd Planification d'itinéraire optimisée
US8977495B1 (en) * 2011-10-27 2015-03-10 Google Inc. Time independent transit routing
GB201314824D0 (en) * 2013-08-19 2013-10-02 Tomtom Dev Germany Gmbh Multi-modal routing
KR101558324B1 (ko) * 2013-10-11 2015-10-13 주식회사 크루메이트 휴리스틱 항공조회 시스템 및 그 제공방법
US9581455B2 (en) * 2014-05-06 2017-02-28 Elwha Llc Systems and methods for providing at least a portion of a travel plan that calls for at least one transportation vehicle unit
US10996064B2 (en) * 2017-09-20 2021-05-04 Ridecell, Inc. Dynamic multi-modal mobility service platform
US11067406B2 (en) * 2017-12-20 2021-07-20 Trafi Limited Navigation method using historical navigation data to provide geographical- and user-optimised route suggestions
US20190383621A1 (en) * 2018-06-14 2019-12-19 Ford Motor Company Journey segment performance analysis
US20190383623A1 (en) * 2018-06-14 2019-12-19 Ford Motor Company Dynamic connection determinations
US20190383622A1 (en) * 2018-06-14 2019-12-19 Ford Motor Company Dynamic connection management

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8738286B2 (en) * 2009-11-11 2014-05-27 Google Inc. Transit routing system for public transportation trip planning
US8700328B1 (en) * 2011-09-13 2014-04-15 Google Inc. Better diversity for transit routing
US8972185B1 (en) * 2012-10-01 2015-03-03 Google Inc. Constructing a transit transfer network from transit data
US8972190B1 (en) * 2013-05-14 2015-03-03 Google Inc. Systems and methods for generating transit trips
DE102014102035A1 (de) * 2013-08-13 2015-02-19 Deutsches Zentrum für Luft- und Raumfahrt e.V. Computereinrichtung, System mit einer Computereinrichtung und Computerprogramm
EP2897344B1 (fr) 2014-01-21 2016-07-27 Amadeus S.A.S. Structure d'intégration de contenu
WO2016153426A1 (fr) * 2015-03-23 2016-09-29 Nestia Pte Ltd Procédé et appareil pour la création de données cartographiques pour calculer le temps de trajet en utilisant des informations de transport public
US20170059341A1 (en) * 2015-08-31 2017-03-02 Sap Se Diversified route planning for public transportation network

Also Published As

Publication number Publication date
US11676233B2 (en) 2023-06-13
US20200051192A1 (en) 2020-02-13

Similar Documents

Publication Publication Date Title
FR3084949A1 (fr) Procede de generation d&#39;un ensemble d&#39;itineraires par une interrogation limitee de bases de donnees
Gurumurthy et al. Analyzing the dynamic ride-sharing potential for shared autonomous vehicle fleets using cellphone data from Orlando, Florida
US10231079B2 (en) Geo-fence management using a cluster analysis technique
US9715233B1 (en) System and method for inputting a second taxi-start location parameter for an autonomous vehicle to navigate to whilst reducing distraction
US10013986B1 (en) Data structure pooling of voice activated data packets
US10371542B2 (en) System and methods for performing multivariate optimizations based on location data
WO2018225069A1 (fr) Numérisation et mappage de l&#39;espace public à l&#39;aide de réseaux collaboratifs d&#39;agents mobiles et de nœuds en nuage
US20090224941A1 (en) Efficient stream sharing for multi-user sensor data collection
Dezfouli et al. A novel tour planning model using big data
Markou et al. Real-Time Taxi Demand Prediction using data from the web
Mourad et al. Owning or sharing autonomous vehicles: comparing different ownership and usage scenarios
US20150185020A1 (en) Compatibility based resource matching
US20160131491A1 (en) Interactively Scheduling an Itinerary
Faieq et al. C2IoT: A framework for Cloud-based Context-aware Internet of Things services for smart cities
US11044588B2 (en) System and method for collaborative caching
Setiawan et al. A study of the tourism area life cycle in Dieng Kulon village
Verhun et al. Digital Tools for the Development of the Hospitality and Tourism Industry in the Context of a Digitized Economy
González et al. Utilization rate of the fleet: a novel performance metric for a novel shared mobility
Sala et al. Generating demand responsive bus routes from social network data analysis
Pareekh et al. Quantifying dimensions of transportation diversity: a City-based comparative approach
FR3084948A1 (fr) Procede de generation d&#39;un ensemble de routes base sur des graphes
US20180204467A1 (en) Ephemeral flights with transient windows
Saputra et al. Selective federated learning for on-road services in internet-of-vehicles
Alowibdi et al. VacationFinder: A tool for collecting, analyzing, and visualizing geotagged Twitter data to find top vacation spots
US20230140057A1 (en) Conversational user experience for multimodal travel system

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20200214

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6

PLFP Fee payment

Year of fee payment: 7