System and method for recommending transportation travel service
阅读说明:本技术 推荐交通出行服务的系统和方法 (System and method for recommending transportation travel service ) 是由 张凌宇 于 2019-02-03 设计创作,主要内容包括:本申请涉及用于向用户推荐服务类型的系统和方法。该方法包括在设备中获取并存储由用户发出的至少两个先前服务请求,其中,所述至少两个先前服务请求中的每一个包括订单信息,所述订单信息包括请求服务的类型以及服务时间或服务位置中的至少一个。该方法还包括使用处理器基于至少两个先前服务请求的订单信息,生成服务类型预测模型。该方法还包括从用户接收包括当前服务时间或当前服务位置中的至少一个的服务请求,并使用服务类型预测模型,预测用户的首选服务类型。(The present application relates to systems and methods for recommending service types to users. The method includes obtaining and storing, in a device, at least two previous service requests issued by a user, wherein each of the at least two previous service requests includes order information including a type of a requested service and at least one of a service time or a service location. The method also includes generating, using the processor, a service type prediction model based on the order information of the at least two previous service requests. The method also includes receiving a service request from the user including at least one of a current service time or a current service location, and predicting a preferred service type of the user using a service type prediction model.)
1. A method, implemented on a device comprising at least one processor and at least one computer-readable storage medium, for recommending service types to a user, the method comprising:
obtaining and storing in the device at least two previous service requests issued by the user, wherein each of the at least two previous service requests comprises order information comprising a type of the requested service and at least one of a service time or a service location;
generating, using the processor, a service type prediction model based on the order information of the at least two previous service requests;
receiving a service request including at least one of a current service time or a current service location from the user; and
and predicting the preferred service type of the user by using the service type prediction model.
2. The method of claim 1, wherein the preferred service type has a user interface corresponding thereto, and wherein the method further comprises providing the user with a user interface corresponding to the preferred service type.
3. Method according to claim 1 or 2, characterized in that said service location comprises a specific location or a statistical geographical area comprising said specific location.
4. Method according to any of the preceding claims, wherein the service time comprises a specific point in time or a target statistical time period comprising the specific point in time.
5. The method of any of the preceding claims, wherein the service type prediction model is based on a Markov model, a Gaussian mixture model, a Bayesian model, or a combination thereof.
6. Method according to any of the preceding claims, characterized in that the service type prediction model is generated by:
performing cluster analysis on the requested service types based on at least one of the corresponding service time or service location, obtaining a Gaussian mixture model for each service type, an
Determining a probability density value of each type of service according to the Gaussian mixture model, wherein the preferred service type of the user is predicted based on the probability density value.
7. The method of claim 6, wherein the preferred service type of the user is predicted by:
determining a first probability value for each service type using a Bayesian model and the probability density values; and
the service type with the highest first probability value is designated as the preferred service type for the user.
8. The method of claim 7, wherein the specifying comprises:
determining the type of service having the highest first probability value and whether the highest first probability value is greater than or equal to a first preset threshold; and
if so, the type of service with the highest first probability value is specified and recommended as the preferred service type for the user.
9. The method of claim 6, further comprising, prior to performing the steps of claim 6:
determining a frequency of each service type based on the order information of the at least two previous service requests issued by the user, generating a Markov model;
obtaining a second probability value of each service type by inputting the last service type requested by the user into the Markov model;
determining whether the service type having the highest second probability value and the highest second probability value are greater than or equal to a second preset threshold; and
if yes, the service type with the highest second probability value is designated and recommended as a preferred service type of the user, or
If not, the steps of claim 6 are performed.
10. A method implemented on a device comprising at least one processor and at least one computer readable storage medium for estimating order success rates for different travel services for a user requesting travel services from one physical location at a particular service request time, the method comprising:
upon sensing that the user turns on a transit user interface (interface), providing at least two transit services to the user on the interface;
obtaining the physical location of the user; and
estimating, at the physical location of the user, an order success rate for each of the at least two travel services based on pre-established evaluation criteria.
11. The method of claim 10, further comprising:
and sending the estimated order success rate matched with each transportation travel service on the interface.
12. The method of claim 10 or 11, wherein the pre-established evaluation criteria comprise statistical time period evaluation criteria and statistical geographic area evaluation criteria, and the order success rate estimation step comprises:
determining that the opening time of the interface belongs to a target statistical time period;
determining that the physical location of the user belongs to a target statistical geographic area;
obtaining the historical order success rate of each transportation travel service in the target statistical geographic area within the target statistical time period by performing statistical analysis on the total number of available transportation travel services and service requests within the target statistical geographic area within the target statistical time period; and
based on the historical order success rates, an order success rate for each of the more than one transit travel services is pre-estimated.
13. The method of claim 12, wherein the pre-established evaluation criteria further comprises at least one of weather conditions including special weather conditions and traffic conditions including traffic congestion, the method further comprising:
if at the service time and the user physical location, at least one of a special weather condition or a certain traffic jam degree exists based on the property of each traffic travel service, determining an influence factor of the special weather condition or the specific traffic jam degree on each of the at least two traffic travel services, and
based on their corresponding historical order success rates and impact factors, the order success rate is pre-estimated for each of the at least two transit travel services at the user physical location.
14. The method of claim 12, further comprising:
obtaining a date of the service request and determining a target statistical date based on the date of the service request, an
And determining the historical order success rate of the date corresponding to the target statistical date.
15. The method of any preceding claim, further comprising:
determining whether the estimated order success rate of each of the two travel services is less than a preset order success rate threshold value; and
for the travel service with the estimated order success rate smaller than the preset order success rate threshold,
acquiring the historical order success rate of each transportation travel service in a time period (delayed time period) subsequent to the service request time; and
and sending the historical order success rates of the transportation travel services together with the corresponding delayed time periods, and respectively matching with the transportation travel services on the interface.
16. A method, implemented on a device comprising at least one processor and at least one computer-readable storage medium, for recommending a mode of travel to a user over a travel route, wherein the travel route includes at least two road segments, each road segment having a road segment route, the method comprising:
acquiring and storing in the storage medium previous travel data for each road segment route of the user, including a departure position and time (departure data), an arrival position and time (arrival data), and a used travel mode of transportation;
retrieving and using, by the processor, the departure data and the arrival data, determining a correlation between routes for each road segment, generating a personalized travel route for the user, each route including one or more road segments;
retrieving and using the travel modes of each road section through the processor, determining the use frequency of each travel mode on each road section on each personalized travel route, and establishing a travel mode estimation model;
selecting a recommended travel route from the personalized travel routes based on the current position of the user, wherein the recommended travel route comprises a recommended road section; and
and predicting the traffic travel mode of each recommended road section by using the traffic travel mode estimation model, and generating a recommended traffic travel mode for each recommended road section.
17. The method of claim 16, further comprising sending the user a recommended travel route and a recommended travel mode for each recommended road segment.
18. The method according to claim 16 or 17, wherein the personalized travel route is generated by the steps of:
based on SiTime of arrival and Si+1Determining each two consecutive road sections SiAnd Si+1The time interval in between;
if the time interval is less than or equal to a first time interval threshold, there is a correlation between the two consecutive road segments; and
and connecting the relevant road sections to generate the personalized travel route.
19. The method of claim 18, further comprising:
if the time interval is greater than the first time interval threshold but less than or equal to a second time interval threshold,
based on SiIs reached and Si+1Determining each two consecutive road sections SiAnd Si+1The distance interval therebetween;
if the distance separation is less than or equal to a first distance separation threshold, there is a correlation between the two consecutive road segments; and
and connecting the relevant road sections to generate the personalized travel route.
20. The method of claim 16, further comprising:
acquiring the road condition of each road section; and
and optimizing the traffic travel mode estimation model based on the road condition of each road section.
21. A system for recommending service types to a user, comprising:
at least one storage medium comprising a set of instructions; and
at least one processor is configured to communicate with the at least one storage medium, wherein the at least one processor, when executing the set of instructions, is configured to:
obtaining and storing in the device at least two previous service requests issued by the user, wherein each of the at least two previous service requests comprises order information comprising the type of requested service and at least one of a service time or a service location;
generating, using the processor, a service type prediction model based on the order information of the at least two previous service requests;
receiving a service request including at least one of a current service time or a current service location from the user; and
and predicting the preferred service type of the user by using the service type prediction model.
22. The system of claim 21, wherein the preferred service type has a user interface corresponding thereto, and wherein the at least one processor is further configured to provide the user with the user interface corresponding to the preferred service type.
23. The system according to claim 21 or 22, wherein said service location comprises a specific location or a statistical geographical area comprising said specific location.
24. The system according to any of the preceding claims, characterized in that the service time comprises a specific point in time or a target statistical time period comprising the specific point in time.
25. The system of any preceding claim, wherein the service type prediction model is based on a markov model, a gaussian mixture model, a bayesian model, or a combination thereof.
26. The system according to any of the preceding claims, characterized in that the service type prediction model is generated by the steps of:
performing cluster analysis on the requested service types based on the corresponding at least one of the service time or the service location, obtaining a Gaussian mixture model for each service type, an
Determining a probability density value of each type of service according to the Gaussian mixture model, wherein the preferred service type of the user is predicted based on the probability density value.
27. The system of claim 26, wherein the preferred service type of the user is predicted by:
determining a first probability value for each service type using a Bayesian model and the probability density values; and
assigning the service type having the highest first probability value as a preferred service type for the user.
28. The system of claim 27, wherein the specifying comprises:
determining the type of service having the highest first probability value and whether the highest first probability value is greater than or equal to a first preset threshold; and
if so, the type of service having the highest first probability value is specified and recommended as the preferred service type for the user.
29. The system of claim 26, the at least one processor, prior to implementing the steps of claim 26, further configured to:
determining the frequency of each service type based on the order information of the at least two previous service requests issued by the user, generating a Markov model;
obtaining a second probability value for each service type by inputting the last service type requested by the user into the Markov model;
determining whether the service type having the highest second probability value and the highest second probability value are greater than or equal to a second preset threshold; and
if yes, the service type with the highest second probability value is designated and recommended as a preferred service type of the user, or
If not, the steps of claim 26 are performed.
30. A system for predicting order success rates for different transit travel services at a service request time for a user requesting transit travel services from a physical location, comprising:
at least one storage medium comprising a set of instructions; and
at least one processor is configured to communicate with the at least one storage medium, wherein the at least one processor, when executing the set of instructions, is configured to:
upon sensing that the user turns on a transit user interface (interface), providing at least two transit services to the user on the interface;
obtaining the physical location of the user; and
estimating the physical location of the user, and based on pre-established evaluation criteria, providing an order success rate for each of the at least two travel services.
31. The system of claim 30, the at least one processor further configured to:
and sending the estimated order success rate matched with each transportation travel service on the interface.
32. The system of claim 30 or 31, wherein the pre-established evaluation criteria comprise statistical time period evaluation criteria and statistical geographic area evaluation criteria, and wherein the at least one processor is configured to predict the order success rate, and wherein the at least one processor is configured to:
determining that the opening time of the interface belongs to a target statistical time period;
determining that the physical location of the user belongs to a target statistical geographic area;
obtaining a historical order success rate of each transportation travel service within the target statistical time period within the target statistical geographic area by performing statistical analysis on a plurality of available transportation travel services and a total number of service requests provided within the target statistical time period within the target statistical geographic area; and
predicting the order success rate for the each of the more than one transit travel services based on the historical order success rates.
33. The system of claim 32, wherein the pre-established evaluation criteria further comprises at least one of weather conditions and traffic conditions, wherein the weather conditions comprise special weather conditions, and wherein the traffic conditions comprise traffic congestion, and wherein the at least one processor is further configured to:
determining an impact factor imposed by at least one of a special weather condition or a degree of traffic congestion on each of the at least two travel services if at the service time and the user physical location, based on the nature of each travel service, there is at least one of a special weather condition or a degree of traffic congestion, and
based on their corresponding historical order success rates and impact factors, the order success rate is pre-estimated for each of the at least two transit travel services at the user physical location.
34. The system of claim 32, the system of at least one processor further configured to:
obtaining a date of the service request and determining a target statistical date based on the date of the service request, an
And determining the historical order success rate of the date corresponding to the target statistical date.
35. The system of any of the preceding claims, the at least one processor further configured to:
determining whether the estimated order success rate of each of the two travel services is less than a preset order success rate threshold; and
for the travel service with the estimated order success rate smaller than the preset order success rate threshold,
acquiring the historical order success rate of each transportation travel service in a time period (delayed time period) subsequent to the service request time; and
and sending the historical order success rates of the travel services together with the corresponding delayed time periods, and respectively matching the historical order success rates with the travel services on the interface.
36. A system for recommending a mode of transportation for a user on a travel route, wherein the travel route includes at least two segments, each segment having a segment route, comprising:
at least one storage medium comprising a set of instructions; and
at least one processor is configured to communicate with the at least one storage medium, wherein the at least one processor, when executing the set of instructions, is configured to:
acquiring and storing in the storage medium previous travel data for each road segment route of the user, including a departure position and time (departure data), an arrival position and time (arrival data), and a used travel mode of transportation;
retrieving and using, by the processor, the departure data and the arrival data, determining a correlation between routes for each of the road segments, generating personalized travel routes for the user, each route including one or more road segments;
retrieving and using the travel modes of each road section through the processor, determining the use frequency of each travel mode on each road section on each personalized travel route, and establishing a travel mode estimation model;
selecting a recommended travel route based on the current position of the user, wherein the recommended travel route comprises a recommended road section from the personalized travel route; and
and predicting the traffic travel mode of each recommended road section by using the traffic travel mode estimation model, and generating a recommended traffic travel mode for each recommended road section.
37. The system of claim 36, the at least one processor further configured to send the recommended travel route and a recommended mode of travel for each recommended road segment to the user.
38. The system according to claim 36 or 37, wherein the personalized travel route is generated by the steps of:
based on SiOf said arrival time sum Si+1Determining every two consecutive road sections SiAnd Si+1The time interval in between;
if the time interval is less than or equal to a first time interval threshold, there is a correlation between the two consecutive road segments; and
and connecting the relevant road sections to generate the personalized travel route.
39. The system of claim 38, further comprising:
if the time interval is greater than the first time interval threshold but less than or equal to a second time interval threshold,
based on SiOf said arrival position and Si+1Determining every two consecutive road sections SiAnd Si+1The distance interval therebetween;
if the distance separation is less than or equal to a first distance separation threshold, there is a correlation between the two consecutive road segments; and
and connecting the relevant road sections to generate the personalized travel route.
40. The system of claim 36, the at least one processor further configured to:
acquiring the road condition of each road section; and
and optimizing the traffic travel mode estimation model based on the road condition of each road section.
41. A non-transitory computer-readable medium comprising at least one set of instructions for recommending service types to a user, wherein the at least one set of instructions, when executed by at least one processor of a computing device, cause the computing device to perform a method comprising:
obtaining and storing in the device at least two previous service requests issued by the user, wherein each of the at least two previous service requests comprises order information comprising a type of the requested service and at least one of a service time or a service location;
generating, using the processor, a service type prediction model based on the order information of the at least two previous service requests;
receiving a service request including at least one of a current service time or a current service location from the user; and
and predicting the preferred service type of the user by using the service type prediction model.
42. A non-transitory computer-readable medium comprising at least one set of instructions for estimating an order success rate for different travel services for a user requesting travel services from one physical location at a particular service request time, wherein the at least one set of instructions, when executed by at least one processor of a computing device, cause the computing device to perform a method comprising:
upon sensing that the user turns on a transit user interface (interface), providing at least two transit services to the user on the interface;
obtaining the physical location of the user; and
estimating, at the physical location of the user, an order success rate for each of the at least two travel services based on pre-established evaluation criteria.
43. A non-transitory computer-readable medium comprising at least one set of instructions for recommending a mode of travel to a user on a travel route, wherein the travel route comprises at least two road segments, each road segment having a road segment route, wherein the at least one set of instructions, when executed by at least one processor of a computing device, cause the computing device to perform a method comprising:
in the storage medium, the previous travel data of each road segment route of the user includes a departure position and time (departure data), an arrival position and time (arrival data), and a used travel mode;
retrieving and using, by the processor, the departure data and the arrival data, determining a correlation between routes for each of the road segments, generating personalized travel routes for the user, each route including one or more road segments;
retrieving and using the travel modes of each road section through the processor, determining the use frequency of each travel mode on each road section on each personalized travel route, and establishing a travel mode estimation model;
selecting a recommended travel route from the personalized travel routes based on the current position of the user, wherein the recommended travel route comprises a recommended road section; and
and predicting the traffic travel mode of each recommended road section by using the traffic travel mode estimation model, and generating a recommended traffic travel mode for each recommended road section.
Technical Field
The present application relates generally to online services and, more particularly, to a system and method for recommending travel types in an online service.
Background
In one aspect, the use of smart terminals for online automobiles has become more and more popular with the development of internet technology. According to the service type requested by the user, the service platform provides a corresponding user interface for the requested service type, so that the user can place an order in the corresponding user interface.
In the prior art, in order to enable a user to quickly request a service, a service platform can predict the type of service that the user needs at the moment and switch from the current user interface to the user interface corresponding to the requested service, so as to reduce the time taken to manually select a desired user interface among the user interfaces in an application.
However, the type of service is typically predicted based on the type of service previously ordered by the user. In practical applications, the accuracy of such predictions is not high enough. Due to inaccurate predictions, the user always needs to manually select the required user interface, and the time consumed to place an order will increase.
On the other hand, taking e-commerce technology providing a transit travel service as an example, an existing transit travel platform may provide a user with different travel options, and the user may reserve a vehicle in advance before he/she travels, for example, a taxi, a private car (e.g., express, special, right-hand), a bicycle, etc., and reserve information of the vehicle, for example, a departure time of a bus, a train, etc., may be transmitted to the user. However, if more choices are provided for the travel service, it should be considered which travel service the user may prefer, or which may improve efficiency. Taking the actual scenario where the user requests a service as an example, during peak hours in the evening, the user may choose to have him/her wait for a long time for express service because the driver who is not providing express service accepts the order. If a user attempts to call out a taxi, and it may happen that no taxi driver accepts the order after a long period of time (e.g., 2 minutes). The user may then need to request a special car. The three travel services have different prices. The price of the express service is lower than that of the taxi service, and the price of the taxi service is lower than that of the special taxi service. However, in this case, many users are willing to pay more money for the special car service rather than waiting longer.
However, in the prior art, this occurs because the user cannot know which travel service he/she should select in order for the driver to accept the order before he/she tries each travel service, which takes more time.
On the other hand, in an actual scenario, a user often needs to transition between different types of vehicles in a travel route. For example, when a user starts his/her trip from a (near location a) to B (near location B), the user may need to ride a bike from a to a nearby subway station, then a subway to another subway station near B, then a express or taxi to B. Of course, there are other travel patterns from a to B. For example, a user may ride a bus from a to a nearby bus stop, then ride a bus to another bus stop near B, and then ride a bicycle to B.
It can be seen that as the number of travel stations and travel modes increases, the complexity of planning a trip increases, considering how to reach another travel station, consuming more energy and time, and which travel mode to take, results in inefficiency. Accordingly, a system and method for improving efficiency and saving travel time is desired.
Disclosure of Invention
According to one aspect of the present application, a method for recommending a service type to a user is provided. The method may include obtaining and storing, in the device, at least two previous service requests issued by the user, wherein each of the at least two previous service requests includes order information including a type of requested service and at least one of a service time or a service location; generating, using a processor, a service type prediction model from order information of at least two previous service requests; receiving a service request including at least one of a current service time or a current service location from a user; and predicting the preferred service type of the user by using the service type prediction model.
According to another aspect of the present application, a system for recommending service types to a user is provided. The system may include at least one storage medium comprising a set of instructions; at least one processor configured to communicate with the at least one storage medium, wherein the set of instructions, when executed, direct the at least one processor to obtain and store in the device at least two previous service requests issued by a user, wherein each at least two previous service requests includes order information including a type of requested service and at least one of a service time or a service location; generating, using a processor, a service type prediction model from order information of at least two previous service requests; receiving a service request including at least one of a current service time or a current service location from a user; and predicting the preferred service type of the user by using the service type prediction model.
According to another aspect of the present application, a non-transitory computer-readable medium is provided. A non-transitory computer-readable medium includes at least one set of instructions for recommending a service type to a user, wherein the at least one set of instructions, when executed by at least one processor of a computing device, cause the computing device to perform a method. The method includes obtaining and storing in the device at least two previous service requests issued by a user, wherein each of the at least two previous service requests includes order information including a type of requested service and at least one of a service time or a service location; generating, using a processor, a service type prediction model from order information of at least two previous service requests; receiving a service request including at least one of a current service time or a current service location from a user; and predicting the preferred service type of the user by using the service type prediction model.
In some embodiments, the preferred service type has a user interface corresponding thereto, and the method further comprises providing the user with a user interface corresponding to the preferred service type.
In some embodiments, the service location comprises a particular location or a statistical geographic area comprising a particular location.
In some embodiments, the service time comprises a specific point in time or a target statistical time period comprising a specific point in time.
In some embodiments, the service type prediction model is based on a markov model, a gaussian model, a mixed gaussian model, a bayesian model, or a combination thereof.
In some embodiments, the service type prediction model is generated by performing cluster analysis on the requested service type based on at least one of service time or service location, obtaining a mixture gaussian model for each service type, and determining a probability density value for each type of service according to the mixture gaussian model, wherein a preferred service type of the user is predicted based on the probability density value.
In some embodiments, a first probability value for each service type is determined by predicting a preferred service type for a user using a bayesian model and a probability density value; and designates the service type having the highest first probability value as the preferred service type of the user.
In some embodiments, specifying includes determining a type of service having a highest first probability value, and whether the highest first probability value is greater than or equal to a first preset threshold; if so, the service type with the highest first probability value is specified and recommended as the preferred service type of the user.
In some embodiments, before the step of generating the service type prediction model is implemented, the method further comprises determining a frequency of each service type based on order information of at least two previous service requests issued by the user, and generating a markov model; inputting the last service type requested by the user into a Markov model to obtain a second probability value of each service type; determining the service type with the highest second probability value and whether the highest second probability value is greater than or equal to a second preset threshold value; if so, the service type with the highest second probability value is appointed and recommended as the preferred service type of the user, or if not, a service type prediction model generation step is executed.
According to one aspect of the present application, a method for predicting order success rates of different transportation services for a user requesting transportation services from a physical location at a service request time is provided. The method may include providing at least two travel services to a user on an interface when the user senses activation of a travel user interface (interface); acquiring a physical position of a user; estimating, at the physical location of the user, an order success rate for each of the at least two travel services based on pre-established evaluation criteria.
According to another aspect of the present application, a system for predicting order success rates for different transportation services at a service request time for a user requesting transportation services from a physical location is provided. The system may include at least one storage medium comprising a set of instructions; at least one processor is configured to communicate with at least one storage medium, wherein the at least one processor, when executing a set of instructions, directs a user to provide at least two transit travel services to the user on an interface when the user senses activation of the transit travel user interface (interface); acquiring a physical position of a user; and, based on pre-established evaluation criteria, estimating an order success rate for each of the at least two travel services at the user's physical location.
According to another aspect of the present application, a non-transitory computer-readable medium is provided. A non-transitory computer-readable medium includes at least one set of instructions for estimating an order success rate for different transportation services when a user requests a transportation service from one physical location at a particular service request time, wherein the at least one set of instructions, when executed by at least one processor of a computing device, cause the computing device to perform a method. The method may include providing at least two travel services to a user on an interface when the user senses activation of a travel user interface (interface); acquiring a physical position of a user; estimating, at the physical location of the user, an order success rate for each of the at least two travel services based on pre-established evaluation criteria.
In some embodiments, the method further includes sending a predicted order success rate matching each of the travel services on the interface.
In some embodiments, the pre-established evaluation criteria include statistical time period evaluation criteria and statistical geographic area evaluation criteria, and the order success rate estimating step includes determining that the interface opening time belongs to a target statistical time period; determining a target statistical geographic area where a physical position of a user is; the method comprises the steps that through statistical analysis of the total number of a plurality of available travel services and service requests provided in a target statistical geographic area within a target statistical time period, the historical order success rate of each travel service in the target statistical geographic area within the target statistical time period is obtained; the order success rate of each of the plurality of types of travel services is estimated based on the historical order success rate.
In some embodiments, the pre-established evaluation criteria further comprises at least one of weather conditions and traffic conditions, the weather conditions comprising particular weather conditions, and the traffic conditions comprising traffic congestion degrees. The method further comprises the following steps: if at the service time and the user physical location, at least one of special weather conditions or certain traffic jam degrees exists based on the properties of each kind of traffic travel service, determining an influence factor exerted on each kind of the at least two kinds of traffic travel services by at least one of the special weather conditions or the certain traffic jam degrees, and estimating the order success rate of each kind of the at least two kinds of traffic travel services at the user physical location based on the corresponding historical order success rate and the influence factor.
In some embodiments, the method further includes obtaining a date of the service request and determining a target statistical date based on the date of the service request, and determining a historical order success rate for a date corresponding to the target statistical date.
In some embodiments, the method further comprises determining whether the estimated order success rate for each of the two travel services is less than a preset order success rate threshold; for the transportation travel services with the estimated order success rate smaller than the preset order success rate threshold, acquiring the historical order success rate of each transportation travel service in a time period (delayed time period) subsequent to the service request time; and the historical order success rates of the travel services and the corresponding delayed time periods are sent together and are respectively matched with the travel services on the interface.
According to one aspect of the present application, a method for recommending a mode of travel to a user on a travel route is provided, wherein the travel route includes at least two road segments, each road segment having a road segment route. The method may include acquiring and storing in a storage medium previous travel data for each road segment route of the user, including a departure location and time (departure data), an arrival location and time (arrival data), and a used travel mode of transportation; the processor retrieves and uses the departure data and the arrival data of the road sections, determines the correlation between routes of each road section, and generates a personalized travel route for the user, wherein each route comprises one or more road sections; retrieving and using the traffic travel mode of each road section through a processor, determining the use frequency of each traffic travel mode on each road section on each personalized travel route, and establishing a traffic travel mode estimation model; selecting a recommended travel route from the personalized travel routes according to the current position of the user, wherein the recommended travel route comprises a recommended road section; and predicting the traffic travel mode of each recommended road section by using the traffic travel mode estimation model, and generating the recommended traffic travel mode for each recommended road section.
According to another aspect of the present application, there is provided a system for recommending a transportation travel pattern to a user on a travel route, wherein the travel route includes at least two road segments, each road segment having a road segment route. The system may include at least one storage medium comprising a set of instructions; at least one processor is configured to communicate with at least one storage medium, wherein the at least one processor, when executing a set of instructions, is directed to obtain and store in the storage medium user previous travel data for each road segment route, including departure location and time (departure data), arrival location and time (arrival data), and used travel mode; the processor retrieves and uses the departure data and the arrival data of the road sections, determines the correlation between routes of each road section, and generates a personalized travel route for the user, wherein each route comprises one or more road sections; retrieving and using the traffic travel mode of each road section through a processor, determining the use frequency of each traffic travel mode on each road section on each personalized travel route, and establishing the traffic travel mode of the pre-estimated model; selecting a recommended travel route from the personalized travel routes according to the current position of the user, wherein the recommended travel route comprises a recommended road section; and predicting the traffic travel mode of each recommended road section by using the traffic travel mode estimation model, and generating the recommended traffic travel mode for each recommended road section.
According to another aspect of the present application, a non-transitory computer-readable medium is provided. A non-transitory computer-readable medium includes at least one set of instructions for recommending a mode of travel to a user over a travel route, wherein the travel route includes at least two road segments, each road segment having a road segment route, wherein the at least one set of instructions, when executed by at least one processor of a computing device, cause the computing device to perform a method. The method may include acquiring and storing in a storage medium previous travel data for each road segment route of the user, including a departure location and time (departure data), an arrival location and time (arrival data), and a used travel mode of transportation; the processor retrieves and uses the departure data and the arrival data of the road sections, determines the correlation between routes of each road section, and generates a personalized travel route for the user, wherein each route comprises one or more road sections; retrieving and using the traffic travel mode of each road section through a processor, determining the use frequency of each traffic travel mode on each road section on each personalized travel route, and establishing a traffic travel mode estimation model; selecting a recommended travel route from the personalized travel routes according to the current position of the user, wherein the recommended travel route comprises a recommended road section; and predicting the traffic travel mode of each recommended road section by using the traffic travel mode estimation model, and generating the recommended traffic travel mode for each recommended road section.
In some embodiments, the method further comprises sending the recommended travel route for each recommended road segment and the recommended mode of travel for each recommended road segment to the user.
In some embodiments, by being based on SiTime of arrival and Si+1Determining each two consecutive road sections SiAnd Si+1Generating personalized travel routes at intervals; if the time interval is less than or equal to the first time interval threshold, there is a correlation between two consecutive road segments; and connecting the relevant road sections to generate a personalized travel route.
In some embodiments, the method further comprises if the time interval is greater than the first time interval threshold but less than or equal to the second time interval threshold, according to SiIs reached and Si+1Determining each two consecutive road sections SiAnd Si+1The distance interval therebetween; if the distance separation is less than or equal to a first distance separation threshold, there is a correlation between two consecutive road segments; and connecting the relevant road sections to generate a personalized travel route.
In some embodiments, the method further comprises obtaining road conditions on each road segment; and optimizing a traffic travel mode estimation model based on the road condition of each road section.
Additional features of the present application will be set forth in part in the description which follows. Additional features of some aspects of the present application will be apparent to those of ordinary skill in the art in view of the following description and accompanying drawings, or in view of the production or operation of the embodiments. The features of the present application may be realized and attained by practice or use of the methods, instrumentalities and combinations of the various aspects of the specific embodiments described below.
Drawings
The present application will be further described by way of exemplary embodiments. These exemplary embodiments will be described in detail by means of the accompanying drawings. The figures are not drawn to scale. These embodiments are non-limiting exemplary embodiments in which like reference numerals refer to similar structures in each of the figures and wherein:
FIG. 1 is a schematic diagram of an exemplary outgoing communication recommendation system, shown in accordance with some embodiments of the present application;
FIG. 2 is a schematic diagram of exemplary components of a computing device shown in accordance with some embodiments of the present application;
FIG. 3 is a schematic diagram of exemplary hardware and/or software components of an exemplary user terminal according to some embodiments of the present application;
FIG. 4 is a flow diagram of an exemplary process of predicting a service type, shown in accordance with some embodiments of the present application;
FIG. 5 is a flow diagram of a
fig. 6A and 6B are schematic diagrams of frequencies of requesting taxi service and express service, respectively, according to some embodiments of the present application;
FIG. 7 is a flow diagram of a process 700 for predicting a service type, according to some embodiments of the present application;
FIG. 8 is a schematic diagram of a service type prediction device according to some embodiments of the present application;
FIG. 9 is a flow chart of a
FIG. 10 is a flow chart of a
FIG. 11A is a flow chart of a
FIG. 11B is a schematic diagram of a user interface displaying a travel service according to some embodiments of the present application;
FIG. 11C is a schematic view of a user interface displaying a transit travel service in accordance with some embodiments of the present application;
FIG. 12 is a schematic diagram of an order success rate estimation device according to some embodiments of the present application;
FIG. 13 is a flow chart of a
FIG. 14 is a flow chart illustrating a
fig. 15 is a schematic diagram of a travel mode recommendation device according to some embodiments of the present application.
Detailed Description
Detailed description in order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings used in the description of the embodiments will be briefly introduced below. It is obvious that the drawings in the following description are only examples or embodiments of the application, from which the application can also be applied to other similar scenarios without inventive effort for a person skilled in the art. Unless otherwise apparent from the context of language or otherwise indicated, like reference numerals in the figures refer to like structures and operations.
As indicated in the present application and claims, unless the context clearly dictates otherwise,
the terms "a", "an" and/or "the" are not intended to be inclusive of the singular, but may include the plural. It will be further understood that the terms "comprises" and/or "comprising," when used in this application, specify the presence of stated steps or elements, but do not constitute an exclusive list, and may include other steps or elements.
Although various references are made herein to certain modules in a system according to embodiments of the present application, any number of different modules may be used and run on a client and/or server. These modules are intended to be illustrative, and not to limit the scope of the present application. Different modules may be used in different aspects of the systems and methods.
Flow charts are used herein to illustrate operations performed by systems according to embodiments of the present application. It should be understood that the preceding and following operations are not necessarily performed in the exact order in which they are performed. Rather, various steps may be processed in reverse order or simultaneously. Also, other operations may be added to the processes or one or more operations may be removed from the processes.
Technical solutions of embodiments of the present application are described with reference to drawings described below. It will be clear that the described embodiments are not exhaustive and are not limiting. In the embodiments of the present application, other embodiments that may be obtained by one of ordinary skill in the art without any inventive work are within the scope of the present application.
Some embodiments of the present application relate to online service forecast functionality applicable to, for example, on-demand services, which are emerging services or needs rooted only in the late internet era. It provides technical solutions for customers, which are only emerging in the post internet era. In the former internet era, the type of service requested by a user cannot be predicted. Thus, the present solution is deeply rooted and intended to solve the problems occurring only in the late internet era.
FIG. 1 illustrates an exemplary network environment of a transit travel recommendation system according to some embodiments of the present application. The transit
The transit
The
In some embodiments, the
In some embodiments, the
The
The customer may receive a service response for the trip through the
The driver can receive a service request via the
In some embodiments,
In some embodiments, one or more components in the transit
The positioning device 160 can determine information associated with an object (e.g., one or more of the
It will be understood by those of ordinary skill in the art that when an element of the transit
FIG. 2 is a schematic diagram of exemplary components of a computing device shown in accordance with some embodiments of the present application. According to some embodiments of the present application, the
For example, the
An exemplary computing device may include an
For illustration only, only one processor and/or processors are shown in FIG. 2. Multiple CPUs and/or processors are also contemplated; thus, operations and/or method steps described herein as being performed by one CPU and/or processor may also be performed by multiple CPUs and/or processors, either jointly or separately. For example, if in the present application, the CPUs and/or processors of
Fig. 3 is a block diagram of exemplary hardware and/or software components of an exemplary requester terminal shown in accordance with some embodiments of the present application. According to some embodiments of the present application, the
To implement the various modules, units, and their functionality described above, a computer hardware platform may be used as the hardware platform for one or more elements (e.g., components of
For the purpose of illustrating the disclosed embodiments, the technical solutions and advantages thereof, will be apparent from the following detailed description, taken in conjunction with the accompanying drawings.
With the development of internet technology, the use of online automobile intelligent terminals is more and more popular. With the development of car booking services, users can select various types of car booking services on a service platform, such as: taxis, express cars, special cars, carpooling, car rentals, and the like.
In the prior art, different types of services have different ordering interfaces due to the different charging mechanisms and call mechanisms for each service type. To enable a user to more quickly place an order or pay a bill, the service platform predicts the user's likely service type and switches to an order interface corresponding to the predicted service type when the user logs into or triggers the order interface of the service platform.
However, existing predictions of the user's current service type are determined based on the type of service the user requested in previous orders. Taking the previous order of the user as an example in relation to the "express" service, when the user starts the service platform, the service platform will automatically display the "express" interface, which is not in line with the actual needs of the user. That is, if the type of service required by the user is not "express", the user needs to switch to another ordering interface, thereby reducing the efficiency of requesting the service. Therefore, how to improve the accuracy of service type prediction to make the predicted service type consistent with the service type actually required by the user, thereby improving the efficiency has become a technical problem to be solved.
Fig. 4 is a flow diagram of a
In 401, order information of a user's previous service request may be obtained. The order information may include a type of the requested service and at least one of a service time or a service location. In some embodiments, the order information may be obtained by the
In 402, a service type prediction model may be generated based on order information of previous service requests, and when a service request including at least one of a current requested service time or a current requested service location is received from a user, a preferred service type may be predicted using the service type prediction model. In some embodiments, the service type prediction model may be generated by the
It should be noted that the execution subject (e.g., process 400) of the service type prediction methods described herein may specifically be a service type prediction device, and the service type prediction device may be implemented by hardware and/or software. In general, the service type prediction apparatus may be integrated into a cloud server in which a service platform is implemented, and used together with a data server in which various databases are stored and the service platform is implemented. In addition, the server in which the prediction device is implemented may be the same as the data server, or another server of the same server cluster as the data server, which is not limited in this application.
Previous service requests refer to service requests made by the user during a historical period of time (e.g., yesterday, last week, last month, last three months, etc.). In some embodiments, the user's previous service request may relate to a car appointment service request requested by the user through the service platform. The car appointment service may be a real-time service or a subscription service. The car appointment service may include, but is not limited to, a taxi service, a express service, a driver service, a ride share service, a car rental service, a car pooling service, and the like.
In some embodiments, the order information for each previous service request may include the type of service requested, the time of service, and/or the location of the service. In some embodiments, the order information may also include an order number, price, and the like. In some embodiments, the service time may include a specific point in time or a target statistical time period including the specific point in time. For example only, the service time may specifically be a start time of the request service, an end time of the request service, a wait time of the request service, or the like, or a combination thereof. In some embodiments, the service location may comprise a particular location or a statistical geographic area comprising a particular location. For example only, the service location may include a departure location of the requested service, an arrival location of the requested service, or the like, or a combination thereof.
Since the order information of previous service requests includes various types of information, the analysis of the information may indicate the user's preferences/behavior for the service type (i.e., the probability of the user selecting the service type in certain specific scenarios).
For example, most of the user's prior service requests on weekdays (i.e., monday through friday) are taxi services, and most of the prior service requests on saturday and sunday are express services. By analyzing the user's preferences/behavior based on service time, it can be concluded that the probability of the user selecting taxi service on weekdays is relatively high, and the probability of the user selecting express service on holidays is also relatively high. As another example, most previous service requests for service locations at or near an office building are taxi services, and the service locations for most previous service requests are express services at or near the community.
The office building may be the user's workplace by analyzing the user's preferences/behaviors based on the service location. When the user leaves his/her work location to reach the destination, the probability that the user selects a taxi service is relatively high. The community may be the user's home. When the user leaves his/her home to reach the destination, the probability that the user selects the express service is relatively high. The user's behavior rules or preferences may be comprehensively analyzed in consideration of service time and/or service location to obtain a probability that the user selects a service type in a particular scenario.
Thus, the mathematical model may represent the behavior/preference pattern of the user. In some embodiments, a service type prediction model may be constructed to predict the service type of a user's real-time service request. The service type prediction models may include, but are not limited to, markov models, gaussian models, mixed gaussian models, bayesian models, and the like. The service type prediction model can be used for identifying a historical scene similar to the current scene according to the current request service time and/or the current request service position of the user, and designating the service type in the historical scene as the preferred service type of the user. As used herein, the current requested service time refers to the service time of the current order, and the current requested service location refers to the service location of the current order.
The method for predicting service types provided in the
It should be noted that the foregoing is provided for illustrative purposes only and is not intended to limit the scope of the present application. Various changes and modifications can be made by one of ordinary skill in the art in light of the description herein. For example, the
Fig. 5 is a flow diagram of a
In 501, order information for a user's previous service request may be obtained. The order information may include a type of the requested service and at least one of a service time or a service location.
In 502, a cluster analysis may be performed on each type of service in at least two previous service requests based on service time and/or service location to generate a Gaussian mixture model corresponding to each service type. In some embodiments, the cluster analysis may be performed by the
At 503, the
At 504, a preferred service type of the user may be predicted based on the probability density value.
The embodiments provided in
The embodiment described in
It should be noted that the foregoing is provided for illustrative purposes only and is not intended to limit the scope of the present application. Various changes and modifications can be made by one of ordinary skill in the art in light of the description herein. For example, the
Fig. 6A and 6B are schematic diagrams of frequencies of taxi service and express service, respectively, according to some embodiments of the present application. Table 1 is order information of a user's previous service request. Fig. 6A and 6B will be described in conjunction with table 1. The order information in table 1 may be processed to extract the point in time of the previous service request. The extracted time points may belong to one or more time periods. Then, the service type corresponding to each time period may be acquired and expressed in the form of a histogram, as shown in fig. 6A and 6B. It can be concluded from the histogram that the peak time for taxi service is around 12 o ' clock, and the peak time for express service is around 7 o ' clock and around 18 o ' clock. Therefore, considering the service time, the cluster center of the service time of the taxi service is 12 points, and the cluster center of the service time of the express service is 7 points and 18 points.
In some embodiments, the cluster center may be used to determine a gaussian distribution. The gaussian distribution may be centered around the cluster center. For example, a gaussian model for taxi service may have a 12-point center. As another example, a Gaussian mixture model for quick services consists of two superimposed Gaussian distributions with a first center at 7 o 'clock and a second center at 18 o' clock.
TABLE 1
The method of building a hybrid gaussian model based on service time may be implemented in various ways. In some embodiments, a service time-based gaussian mixture model for each service type may be obtained by vectorizing the time points and calculating a mean and a square deviation corresponding to each time point.
In the above-described embodiment, the prediction model is described in consideration of the service time. In some embodiments, a hybrid Gaussian model may be built based on service locations or a combination of service times and service locations. The method described in
The probability density value of each service type with respect to the current requested service time may be determined by incorporating the current requested service time into a gaussian mixture model, and the probability density value may be used to predict a preferred service type of the user.
The service type requested by the user in real time is predicted by establishing the hybrid Gaussian model, so that the prediction precision is effectively improved, the service platform can display a corresponding user interface to the user by using the predicted service type, and the efficiency of requesting the service by the user is improved.
In some embodiments, predicting the service type according to the probability density value for each service type in 504 of
A bayesian model can be used to represent the probability of a service type under various dynamic conditions, which can be understood as a mathematical expression of the probability of selecting a service type. Thus, the first probability for each service type may be obtained by processing the probability density value for each service type. The first probability may indicate a likelihood of selecting a service type at a current requested service time and/or a current requested service location. Thus, specifying the service type with the largest first probability value may be more accurate, as the predicted service type will further improve the accuracy of the service type prediction.
In some embodiments, to make the prediction closer to the user's actual request, the service type with the largest first probability value may be designated as the predicted service type. During this process, it may be determined whether the maximum first probability is greater than or equal to a first preset threshold. If the maximum first probability is greater than or equal to the first preset threshold, the service type may be designated as a predicted service type and output to, for example, the
Since the order information of one user is different from the order information of other users, the service type prediction model may not be applicable to other users, especially to users with a small number of orders. Thus, by setting the first preset threshold, the service type having the largest first probability value may be verified, and the preferred service type of the user may be determined only when the probability value of the service type is greater than or equal to the first preset threshold.
If the probability value of the service type is not greater than or equal to the first preset threshold, other service type prediction models or existing methods may be used to predict the service type. In some embodiments, for a user with a small number of orders, once the order information of the user is sufficient to build the service type of the prediction model, the transit
The application provides a service type prediction method, which is used for predicting by decomposing order information of a previous service request and a service type Gaussian mixture model of a user request, the prediction process is effective, and the prediction accuracy is improved.
Fig. 7 is a flow diagram of a process 700 for predicting a service type, according to some embodiments of the present application. In some embodiments, process 700 may be described in conjunction with
In 701, order information for a user's previous service request may be obtained. The order information may include a type of the requested service and at least one of a service time or a service location. In some embodiments, the order information may be obtained by the
In 702, the
At 703, the
In 704, a service type having a maximum second probability value may be determined, and it may be determined whether the maximum second probability value is greater than or equal to a second preset threshold.
If the maximum second probability value is greater than or equal to the second preset threshold, the process may proceed to 705. If the maximum second probability value is not greater than or equal to the second preset threshold, the process may proceed to 706.
In 705, the service type corresponding to the largest second probability may be designated as the preferred service type for the user. The user's preferred service type may be output to, for example,
In 706, the
In 707, the
At 708, the type of service requested by the user may be predicted based on the probability density value for each type of service.
To improve the efficiency of service type prediction, the
In some embodiments, a Markov model may be used to predict the type of service requested by a user after obtaining a previous service request by the user.
Table 2 shows order information of previous service requests of the user. Table 3 shows statistics of order information of previous service requests of table 2.
TABLE 2
TABLE 3
In some embodiments, the service type of the user's last service request may be obtained from the order information, and the hopping matrix may be determined based on the service type and statistics of the previous service in table 3.
A second probability for each service type may be obtained. The probability that the user requests the express service is 0, and the probability that the user requests the taxi service is 1. Then, once the probability value of the service type is greater than or equal to the second preset threshold, the service type corresponding to the maximum second probability may be designated as the predicted service type. Otherwise, a service type prediction may be made using a Gaussian mixture model as described above.
In some embodiments, a Markov model may be more efficient for a user who always requests a single service type. The markov model may be less computationally loaded than the gaussian mixture model, which is advantageous for improving the processing efficiency of the configured service prediction apparatus to predict the service type of the user. In an embodiment, the first/second preset threshold is set according to an actual request, so that when the markov model is not suitable for processing the order information of the user, the service type of the user can be effectively predicted according to the gaussian mixture model.
Fig. 8 is a schematic diagram of a service type prediction device according to some embodiments of the present application. The service type prediction apparatus 800 may include an information retrieval module 801 and a service prediction module 802.
The information retrieval module 801 may be configured to obtain at least two previous service requests issued by a user, wherein each of the at least two previous service requests includes order information including a requested service type and at least one of a service time or a service location.
The service prediction module 802 may be configured to generate a service type prediction model based on order information of at least two previous service requests and predict a preferred service type of the user using the service type prediction model when a service request including at least one of a current service time or a current service location is received from the user.
It should be noted that the execution subject (e.g., process 400) of the service type prediction methods described herein may specifically be a service type prediction device, and the service type prediction device may be implemented by hardware and/or software. In general, the service type prediction apparatus may be integrated into a cloud server in which a service platform is implemented, and used together with a data server in which various databases are stored and the service platform is implemented. In addition, the server in which the prediction device is implemented may be the same as the data server, or another server of the same server cluster as the data server, which is not limited in this application.
Previous service requests refer to service requests made by the user during a historical period of time (e.g., yesterday, last week, last month, last three months, etc.). In some embodiments, the user's previous service request may relate to a car appointment service request requested by the user through the service platform. The car appointment service may be a real-time service or a subscription service. The car appointment service may include, but is not limited to, a taxi service, a express service, a driver service, a ride share service, a car rental service, a car pooling service, and the like.
In some embodiments, the order information for each previous service request may include the type of service requested, the time of service, and/or the location of the service. In some embodiments, the order information may also include an order number, price, and the like. In some embodiments, the service time may include a specific point in time or a target statistical time period including the specific point in time. For example only, the service time may specifically be a start time of the request service, an end time of the request service, a wait time of the request service, or the like, or a combination thereof. In some embodiments, the service location may comprise a particular location or a statistical geographic area comprising a particular location. For example only, the service location may include a departure location of the requested service, an arrival location of the requested service, or the like, or a combination thereof.
Since the order information of previous service requests includes various types of information, the analysis of the information may indicate the user's preferences/behavior for the service type (i.e., the probability of the user selecting the service type in certain specific scenarios).
For example, most of the user's prior service requests on weekdays (i.e., monday through friday) are taxi services, and most of the prior service requests on saturday and sunday are express services. By analyzing the user's preferences/behavior based on service time, it can be concluded that the probability of the user selecting taxi service on weekdays is relatively high, and the probability of the user selecting express service on holidays is also relatively high. As another example, most previous service requests for service locations at or near an office building are taxi services, and the service locations for most previous service requests are express services at or near the community. The office building may be the user's workplace by analyzing the user's preferences/behaviors based on the service location. When the user leaves his/her work location to reach the destination, the probability that the user selects a taxi service is relatively high. The community may be the user's home. When the user leaves his/her home to reach the destination, the probability that the user selects the express service is relatively high. The user's behavior rules or preferences may be comprehensively analyzed in consideration of service time and/or service location to obtain a probability that the user selects a service type in a particular scenario.
Thus, the mathematical model may represent the behavior/preference pattern of the user. In some embodiments, a service type prediction model may be constructed to predict the service type of a user's real-time service request. The service type prediction models may include, but are not limited to, markov models, gaussian models, mixed gaussian models, bayesian models, and the like. The service type prediction model can be used for identifying a historical scene similar to the current scene according to the current request service time and/or the current request service position of the user, and designating the service type in the historical scene as the preferred service type of the user.
In some embodiments, the service prediction module 802 may be configured to perform cluster analysis to generate a gaussian mixture model corresponding to each service type in each type of service based on service time and/or service location. Service prediction module 802 may determine a probability density value for each service type for the current requested service time and/or current requested service location based on a gaussian mixture model. The preferred service type of the user may be predicted based on the probability density value. In some embodiments, the service prediction module 802 may determine a first probability for each service type using a bayesian model and a probability density value for each service type and specify the service type corresponding to the highest probability value as the preferred service type (i.e., the predicted service type) for the user. In some embodiments, it may be determined whether the maximum first probability is greater than or equal to a first preset threshold. If the maximum first probability is greater than or equal to the first preset threshold, the service type may be designated as a predicted service type and output to, for example, the
In some embodiments, service prediction module 802 may obtain a frequency for each service type from order information of previous service requests to generate a markov model and input order information of previous orders into the markov model to determine a second probability for each service type. The service prediction module 802 may determine the service type having the largest second probability value. It may be determined whether the maximum second probability value is greater than or equal to a second preset threshold. If the maximum second probability value is greater than or equal to a second preset threshold, the service type corresponding to the maximum second probability may be designated as the preferred service type of the user. Otherwise, the service prediction module 802 may perform cluster analysis on each service type in the order information based on the service time and/or the service location to obtain a gaussian mixture model for each service type, and determine a probability density value of each service type at the current requested service time and/or the current requested service location according to the corresponding gaussian mixture model. The service type requested by the user can be predicted according to the probability density value of each service type.
FIG. 9 is a flow chart of a
At 901, when a user senses the turn-on of a transit travel user interface, the
A user operation to open the application may be sensed by the
The travel service may include any type of travel, such as taxis, private cars (express, special, shared, with designated drivers), bicycles, etc., or public transportation with fixed stations, such as buses, trains, subways, etc. A user may install an application (also referred to as "APP") presenting a transportation travel service in a terminal (e.g., user terminal 130). When a user wants to book a taxi before departure, the user can click on the terminal to open an application installed on the terminal.
At 902, a physical location of a user may be obtained.
In some embodiments, the physical location of the user may be the current geographic location of the user. The current geographic location of the user may be obtained using location technology. In some embodiments, prior to obtaining the user's current geographic location, the
In some embodiments, the
In 903, the
The pre-established evaluation criteria refers to one or more factors or terms based on which a view of the order success rate for each of the at least two transit travel services can be determined. In some embodiments, the pre-established assessment criteria may include, but are not limited to, user likeness (e.g., the user's age, gender, whether the user account has an avatar, profession, etc.), weather conditions, traffic conditions, city, driver to passenger ratio, weekday or weekend, physical location is suburban or urban. In some embodiments, the pre-established evaluation criteria may be set by the user according to default settings of the transit
The
For illustrative purposes only, order success refers to whether a taxi driver accepts an order placed by a user within a preset time period (e.g., within 1 minute) after the user requests taxi service, so that the user and the driver can reach a trip agreement. For another example, if the user selects to ride a bicycle, whether there is a bicycle available within a preset range of the user's physical location (e.g., within 50 meters) so that the user can reserve the bicycle.
Order success rate refers to the likelihood that a service requester matches a service provider. For example only, if an area has 100 taxis and the area has 500 users selecting taxi service, the order success rate for taxi service may be 20%. In some embodiments, the pre-established evaluation criteria may vary due to different algorithms used in order success rate evaluation, and the order success rate may vary accordingly. It should be noted that the above embodiments are not intended to limit the scope of the present application. One of ordinary skill in the art can adjust the pre-established evaluation criteria according to the attributes or properties of the transportation travel service and the application scenario of the travel environment. The order success rate estimation method can be used for acquiring the opening information of the user from the client application program, and the client application program can provide at least two types of travel services for the user. The current geographic location of the user may be obtained. The order success rate for each transit travel service at the current geographic location may be determined based on pre-established evaluation criteria. The method and the device for identifying the traffic travel service enable the traffic travel service with higher order success rate to be identified based on the current geographic position of the user, and are beneficial to accurately and reliably analyzing the order success rate of the user at the current service position, so that reliable traffic travel service recommendation is provided for the user, and the travel efficiency of the user is improved. Meanwhile, the method helps to balance the supply-demand ratio between the travel service provider (such as a driver) and the travel service requester (such as a passenger) as much as possible, so that the benefits of the service provider and the service requester can be improved to the maximum extent, the resource utilization rate is improved, and the convenience of user behaviors is realized.
It should be noted that the foregoing is provided for illustrative purposes only and is not intended to limit the scope of the present application. Various changes and modifications can be made by one of ordinary skill in the art in light of the description herein. For example, the
FIG. 10 is a flow chart of a
In 1001, when the user senses the turn-on of the transit travel user interface, the
In 1002, a physical location of a user may be obtained. In some embodiments, the physical location may be the current geographic location of the user.
Pre-established evaluation criteria for predicting order success rates for each of the one or more available travel services may be obtained. In some embodiments, the pre-established evaluation criteria may include, but are not limited to, a user portrait (e.g., the user's age, gender, whether the user's account has an avatar, occupation, etc.), weather conditions, traffic conditions, a city, a proportion of drivers to passengers, a weekday or weekend, a physical location being a suburban or urban area. In some embodiments, the pre-established evaluation criteria include a statistical time period and a statistical geographic area.
In 1003a, the
The statistical time period may refer to a time interval having a certain length. In some embodiments, it may be defined that hourly is a statistical time period, e.g., a statistical time period from 0 to 1, a statistical time period from 8 to 9, etc. In some embodiments, the
For example only, the statistical time periods may have different lengths. For example, during early/late peak hours, the statistical time period may be set to 5: 00-5: 15. 5: 15-5: 30. 5: 30-5: 45 … … was 15 minutes in length. During early morning hours, the statistical time period may be set to 1: 00-2: 00. 2: 00-3: 00 … … was 1 hour in length. It should be noted that the statistical time period is for illustrative purposes only and is not intended to limit the scope of the present application. During morning rush hours, most users intend to go to work, meetings, etc. and the statistical time period may be concentrated, e.g., every 2 minutes may be set as the statistical time period.
When the user clicks the terminal device to activate the client program, the operation of the user activating the client forms the opening information. The opening information may be sent to the application server. The application server may determine a statistical time period in which the turn-on time of the transit user interface falls below, and may designate the determined statistical time period as a target statistical time period. For example, if the statistical time period is preset to 7: 55-8: 00. 8: 00-8: 05. 8: 05-8: 10 … … when the user opens the client application at 8:02, the statistical time period 8: 00-8: 05, determining as a target statistical time period. Typically, the time difference between the point in time when the user opens the client application and the point in time when the application server receives the opening information may be milliseconds or seconds, which may be negligible.
In 1003b, the
The statistical geographic region refers to the smallest geographic region that includes the user's physical location (e.g., the current geographic location). The definition of the statistical geographic region may be similar to the statistical time period described above.
In some embodiments, the supply-to-demand ratios for different statistical geographic regions may be obtained by one skilled in the art according to an algorithm such as clustering based on at least two previous user orders. The statistical geographic area may be determined according to supply-to-demand ratio. In Beijing, for example, a larger population may live in a second ring area, a third ring area, or some business area, and an area with one or two blocks may be set as the demographic area. However, a smaller population may live in the fifth ring of areas, the sixth ring of areas, or other suburban areas, and a larger area may be set as the statistical geographic area. It should be noted that the statistical geographic area is for illustrative purposes only and is not intended to limit the scope of the present application.
In some embodiments, the particular method for determining statistical geographic regions may be used in a particular geographic environment. In some embodiments, a number of factors may be considered. These factors may include whether the road is a one-way road, whether there are multiple entrances and exits to a large commercial square, whether the road has a "no stop" sign, and the like. These factors may be considered to determine the statistical geographic region. After determining the statistical geographic area, a target statistical geographic area may be identified from the statistical geographic area by locating a physical location of the user. The physical location may belong to a target statistical geographic area.
At 1004, the
In some embodiments, at least two previous orders may be obtained. The processing device may sort the at least two previous orders according to the statistical time period and the statistical geographic area. Historical order success rates within each statistical geographic area during each statistical time period may be obtained. Historical order success rates are determined by taking previous service requests and previous service offerings in a statistical geographic area over a statistical time period.
An order success rate corresponding to each target statistics time period and each target statistics geographic area may be determined, and a mapping table between target statistics time periods, target statistics geographic areas, and order success rates may be performed. The mapping table may be updated in real time at preset intervals, for example, every month, every day, etc. In addition, the mapping table may have other dimensions. For example, the mapping table may be a weekday mapping table, a holiday mapping table, or a week mapping table. For example, the order success rate for a weekday (e.g., from 8 to 9) may be less than the order success rate for a holiday (e.g., from 8 to 9). As another example, the order success rate for Monday (e.g., from 18 to 19) may be greater than the order success rate for Friday (e.g., from 18 to 19). In some embodiments, date information may be obtained. The date information refers to the date on which the application server received the opening information (i.e., the date of the service request). The target statistical date may be determined from date information (e.g., monday, week, etc.). Thus, historical order success rates for dates (e.g., order success rates for previous orders on Monday and Tuesday) may be determined.
The order success rate estimation method provided in the
FIG. 11A is a flow chart of a
In 1101, upon the user sensing the turn on of the transit travel user interface, the
In 1102, a physical location of a user may be obtained. In some embodiments, the physical location may be the current geographic location of the user.
Pre-established evaluation criteria for predicting order success rates for each of the at least two travel services may be obtained. In some embodiments, the pre-established evaluation criteria include a statistical time period and a statistical geographic area.
In 1103a, the
In 1103b, the
At 1104, the
In some embodiments, the operations in 1101 to 1104 may be similar or identical to the operations in 1001 to 1004.
In some embodiments, the pre-established evaluation criteria may also include, for example, weather conditions, traffic conditions, and the like. The weather conditions may include particular weather conditions. In some embodiments, the weather condition may be a real-time weather condition or a forecasted weather condition. The traffic conditions may include a degree of traffic congestion. In some embodiments, the traffic condition may be a real-time traffic condition or a predicted traffic condition.
In 1105a, if the pre-established evaluation criteria include weather conditions, the
Special weather conditions refer to weather conditions that affect the success rate of historical orders. For example, in weather conditions such as heavy rain or snow storms, the number of traffic services such as taxi service and private car may be greatly reduced. The historical order success rate will be much less due to the effects of special weather. Therefore, it is necessary to determine whether there are special weather conditions that affect the success rate of the historical order based on the weather conditions. If special weather conditions exist, historical order success rates determined based on a large number of previous orders may be adjusted to provide a more accurate order success rate for the user.
In 1105b, the
Traffic congestion relates to the flow of road traffic determined from real-time road conditions. For example, a traffic accident occurring near the user's physical location may affect the travel speed of each vehicle within a certain range of the traffic accident. Due to the influence of traffic accidents, the historical order success rate of acquisition will be much less. Therefore, it is necessary to determine whether the traffic congestion affects the historical order success rate according to the real-time traffic conditions. If the traffic congestion level changes, the historical order success rate determined based on a large number of previous orders may be adjusted to provide a more accurate order success rate for the user.
At 1106, if a particular weather condition and/or a certain degree of traffic congestion exists at the physical location while the user interface is turned on, the
In some embodiments, pre-established evaluation criteria such as special weather conditions, traffic congestion levels, or both, may be used as adjustment factors for adjusting historical order success rates. In addition, different influence factors are set for different weather conditions and different traffic congestion degrees (for example, the higher the traffic congestion degree, the smaller the influence factor, the smaller the historical order success rate). Meanwhile, the setting of the influence factor also needs to consider the nature of the transportation travel service. For example, in the case of road congestion, these travel services may be less affected by road congestion since buses have a bus lane and bicycles have a bicycle lane. Thus, for different travel services, the impact factor may be different for the same degree of traffic congestion
In 1107, the
After determining the order success rates of the various transportation services, the user terminal may display the order success rates corresponding to each of the various transportation services, so that the user may select the transportation services in consideration of the order success rates (i.e., transaction probabilities) of the various transportation services.
A
In some embodiments, more choices may be provided, depending on different habits or preferences of the user, to further save the user time in deciding to select a travel service. For example, in a real application scenario, a user may want to be faster even if the user waits for a period of time. Unless he needs to wait for a long time he will choose a taxi or a car with a driver. The user may then be provided with an order success rate for the current order, an order success rate for placing an order after 3 minutes, an order success rate for placing an order after 5 minutes, and so on.
This particular implementation includes that for those travel services for which the estimated order success rate is less than the preset order success rate threshold, the
A
FIG. 12 is a schematic diagram of an order success rate estimation device according to some embodiments of the present application. The order success
The
The
The order success rate estimation device may be configured to acquire opening information of the user from the client application program, and the client application program may provide at least two types of travel services for the user. The current geographic location of the user may be obtained. The order success rate for each transit travel service at the current geographic location may be determined based on pre-established evaluation criteria. The method and the device for identifying the traffic travel service have the advantages that the traffic travel service with higher order success rate can be identified based on the current geographic position of the user, the order success rate of the user at the current service position can be accurately and reliably analyzed, reliable traffic travel service recommendation is provided for the user, and the travel efficiency of the user is improved. Meanwhile, the method helps to balance the supply-demand ratio between the travel service provider (such as a driver) and the travel service requester (such as a passenger) as much as possible, so that the benefits of the service provider and the service requester can be improved to the maximum extent, the resource utilization rate is improved, and the convenience of user behaviors is realized.
In some embodiments, the determination module may further include a statistical time period determination sub-module. The statistical time period determination submodule may determine that the opening time of the transit user interface belongs to the target statistical time period.
In some embodiments, the determination module may further include a statistical geographic area determination sub-module. The statistical geographic area determination sub-module may determine that the physical location of the user belongs to a target statistical geographic area.
In some embodiments, the determination module may further include a historical order success rate acquisition sub-module. The historical order success rate obtaining sub-module can obtain the historical order success rate of each transportation travel service in the target counting geographic area within the target counting time period. In some embodiments, historical order success rates may be determined by taking previous service requests and previous service offerings in a statistical geographic area during a statistical time period.
In some embodiments, the determination module may also include a weather determination submodule. If the pre-established evaluation criteria include weather conditions, the weather determination sub-module may determine whether particular weather conditions exist at the physical location while the user interface is turned on.
In some embodiments, the determination module may also include a traffic condition determination sub-module. The traffic condition determination sub-module rewrites the traffic congestion degree of the road within a preset range of the physical location if the pre-established evaluation criterion includes the traffic condition.
In some embodiments, the determination module may further include an impact factor determination sub-module. The influence factor determination submodule may determine the influence factor imposed by at least one of the special weather condition or the certain traffic congestion degree, according to a property of each of the travel services, if the special weather condition and/or the certain traffic congestion degree exists at the physical location when the user interface is turned on.
In some embodiments, the determination module may further include an order success rate determination sub-module. The order success rate determination sub-module may estimate an order success rate for each of the at least two transit travel services at the user physical location based on the historical order success rate and the impact factor corresponding thereto.
In some embodiments, the obtaining
The
Fig. 13 is a flow chart of a
As shown in fig. 13, the travel mode recommendation method may be implemented in a travel mode recommendation device. The travel mode recommendation device may be implemented by hardware and/or software. In practical applications, the travel mode recommendation device may be a stand-alone device, such as an application server client interacting with a user client. The travel mode recommendation device may also be integrated in a cloud server on which a network platform providing a travel service (hereinafter, referred to as "platform") is based, and used in combination with a data server storing various types of databases on which the network platform providing the travel service is based. The server on which the travel mode recommendation device is based may be a data server, or may be a different server of the same server cluster as the data server, but is not limited thereto. The travel mode recommendation device may also be integrated in a device supported by a customer of a user interacting with a network platform providing a travel service. The method for recommending the travel mode can be realized by performing information interaction and data updating with a network platform providing travel services. The device supported by the user client may be, for example, a smartphone, a tablet (portable android device) or other electronic mobile device. These electronic devices may be referred to as "user terminals". The travel mode recommendation device may be in the form of an application server.
In 1301, the
Previous travel data refers to data collected on a travel route. The travel route may include at least two road segments. The previous travel data may include departure data, arrival data, and travel patterns used on each segment of the travel route. The departure data may include, for example, a departure location (i.e., a departure location) and a departure time for each segment of the travel route. The arrival data may include an arrival location (i.e., arrival location) and an arrival time for each segment of the travel route. The previous travel data may be acquired by a network platform providing a transportation travel service, and the user's order is collected through the network platform. The mode of travel of the transport used in each section of the travel route may be of any type, for example, a taxi, a private car (express, special, carpool, etc.), a bicycle, or a public transport with fixed stations, such as a bus, a train, a subway, etc. A user may install an Application (APP) presenting various travel services in a terminal. Taking a practical application scenario as an example, a user can arrange a taxi through the platform before starting. The platform may store the travel record of the user riding the taxi as previous travel data of the user.
In 1302, the
The relevance between the sections of the travel route means that discrete travels of the user within a certain time period can form an individualized travel track. In some embodiments, the coordinates of the arrival location of the first trip and the coordinates of the departure location of the second trip may be connected along the user's travel direction. For example, if the user is sending from location a, then go through location B, then go to location C, and finally go to location D, connecting the four geographic locations A, B, C and D in sequence to obtain the user's travel trajectory. The departure location and the arrival location of each road segment on the travel route means that, for example, when the user rides a common bicycle at location a, the platform records location a as the departure location of the first road segment on the travel route; when the user rides the bicycle to location B and transfers to the subway, the platform records location B as the arrival location of the first road segment on the route of travel, the first road segment being from a to B. The user starts traveling on the second leg of the travel route by purchasing an airline ticket at location B or entering a nearby subway station. When the user arrives at location C on the subway and requests quick service through the platform, a second road segment from B to C may be recorded. On the second road segment, the platform records position B as the departure position and position C as the arrival position. Similarly, if the user is riding in an express car at location C, location C may be the departure location of the third road segment on the travel route. If the user arrives at location D, the platform may record location D as the arrival location of the third road segment. From position a to position D, the user uses different travel modes. Locations A, B, C and D are not isolated geographical locations, but rather form a complete travel trajectory. Thus, each of the geographic locations A, B, C, D, etc. described above are associated to form a personalized travel route that includes the three segments of the route described above (e.g., a first segment from a to B, a second segment from B to C, and a third segment from C to D).
In addition, the personalized travel route of the user can be determined according to the departure time of each road segment and the arrival time of each road segment. For example, the platform records the user's previous travel data from a to D, however, the trip from a to C occurs in the morning and the trip from C to D occurs in the afternoon, then the trip from a to D may not be considered a personalized travel route for the user. Thus, a personalized travel route may need to meet time conditions. That is, the user is sent from location a to location D, and locations B and C are the transfer stations between location a and location D. Thus, the trip from a to C may be a personalized travel route for the user, and the trip from C to D may be another personalized travel route for the user. The determination of personalized travel routes may be understood by those skilled in the art by simulating the user's previous travel data and/or using statistical analysis methods. For example, a machine-learning algorithm or other statistical algorithm may be used.
In 1303, the
The travel mode prediction model may be used to determine a probability of a user selecting each travel mode in each road segment route on a personalized travel route. The manner in which the model is built may include, but is not limited to, using a mathematical model to represent the personalized travel route for each user. The constructed mathematical model is used for predicting the most probable transportation travel mode used by the user on each road section route of the personalized travel route. The travel pattern prediction model may include, but is not limited to, a markov model, a gaussian model, a mixed gaussian model, a bayesian model, etc., or a combination thereof.
At 1304, the
In some embodiments, the current location of the user may be obtained when the user opens a user interface of a platform providing transit travel services. Before acquiring the current location of the user, the method may further include sending a query message to the terminal device of the user to query whether the positioning device is turned on the terminal device. And if the user agrees to turn on the positioning device, the current position of the user can be acquired through the terminal device and is sent to an application server of the platform. The current location may be acquired by locating the location of the terminal device via a GPS device, or calculating the current location of the terminal device based on a signal of the terminal device, or acquiring an IP address of the terminal device.
The current location of the user may be obtained. After the application server analyzes the user's previous travel data, more than one personalized travel route for the user may be determined. The personalized travel route including the current location may be selected as the recommended travel route for the user. Under different conditions, the method for determining the recommended travel route of the user in the personalized travel route may also be different according to the current position of the user. For example, if the current location of the user is obtained, a recommended travel route may be determined from the personalized travel route determined in 1302. It is also possible to more accurately determine a cut-through or diversion route between two locations based on a combination of a user-entered destination and a current location.
Further, a plurality of possible personalized travel routes may be selected based on the current location of the user. The most likely recommended travel route may then be recommended to the user, or several possible recommended travel routes may be recommended to the user, with the frequency of selecting each personalized travel route from previous travel data. The
In 1305, the
At 1306, the
In some embodiments, after determining the recommended travel route according to the current location of the user, if the recommended travel route includes a plurality of route segments, a travel mode used on each recommended route segment may be predicted according to the travel mode prediction model and recommended to the user. In some embodiments, the travel mode prediction model may be combined with road conditions to predict a suitable travel mode, so as to provide a new travel mode prediction model, and combine the user preference (travel mode prediction model) and the actual travel environment, so as to further improve the travel efficiency of the user, and facilitate the travel experience of the user.
The provided travel service recommendation method may include acquiring previous travel data of the user for each road segment route, including a departure location and time (departure data), an arrival location and time (arrival data), and a used travel mode of transportation; retrieving and using departure data and arrival data of road sections, determining correlation among routes of each road section, and generating an individualized travel route for a user, wherein each route comprises one or more road sections; retrieving and using the traffic travel mode of each road section, determining the use frequency of each traffic travel mode on each road section and each road section on each personalized travel route, and establishing a traffic travel mode estimation model; selecting a recommended travel route from the personalized travel routes according to the current position of the user, wherein the recommended travel route comprises a recommended road section; predicting the traffic travel mode of each recommended road section by using a traffic travel mode estimation model, and generating a recommended traffic travel mode for each recommended road section; and sending the recommended travel route and the recommended traffic travel mode thereof to the user.
Fig. 14 is a flow chart of a
In 1401, the
At 1402, the
As used herein, a time interval refers to a time period between the arrival time of a user on a road segment and the departure time of the user on a continuous road segment. If every two consecutive road sections SiAnd Si+1The time interval in between is less than or equal to the first time interval threshold, the process may proceed to 1403. If every two consecutive road sections SiAnd Si+1The time interval in between is greater than the first time interval threshold, the process may proceed to 1404.
In some embodiments, the relationship between the first road segment and the second road segment may be two road segments of the travel route if the arrival time of the first road segment is before the departure time of the second road segment. The time interval between the arrival time of the first road segment and the departure time of the second road segment defines the length of time between the end of the first road segment and the start of the second road segment. For example, the user uses a shared bicycle at location a, and transfers to the subway after he/she arrives at location B. The user takes the subway to reach the position C and then requests the express train to reach the position D. If the time for riding the common bicycle in the B position is t1(arrival time of first road section), the time of entry into the subway station at position B is t2(departure time of second link), t2-t1A time interval between an arrival time of the first road segment and a departure time of the second road segment may be represented.
The first time interval threshold may be a threshold that is consistent with a user's general travel rules based on a large amount of previous travel data. For example, if a user walks from a location where shared bicycles are parked to a subway station, it may take 3 minutes. If the first time interval threshold is 10 minutes, location B may be considered a transfer station and the trips from a to B and B to C may be determined as a personalized travel route for the user.
In 1403, the
In some embodiments, the correlated road segments may be identified from 1402 and connected to each other, thereby forming a personalized travel route for the user.
At 1404, if every two consecutive road segments SiAnd Si+1The time interval between is greater than the first time interval threshold but less than the second time interval threshold, the
If only the first time interval threshold is used to determine whether two road segments have a correlation, a large number of personalized travel routes for the user may be missed in many practical applications. Therefore, it is necessary to determine a personalized travel route in consideration of the geographic range threshold. For example, the user takes a subway at location a to location B, then walks to location C, and then calls a express car from location C to location D. Where location a is the user's workplace and location D is the user's home. It is clear that the journey from a to D is a personalized travel route for the user. However, since the user walks from location B to location C longer than the first time interval threshold (e.g., 10 minutes), the platform may not be able to determine that the trip from a to B and the trip from C to D have a correlation.
In this case, a preset distance threshold may be used to determine whether the distance separation between location B and location C exceeds the preset distance threshold (e.g., 1 kilometer). The preset distance threshold may be a distance determined from previous trip data. If the distance interval does not exceed the preset distance threshold, the user may be considered to walk from location B to location C and a personalized travel route for the user may be formed. Additionally, for some reasons, the user may shift at location B, for example, purchasing a bottle of water at a supermarket, etc., and the time interval between the arrival time of the first road segment and the departure time of the second road segment may exceed the first time threshold. However, it may be determined that the user is close to location B, and thus it is determined that the trip from a to B and the trip from B to C have a correlation according to a preset distance threshold. Further, other methods or techniques may be used to determine whether two consecutive road segments have a correlation. For example, data measured by an acceleration sensor or a walking detection sensor of the user terminal may be acquired to determine whether the user walks from B to C.
In some embodiments, road segments having time intervals greater than a first time interval threshold may be considered, in conjunction with a preset distance threshold. Thus, it is desirable to define a time interval greater than the first time interval threshold but less than or equal to the second time interval threshold (e.g., half an hour, a brief stay in a place, or a bottle of water purchased at a supermarket). Additionally, a user is not generally considered a coherent travel route where they stay in a certain place for a long time and then start another trip. For example, in the morning, the user arrives at location B from location A, which is the user's home, and then departs to location C, which is the user's work location, and location B is a transfer station. In the afternoon, the user arrives at location D from location C and then returns to location a, which means that the user goes home from a work location on a different route. In this case, the journey from a to B to C to D, then D to a, would not be considered a personalized travel route for the user. Conversely, the trip from a to C is a personalized travel route for the user, and the trip from C to a is another personalized travel route for the user.
In 1405,
At 1406, the
In 1407, the
In 1408, the
In 1409, the
In 1405 to 1409, the markov model follows markov principles and is a statistical model that can determine the regularity of the sequence of states for each sequence of states by which each state depends on a finite number of states. For the process of predicting the vehicle type used in each personalized travel route, the historical travel route of the user can be obtained through the statistical determination of the previous travel data of the user; the frequency of the next mode of travel may then be determined based on the modes of travel used in the previous travel on each personalized travel route. That is, in the personalized travel route, after the last trip uses the vehicles, the next trip uses the number distribution of various vehicles. This infers the type of vehicle that the user will use on the next trip. To simplify the operation, for the first level markov model, assume that the vehicle records used by the user in a portion of the personalized travel route are as shown in table 3.
TABLE 3
Time of day
Vehicle with a steering wheel
2017/5/30 18:36
Taxi
2017/6/2 17:58
Taxi
2017/6/12 12:04
Taxi
2017/6/20 20:07
Express train
2017/6/27 9:43
Taxi
2017/6/28 13:06
Taxi
2017/6/28 14:56
Taxi
2017/6/28 17:40
Taxi
2017/6/29 9:10
Taxi
2017/6/29 11:16
Taxi
2017/6/29 16:44
Taxi
2017/7/3 10:26
Taxi
2017/7/4 18:58
Taxi
2017/7/4 22:18
Taxi
2017/7/6 10:01
Taxi
2017/7/7 15:06
Taxi
2017/7/7 19:27
Taxi
2017/7/11 9:30
Taxi
2017/7/13 11:36
Express train
2017/7/15 15:25
Taxi
2017/7/17 9:00
Taxi
2017/7/18 11:42
Taxi
2017/7/18 20:58
Taxi
Based on the markov model, according to the
TABLE 4
Time of the next taxi
Next time of express
Last taxi time
18
2
Last time of
2
0
As can be seen from the probability matrix of table 4, when the user is notified of the travel mode used in the trip, the hopping matrix of table 4 can be used to predict which travel mode will be used in the next trip. The statistically obtained conditional probabilities are as follows:
P(Y=A│X=A)=0.9,
P(Y=B│X=A)=0.1,
P(Y=A│X=B)=1,
P(Y=B│X=B)=0,
wherein X represents the last used mode of travel, Y represents the next used mode of travel, A represents that the mode of travel is a taxi, and B represents that the mode of travel is a express.
Assuming that the traffic travel mode directly used by the user is a express B in a road section, the probability of obtaining the express B in the next road section is 0 through a Markov matrix, and the probability of using the taxi A is 1, and the platform recommends a taxi to be the solution for the user to select the taxi A. The above is described by taking a markov matrix of only a part of the personalized travel route as an example, and different markov models are established according to different personalized travel routes, and markov models with different dimensions are established according to the multi-path travel frequency contained in each personalized travel route, so as to determine the travel modes that the user is most likely to take in each route segment, such as position a to position B, position B to position C, and position C to position D, and recommend the travel modes to the user.
Fig. 15 is a schematic diagram of a travel mode recommendation device according to some embodiments of the present application. The travel
The
The
The
The
The travel mode recommendation device disclosed in the present application can acquire previous travel data of the user for each road segment route, which includes a departure position and time (departure data), an arrival position and time (arrival data), and a used travel mode; retrieving and using the departure data and the arrival data of the road sections, determining the correlation between routes of each road section, and generating an individualized travel route for a user, wherein each route comprises one or more road sections; retrieving and using the traffic travel mode of each road section, determining the use frequency of each traffic travel mode in each road section route in each personalized travel route, and establishing the traffic travel mode of the pre-estimated model; selecting a recommended travel route from the personalized travel routes according to the current position of the user, wherein the recommended travel route comprises a recommended road section; predicting the traffic travel mode of each recommended road section by using a traffic travel mode estimation model, and generating a recommended traffic travel mode for each recommended road section; and sending the recommended travel route and the recommended traffic travel mode thereof to the user.
In some embodiments, the
In some embodiments,
In some embodiments,
In some embodiments,
The acquisition submodule can acquire the previous transmission mode of the user on each road section;
the determining submodule can determine the use frequency of the next travel mode on each road section according to the previous travel modes of the user on the basis of the probability matrix;
the calculation sub-module may determine a probability of each mode of travel on each road segment of the personalized travel route based on a frequency of use of the next mode of travel; and
the selection sub-module may determine the travel mode corresponding to the maximum probability on each road segment as the recommended travel mode on each road segment.
Having thus described the basic concepts, it will be apparent to those of ordinary skill in the art having read this application that the foregoing disclosure is to be construed as illustrative only and is not limiting of the application. Various modifications, improvements and adaptations of the present application may occur to those skilled in the art, although they are not explicitly described herein. Such modifications, improvements and adaptations are proposed in the present application and thus fall within the spirit and scope of the exemplary embodiments of the present application.
Also, this application uses specific language to describe embodiments of the application. Furthermore, this application uses specific terminology to describe embodiments of the application. For example, the terms "one embodiment," "an embodiment," and "some embodiments" mean a certain feature, structure, or characteristic described in connection with at least one embodiment of the application. Therefore, it is emphasized and should be appreciated that two or more references to "an embodiment" or "one embodiment" or "an alternative embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, certain features, structures, or characteristics of one or more embodiments of the application may be combined as appropriate.
Moreover, those skilled in the art will appreciate that each aspect of the present application may be illustrated and described herein by a number of patentable species or situation, including any new and useful process, machine, article, or combination of matter, or any new and useful improvement thereof. Accordingly, each aspect of the present application may be embodied entirely in hardware, entirely in software (including firmware, resident software, micro-code, etc.) or in a combination of hardware and software that may be referred to as a "module," unit, "" component, "" device, "or" system. Moreover, each aspect of the present application may take the form of a computer program product embodied in one or more computer-readable media, with computer-readable program code embodied therein.
A computer readable signal medium may comprise a propagated data signal with computer program code embodied therewith, for example, on baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including electro-magnetic, optical, and the like, or any suitable combination. A computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code on a computer readable signal medium may be propagated over any suitable medium, including radio, cable, fiber optic cable, RF, etc., or any combination of the preceding.
Computer program code required for the operation of each part of the present application may be written in any one or more of a variety of programming languages, including a subject oriented programming language such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C + +, C #, VB.NET, Python, and the like, a conventional programming language such as C, Visual Basic, Fortran 2003, Perl, COBOL 2002, PHP, ABAP, a dynamic programming language such as Python, Ruby, and Groovy, or other programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any network format, such as a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet), or in a cloud computing environment, or as a service, such as a software as a service (SaaS).
Additionally, the order in which elements and sequences of the processes described herein are processed, the use of alphanumeric characters, or the use of other designations, is not intended to limit the order of the processes and methods described herein, unless otherwise indicated in the claims. While various presently contemplated embodiments of the invention have been discussed in the foregoing disclosure by way of example, it should be understood that such detail is solely for that purpose and that the appended claims are not limited to the disclosed embodiments, but, on the contrary, are intended to cover all modifications and equivalent arrangements that are within the spirit and scope of the embodiments herein. For example, although the system components described above may be implemented by hardware devices, they may also be implemented by software-only solutions, such as installing the described system on an existing server or mobile device.
Similarly, it should be noted that in the preceding description of embodiments of the present application, various features are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the embodiments. This method of application, however, is not to be interpreted as reflecting an intention that the claimed subject matter to be scanned requires more features than are expressly recited in each claim. Indeed, the claimed subject matter may be characterized as encompassing less than all of the features of a single disclosed embodiment.
- 上一篇:一种医用注射器针头装配设备
- 下一篇:用于监测交通工具使用的系统和方法