CN111881227A - Method and system for determining carpool order access map - Google Patents
Method and system for determining carpool order access map Download PDFInfo
- Publication number
- CN111881227A CN111881227A CN202010437553.9A CN202010437553A CN111881227A CN 111881227 A CN111881227 A CN 111881227A CN 202010437553 A CN202010437553 A CN 202010437553A CN 111881227 A CN111881227 A CN 111881227A
- Authority
- CN
- China
- Prior art keywords
- order
- map
- access
- carpooled
- orders
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 48
- 238000012545 processing Methods 0.000 claims abstract description 26
- 238000012549 training Methods 0.000 claims description 22
- 238000007637 random forest analysis Methods 0.000 claims description 12
- 238000003066 decision tree Methods 0.000 claims description 9
- 238000011176 pooling Methods 0.000 claims description 9
- 238000013528 artificial neural network Methods 0.000 claims description 6
- 238000013145 classification model Methods 0.000 claims description 6
- 238000012706 support-vector machine Methods 0.000 claims description 6
- 238000010586 diagram Methods 0.000 description 12
- 230000008569 process Effects 0.000 description 12
- 238000012986 modification Methods 0.000 description 8
- 230000004048 modification Effects 0.000 description 8
- 238000004891 communication Methods 0.000 description 7
- 238000004422 calculation algorithm Methods 0.000 description 6
- 230000006870 function Effects 0.000 description 5
- 230000008901 benefit Effects 0.000 description 4
- 230000003993 interaction Effects 0.000 description 4
- 238000013507 mapping Methods 0.000 description 4
- 230000003044 adaptive effect Effects 0.000 description 3
- 238000001514 detection method Methods 0.000 description 3
- 238000011156 evaluation Methods 0.000 description 3
- 230000006872 improvement Effects 0.000 description 3
- 239000000463 material Substances 0.000 description 3
- 230000000644 propagated effect Effects 0.000 description 3
- 230000006978 adaptation Effects 0.000 description 2
- 238000003491 array Methods 0.000 description 2
- 230000006399 behavior Effects 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 230000015556 catabolic process Effects 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 239000000835 fiber Substances 0.000 description 2
- 238000010801 machine learning Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000004088 simulation Methods 0.000 description 2
- 238000010200 validation analysis Methods 0.000 description 2
- 238000007476 Maximum Likelihood Methods 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000000712 assembly Effects 0.000 description 1
- 238000000429 assembly Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000014509 gene expression Effects 0.000 description 1
- 239000010977 jade Substances 0.000 description 1
- 238000002372 labelling Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 239000003607 modifier Substances 0.000 description 1
- 230000002035 prolonged effect Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 239000004984 smart glass Substances 0.000 description 1
- 230000000391 smoking effect Effects 0.000 description 1
- 241000894007 species Species 0.000 description 1
- 230000029305 taxis Effects 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/29—Geographical information databases
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
- G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
- G06Q30/0635—Processing of requisition or of purchase orders
-
- G06Q50/40—
Abstract
The embodiment of the application discloses a method and a system for determining a carpool order access map. The method comprises the following steps: acquiring at least two to-be-carpooled order forms; acquiring characteristic parameters related to the at least two to-be-carpooled orders; processing at least one part of characteristic parameters related to the at least two orders to be carpooled by utilizing an identification model, and determining whether the orders to be carpooled need to access a map. The method and the device screen the order to be carpooled, which can not be obviously spliced, through the recognition model, the order quantity of the access map in a carpooling scene is effectively reduced, and the map access efficiency is improved, so that the condition that the server is overloaded or crashed is avoided, and the user experience is improved.
Description
Technical Field
The application relates to the field of shared travel, in particular to a method and a system for determining a carpool order access map.
Background
In the field of shared travel, the access volume of the network car booking service platform is more and more due to the rapid development of the network car booking industry. In a carpooling scenario, if all orders require access to the map server (e.g., apparently unsuccessful carpooling orders to Beijing and to Harbin) to determine whether the carpooling condition is met, the load on the server is increased. In some cases, if a large number of users send orders simultaneously and need to access the map server, the map server may be accessed too much, the calculation time is prolonged, and the user interface does not respond for a long time, which may result in poor user experience.
Therefore, it is necessary to provide a method for determining a carpool order access map to determine an apparently non-pieced order to be carpooled, so as to reduce the access amount of a map server in a carpool scene, thereby avoiding the occurrence of server overload or breakdown, and further improving the user experience.
Disclosure of Invention
One aspect of the present application provides a method of determining a carpool order access map. The method comprises the following steps: acquiring at least two to-be-carpooled order forms; acquiring characteristic parameters related to the at least two to-be-carpooled orders; processing at least one part of characteristic parameters related to the at least two orders to be carpooled by utilizing an identification model, and determining whether the orders to be carpooled need to access a map.
In some embodiments, the characteristic parameters related to the at least two orders to share include at least one of: the order placing time, the order executing time, the longitude and latitude of the order starting and ending point, the straight distance of the starting and ending point based on the longitude and latitude, the angle based on the straight distance, the estimated driving time based on the straight distance, the history of the service requester or the service provider, the personal information of the service requester or the service provider and the ordering requirement of the service requester or the service provider for the service.
In some embodiments, the recognition model comprises a classification model.
In some embodiments, the recognition model comprises a decision tree model, bayesian classification, random forest, support vector machine, or neural network.
In some embodiments, the recognition model is obtained by: obtaining a historical car pooling order sample; at least two carpool orders accessing the map are used as a sample and marked as a positive sample, and at least two carpool orders not accessing the map are used as a sample and marked as a negative sample; acquiring characteristic parameters related to the historical carpooling order; and training an initial model to obtain the recognition model based on the characteristic parameters and the marking result.
In some embodiments, the characteristic parameters associated with the historical ride share orders include at least one of: the order placing time, the order executing time, the longitude and latitude of the order starting and ending point, the straight distance of the starting and ending point based on the longitude and latitude, the angle based on the straight distance, the estimated driving time based on the straight distance, the history of the service requester or the service provider, the personal information of the service requester or the service provider, the ordering requirement of the service requester and whether the order accesses a map.
In some embodiments, the order to be carpooled that requires access to the map is an order other than an apparently unpinned order.
In some embodiments, the apparently misspelled order comprises an order with unmatched departure and destination information, long detour times, long pickup times, short ride sharing times, or low user tolerance.
In some embodiments, the method further comprises allowing the order to be carpooled to access the map based on the determination result of the access map.
Another aspect of the application provides a system for determining a carpool order access map. The system comprises: the system comprises an order acquisition module, a characteristic parameter acquisition module and an access map determination module; wherein: the order acquisition module is used for acquiring at least two orders to be shared; the characteristic parameter acquisition module is used for acquiring characteristic parameters related to the at least two to-be-carpooled orders; the access map determining module is used for processing at least one part of the characteristic parameters related to the at least two orders to be carpooled by utilizing the identification model and determining whether the orders to be carpooled need to access the map.
In some embodiments, the characteristic parameters related to the at least two orders to share include at least one of: the order placing time, the order executing time, the longitude and latitude of the order starting and ending point, the straight distance of the starting and ending point based on the longitude and latitude, the angle based on the straight distance, the estimated driving time based on the straight distance, the history of the service requester or the service provider, the personal information of the service requester or the service provider and the customization requirement of the service requester on the service.
In some embodiments, the recognition model comprises a classification model.
In some embodiments, the recognition model comprises a decision tree model, bayesian classification, random forest, support vector machine, or neural network.
In some embodiments, the system further comprises a recognition model training module configured to: obtaining a historical car pooling order sample; at least two carpool orders accessing the map are used as a sample and marked as a positive sample, and at least two carpool orders not accessing the map are used as a sample and marked as a negative sample; acquiring characteristic parameters related to the historical carpooling order; and training an initial model to obtain the recognition model based on the characteristic parameters and the marking result.
In some embodiments, the characteristic parameters associated with the historical ride share orders include at least one of: the order placing time, the order executing time, the longitude and latitude of the order starting and ending point, the straight distance of the starting and ending point based on the longitude and latitude, the angle based on the straight distance, the estimated driving time based on the straight distance, the history of the service requester or the service provider, the personal information of the service requester or the service provider, the ordering requirement of the service requester and whether the order accesses a map.
In some embodiments, the order to be carpooled that requires access to the map is an order other than an apparently unpinned order.
In some embodiments, the apparently misspelled order comprises an order with unmatched departure and destination information, long detour times, long pickup times, short ride sharing times, or low user tolerance.
In some embodiments, the system further comprises an access map enforcement module, wherein: and the access map implementation module is used for allowing the to-be-carpooled order access map which needs to access the map based on the determination result of the access map.
Another aspect of the present application provides an apparatus for determining a carpool order access map, the apparatus comprising at least one processor and at least one memory device, the memory device being configured to store instructions that, when executed by the at least one processor, implement the method of any of the embodiments of the present application.
Another aspect of the present application provides a computer-readable storage medium, which stores computer instructions, and when the computer instructions in the storage medium are read by a computer, the computer executes the method according to any embodiment of the present application.
Drawings
The present application will be further explained by way of exemplary embodiments, which will be described in detail by way of the accompanying drawings. These embodiments are not intended to be limiting, and in these embodiments like numerals are used to indicate like structures, wherein:
fig. 1 is a schematic diagram of an application scenario of an order access map determination system according to some embodiments of the present application.
FIG. 2 is a schematic diagram of an exemplary 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 mobile device shown in accordance with some embodiments of the present application.
FIG. 4 is a block diagram of a carpool order access map determination system shown in accordance with some embodiments of the present application;
FIG. 5 is an exemplary flow diagram of a method for determining a carpool order access map, shown in accordance with some embodiments of the present application.
FIG. 6 is an exemplary flow diagram of a recognition model training method shown in accordance with some embodiments of the present application.
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, or otherwise indicated, like reference numbers in the figures refer to the same structure or operation.
It should be understood that "system", "device", "unit" and/or "module" as used herein is a method for distinguishing different components, elements, parts, portions or assemblies at different levels. However, other words may be substituted by other expressions if they accomplish the same purpose.
As used in this application and the appended claims, the terms "a," "an," "the," and/or "the" are not intended to be inclusive in the singular, but rather are intended to be inclusive in the plural unless the context clearly dictates otherwise. In general, the terms "comprises" and "comprising" merely indicate that steps and elements are included which are explicitly identified, that the steps and elements do not form an exclusive list, and that a method or apparatus may include other steps or elements.
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 or following operations are not necessarily performed in the exact order in which they are performed. Rather, the various steps may be processed in reverse order or simultaneously. Meanwhile, other operations may be added to the processes, or a certain step or several steps of operations may be removed from the processes.
Embodiments of the present application may be applied to different transportation systems, e.g., taxis, special cars, tailgating, buses, designated drives, etc. The terms "passenger", "passenger end", "user terminal", "customer", "demander", "service demander", "consumer", "user demander" and the like are used interchangeably and refer to a party that needs or orders a service, either a person or a tool. Similarly, "driver," "provider," "service provider," "server," and the like, as described herein, are interchangeable and refer to an individual, tool, or other entity that provides a service or assists in providing a service. In addition, a "user" as described herein may be a party that needs or subscribes to a service, or a party that provides or assists in providing a service.
Fig. 1 is a schematic diagram of an application scenario of an order access map determination system 100 according to some embodiments of the present application. The order access map determination system 100 can determine whether a carpool order requires access to a map, avoiding access to maps for orders that are clearly unavailable for carpooling, thereby reducing the amount of access to the order access map. The order access map determination system 100 may be a service platform for the internet or other network. For example, the order access map determination system 100 may be an online service platform that provides services for transportation. In some embodiments, the order access map determination system 100 may be applied to taxi appointment services, such as taxi calls, express calls, special calls, mini-bus calls, carpools, bus services, driver employment and pickup services, and the like. In some embodiments, the order access map determination system 100 may also be applied to designated drives, couriers, takeoffs, and the like. In other embodiments, the order access map determination system 100 may also be applied to the fields of housekeeping services, travel (e.g., tourism) services, education (e.g., offline education) services, and the like. The order access map determination system 100 may include a server 110, one or more service requester terminals 120, a storage device 130, one or more service provider terminals 140, a network 150, and an information source 160. The server 110 may include a processing engine 112.
In some embodiments, the server 110 may be a single server or a group of servers. The server farm can be centralized or distributed (e.g., server 110 can be a distributed system). In some embodiments, the server 110 may be local or remote. For example, the server 110 may access information and/or data stored in the storage device 130, the service requester terminal 120 through the network 150. As another example, the server 110 may be directly connected to the storage device 130, the service requester terminal 120 to access stored information and/or data. In some embodiments, the server 110 may be implemented on a cloud platform. By way of example only, the cloud platform may include a private cloud, a public cloud, a hybrid cloud, a community cloud, a distributed cloud, between clouds, multiple clouds, the like, or any combination of the above. In some embodiments, server 110 may be implemented on a computing device similar to that shown in FIG. 2 or FIG. 3 of the present application. For example, server 110 may be implemented on one computing device 200 as shown in FIG. 2, including one or more components in computing device 200. As another example, server 110 may be implemented on a mobile device 300 as shown in FIG. 3, including one or more components in computing device 300. In some embodiments, processing engine 112 may process data and/or information related to a service request to perform one or more of the functions described herein. For example, the processing engine 112 may process the acquired data based on the recognition model to determine whether the order requires access to a map, and allow the order to be carpooled that requires access to the map to access the map according to the determination result. In some embodiments, the processing engine 112 may obtain at least two orders to share. In some embodiments, the processing engine 112 may obtain characteristic parameters associated with the at least two orders to be carpooled. In some embodiments, the processing engine 112 may process at least a portion of the characteristic parameters using a recognition model to determine whether the order to be carpooled requires access to a map. In some embodiments, the processing engine 112 may allow the access map for the order to be carpooled that requires access to the map based on the determination of the access map.
In some embodiments, the user of the service requester terminal 120 may be the service requester himself. In some embodiments, the user of the service requester terminal 120 may be a person other than the service requester. For example, in the network car booking service, the user of the service requester terminal 120 may be the vehicle occupant himself or a person who places an order with the vehicle occupant, such as a relative or a friend of the vehicle occupant. For example, in the takeout service, the user of the service requester terminal 120 may be a target object for takeout delivery or a person who helps the target object to take out. For another example, in the home service, the user of the service requester terminal 120 may be an actual requester of the home service, or a person who helps the requester to purchase the home service.
In some embodiments, the user of the service provider terminal 140 may be the service provider himself. In some embodiments, the user of service provider terminal 140 may be a person other than the service provider. For example, in the network appointment service, the user of the service provider terminal 140 may be the driver himself or herself, or a person who helps the driver to take an order. For example, in the takeaway service, the user of the service provider terminal 140 may be the takeaway dispatcher himself or a person who helps the dispatcher take an order. For another example, in home services, the user of the service provider terminal 140 may be an actual service person (such as a maintenance person, a cleaner, etc.) of the home services, or a person who helps the service person to take an order.
In some embodiments, the service requester terminal 120 may include, but is not limited to, a desktop computer 120-1, a laptop computer 120-2, an in-vehicle built-in device 120-3, a mobile device 120-4, and the like or any combination thereof. In some embodiments, the in-vehicle built-in device 120-3 may include, but is not limited to, a personal computer, an in-vehicle heads-up display (HUD), an in-vehicle automatic diagnostic system (OBD), and the like, or any combination thereof. In some embodiments, mobile device 120-4 may include, but is not limited to, a smartphone, a Personal Digital Assistant (PDA), a tablet, a palmtop, smart glasses, a smart watch, a wearable device, a virtual display device, a display enhancement device, and the like, or any combination thereof. In some embodiments, the service requester terminal 120 may send the transportation service requirements to one or more devices in the order access map determination system 100. For example, the service requester terminal 120 may send the transport service requirements to the server 110 for processing.
In some embodiments, the service provider terminal 140 may be a similar or identical device as the service requestor terminal 120. In some embodiments, the service provider terminal 140 may be a device with location technology to determine the location of the service provider and/or the service provider terminal 140. In some embodiments, the service requester terminal 120 and/or the service provider terminal 140 may communicate with other locating devices to determine the location of the service requester, service requester terminal 120, service provider, or service provider terminal 140. In some embodiments, the service requester terminal 120 and/or the service provider terminal 140 may send the location information to the server 110.
The network 150 may facilitate the exchange of information and/or data. In some embodiments, one or more components (e.g., server 110, storage 130, and service requester terminal 120, etc.) in the order access map determination system 100 may send information and/or data to other components in the order access map determination system 100 over the network 150. For example, the server 110 may obtain/obtain data information from the service requester terminal 120 through the network 150. In some embodiments, the network 150 may be any one of, or a combination of, a wired network or a wireless network. For example, network 150 may include a cable network, a wired network, a fiber optic network, a telecommunications network, an intranet, the internet, a Local Area Network (LAN), a Wide Area Network (WAN), a Wireless Local Area Network (WLAN), a Metropolitan Area Network (MAN), a Public Switched Telephone Network (PSTN), a bluetooth network, a ZigBee network, a Near Field Communication (NFC) network, the like, or any combination of the above. In some embodiments, network 150 may include one or more network access points. For example, the network 150 may include wired or wireless network access points, such as base stations and/or Internet switching points 150-1, 150-2, and so forth. Through the access point, one or more components of the order access mapping system 100 may be connected to the network 150 to exchange data and/or information.
The information source 160 is one source that provides other information for the order access map determination system 100. Information sources 160 may be used to provide the system with information related to order information, such as service times, service locations, legal information, news information, life guide information, and the like. The information source 160 may be in the form of a single central server, or may be in the form of a plurality of servers connected via a network, or may be in the form of a large number of personal devices. When the information source 160 is in the form of a plurality of personal devices, the devices may upload text, voice, images, videos, etc. to the cloud server in a user-generated content manner, so that the cloud server communicates with the plurality of personal devices connected thereto to form the information source 160.
FIG. 2 is a schematic diagram of an exemplary computing device 200 shown in accordance with some embodiments of the present application. Server 110 and storage device 130 may be implemented on computing device 200. For example, the processing engine 112 may be implemented on the computing device 200 and configured to implement the functionality disclosed herein.
For ease of understanding, only one processor is exemplarily depicted in fig. 2. However, it should be noted that the computing device 200 in the present application may include multiple processors, and thus the operations and/or methods described in the present application that are implemented by one processor may also be implemented by multiple processors, collectively or independently. For example, if in the present application the processors of computing device 200 perform steps 1 and 2, it should be understood that steps 1 and 2 may also be performed by two different processors of computing device 200, either collectively or independently (e.g., a first processor performing step 1, a second processor performing step 2, or a first and second processor performing steps 1 and 2 collectively).
FIG. 3 illustrates a schematic diagram of exemplary hardware and/or software components of an exemplary mobile device according to some embodiments of the present application.
As shown in fig. 3, the mobile device 300 may include a communication unit 310, a display unit 320, a Graphics Processing Unit (GPU)330, a Central Processing Unit (CPU)340, an input/output 350, a memory 360, a storage 370, and a sensor 380. In some embodiments, any other suitable component, including but not limited to a system bus or a controller (not shown), may also be included in the mobile device 300.
In some embodiments, the operating system 362 (e.g., IOS) is movedTM、AndroidTM、Windows PhoneTMEtc.) and one or more application programs 364 may be loaded from storage 370 into memory 360 for execution by CPU 340. The application 364 may include a browser or any other suitable mobile application for sending data/information associated with transportation services and receiving and presenting processing or other related information from the order access map determination system 100. For example, application 364 may be an online taxi appointment travel platform (e.g., a drip line)TM) The user (e.g., a service requester) can request the transportation service through the application 364 and send the request information to the backend server. User interaction with the information flow may be accomplished via input/output 350 and provided to server 110 and/or other components of order access mapping system 100 via network 150.
To implement the various modules, units, and functions thereof described herein, a computer hardware platform may be used as the hardware platform for one or more of the components described herein. A computer with user interface components may be used to implement a Personal Computer (PC) or any other type of workstation or terminal device. A computer can also function as a system if the computer is appropriately programmed.
FIG. 4 is a block diagram of a carpool order access map determination system shown in accordance with some embodiments of the present application. As shown in fig. 4, the order access map determination system 400 may include an order acquisition module 410, a feature parameter acquisition module 420, an access map determination module 430, and an access map enforcement module 440. In some embodiments, the order acquisition module 410, the feature parameter acquisition module 420, the access map determination module 430, and the access map enforcement module 440 may be included in the processing engine 112 shown in FIG. 1.
The order taking module 410 may be used to take a ride share order. In some embodiments, the order to be carpooled may include a net appointment service order (e.g., a taxi carpool, a private carpool, a bus carpool, etc. order). In some embodiments, the order to be carpooled may be an order that is currently being executed. In some embodiments, the order obtaining module 410 may obtain the order to be carpooled from the storage device 130, and the order obtaining module 410 may also obtain the current order to be carpooled directly from the service requester terminal 120.
The characteristic parameter obtaining module 420 may further be configured to obtain characteristic parameters related to at least two orders to be carpooled. In some embodiments, the characteristic parameter associated with the ride share order reflects at least one of the following pieces of information: the order placing time, the order executing time, the longitude and latitude of the order starting and ending point, the straight distance of the starting and ending point based on the longitude and latitude, the angle based on the straight distance, the estimated driving time based on the straight distance, the history of the service requester or the service provider, the personal information of the service requester or the service provider and the ordering requirement of the service requester or the service provider for the service. Further description of the characteristic parameters can be found elsewhere in this application (e.g., in flowchart 5 and related description), and will not be repeated herein.
The access map determination module 430 may be configured to process at least a portion of the characteristic parameters using the recognition model to determine whether the order to be carpooled requires access to a map.
In some embodiments, the recognition model may be a classification model. Such as decision tree models, bayesian classification, random forests, support vector machines, neural networks, and the like. In some embodiments, the decision Tree model may include, but is not limited to, Classification And Regression Trees (CART), iterative binary Tree three (iterative dichotomiser 3, ID3), C4.5 algorithm, random forest (random forest), chi-square Automatic Interaction Detection (CHAID), Multivariate Adaptive Regression Splines (MARS), And Gradient Boosting Machine (GBM), or the like, or any combination thereof. In some embodiments, the order to be carpooled that requires access to the map may be an order other than an apparently unpinned order. In some embodiments, the order to be carpooled that does not require access to a map may be an apparently unpinned order. Specifically, the apparently unfinished order may include an order with unmatched order start and end point information (e.g., latitude and longitude), long travel detour time, long service provider pick-up time, short riding time (on-board time) shared by a plurality of service requesters, low user tolerance (high customization requirements of the service provider or the service requester), and the like. In some embodiments, the accessed map may be a map server of the ride share system.
As shown in fig. 4, the order access map determination system 400 may further include a recognition model training module 450. The recognition model training module 450 may be used to obtain a recognition model. Specifically, the recognition model training module 450 may obtain a historical car pooling order sample; at least two carpool orders accessing the map are used as a sample and marked as a positive sample, and at least two carpool orders not accessing the map are used as a sample and marked as a negative sample; acquiring characteristic parameters related to historical car pooling orders; and training the initial model to obtain the recognition model based on the characteristic parameters and the marking result.
In some embodiments, the characteristic parameters related to the historical taxi share order may include order placing time, order execution time, longitude and latitude of an order starting and ending point, straight distance of the starting and ending point based on the longitude and latitude, angle based on the straight distance, estimated travel time based on the straight distance, historical records of a service requester or a service provider, personal information of the service requester or the service provider, subscription requirements of the service requester or the service provider and whether the order accesses a map, and the like. Further description of the characteristic parameters can be found elsewhere in this application (e.g., in flowchart 5 and related description), and will not be repeated herein.
The access map enforcement module 440 may be configured to allow the access map for the order to be carpooled that requires access to the map based on the determination result of the access map.
In some embodiments, the determination to access the map may include an "access map order" or a "no access map order". In some embodiments, the access map enforcement module 440 may allow access to the map for a to-be-carpooled order that requires access to the map, and disallow access to the map for a to-be-carpooled order that does not require access to the map.
It should be understood that the system and its modules shown in FIG. 4 may be implemented in a variety of ways. For example, in some embodiments, the system and its modules may be implemented in hardware, software, or a combination of software and hardware. Wherein the hardware portion may be implemented using dedicated logic; the software portions may be stored in a memory for execution by a suitable instruction execution system, such as a microprocessor or specially designed hardware. Those skilled in the art will appreciate that the methods and systems described above may be implemented using computer executable instructions and/or embodied in processor control code, such code being provided, for example, on a carrier medium such as a diskette, CD-or DVD-ROM, a programmable memory such as read-only memory (firmware), or a data carrier such as an optical or electronic signal carrier. The system and its modules of the present application may be implemented not only by hardware circuits such as very large scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, or programmable hardware devices such as field programmable gate arrays, programmable logic devices, etc., but also by software executed by various types of processors, for example, or by a combination of the above hardware circuits and software (e.g., firmware).
It should be noted that the above description of the order access map system and its modules is merely for convenience of description and should not limit the scope of the present application. It will be appreciated by those skilled in the art that, given the teachings of the present system, any combination of modules or sub-system configurations may be used to connect to other modules without departing from such teachings. For example, the order obtaining module 410 and the characteristic parameter obtaining module 420 may be the same module, and the order obtaining module 410 may obtain at least two orders to be carpooled and characteristic parameters related to the at least two orders to be carpooled simultaneously. Such variations are within the scope of the present application.
FIG. 5 is an exemplary flow diagram of a method for determining a carpool order access map, shown in accordance with some embodiments of the present application. In some embodiments, flow 500 may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (instructions run on a processing device to perform hardware simulation), etc., or any combination thereof. One or more operations of the process 500 for determining a carpool order access map shown in fig. 5 may be implemented by the order access map determination system 100 shown in fig. 1. For example, the flow 500 may be stored in the storage device 130 in the form of instructions and executed by the processing engine 112 to perform the calls and/or perform the operations (e.g., the processor 220 of the computing device 200 shown in fig. 2, the central processor 340 of the mobile device 300 shown in fig. 3).
In step 510, at least two ride share orders may be obtained. Specifically, step 510 may be performed by the order taking module 410.
In some embodiments, the order to be carpooled may include a net appointment service order (e.g., a taxi carpool, a private carpool, a bus carpool, etc. order). In some embodiments, the order to share may include at least two orders to share. Specifically, the at least two orders to be carpooled may be the current executing carpool order and the waiting carpool order, or may be the two orders waiting for carpooling with similar order executing time (the time for passengers to get on the car). In some embodiments, the ride share order may include ride share order information. Specifically, the car pool order information may include personal information of the service requester (e.g., nickname, gender, contact address, etc.), time when the service requester requests the service, service location, personal information of the service provider (e.g., nickname, gender, contact address, etc.), and the like. In some embodiments, the service requester terminal 120 may upload the to-be-carpooled order over the network 150 and store it in the storage device 130. In some embodiments, the order obtaining module 410 may obtain the order to be carpooled from the storage device 130, and the order obtaining module 410 may also obtain the current order to be carpooled directly from the service requester terminal 120.
In step 520, characteristic parameters associated with at least two of the to-be-carpooled orders may be obtained. Specifically, step 520 may be performed by the feature parameter obtaining module 420.
In some embodiments, the characteristic parameter associated with the at least two ride share orders reflects at least one of the following pieces of information: the order placing time, the order executing time, the longitude and latitude of the order starting and ending point, the straight distance of the starting and ending point based on the longitude and latitude, the angle based on the straight distance, the estimated driving time based on the straight distance, the history of the service requester or the service provider, the personal information of the service requester or the service provider and the ordering requirement of the service requester or the service provider for the service. In some embodiments, the order placing time may be the time at which a service request is submitted to the server and the order execution time may be the time at which a passenger gets on the bus. For example, the passenger's order time is 7:00 am and the order execution time is 9:00 am.
In some embodiments, the latitude and longitude of the order origination point and destination point may include latitude and longitude information of the order origination point and destination point at which the service requester (e.g., passenger) requests the ride. In some embodiments, the latitude and longitude of the start and end points of the order may be obtained from a map coordinate system via a GPS location point. In some embodiments, the correspondence between latitude and GPS fix in the map coordinate system may be stored in the storage device 130 for acquisition by the feature parameter acquisition module 420. In some embodiments, the linear distance of the start and end points and the angle of the linear distance of the start and end points in the map coordinate system may be calculated based on the longitude and latitude of the start and end points. In some embodiments, the angle may be an angle between the start and end point line and the true north direction, and the angle may be an angle rotated clockwise from the true north direction. For example, the angle may be 30 ° or 210 °. In some embodiments, the travel time to fulfill the order may also be estimated based on the straight-line distance from the start and end points and the vehicle travel speed. In some embodiments, the data and algorithms for calculating the linear distance between the start point and the end point, the angle of the linear distance between the start point and the end point in the map coordinate system, the vehicle driving speed, and the estimated driving time for executing the order may be stored in the storage device 130, and the characteristic parameter obtaining module 420 may obtain the data and algorithms for calculation. In some embodiments, the travel time to execute the order may include a travel time period and a travel time period for executing the order. For example, passenger a sends a car pooling order request to Changshan district of Beijing City at Qinghua university, after 1min, passenger B sends a car pooling order request to Changshan district of Beijing City at Qinghua university, the longitude and latitude of the starting points of passenger a and passenger B can be obtained through a GPS positioning point to be (116.33, 40.0), the longitude and latitude of the terminal point of passenger a to be (116.20, 40.22), and the longitude and latitude of the terminal point of passenger B to be (115.98, 39.72), the characteristic parameter obtaining module 420 can calculate the straight line distance of passenger a order to be 26.6km, and the angle of the straight line distance in the map coordinate with the starting point as the origin is 100 °; the linear distance of the passenger B order is 33km, and the angle of the linear distance in the map coordinates with the starting point as the origin is 240 degrees; if the driving speed of the vehicle obtained by the characteristic parameter obtaining module 420 is 40km/h, the estimated driving time for executing the car pooling order of the passenger A is about 40min, and the estimated driving time for executing the car pooling order of the passenger B is about 49.5 min.
In some embodiments, the history of the service requester or service provider may be the operational behavior of the service requester or service provider on the platform. In some embodiments, the operation behavior of the service requester or service provider on the platform may include the order cancellation frequency, the order cancellation timing, the order modification operation, and the like of the service requester or service provider within a certain time range. For example, the frequency of a passenger or driver taking an order within a day, or the frequency of a driver taking an order again after a continuous order snatching within 10 minutes. The history of service requesters or service providers may also be the amount of outstanding or total outstanding of a service requester or service provider over a time frame in some embodiments. For example, the passenger or driver completes the number of orders within a month.
In some embodiments, the personal information of the service requester or service provider may include a gender of the service requester or service provider, a registration time of the service requester or service provider, an address confidence of the service requester or service provider, a workplace confidence of the service requester or service provider, a loan condition of the service requester or service provider, an education level of the service requester or service provider, a number of complaints of the service requester or service provider within a time range, and an evaluated condition of the service requester or service provider within a time range. In some embodiments, an address confidence for a service requester or service provider, a workplace confidence for a service requester or service provider may be determined based on a confidence for a user frequented location.
In some embodiments, the loan condition may include, but is not limited to, the number of loans, the amount of borrowed, the term of borrowed, and the repayment condition. In some embodiments, the characteristic parameter obtaining module 420 may obtain the loan status of the order originator from a third party database. The third party database includes but is not limited to bank database, social security agency database, credit assessment agency database, p2p network lending platform database.
In some embodiments, the level of education may be represented by discrete values. For example, the primary school culture is represented by 0, the junior middle school culture is represented by 1, the high school culture is represented by 2, and the subject and above are represented by 3. In some embodiments, the educational level may be represented by two values, where the educational level is represented by 1 if the academic story is above the subject and 0 if below the subject.
In some embodiments, the personal information of the service requester or service provider may include the number of complaints of the service requester or service provider within a certain time range and/or the evaluated condition of the service requester or service provider within a certain time range. For example, the number of complaints made by a service requester or a service provider within a month may be counted. In some embodiments, service requestors or service providers may cross-rate, with a full score of five stars, and a worst case may have no or one star; or directly give good or bad comments for mutual evaluation. For example, the number of bad comments received by the service requester or service provider, and the number of good comments received by the service requester or service provider within one month may be counted; or the order quantity of one-star evaluation received in one month and the order quantity of five-star evaluation received in one month.
In some embodiments, the subscription requirement of the service requester or the service provider for the service may include a subscription requirement of the service requester for the service tool or a subscription requirement of the service provider, and may further include a subscription requirement of the service requester or the service provider for the other party. For example, the passenger's requirement for the gender of the driver, the driver's claim for the amount of goodness, the brand of the vehicle, the model of the vehicle, or the price of the vehicle, etc. As another example, a driver or passenger's requirement for a party's personal habits (e.g., no smoking).
In step 530, at least a portion of the characteristic parameters associated with the at least two ride share orders may be processed using the recognition model to determine whether the to-be-ride share order requires access to a map. In particular, step 530 may be performed by the access map determination module 430.
In some embodiments, the recognition model may be a classification model. Such as decision tree models, bayesian classification, random forests, support vector machines, neural networks, and the like. In some embodiments, the decision Tree model may include, but is not limited to, Classification And Regression Trees (CART), iterative binary Tree three (ID 3), C4.5 algorithm, Random Forest (Random Forest), chi-square Automatic Interaction Detection (CHAID), Multivariate Adaptive Regression Splines (MARS), And Gradient Boosting Machine (GBM), or the like, or any combination thereof. In some embodiments, the order to be carpooled that requires access to the map may be an order other than an apparently unpinned order. In some embodiments, the order to be carpooled that does not require access to a map may be an apparently unpinned order. Specifically, the apparently unfinished order may include an order with unmatched order start and end point information (e.g., latitude and longitude), long travel detour time, long service provider pick-up time, short riding time (on-board time) shared by a plurality of service requesters, low user tolerance (high customization requirements of the service provider or the service requester), and the like. In some embodiments, the accessed map may be a map server of the ride share system. Taking the network appointment service as an example, when the execution time of the order C is 10:00 am at 30 days of 4 months, and the execution time of the order C is 15:00 pm at 30 days of 4 months, the execution times of the two orders are greatly different, and the orders are obviously pieced together, so that the order C and the order D do not need to access a map server of the carpooling system. For another example, two orders from Beijing city, the end point of order E is Shenyang river district, and the longitude and latitude are (123.45, 41.80); the destination of order F is Zheng Zhou university, longitude and latitude are (113.381523, 34.443624), and the longitude and latitude of the two order destinations are far away, so that the order E and the order F are obviously not pieced together, and therefore the order E and the order F do not need to access a map database of the carpool system. In some embodiments, the order placing time, the order execution time, the longitude and latitude of the order starting and ending point, the straight distance of the starting and ending point based on the longitude and latitude, the angle based on the straight distance, the estimated travel time based on the straight distance, the history of the service requester or the service provider, the personal information of the service requester or the service provider, or the subscription requirement of the service requester to the service may be input into the identification model to obtain the final identification result. In some embodiments, the identification result may be a result of an "access map order" or a "do not need access map order". In some embodiments, the recognition result may be output with different values, for example, "1" represents "an order requiring access to a map" and "0" represents "an order requiring no access to a map".
In step 540, the access map may be allowed for the order to be carpooled that requires access to the map based on the determination result of the access map. In particular, this step 540 may be performed by the access map enforcement module 440.
In some embodiments, the determination to access the map may include an "access map order" or a "no access map order". In some embodiments, the access map enforcement module 440 may allow access to the map for a to-be-carpooled order that requires access to the map, and disallow access to the map for a to-be-carpooled order that does not require access to the map.
It should be noted that the above description related to the flow 500 is only for illustration and explanation, and does not limit the applicable scope of the present application. Various modifications and changes to flow 500 may occur to those skilled in the art upon review of the present application. However, such modifications and variations are intended to be within the scope of the present application. For example, step 510 and step 520 may be combined into one step, and the order obtaining module 410 may obtain at least two orders to be carpooled and characteristic parameters related to the at least two orders to be carpooled simultaneously.
FIG. 6 is an exemplary flow diagram of a recognition model training method shown in accordance with some embodiments of the present application. In some embodiments, flow 600 may be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (instructions run on a processing device to perform hardware simulation), etc., or any combination thereof. One or more of the operations in the flow 600 for recognition model training illustrated in FIG. 6 may be implemented by the order access map determination system 100 illustrated in FIG. 1. For example, the flow 600 may be stored in the storage device 130 in the form of instructions and executed by the processing engine 112 to perform the calls and/or perform the operations (e.g., the processor 220 of the computing device 200 shown in fig. 2, the central processor 340 of the mobile device 300 shown in fig. 3).
In step 610, a sample of historical ride share orders may be obtained. In particular, this step 610 may be performed by the recognition model training module 450.
In some embodiments, the historical ride share order sample may include historical ride share orders over a period of time. Such as a one week historical order, a one month historical order, etc. In some embodiments, the historical orders may include orders that are completed. In particular, completed orders may include orders that were carpooled successfully and orders that were not carpooled successfully. In some embodiments, the recognition model training module 450 may retrieve historical orders from the order access map determination system 100 (e.g., the storage device 130). For example, the model training unit 431 may obtain the historical carpool orders from 1 month 1 day to 1 month 7 day of 2019 from the storage device 130 as a sample of the recognition model training.
In some embodiments, the recognition model training module 450 may also label the obtained historical car pool order samples. Specifically, at least two carpool orders that access the map may be marked as a positive sample, and at least two carpool orders that do not access the map may be marked as a negative sample. In some embodiments, positive samples may be represented by a number "1" and negative samples by a number "0".
In step 620, characteristic parameters associated with the historical ride share order may be obtained. In particular, this step 620 may be performed by the recognition model training module 450.
In some embodiments, the characteristic parameters related to the historical taxi share order may include order placing time, order execution time, longitude and latitude of an order starting and ending point, straight distance of the starting and ending point based on the longitude and latitude, angle based on the straight distance, estimated travel time based on the straight distance, historical records of a service requester or a service provider, personal information of the service requester or the service provider, subscription requirements of the service requester or the service provider and whether the order accesses a map, and the like. Further description of the characteristic parameters can be found elsewhere in this application (e.g., in flowchart 5 and related description), and will not be repeated herein. In some embodiments, the recognition model training module 450 may obtain feature parameters associated with historical ride share orders.
In step 630, the initial model may be trained to obtain a recognition model based on the feature parameters and the labeling result.
In some embodiments, each sample includes characteristic information of two or more ride share orders, and marking a ride share order sample may be marking the two or more ride share orders as one sample. In some embodiments, the output recognition result of the trained recognition model may be "an order to access a map" or "an order not to access a map", corresponding to the positive and negative examples marked in step 610, respectively. In some embodiments, the recognition result may be to output a different value, for example, "1" represents "an order to access a map", corresponding to a positive sample in a historical order; "0" represents "an order without access to a map", corresponding to a negative example in a historical order.
In some embodiments, the recognition model may be a classification model. Such as decision tree models, bayesian classification, random forests, support vector machines, neural networks, and the like. In some embodiments, the decision Tree model may include, but is not limited to, Classification And Regression Trees (CART), iterative binary Tree three (ID 3), C4.5 algorithm, Random Forest (Random Forest), chi-square Automatic Interaction Detection (CHAID), Multivariate Adaptive Regression Splines (MARS), And Gradient Boosting Machine (GBM), or the like, or any combination thereof.
In some embodiments, the characteristic parameters and the labeled results in the historical car-sharing order samples can be input into the initial model for training, so as to obtain a trained recognition model. The recognition model can recognize the order to be carpooled so as to determine whether the order to be carpooled needs to access the map.
In some embodiments, during the training process, the model may be validated using the validation set and the model parameters may be adjusted to optimize the model based on the validation results (e.g., the model is under-fit and/or over-fit). And the data in the verification set and the training data of the initial model are independently and identically distributed and have no intersection. In some embodiments, when a preset condition is met, the model training may be stopped and the final model may be output as the required machine learning model. In some embodiments, a greedy algorithm may be employed to optimize the model. In some embodiments, the characteristic parameters in the model may be determined by maximum likelihood estimation. In some embodiments, a log-likelihood function may be employed, i.e.
And (4) calculating. It should be noted that the above description of flow 600 is for purposes of example and illustration only and is not limiting of the present applicationAnd (4) application range. Various modifications and changes to flow 600 may occur to those skilled in the art, given the benefit of this disclosure. However, such modifications and variations are intended to be within the scope of the present application. For example, steps 610 and 620 may be combined into one step, and the historical ride share order is obtained at the same time as the characteristic parameters related to the historical ride share order. For another example, in step 610, at least two ride share orders that access the map can be marked as negative examples as a sample, and at least two ride share orders that do not access the map can be marked as positive examples as a sample.
The beneficial effects that may be brought by the embodiments of the present application include, but are not limited to: (1) the order to be carpooled which can not be obviously spliced can be screened out through the machine learning model without depending on a map, so that the order quantity of the map to be carpooled under the carpooling scene is effectively reduced, and the map access efficiency is improved; (2) the situation that a large number of car sharing orders access the map at the same time to cause overload or breakdown of the server is avoided, and the user experience is improved. It is to be noted that different embodiments may produce different advantages, and in different embodiments, any one or combination of the above advantages may be produced, or any other advantages may be obtained.
Having thus described the basic concept, it will be apparent to those skilled in the art that the foregoing detailed disclosure is to be considered merely illustrative and not restrictive of the broad application. Various modifications, improvements and adaptations to the present application may occur to those skilled in the art, although 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. Reference throughout this specification to "one embodiment," "an embodiment," and/or "some embodiments" means that a particular feature, structure, or characteristic described in connection with at least one embodiment of the present application is included in at least one embodiment of the present 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, some features, structures, or characteristics of one or more embodiments of the present application may be combined as appropriate.
Moreover, those skilled in the art will appreciate that aspects of the present application may be illustrated and described in terms of several patentable species or situations, including any new and useful combination of processes, machines, manufacture, or materials, or any new and useful improvement thereon. Accordingly, various aspects 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. The above hardware or software may be referred to as "data block," module, "" engine, "" unit, "" component, "or" system. Furthermore, aspects of the present application may be represented as a computer product, including computer readable program code, embodied in one or more computer readable media.
The computer storage medium may comprise a propagated data signal with the computer program code embodied therewith, for example, on baseband or as part of a carrier wave. The propagated signal may take any of a variety of forms, including electromagnetic, optical, etc., or any suitable combination. A computer storage medium may be any computer-readable medium that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code located on a computer storage medium may be propagated over any suitable medium, including radio, cable, fiber optic cable, RF, or the like, or any combination of the preceding.
Computer program code required for the operation of various portions of the present application may be written in any one or more programming languages, including an object 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, and the like. 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 explicitly claimed. While various presently contemplated embodiments of the invention have been discussed in the foregoing disclosure by way of example, it is to 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 application, various features are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure aiding in the understanding of one or more of the embodiments. This method of disclosure, however, is not intended to require more features than are expressly recited in the claims. Indeed, the embodiments may be characterized as having less than all of the features of a single embodiment disclosed above.
Numerals describing the number of components, attributes, etc. are used in some embodiments, it being understood that such numerals used in the description of the embodiments are modified in some instances by the use of the modifier "about", "approximately" or "substantially". Unless otherwise indicated, "about", "approximately" or "substantially" indicates that the number allows a variation of ± 20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximations that may vary depending upon the desired properties of the individual embodiments. In some embodiments, the numerical parameter should take into account the specified significant digits and employ a general digit preserving approach. Notwithstanding that the numerical ranges and parameters setting forth the broad scope of the range are approximations, in the specific examples, such numerical values are set forth as precisely as possible within the scope of the application.
The entire contents of each patent, patent application publication, and other material cited in this application, such as articles, books, specifications, publications, documents, and the like, are hereby incorporated by reference into this application. Except where the application is filed in a manner inconsistent or contrary to the present disclosure, and except where the claim is filed in its broadest scope (whether present or later appended to the application) as well. It is noted that the descriptions, definitions and/or use of terms in this application shall control if they are inconsistent or contrary to the statements and/or uses of the present application in the material attached to this application.
Finally, it should be understood that the embodiments described herein are merely illustrative of the principles of the embodiments of the present application. Other variations are also possible within the scope of the present application. Thus, by way of example, and not limitation, alternative configurations of the embodiments of the present application can be viewed as being consistent with the teachings of the present application. Accordingly, the embodiments of the present application are not limited to only those embodiments explicitly described and depicted herein.
Claims (12)
1. A method for determining a carpool order access map, comprising:
acquiring at least two to-be-carpooled order forms;
acquiring characteristic parameters related to the at least two to-be-carpooled orders;
processing at least one part of characteristic parameters related to the at least two orders to be carpooled by utilizing an identification model, and determining whether the orders to be carpooled need to access a map.
2. The method according to claim 1, wherein the characteristic parameters related to the at least two to-be-carpooled orders comprise at least one of:
the order placing time, the order executing time, the longitude and latitude of the order starting and ending point, the straight distance of the starting and ending point based on the longitude and latitude, the angle based on the straight distance, the estimated driving time based on the straight distance, the history of the service requester or the service provider, the personal information of the service requester or the service provider and the ordering requirement of the service requester or the service provider for the service.
3. The method of claim 1, wherein the recognition model comprises a classification model.
4. The method of claim 1, wherein the recognition model comprises a decision tree model, a bayesian classification method, a random forest, a support vector machine, or a neural network.
5. The method of claim 1, wherein the recognition model is obtained by:
obtaining a historical car pooling order sample; at least two carpool orders accessing the map are used as a sample and marked as a positive sample, and at least two carpool orders not accessing the map are used as a sample and marked as a negative sample;
acquiring characteristic parameters related to the historical carpooling order;
and training an initial model to obtain the recognition model based on the characteristic parameters and the marking result.
6. The method of claim 5, wherein the characteristic parameters associated with the historical ride share order comprise at least one of:
the order placing time, the order executing time, the longitude and latitude of the order starting and ending point, the straight distance of the starting and ending point based on the longitude and latitude, the angle based on the straight distance, the estimated driving time based on the straight distance, the history of the service requester or the service provider, the personal information of the service requester or the service provider, the ordering requirement of the service requester and whether the order accesses a map.
7. The method of claim 1, wherein the order to be carpooled requiring access to the map is an order other than an explicit impossibility order.
8. The method of claim 7, wherein the explicit misspelled order comprises an order with unmatched departure and destination information, long detour times, long take-over times, short ride-sharing times, or low user tolerance.
9. The method of claim 1, further comprising:
and allowing the to-be-carpooled order requiring to access the map based on the determination result of the access map.
10. A system for determining a carpool order access map is characterized by comprising an order acquisition module, a characteristic parameter acquisition module and an access map determination module; wherein:
the order acquisition module is used for acquiring at least two orders to be shared;
the characteristic parameter acquisition module is used for acquiring characteristic parameters related to the at least two to-be-carpooled orders;
the access map determining module is used for processing at least one part of the characteristic parameters related to the at least two orders to be carpooled by utilizing the identification model and determining whether the orders to be carpooled need to access the map.
11. An apparatus for determining a carpool order access map, the apparatus comprising at least one processor and at least one memory device for storing instructions that, when executed by the at least one processor, implement the method of any of claims 1-9.
12. A computer readable storage medium storing computer instructions which, when read by a computer, cause the computer to perform the method of any one of claims 1 to 9.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010437553.9A CN111881227A (en) | 2020-05-21 | 2020-05-21 | Method and system for determining carpool order access map |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010437553.9A CN111881227A (en) | 2020-05-21 | 2020-05-21 | Method and system for determining carpool order access map |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111881227A true CN111881227A (en) | 2020-11-03 |
Family
ID=73154386
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010437553.9A Pending CN111881227A (en) | 2020-05-21 | 2020-05-21 | Method and system for determining carpool order access map |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111881227A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113724495A (en) * | 2021-08-09 | 2021-11-30 | 东南大学 | Traffic prediction method for city sharing trip |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107230091A (en) * | 2016-03-23 | 2017-10-03 | 滴滴（中国）科技有限公司 | Order matching process and device are asked in share-car |
| CN107682419A (en) * | 2017-09-20 | 2018-02-09 | 北京摩拜科技有限公司 | Offer method, client, server and the Carpooling system of share-car route |
| CN107767322A (en) * | 2016-08-22 | 2018-03-06 | 平安科技（深圳）有限公司 | Share-car method and apparatus |
| CN108734361A (en) * | 2017-04-18 | 2018-11-02 | 北京嘀嘀无限科技发展有限公司 | Share-car order processing method and apparatus |
| CN108805411A (en) * | 2018-05-18 | 2018-11-13 | 北京嘀嘀无限科技发展有限公司 | Net about vehicle order allocation method, device, server, terminal and readable storage medium storing program for executing |
| US20190050764A1 (en) * | 2016-11-08 | 2019-02-14 | Beijing Didi Infinity Technology And Development Co., Ltd. | Systems and methods for determining a reference direction related to a vehicle |
| CN110619402A (en) * | 2019-08-13 | 2019-12-27 | 杭州飞步科技有限公司 | Vehicle dispatching method and device, electronic equipment and storage medium |
-
2020
- 2020-05-21 CN CN202010437553.9A patent/CN111881227A/en active Pending
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107230091A (en) * | 2016-03-23 | 2017-10-03 | 滴滴（中国）科技有限公司 | Order matching process and device are asked in share-car |
| CN107767322A (en) * | 2016-08-22 | 2018-03-06 | 平安科技（深圳）有限公司 | Share-car method and apparatus |
| US20190050764A1 (en) * | 2016-11-08 | 2019-02-14 | Beijing Didi Infinity Technology And Development Co., Ltd. | Systems and methods for determining a reference direction related to a vehicle |
| CN108734361A (en) * | 2017-04-18 | 2018-11-02 | 北京嘀嘀无限科技发展有限公司 | Share-car order processing method and apparatus |
| CN107682419A (en) * | 2017-09-20 | 2018-02-09 | 北京摩拜科技有限公司 | Offer method, client, server and the Carpooling system of share-car route |
| CN108805411A (en) * | 2018-05-18 | 2018-11-13 | 北京嘀嘀无限科技发展有限公司 | Net about vehicle order allocation method, device, server, terminal and readable storage medium storing program for executing |
| CN110619402A (en) * | 2019-08-13 | 2019-12-27 | 杭州飞步科技有限公司 | Vehicle dispatching method and device, electronic equipment and storage medium |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113724495A (en) * | 2021-08-09 | 2021-11-30 | 东南大学 | Traffic prediction method for city sharing trip |
| CN113724495B (en) * | 2021-08-09 | 2022-07-01 | 东南大学 | Traffic prediction method for city shared trip |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10701556B2 (en) | Systems and methods for determining an affinity between users | |
| US11279368B2 (en) | System and method for determining safety score of driver | |
| CN109478275B (en) | System and method for distributing service requests | |
| US20180240045A1 (en) | Systems and methods for allocating sharable orders | |
| CN111052158B (en) | System and method for distributing service requests | |
| US20180053277A1 (en) | Systems and methods for carpooling | |
| US20210043086A1 (en) | Systems and methods for generating personalized destination recommendations | |
| US20200300650A1 (en) | Systems and methods for determining an estimated time of arrival for online to offline services | |
| US11388547B2 (en) | Systems and methods for updating sequence of services | |
| CN111861618A (en) | Boarding point recommendation method and system | |
| US20210042817A1 (en) | Methods and systems for order allocation | |
| CN111861619A (en) | Recommendation method and system for shared vehicles | |
| US20200167812A1 (en) | Systems and methods for determining a fee of a service request | |
| CN111932341A (en) | Method and system for determining car pooling order | |
| CN111133484A (en) | System and method for evaluating a dispatch strategy associated with a specified driving service | |
| CN110914856B (en) | System and method for determining marketing strategies for online-to-offline services | |
| CN111881227A (en) | Method and system for determining carpool order access map | |
| CN110839346A (en) | System and method for distributing service requests | |
| CN111858868A (en) | Customer service response model training method and system | |
| US20200286008A1 (en) | Systems and methods for distributing on-demand service requests | |
| CN111858788A (en) | Method and system for recommending taxi-sharing boarding points | |
| WO2019153944A1 (en) | Systems and methods for secured communication of service information | |
| CN111859059A (en) | Geographic information feature extraction method and system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |