RU2807495C1 - Method and system for forming door-to-door travel route - Google Patents

Abstract

FIELD: computer technology.

SUBSTANCE: method for planning a travel route using various modes of transport. A method for generating a door-to-door travel route performed by a computing device includes the following steps: receiving a request from the user's device to a search service located on the server, wherein the request includes the exact address of the destination, receiving a schedule from suppliers on the server, generating a route using the RAPTOR algorithm based on data from the user's request, requesting information about available seats and prices from suppliers based on prepared routes, obtaining search parameters through the use of recurrent artificial neural networks that predict the next reference route for the user, comparing one by one the found routes with the reference route, generating travel route for use by filtering the travel routes obtained in the previous step, booking the route automatically.

EFFECT: improved accuracy of generating a door-to-door travel route.

1 cl, 6 dwg

Description

TECHNICAL FIELD

[001] The invention relates generally to the computing field, and in particular to methods and systems for planning a route for travel using various modes of transport with a pre-known starting point of departure and final point of arrival, taking into account various parameters and criteria for selecting modes of transport, such as travel time, cost, transfer times and others. The method provides the opportunity to create a route not only by land transport, but also by air and sea.

BACKGROUND OF THE ART

[002] At the moment, there are a large number of solutions for building routes from a known departure point to an arrival point. Such solutions are used in navigators and logistics systems. Such solutions offer route construction by ground transport without transfers. Those. plan a route along well-known public roads, taking into account traffic jams and other factors affecting the speed of travel.

[003] Also in the published application RU2571450C2 devices for constructing multimodal navigation are disclosed. The traveler's current GPS location is synchronized with the planned one and, if the route deviates, it is rebuilt. The application also states that it is possible to use various modes of transport in an urban environment: on foot, by car, by bus or metro. It is assumed that the traveler himself will buy tickets and take care of the possibility of traveling by one or another type of transport. The navigation system only creates a route.

[004] Application RU2572279C1 also discloses a method for constructing a multimodal route. This application considers ground transport for the urban environment using buses, walking routes, and scooters.

[005] It’s tiresome to search and select routes for movement every time. Despite the fact that the choice usually falls on reliable service providers and on familiar and similar travel options. It is difficult to manually select route connecting times. For example, if the route includes a train route and departure time is at 19:00, then you need to manually select a flight or taxi for the shortest wait. You should also take into account the price, class of transport and other parameters. There may be personal preferences, such as a seat in a women's compartment or a taxi with a female driver.

[006] Guaranteed delivery of the traveler from the point of departure to the point of arrival. Building a route by various modes of transport, taking into account search parameters. Options are also selected taking into account the traveler’s personal preferences. The traveler will not have to think about buying tickets, getting a refund in case of cancellation or rescheduling of flights, or independently ordering a taxi and other types of transport.

SUMMARY OF THE INVENTION

[007] The present invention includes generating a travel route for a user from a pre-known departure point to a pre-known arrival point. The route is automatically compiled taking into account the user's criteria through the use of machine learning algorithms. The user’s preferences are also taken into account based on his “behavioral portrait” of the user.

[008] The invention provides the user with a reservation system that selects a route according to preferences and makes it possible to book all means of transportation. From the user of the invention it is only necessary to obtain the point of departure, the point of arrival and indicate the user. The system will suggest a route based on the parameters automatically.

[009] The technical result achieved in this technical solution is to increase the accuracy of forming a door-to-door travel route through the use of the RAPTOR route search algorithm and machine learning algorithms.

[0010] The specified technical result is achieved by implementing a method for generating a travel route from door to door, which is performed by at least one computing device and includes the following steps: receiving a request from at least one user device via the HTTPS protocol in JSON format to the d2d search service service located on at least one server, the request including the exact destination address; generating at least one route using the RAPTOR algorithm based on data from the user request received in the previous step; obtaining search parameters by using a recurrent artificial neural network, wherein the neural network model predicts a reference route based on the user's movement history; search for travel routes through requests to route providers, and the found routes are compared one by one with the reference route using the cosine proximity method; forming at least one travel route for use by filtering the travel routes obtained at the previous step.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In FIG. 1 shows an example implementation of a door-to-door travel method in the form of a block diagram.

[0014] In FIG. Figure 2 shows an implementation option where the data from the response is stored in a relational database for quick access and quick retrieval.

[0013] In FIG. Figure 3 shows a variant of the interface implementation, which displays a map with which it is possible to set coordinates.

[0014] In FIG. Figure 4 shows an implementation of an algorithm that finds the shortest path consisting of a set of routes.

[0015] In FIG. Figure 5 shows an implementation option for the final output, which is generated in the aggregation-service and sent to the d2d-service.

[0016] In FIG. Figure 6 shows an option for implementing routes and available travel options from suppliers.

DETAILED DISCLOSURE OF TECHNICAL SOLUTION

[0017] This technical solution makes it possible to search for travel options using various vehicles and methods (see Fig. 1).

[0018] At the first step of the method, schedules are received from suppliers on the server. The supplier may be a service on the Internet that provides information about the movement of, for example, a vehicle. For air travel, there is a GDS (global distribution system), which provides the ability to search and book air tickets. The most famous GDS systems in the state of the art: Amadeus, Saber, Galileo. Some airlines have their own reservation systems, and they may also act as a supplier. GDS also contains information about rail transportation. The supplier for rail transport can be a GDS or a reservation system from railway companies. For, for example, Russia, the supplier of railway transportation services is Russian Railways, through the integrator Teletrain. For hotels, the supplier is hotel reservation systems, for example, Ostrovok, Bronevik, A&A, etc., including foreign ones: Booking, Expedia. For a taxi, the supplier can be a taxi aggregator operating in the country of use, for example, Yandex.Taxi, Uber. For each service provider, integration with it is done in advance.

[0019] To create a route, you need to know all possible travel options, i.e. schedule of planes, trains, electric trains and Aeroexpress. This information is provided by service providers via API based on a preliminary request from this system.

[0020] The system is built on a service-oriented architecture. Each element of the system is responsible for one specific task and is called a service. The search service makes requests to all available providers via API. The request format varies by provider. For example, the NDC interaction protocol is common for searching for air tickets. It can also be SOAP or REST in JSON format over HTTP. This technical solution does not limit the interaction protocols between the system and the supplier. In response, the full schedule is returned in the format of interaction with suppliers. The answer contains the point of departure, point of arrival, departure time, travel time, departure/arrival terminal, flight time, flight number/train number.

[0021] Each provider has a method in the API to retrieve the schedule. The request and response format varies by vendor. In general, this is a request without parameters. For REST requests it will look like Error! Hyperlink reference not valid.

[0022] For SOAP

0023] Depending on the vendor, the response may be a schedule file in CSV or JSON format, or a response in SOAP format.

[0024] Regardless of the response format, the response will contain the necessary data:

FlightNumber - flight number;

Departure - departure airport;

Arrival - arrival airport;

DepartureDate - date and time of departure;

ArrivalDate - date and time of arrival;

DepartureTerminal - departure terminal;

ArrivalTerminal - arrival terminal;

FlightDuration - flight time.

[0025] The schedule is saved on the server in a relational database with a structure (Fig. 2). Separate tables are used for each supplier.

create table segments_provider

[0026] For train tickets, the algorithm works in a similar way. First, all possible trains are obtained using the API method. The train directory request is called without parameters. And the answer will be a list of trains.

<train_number>772AA</train_number>
<train_number>51B</train_number>

<train_number>51й</train_number>

[0027] For each train, its route is requested, a method for obtaining information about the route of the train.

[0028] The request parameters indicate the train number: <train_number>772A</train_number>

[0029] In the response we get the entire route with all stops

<route>MOSCOW OCT</route>

<route>S-PETER-GL</route>

<stop>

<station>MOSCOW</station>

<code>2000000</code>

<dep_time>19:30</dep_time>

<days>00</days>

</stop>

<stop>

<station>MOSCOW OCT</station>

<code>2006004</code>

<dep_time>19:30</dep_time>

<days>00</days>

</stop>

[0030] Where:

station - stopping station;

code - station code;

dep_time - departure time;

days - day if the train travels for more than one day.

[0031] This data is stored in a relational database in a table with a schema (Fig. 2).

create table segments_provider

[0032] The update occurs once a day, but a manual update is also available in case of an error or unforeseen circumstances. Data from the response is stored in a relational database for quick access and quick retrieval (Fig. 2). For ease of data retrieval, a relational database was chosen in a specific implementation example. Columnar databases can be an alternative, but in columnar databases updating/deleting elements is an expensive operation. In document-oriented databases, movement search will be a bottleneck.

[0033] The selection of the departure point and arrival point is discussed in more detail below.

[0034] There is a web interface for entering search parameters, with two text fields and two date fields. A map is also available for entering parameters. The map module can be anything, for example Yandex.Maps, OpenStreetMaps. Yandex maps are connected using the following script

<head>

<script src="https://api-maps.yandex.ru/2.1/?apikey=your API key&lang=ru_RU"

type="text/javascript">

</script>
</head>

<meta name="viewport" content="initial-scale=1.0, user-scalable=no, maximum-scale=1" />

[0035] The interface contains a map with which you can set coordinates. There are 2 text fields, 2 buttons, 2 fields for entering a date, a field for selecting an employee and a search button (Fig. 3).

[0036] The user can enter data into the input field in the format <Country> <City> <Street> <House>. Based on the entered characters, the system offers suitable search options. Directories for regions and streets are stored in the database and indexed by the ElasticSearch DBMS. Any other DBMS that supports n-gram tokenization can be used. N-gram is a sequence of words, letters, syllables. For fuzzy search, it is enough to divide the dictionary of countries, cities, streets into trigrams, i.e. three characters each. Based on these trigrams, you can determine which of them occur frequently. For example, the trigram “Mos” is found often, but “Mso” is not, most likely they meant “Mos”. This approach allows you to search for entries in the dictionary even if there is an error/typo in the word. The database is filled with countries, regions (cities, towns, villages, villages, etc.), streets and house numbers. For Russia, this data is taken from the FIAS federal information address system; for other countries, OpenStreetMap is used. Both sources are free to download and use. A prerequisite is that the search must be in lower case. N-gram tokenization supports errors in words; if the user misspelt one of the regions, the system will be able to offer the correct option.

[0037] The system offers two ways to enter search parameters. The first is to enter the exact address (described above). The second is to set coordinates on the map using the web interface. Any service that provides such an opportunity can act as maps: Yandex.Maps, OpenStreetMap, Google Maps, etc.

[0038] The movement graph is compiled as follows.

[0039] Based on the point of departure, the point of arrival and the schedule of the suppliers, a movement graph is drawn up. If the user has specified coordinates, the system finds the nearest settlement with a railway station or airport. To determine the nearest settlement, the PostgreSQL DBMS with the postgis extension is used. This extension has an operator "<->" that finds the nearest points:

[0040] The RAPTOR algorithm is used to create the final travel route. For this algorithm, route construction parameters are loaded.

[0041] The algorithm works with parameters (P, S, T, R, F).
P - Travel time. This parameter is needed to control travel time so that trips fit within a reasonable time frame. This parameter can also be changed to reduce travel time.

[0042] S - Many stops. Set of transfer points. In our case, these will be all points from the general output. In other words, these are all railway stations and all airports.

[0043] T - Lots of trips. The trip is one offer from the supplier. Either a specific train or a separate flight.

[0044] R - Select routes. One trip can have several routes. For example, one trip Penza - St. Petersburg, but 2 routes Penza - Moscow and Moscow - St. Petersburg. In other words, the trip may have a transfer

[0045] F - Set of transfers. This parameter specifies the number of transfers that can be made. For example, if you have a transfer in Moscow, you can get from the Airport to the railway station and continue your journey. Parameter F will contain this information. In other words, all possible movements between railway stations and airports.

[0046] Parameter S. Filled in with all airports and train stations.

[0047] Parameter T. Possible trips are built from the schedule database, i.e. This is a set of point-to-point movements without transfers. For railways these are stations on one route, for airplanes these are cities with direct flights and with transfers.

[0048] Parameter R. Routes. Trains run along routes, the entire route will be recorded in parameter R. For airplanes, the route will be the flight, i.e. route from 2 points. The Aeroexpress also arrives at this point as a route consisting of 2 points.

[0049] Parameter F. A set of points for the “walking path”. Taxis arrive at this point. The worst travel time is calculated from historical data, and one hour is also added for the opportunity to get off the plane or train, and for calling a taxi.

[0050] The algorithm finds the shortest path consisting of a set of routes (Fig. 4).

[0051] At the first stage, the coefficient K is selected - the number of segments. Since this algorithm uses air travel and railway trains, it would be reasonable to select a coefficient K with a small value. A large number of transfers will greatly increase the travel time and there will be no point in such trips. In a specific implementation example, the coefficient of the algorithm is K=3. According to statistics, air travel with two transfers is chosen quite rarely; it is easier to choose either another transport without transfers, or consider other travel options.

[0052] The Raptor algorithm makes a number of iterations equal to the number of transfers. In each iteration, all routes passing through this point are selected. In our case, it will be either an air flight or a train route. At this stage, it is checked whether it is possible to catch the new flight. At the first iteration this will not be useful; in the future, the time of arrival will determine whether the route is suitable or not. Matching routes are saved in the route list for future conversions.

[0053] In the next step, all route points are marked no earlier than the arrival time of the current route. Thus, we have a list of routes and stops suitable for travel. The next iteration filters routes and stops based on the routes and stops found at the previous iteration. After K-iterations, routes suitable for movement will remain.

[0054] Route scanning from stop ps to pt is disclosed below.

[0055] At the first iteration, route r1 is scanned, at the second, r2 and r3, at the third, r4.

[0056] At each iteration, a set of trips consisting of routes and transfers is compiled.

[0057] The RAPTOR algorithm outputs a set of trips. Next, we exclude from the set trips that do not contain the starting and ending points ps and pt. This way, only those trips will remain that are guaranteed to deliver from point ps to point pt.

[0058] Knowing the time of departure and arrival at each transfer, the system calculates the total travel time and selects the shortest travel time, i.e. the fastest route.

[0059] The system then needs to make a request to the suppliers. Search criteria are selected individually. In the interface window there is a field for selecting a traveler. Search criteria are selected based on his past trips.

[0061] The historical data of all users is used to train the artificial neural network. Trips for all time are grouped by user. Those. Each user will have their own set of trips.

[0061] An LSTM (Long Short Term Memory) class RNN (Recurrent Neural Network) neural network can be used to predict a future trip. A recurrent neural network allows you to predict the next item based on a set of items. In this case, there will be a trip option based on past trips.

[0062] Grouped trips are divided into blocks of 5 + 1 trips. After at least five trips it is possible to predict the next trip.

[0063] For training, data must be prepared.

[0064] The vector representation of a string is generated as:

def vectorize(self, text)

[0065] Each character is given its own numeric representation, which is a UTF-8 code, which is returned as a vector (array). To prepare clean input data, the Vectorizer.word_tokenize method from the keras library is used.

[0066] The prepared data is used to train a machine learning model based on LSTM neural networks, where the input data is a list of vectors with parameters, and the output value is the next trip.

[0067] The neural network will use 2 layers: LSTM and Dense.

[0068] The LSTM layer is responsible for training and prediction with the relu activation function. The Relu function returns 0 if it takes a negative argument, but if it takes a positive argument, the function returns the number itself. The activation function will return the value of the parameter, not its probability.

[0069] Dense is a hidden layer that is needed to calculate the final result.

[0070] Trips grouped by user are presented as an array. To train the neural network, we go through the entire list of trips, taking 5 trips for past trips and the 6th trip for the output value. We shift by one trip, and again take 5 trips.

[0071] Input data:

a. Number of transfers - 0, 1, 2;

b. Tariff code - number;

The airline code is a vector representation of the string;

c. Availability of luggage - 0, 1;

The departure airport code is a vector representation of the string;

d. Arrival airport code is a vector string representation;

e. Travel time in seconds - number;

f. Departure time in seconds;

g. Airline - vector line representation.

[0072] Output data:

[number of transfers, fare code, departure time in seconds, travel time in seconds, airline]

[0073] Departure and arrival airports are excluded from the output model, because we already know this data.

[0074] The neural network is trained with the prepared data. The finished model is saved for further use on the server. The definition of suitable flight options is disclosed below.

[0075] For the algorithm to work, the user must have at least five trips. First, a search is made for suppliers for a given direction and date. Then, based on the user’s last 5 trips, the neural network model predicts the next route, and this route is considered the “reference” route for this user.

[0076] The found routes are compared one by one with the reference route using the cosine proximity method. Using it, you can quite accurately determine how similar the option from the search results is to the reference route.

[0077] Example python code for finding cosine distance

from numpy import dot

from numpy. linalg import norm

cos_sim = dot (a, b)/( norm (a)\* norm (b))

[0078] For example, the five closest trips are selected to provide a choice in case the neural network makes a mistake or the user's plans and preferences change.

[0079] For railway tickets, the algorithm differs only in the input and output models.

[0080] The input model looks like this:

○ Car type - a number with a car type code

○ Carrier code - vector representation of the string

Departure time

○ Train number - a number with the train number code

○ Travel time in seconds - number

○ Departure station - vector representation of a line

○ Arrival station - vector representation of line

○ Departure time in seconds

○ Airline - vector representation of a string.

[0081] Output model:

[0082] [Car type, carrier code, departure time, train number, travel time in seconds]

[0083] The departure station and arrival station are excluded from the output model.
Text data, similar to the text data in airline tickets, is represented as vectors of numbers using the word_tokenize function.

[0084] With a confidence probability of 95%, it can be stated that the maximum number of reservations for complete identification will be 5, that is, already from the 6th reservation for each user, suitable travel options can be predicted quite accurately.

[0085] Given the shortest path and search parameters, the system makes queries to all suppliers with the given parameters.

[0086] The format of vendor requests varies by vendor. In general, it can be REST, SOAP, or in a binary format with its own message structure running on top of the TCP protocol.

[0087] The following parameters in requests are required:

Departure - departure airport;

Arrival - arrival airport;

Date - departure date;

Class - flight class;

TravelerCount - number of people.

[0088] Additional parameters are possible, such as airline or carrier type. They will not be useful in a specific implementation example.

[0089] A request is generated in supplier format and sent to the supplier. In response, flight options are returned.

[0090] Because Providers have different formats in their APIs, then the formats will be different. For all suppliers, you can select mandatory data in the response required for booking.

○ DepartureDate - date and time of departure

○ ArrivalDate - date and time of departure AirlineCompany - airline Duration - travel time Fare - fare Price - price

[0091] For train tickets, requests are sent in a similar way to AB. The request format varies by provider. In general, they are sent to the supplier

from - departure station

to - arrival station

date - departure date

[0092] The response returns available tickets for the specified date.

number - train number

type - carrier type

departure_date - departure date

departure_time - departure time

arrival_date - arrival date

arrival_time - arrival time

travel_time - travel time

eregistration - electronic registration flag

There are also free seats on the train:
type - type of seat (reserved seat, compartment)

free_seats - number of free seats

class_service - car class

tariff - cost

[0093] This data is sufficient for further preparation of the route.

[0094] The flight class and airline are specified at the search stage. The same search results are aggregated by price, leaving the cheapest option.

[0095] The system selects two route options: the most suitable and the cheapest.

[0096] The quick sort algorithm sorts search results by price and selects the cheapest options. From these results, the “cheapest” option is compiled.

[0097] For “most suitable”, the system leaves only options that match the search criteria, i.e. filters by parameters: carriage type, transfer flag, baggage, return option, airline. It goes through all search results and leaves only options that match the parameters. Just like in the “cheapest” option, the cheapest options are selected.

[0098] If the user is satisfied with the travel conditions, then this route can be added to the cart and booked. Booking takes place automatically. Those. you don’t need to book every service; at this stage, all the data is enough to buy all the services from the trip.

[0099] The system is built on a service-oriented architecture. It can work both on virtual servers and be deployed in cloud hosting. Access to the system is via a web interface using the secure HTTPS protocol. Within the system, services exchange data using the gRPC protocol.

[00100] Search parameters are sent to the d2d-service search service.

[00101] D2d-service is a service located on servers and part of the system. He is responsible for the search as a whole and for exchanging information with the client part of the system.

[00102] A request is received from the client, the web interface, via the HTTPS protocol in JSON format.

Where

DepartureId - id point of departure

ArrivalId - arrival point id

TravelerId - traveler

DepartureLoc - an object with the coordinates of the departure point

ArriavalLoc - an object with the coordinates of the arrival point

Date - departure date

[00103] The request comes to d2d-service. Then the d2d-service checks whether the DepartureId and ArrivalId are set; if these parameters are set, the coordinates of the departure and arrival points are obtained from the directory. The directory is located in a relational database. The data is retrieved by an SQL query.

SELECT * FROM AirlineDictionary WHERE id = <DepartureId>

[00104] Otherwise, the coordinates are taken from DepartureLoc and ArrivalLoc. If DepartureLoc and ArrivalLoc are not set, the request is considered invalid and an error is returned. TravelerId is required to select recommendations. The prepared data is transferred to the route-engine service.

[00105] Then control is transferred to the route-engine, which takes the schedule for the selected dates from the database and builds a route using the RAPTOR algorithm. The service architecture allows you to replace the algorithm with another suitable one. The constructed routes are transferred to the recommendation-service, which, based on neural networks, selects suitable options based on the trained model. Prepared routes are sent to the search-service, which requests information about available places and prices from suppliers. The final output is generated in the aggregation-service and sent to the d2d-service. (Fig. 5). Routes and available travel options from providers as shown in FIG. 6 are passed to the recommendation-service, where all options are checked for compliance with the “portrait” of the user. The cosine distance described above is calculated, including all options, and compared with the model predicted; the best options are saved in the output model.

Claims (9)

A method for generating a door-to-door travel route, performed by at least one computing device and including the following steps: receiving from at least one user device a request via the HTTPS protocol in JSON format to a d2d-service search service located on at least one server, wherein the request includes the exact address of the destination; receive schedules from suppliers on the server; forming at least one route using the RAPTOR algorithm based on data from the user request received in the previous step, while the system calculates the total travel time and selects the fastest route; request information about available seats and prices from suppliers based on prepared routes; obtain search parameters through the use of recurrent artificial neural networks, which make it possible to predict the next element based on the user’s past trips, while for the algorithm to work, the user must have at least five trips to a given direction, according to which the neural network model predicts the next reference route for the user; compare the found routes one by one with the reference route using the cosine proximity method to accurately determine how similar the option from the search results is to the reference route; at least one travel route for use is formed by filtering the travel routes obtained at the previous step, wherein If the user is satisfied with the travel conditions, then this route can be booked automatically.