CN110702129A

CN110702129A - System and method for path planning

Info

Publication number: CN110702129A
Application number: CN201910469821.2A
Authority: CN
Inventors: 李海波; 仇辉
Original assignee: Beijing Didi Infinity Technology and Development Co Ltd
Current assignee: Beijing Didi Infinity Technology and Development Co Ltd
Priority date: 2019-05-31
Filing date: 2019-05-31
Publication date: 2020-01-17
Anticipated expiration: 2039-05-31
Also published as: CN110702129B; WO2020237710A1

Abstract

The present application relates to systems and methods for path planning. The system may perform the following method: acquiring a path planning request including a departure time from a user terminal; determining at least two candidate paths for the path planning request, wherein each candidate path comprises at least two road sections; for each of at least two road segments of each candidate route, determining a predicted transit time for the road segment for a target time associated with a departure time; acquiring vehicle-road section information related to the number of vehicles on a road section; determining the weight of the road section according to the predicted passing time and the vehicle-road section information; determining an optimal path for the path planning request from the at least two candidate paths based on the weight of each of the at least two segments of each candidate path.

Description

System and method for path planning

Technical Field

The present application relates generally to systems and methods for path planning and, more particularly, to systems and methods for providing optimal paths to alleviate congestion.

Background

With the popularity of Location Based Services (LBS), the passage habits of people are increasingly influenced by moving maps, particularly in the most important and most common functions of providing route planning and recommendation services. People increasingly rely on the path planning function of moving maps to travel. In some cases, the path planning function of the moving map affects the traffic jam of the city to some extent. For example, on weekends, many residents (e.g., users of a moving map) in the same large residential community plan to drive or ride to the same shopping center for entertainment, meals, and the like. If all or most of the users are suggested to use the same shortest time path (also referred to as shortest path), there may be a large number of users on the shortest path, which may result in traffic congestion, at least because of prior planning, users may spend more time reaching the shopping mall. Accordingly, it is desirable to provide an efficient system and method for path planning to simultaneously prevent congestion caused by the planning itself, reduce user transit time, and improve user experience.

Disclosure of Invention

One aspect of the present application introduces a system for path planning. The system may include at least one storage medium including a set of instructions for path planning, and at least one processor in communication with the storage medium. When executing the set of instructions, the at least one processor may perform the following: the at least one processor may obtain a path planning request including a departure time from a user terminal. The at least one processor may determine at least two candidate paths for the path planning request. Each candidate path may include at least two segments. For each of the at least two segments of each candidate route, the at least one processor may determine a predicted transit time for the segment at a target time associated with the departure time, obtain vehicle-segment information associated with a number of vehicles on the segment, and determine a weight for the segment based on the predicted transit time and the vehicle-segment information. The at least one processor may determine an optimal path for the path planning request from the at least two candidate paths based on a weight of each of the at least two segments of each candidate path.

In some embodiments, to obtain vehicle-segment information related to a number of vehicles on the segment, the at least one processor may further determine a historical number of vehicles to pass on the segment for a historical target time corresponding to the departure time; determining a current number of vehicles traveling on the road segment within a current time; determining a number of planned vehicles planned to the road segment within a preset historical time period; and determining vehicle-to-road segment information related to the number of vehicles on the road segment based on the number of historical vehicles, the number of current vehicles, and the number of planned vehicles.

In some embodiments, to determine the expected transit time, the at least one processor may further obtain a historical transit time for the road segment corresponding to the target time within a historical target time; acquiring a current transit time based on the current time; determining a time interval between a target time and a current time; and determining the expected transit time based on the historical transit time, the current transit time, and the time interval.

In some embodiments, to obtain historical transit times, the at least one processor may also determine that the departure time is on a weekday or on a weekend; and in response to determining that the departure time is on a weekday, determining an average historical transit time for the road segment within a historical target time corresponding to the target time on a first preset number of historical weekdays as the historical transit time.

In some embodiments, to obtain historical transit times, the at least one processor may also determine that the departure time is on a weekday or on a weekend; and in response to determining that the departure time is a weekend, determining an average historical transit time for the road segment within a historical target time corresponding to target times for a second preset number of historical weekends as the historical transit time.

In some embodiments, to determine the optimal path from the at least two candidate paths, for each of the at least two candidate paths, the at least one processor may further determine a sum of at least two weights for at least two segments of the candidate path; and determining an optimal path based on the sum of the weights corresponding to the at least two candidate paths.

In some embodiments, the at least one processor may further instruct the user terminal to display the optimal path on a user interface of the user terminal in response to the path planning request.

According to another aspect of the present application, a method for path planning may include obtaining a path planning request including a departure time from a user terminal; determining at least two candidate paths of the path planning request, wherein each candidate path comprises at least two road sections; for each of at least two road segments of each candidate route, determining a predicted transit time for the road segment at a target time related to the departure time, obtaining vehicle-segment information related to the number of vehicles on the road segment, and determining a weight for the road segment based on the predicted transit time and the vehicle-segment information; determining an optimal path for the path planning request from the at least two candidate paths based on the weight of each of the at least two segments of each candidate path.

According to yet another aspect of the application, a non-transitory computer-readable medium includes at least one set of instructions compatible with path planning. When executed by at least one processor of an electronic device, the at least one set of instructions instructs the at least one processor to perform a method. The method may include obtaining a path planning request including a departure time from a user terminal; determining at least two candidate paths of the path planning request, wherein each candidate path comprises at least two road sections; for each of at least two road segments of each candidate route, determining a predicted transit time for the road segment at a target time related to the departure time, obtaining vehicle-segment information related to the number of vehicles on the road segment, and determining a weight for the road segment based on the predicted transit time and the vehicle-segment information; determining an optimal path for the path planning request from the at least two candidate paths based on the weight of each of the at least two segments of each candidate path.

According to yet another aspect of the present application, a system for path planning may include a request acquisition module, a candidate path determination module, a weight determination module, and an optimal path determination module. The request obtaining module may be configured to obtain a path planning request including a departure time from the user terminal. The candidate path determination module may be configured to determine at least two candidate paths of the path planning request. Each candidate path may include at least two segments. For each of the at least two segments of each candidate route, the weight determination module may be configured to determine a predicted transit time for the segment at a target time relative to the departure time; obtaining vehicle-road segment information related to the number of vehicles on the road segment; and determining a weight of the road section according to the predicted transit time and the vehicle-road section information. The optimal path determination module may be configured to determine an optimal path for the path planning request from the at least two candidate paths based on a weight of each of the at least two segments of each candidate path.

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. These embodiments are non-limiting exemplary embodiments in which like reference numerals represent similar structures throughout the several views of the drawings, and wherein:

FIG. 1 is a schematic diagram illustrating an exemplary system according to some embodiments of the present application;

FIG. 2 is a schematic diagram of exemplary hardware and/or software components of a computing device according to some embodiments of the present application;

FIG. 3 is a schematic diagram of exemplary hardware and/or software components of a mobile device shown in accordance with some embodiments of the present application;

FIG. 4 is a block diagram of an exemplary processing engine shown in accordance with some embodiments of the present application;

fig. 5 is a flow diagram of an exemplary process for path planning, according to some embodiments of the present application.

Fig. 6 is a flow diagram of an exemplary process for determining vehicle-road segment information according to some embodiments of the present application.

Fig. 7 is a flow diagram of an exemplary process for determining a projected transit time according to some embodiments of the present application.

FIG. 8 is a flow chart of an exemplary process for determining historical transit times according to some embodiments of the present application.

FIG. 9 is a flow diagram of an exemplary process for determining an optimal path according to some embodiments of the present application; and

fig. 10 is a schematic diagram of an exemplary candidate path according to some embodiments of the present application.

Detailed Description

The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a particular application and its requirements. It will be apparent to those of ordinary skill in the art that various changes can be made to the disclosed embodiments and that the general principles defined in this application can be applied to other embodiments and applications without departing from the principles and scope of the application. Thus, the present application is not limited to the described embodiments, but should be accorded the widest scope consistent with the claims.

The terminology used in the description presented herein is for the purpose of describing particular example embodiments only and is not intended to limit the scope of the present application. As used herein, the singular forms "a", "an" and "the" may include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, components, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, components, and/or groups thereof.

These and other features and characteristics of the present invention, as well as the methods of operation and functions of the related elements of structure and the combination of parts and economies of scale, will become more apparent upon consideration of the following description of the accompanying drawings, all of which form a part of this specification. It is to be understood, however, that the drawings are designed solely for the purposes of illustration and description and are not intended as a definition of the limits of the application. It should be understood that the drawings are not to scale.

Flow charts are used herein to illustrate operations performed by systems according to some embodiments of the present application. It should be understood that the operations in the flow diagrams may be performed out of order. Rather, various steps may be processed in reverse order or simultaneously. Also, one or more other operations may be added to the flowcharts. One or more operations may also be deleted from the flowcharts.

One aspect of the present application relates to systems and methods for path planning. To this end, the system and method may acquire vehicle-road segment information related to the number of vehicles on the road segment. The vehicle-segment information may include a historical number of vehicles traveling on the segment at a particular historical time, a current number of vehicles traveling on the segment at a current time, and a projected number of vehicles projected to travel on the segment within a predetermined time period prior to the current time. The system and method of the present application may also determine a weight for the road segment (related to the time taken for path planning) based on the vehicle-road segment information. The system and method may also determine an optimal path for the path plan based on the weights of at least two segments of the one or more possible routes. In this way, the system and method of the present application can effectively reduce the transit time of the user and simultaneously alleviate congestion.

Fig. 1 is a schematic diagram of an exemplary (AI) system 100 according to some embodiments of the present application. For example, the system 100 may be an online-to-offline service platform for providing services such as taxis, driver services, delivery vehicles, carpools, bus services, driver recruitment, shift services, online navigation services, delivery services for goods, and the like. System 100 may include server 110, network 120, user terminal 130, and memory 140. The server 110 may include a processing engine 112.

The server 110 may be configured to process information and/or data related to path planning. For example, the server 110 may determine at least two candidate paths for a path planning request that includes a departure time. Each candidate path may include at least two segments. For another example, the server 110 may determine an optimal path for the path planning request from the at least two candidate paths based on the weight of each of the at least two segments of each candidate path. For another example, the server 110 may instruct the user terminal to display the optimal path on a user interface of the user terminal in response to the path planning request. In some embodiments, the server 110 may be a single server or a group of servers. The set of servers can be centralized or distributed (e.g., the servers 110 can be a distributed system). In some embodiments, the server 110 may be local or remote. For example, server 110 may access information and/or data stored in user terminal 130 or memory 140 via network 120. As another example, server 110 may be coupled to user terminal 130 and/or memory 140 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, an internal cloud, a multi-tiered cloud, and the like, or any combination thereof. In some embodiments, server 110 may execute on computing device 200 described in FIG. 2, which includes one or more components.

In some embodiments, the server 110 may include a processing engine 112. Processing engine 112 may process information and/or data related to path planning to perform one or more of the functions described herein. For example, the processing engine 112 may determine the expected transit time for each road segment at a target time associated with the departure time for that road segment. For another example, the processing engine 112 may determine the weight for the road segment based on the predicted transit time and vehicle-segment information related to the number of vehicles on the road segment. In some embodiments, the processing engine 112 may comprise one or more processing engines (e.g., a single chip processing engine or a multi-chip processing engine). By way of example only, the processing engine 112 may include one or more hardware processors, such as a Central Processing Unit (CPU), an Application Specific Integrated Circuit (ASIC), an application specific set of instruction processors (ASIP), an image processing unit (GPU), a physical arithmetic processing unit (PPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a controller, a microcontroller unit, a Reduced Instruction Set Computer (RISC), a microprocessor, or the like, or any combination thereof.

Network 120 may facilitate the exchange of information and/or data. In some embodiments, one or more components of system 100 (e.g., server 110, user terminal 130, and memory 140) may send information and/or data to other components in system 100 via network 120. For example, the server 110 may obtain a path planning request including a departure time from a user terminal through the network 120. As another example, the server 110 may instruct the user terminal to display the optimal path on a user interface of the user terminal in response to the path planning request through the network 120. In some embodiments, the network 120 may be any form of wired or wireless network, or any combination thereof. By way of example only, network 120 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 120 may include one or more network access points. For example, network 120 may include wired or wireless network access points, such as base stations and/or Internet switching points 120-1, 120-2, … …, through which one or more components of system 100 may connect to network 120 to exchange data and/or information.

The user terminal 130 may be any electronic device used by a service requester of the path planning service. In some embodiments, the user terminal 130 may be a mobile device 130-1, a tablet computer 130-2, a laptop computer 130-3, a desktop computer 130-4, the like, or any combination thereof. In some embodiments, the mobile device 130-1 may include a wearable apparatus, a smart mobile device, a virtual reality device, an augmented reality device, etc., or any combination thereof. In some embodiments, the wearable device may include a smart bracelet, smart footwear, smart glasses, smart helmet, smart watch, smart clothing, smart backpack, smart accessoryPieces, etc., or any combination thereof. In some embodiments, the smart mobile device may include a smart phone, a Personal Digital Assistant (PDA), a gaming device, a navigation device, a point of sale (POS), etc., or any combination thereof. In some embodiments, the virtual reality device and/or the enhanced virtual reality device may include a virtual reality helmet, virtual reality glasses, virtual reality eyecups, augmented reality helmets, augmented reality glasses, augmented reality eyecups, and the like, or any combination thereof. For example, the virtual reality device and/or augmented reality device may include a Google Glass^TM，RiftCon^TM，Fragments^TM，GearVR^TM, and the like. In some embodiments, desktop computer 130-4 may be an on-board computer, an on-board television, or the like.

In some embodiments, user terminal 130 may be a device having location technology for locating the position of the passenger and/or user terminal 130. Positioning techniques used in the present application may include Global Positioning System (GPS), global satellite navigation system (GLONASS), COMPASS navigation system (COMPASS), galileo positioning system, quasi-zenith satellite system (QZSS), wireless fidelity (WiFi) positioning techniques, and the like, or any combination thereof. One or more of the above positioning techniques may be used interchangeably in this application.

In some embodiments, the user terminal 130 may also include at least one network port. The at least one network port may be configured to transmit information to and/or receive information from one or more components (e.g., server 110, memory 140) in system 100 over network 120. In some embodiments, user terminal 130 may be implemented on computing device 200 having one or more components shown in FIG. 2, or on mobile device 300 in the present application having one or more components shown in FIG. 3.

Memory 140 may store data and/or instructions. For example, the memory 140 may store data acquired from the user terminal 130 (e.g., a path planning request including a departure time). For another example, the memory 140 may store historical data for a road segment (e.g., historical transit times for the road segment at a particular time, historical numbers of vehicles traveling over the road segment at a particular historical time, or planned numbers of vehicles planned to the road segment within a preset historical time period, etc.). As yet another example, memory 140 may store data and/or instructions that server 110 may execute or perform the example methods described herein. In some embodiments, memory 140 may include mass storage, removable storage, volatile read-write memory, read-only memory (ROM), etc., or any combination thereof. Exemplary mass storage devices may include magnetic disks, optical disks, solid state disks, and the like. Exemplary removable memory may include flash drives, floppy disks, optical disks, memory cards, compact disks, magnetic tape, and the like. Exemplary volatile read and write memories can include Random Access Memory (RAM). Exemplary RAM may include Dynamic Random Access Memory (DRAM), double data Rate synchronous dynamic random access memory (DDR)

SDRAM), Static Random Access Memory (SRAM), thyristor random access memory (T-RAM), and zero-capacitance random access memory (Z-RAM), among others. Exemplary read-only memories may include mask read-only memory (MROM), programmable read-only memory (PROM), erasable programmable read-only memory (perrom), electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM), digital versatile disc read-only memory, and the like. In some embodiments, the memory 140 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, an internal cloud, a multi-tiered cloud, and the like, or any combination thereof.

In some embodiments, memory 140 may include at least one network port to communicate with other devices in system 100. For example, the memory 140 may be connected to the network 120 to communicate with one or more components of the system 100 (e.g., the server 110, the user terminal 130) via at least one network port. One or more components in system 100 may access data or instructions stored in memory 140 via network 120. In some embodiments, memory 140 may be directly connected to or in communication with one or more components in system 100 (e.g., server 110, user terminal 130). In some embodiments, memory 140 may be part of server 110.

In some embodiments, one or more components of system 100 (e.g., server 110, user terminal 130, and memory 140) may communicate with each other in the form of electronic and/or electromagnetic signals over wires and/or wirelessly. In some embodiments, system 100 may also include at least one data exchange port. The at least one switch port may be configured to receive information and/or transmit information (e.g., in the form of electronic and/or electromagnetic signals) related to path planning services between any electronic devices in the system 100. In some embodiments, the at least one data exchange port may be one or more of an antenna, a network interface, a network port, etc., or any combination thereof. For example, at least one data exchange port may be a network port connected to server 110 to send information thereto and/or receive information sent therefrom.

FIG. 2 is a schematic diagram of exemplary hardware and software components of a computing device 200, on which computing device 200 server 110 and/or user terminal 130 may be implemented according to some embodiments of the present application. For example, the processing engine 112 may be implemented on the computing device 200 and perform the functions of the processing engine 112 disclosed herein.

Computing device 200 may be used to implement system 100 of the present application. Computing device 200 may be used to implement any components of system 100 that perform one or more functions disclosed herein. For example, the processing engine 112 may be implemented on the computing device 200 by its hardware, software programs, firmware, or a combination thereof. Although only one such computer is shown, for convenience, computer functionality related to the online-to-offline services described herein may be implemented in a distributed manner across multiple similar platforms to distribute processing load.

For example, computing device 200 may include a network connectivity communication port 250 to enable data communication. The COM port 250 may be any network port or data exchange port to facilitate data communications. Computing device 200 may also include a processor (e.g., processor 220) in the form of one or more processors (e.g., logic circuits) for executing program instructions. For example, a processor may include interface circuitry and processing circuitry therein. Interface circuitry may be configured to receive electrical signals from bus 210, where the electrical signals encode structured data and/or instructions for the processing circuitry. The processing circuitry may perform logical computations and then determine the conclusion, result, and/or instruction encoding as electrical signals. The processing circuit may also generate an electronic signal including the conclusion or result and a trigger code. In some embodiments, the trigger code may be in a format recognizable by the operating system (or an application installed therein) of the electronic device (e.g., user terminal 130) in system 100. For example, the trigger code may be instructions, code, indicia, symbols, etc., or any combination thereof, that may activate certain functions and/or operations of the mobile phone or cause the mobile phone to execute a predetermined program. In some embodiments, the trigger code may be configured for an operating system (or application) of the electronic device to generate a presentation of a conclusion or result (e.g., a predicted result) on an interface of the electronic device. The interface circuitry may then send electrical signals from the processing circuitry over bus 210.

Exemplary computing devices may include an internal communication bus 210, program storage, and different forms of data storage, including for example a disk 270, and Read Only Memory (ROM)230 or Random Access Memory (RAM)240 for various data files processed and/or transmitted by the computing device. The exemplary computing device may also include program instructions stored in ROM 230, RAM240, and/or other forms of non-transitory storage that can be executed by processor 220. The methods and/or processes of the present application may be embodied in the form of program instructions. The exemplary computing device may also include an operating system stored in ROM 230, RAM240, and/or other types of non-transitory storage media that are executed by processor 220. The program instructions may be compatible with an operating system for providing online-to-offline services. Computing device 200 also includes I/O components 260 that support input/output between the computer and other components. Computing device 200 may also receive programming and data via network communications.

For illustration only, only one processor is shown in FIG. 2. Multiple processors are also contemplated; thus, operations and/or method steps performed by one processor described herein may also be performed by multiple processors, either jointly or separately. For example, if in the present application the processors of computing device 200 perform steps a and B, it should be understood that steps a and B may also be performed by two different processors of computing device 200, either collectively or independently (e.g., a first processor performing step a, a second processor performing step B, or a first and second processor performing steps a and B collectively).

Fig. 3 is a schematic diagram of exemplary hardware and/or software components of an exemplary mobile device 300 on which user terminal 130 may be implemented according to some embodiments of the present application.

As shown in FIG. 3, mobile device 300 may include a communication platform 310, a display 320, a Graphics Processing Unit (GPU)330, a Central Processing Unit (CPU)340, I/O350, memory 360, and storage 390. The CPU may include interface circuitry and processing circuitry similar to processor 220. 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 mobile device 300. In some embodiments, the operating system 370 is mobile (e.g., iOS)^TM、Android^TM、Windows Phone^TMEtc.) and one or more application programs 380 may be loaded from memory 390 into memory 360 for execution by CPU 340. The application 380 may include a browser or any other suitable mobile application for receiving and presenting information related to a path planning service. User interaction with the information flow may be enabled via the I/O device 350 and provided to the processing engine 112 and/or other components of the system 100 via the network 120.

To implement the various modules, units, and functions thereof described herein, a computer hardware platform may be used as one or more hardware platforms for the elements described herein (e.g., system 100 and/or other components). Refer to FIG. 1-

10) A portion of the system 100 is depicted. The hardware elements, operating systems, and programming languages of such computers are conventional in nature and given sufficient familiarity to those of ordinary skill in the art to adapt these techniques for use in determining the optimal path of a path planning request as described herein. A computer containing user interface elements can be used with a Personal Computer (PC)) or other type of workstation or terminal device, suitably programmed, and also used as a server. It will be appreciated that those skilled in the art will be familiar with the structure, programming and general operation of such computer devices and, therefore, the drawings should not be self-explanatory.

One of ordinary skill in the art will appreciate that when an element of system 100 executes, the element may execute via electrical and/or electromagnetic signals. For example, when the server 110 processes a task, such as determining an optimal path for a path planning request, the server 110 may operate logic in its processor to process such a task. When the server 110 completes determining the optimal path, the processor of the server 110 may generate an electrical signal encoding the optimal path. The processor of the server 110 may then send the electrical signal to at least one data exchange port of a target system associated with the server 110. The server 110 communicates with the target system via a wired network, and at least one data exchange port may be physically connected to a cable, which may also transmit electrical signals to a user's input port (e.g., an information exchange port). And a terminal 130. If the server 110 is in communication with a target system via a wireless network, at least one data exchange port of the target system may be one or more antennas, which may convert electrical signals to electromagnetic signals. Instructions and/or actions are carried out by electrical signals within an electronic device (e.g., user terminal 130) and/or server 110 when its processor processes the instructions, issues the instructions, and/or performs the actions. For example, when the processor retrieves or stores data from a storage medium (e.g., memory 140), it may send electrical signals to a read/write device of the storage medium, which may read or write structured data in the storage medium. The structured data may be transmitted in the form of electrical signals to the processor via a bus of the electronic device. Here, the electrical signal may be one electrical signal, a series of electrical signals, and/or at least two discrete electrical signals.

Fig. 4 is a block diagram of an exemplary processing engine 112 shown in accordance with some embodiments of the present application. As shown in fig. 4, the processing engine 112 may include a request acquisition module 410, a candidate path determination module 420, a weight determination module 430, an optimal path determination module 440, and a display module 450.

The request obtaining module 410 may be configured to obtain a path planning request from a user terminal. The path planning request may include information such as a departure time, a departure location, an end location, a travel pattern, a driving history of the user terminal, profile information of the user, and the like, or any combination thereof. The departure time may refer to a transit time that the user begins from the departure location to the destination location. This information may be obtained from one or more components of system 100 (e.g., memory 140, user terminal 130) or an external source that may be in communication with system 100.

The candidate path determination module 420 may be configured to determine at least two candidate paths for the path planning request. A candidate route may refer to a route having a departure location associated with a route planning request to an end location associated with the route planning request. The candidate path may include at least two segments, and each segment may represent a segment of the candidate path. In some embodiments, the at least two candidate routes may be historical routes from a departure location to an end location, being travel routes that one or more users of the system 100 have historically used. The historical route may be stored in any memory of the system 100 (e.g., memory 140). The candidate path determination module 420 may access a memory to obtain at least two candidate paths. In some embodiments, the at least two candidate paths may be routes from a departure location to an end location planned by the online electronic map. The candidate route determination module 420 may determine at least two candidate routes from the online electronic map.

The weight determination module 430 may be configured to determine the weight of the road segment. The weight of the road segment may indicate an actual expected transit time for the road segment. The actual predicted transit time of the link may refer to a corrected predicted transit time of the link determined based on the predicted transit time of the link by considering vehicle-link information of the link. The greater the weight of the road segment, the longer the actual expected transit time for the road segment may be. In some embodiments, the weight determination module 430 may determine the predicted transit time for the road segment and the vehicle information for the road segment to further determine the weight for the road segment. For example, the weight determination module 430 may determine the predicted transit time for the road segment based on the historical transit time for the road segment and the current transit time on the road segment. For another example, the weight determination module 430 may determine vehicle information for the road segment, such as a number of historical vehicles traveling on the road segment, a number of current vehicles on the road segment, and/or a projected number of vehicles projected onto the road segment. As yet another example, the weight determination module 430 may determine the weight of the road segment according to an algorithm or formula based on the predicted transit time and the vehicle information for the road segment. More details regarding determining segment weights may be found elsewhere in this application (e.g.,

operations

530 and 550 in FIG. 5, FIGS. 6-8, and descriptions thereof).

The optimal path determination module 440 may be configured to determine an optimal path for the path planning request. For example, the optimal path determination module 440 may select an optimal path from at least two candidate paths. In some embodiments, the optimal path determination module 440 may determine a path weight for each candidate path based on a weight for each segment of the at least two segments of each candidate path. The optimal path determination module 440 may determine the candidate path having the smallest path weight as the optimal path. More descriptions of determining the optimal path may be found elsewhere in this application (e.g., operation 560 in fig. 5, fig. 9, and descriptions thereof).

The display module 450 may be configured to instruct the user terminal to display the optimal path on a user interface of the user terminal in response to the path planning request. In some embodiments, the display module 450 may also instruct the user terminal to display one or more candidate paths on a user interface of the user terminal.

The modules in the processing engine 112 may be connected or in communication with each other via a wired connection or a wireless connection. The wired connection may include a metal cable, an optical cable, a hybrid cable, etc., or any combination thereof. The wireless connection may include a Local Area Network (LAN), a Wide Area Network (WAN), bluetooth, zigbee network, Near Field Communication (NFC), etc., or any combination thereof. Two or more modules may be combined into a single module, and any one of the modules may be divided into two or more units. For example, the weight determination module 420 may be divided into two or more units for determining the predicted transit time of the road segment, determining the vehicle-road segment information for the road segment, and determining the weight of the road segment, respectively. As another example, the processing engine 112 may include a storage module (not shown) for storing data and/or information related to road planning services.

Fig. 5 is a flow diagram illustrating an exemplary process 500 for path planning, according to some embodiments of the present application. Process 500 may be performed by system 100. For example, process 500 may be implemented as a set of instructions (e.g., an application program) stored in storage ROM 230 or RAM 240. Processor 220 may execute the set of instructions and, when executing the instructions, may be configured to perform process 500. The operation of the process shown below is for illustration purposes only. In some embodiments, process 500, when implemented, may add one or more additional operations not described, and/or subtract one or more operations described herein. Additionally, the order in which the process operations are illustrated in FIG. 5 and described below is not intended to be limiting.

In 510, the processing engine 112 (e.g., the processor 220, the request acquisition module 410) may acquire a path planning request including a departure time from the user terminal.

In some embodiments, the departure time may refer to a time at which a user of the user terminal starts traveling. The departure time may be a current time or a future time set by a user of the user terminal. For example, when the user intends to start traveling at the current time, the user may request path planning. The current time may refer to the current time at which the user sent the path planning request or a defined time in the field of ordinary people reasonably close to the current time (e.g., 1 minute, 2 minutes, or 5 minutes after the current time). For another example, when the user intends to start traveling at a future time, the user may request path planning. The future time may refer to a reasonably long time from the current time in the field of ordinary people (e.g., 30 minutes, 1 hour, 2 hours, or 1 day after the current time). In some embodiments, if the user does not set the departure time, the departure time may be a default setting of the system 100 (e.g., the current time interval).

As used herein, "obtaining a path planning request" may refer to "obtaining information related to the path planning request. The path planning request may relate to a particular trip that the user intends to start. In some embodiments, the path planning request may include a departure location and an end location associated with a particular trip. The departure location or the destination location may include name information and/or address information, which may be set by a user. For example, a user may select or enter a name and/or address of a departure location or an end location on a user interface of a user terminal (e.g., user terminal 130). In some embodiments, when the user sends a path planning request, the path planning request may include the current location of the user (i.e., the current location of the user terminal). If the user does not select or enter a departure location, the current location may be set as the departure location by default. In some embodiments, the path planning request may also include travel patterns (e.g., driving a car, getting on, riding a bicycle, or walking), driving history (e.g., historical travel times, number of historical trips of the user reflecting his/her driving habits, etc.), profile information of the user (e.g., gender, age, contact information, phone number, education level, address, occupation, marital status, criminal records, credit records, traffic violation records, etc.), or any combination thereof.

In some embodiments, information related to the path planning request may be obtained from one or more components of the system 100. By way of example only, information such as a departure time, a departure location, and an end location may be input by a user through a user terminal and transmitted to memory 140 and/or stored in memory 140. The processing engine 112 may retrieve information from the memory 140 or obtain information from a user terminal via the network 120. Additionally or alternatively, a portion of the information related to the path planning request may be obtained from an external source that may communicate with system 100 over network 120. For example, the profile information for the user may be obtained from one or more third party applications that share the user information with the system 100. For example, the processing engine 112 may retrieve the user's traffic violation record from a website or database of traffic violation records.

At 520, processing engine 112 (e.g., processor 220, candidate path determination module 420) may determine at least two candidate paths for the path planning request. In some embodiments, each candidate path may include at least two road segments.

In some embodiments, a candidate route may refer to a route having directions from a departure location to an end location of a route planning request. From the departure location to the destination location of the path planning request, there may be at least two candidate paths. In some embodiments, the at least two candidate routes may be historical routes from the departure location to the destination location, which are transit routes that one or more users of the system 100 have historically used. The historical route may be stored in any memory of the system 100 (e.g., memory 140). The processing engine 112 may access memory to retrieve at least two candidate paths. In some embodiments, the at least two candidate paths may be routes from a departure location to an end location planned by the online electronic map. The processing engine 112 may determine at least two candidate paths from the online electronic map.

In some embodiments, a road segment may be a road segment or a portion of a road having a particular direction. In some embodiments, the road segments may have a predetermined length. In some embodiments, the road segments may have different lengths. In some embodiments, the predetermined length may be a default value stored in a storage device of the system 100 (e.g., memory 140, ROM 230, RAM240, etc.), or determined by the system 100 or its operator depending on different application scenarios. Two adjacent segments in the candidate path may be connected by a common node. A common node may be an intersection comprising two adjacent road segments or may be a virtual point connecting two (or more) road segments.

At 530, for each of the at least two segments of each candidate route, the processing engine 112 (e.g., the processor 220, the weight determination module 430) may determine an expected transit time for the segment at a target time associated with the departure time.

In some embodiments, the predicted transit time for a road segment may refer to an estimated time that a vehicle associated with the user terminal will take to traverse the road segment. The target time related to the departure time may refer to a point in time at which the vehicle related to the user terminal may start traveling on the road segment. In some embodiments, at a first segment of the candidate route (which may also be referred to as a segment at the beginning of the candidate route), the target time may be a departure time of the route planning request. On another segment of the candidate path other than the first segment, the target time may be an estimated time point calculated from the departure time. Taking a candidate route including five links (represented as l1, l2, l3, l4, l5 in order from the departure position to the destination position) as an example, the target time of the link l1 may be the departure time of the route planning request. The target time for the link l2 may be determined based on the target time for the link l1 and the estimated time for the link l 1. When the departure time is 9:00 am and the estimated time of link l1 is 10 minutes, the target time for link l2 may be 9:10 am. The target times of the links l3, l4, and l5 may be determined similarly to the target time of the link l2, and are not repeated here. In some embodiments, the expected transit times for the road segment at different target times may be different. For example, the expected transit time for a road segment at 8:00 am on weekdays (e.g., any one of monday through friday) may be greater than the expected transit time for a road segment at 10:00 am on weekdays because 8:00 am on weekdays is an early peak. As another example, the expected transit time for a road segment at 11:00 am on a weekday may be lower than the expected transit time for a weekend (e.g., saturday or sunday) because more people may travel to the weekend than on weekdays.

In some embodiments, the processing engine 112 may determine the predicted transit time for the road segment at the target time based on the historical transit time for the road segment at the historical target time corresponding to the target time and the current transit time for the road segment at the current time. The historical transit times for the road segments at the historical target times may be determined by a statistical algorithm based on at least two historical transit times for the road segments at least two historical target times over a past time period (e.g., past week, past month). The current transit time on the road segment at the current time may be determined by a statistical algorithm, such as, but not limited to, an arithmetic mean algorithm, a weighted mean algorithm, a sampled statistical algorithm, etc., or any combination thereof, based on at least two transit times on the road segment associated with the current time. More descriptions of determining the expected transit time for a road segment at a target time may be found elsewhere in this application (e.g., fig. 7 and 8 and their descriptions).

At 540, for each of the at least two road segments of each candidate path, the processing engine 112 (e.g., the processor 220, the weight determination module 430) may obtain vehicle-road segment information related to the number of vehicles on the road segment.

In some embodiments, vehicle-road segment information may refer to information related to vehicle information related to road segments. For example, the vehicle-section information may be information related to the number of vehicles on the section. In some embodiments, the vehicle-to-road segment information related to the number of vehicles on the road segment may include information of historical vehicles on the road segment (e.g., the number of historical vehicles traveling on the road segment at a historical target time corresponding to the target time), information of current vehicles at the current time (e.g., the number of current vehicles traveling on the road segment at the current time), information of planned vehicles on the road segment (e.g., the number of vehicles planned onto the road segment within a preset historical time period), and the like, or any combination thereof. In some embodiments, at the historical target time, the number of historical vehicles traveling on the road segment may determine, by a statistical algorithm, the number of current vehicles on the road segment at the current time based on the number of at least two historical vehicles traveling on the road segment at least two historical target times over a past time period (e.g., past week, past month). The current number of vehicles on the road segment may be determined by a statistical algorithm, based on at least two numbers of vehicles on the road segment associated with the current time, such as, but not limited to, an arithmetic mean algorithm, a weighted mean algorithm, a sampled statistical algorithm, or the like, or any combination thereof. In some embodiments, the statistical algorithm used to determine the number of historic vehicles and the number of current vehicles may be the same or different. The number of planned vehicles planned to travel on the road segment within a preset historical time period may be obtained by a path planning system (e.g., system 100). In some embodiments, the vehicle-road segment information may be stored in a memory (e.g., memory 140, ROM 230, RAM240, etc.) of the system 100. The processing engine 112 may access the memory to obtain the vehicle-road segment information. More description of obtaining vehicle-road segment information may be found elsewhere in the present application (e.g., fig. 6 and its description).

In 550, for each of the at least two road segments of each candidate path, the processing engine 112 (e.g., the processor 220, the weight determination module 430) may determine a weight for the road segment based on the predicted transit time and the vehicle-road segment information.

In some embodiments, the weight of the road segment may indicate an actual expected transit time for the road segment. The actual predicted transit time for the road segment may refer to an estimated time that it will take the vehicle to pass through the road segment after considering the vehicle-road segment information. The greater the weight of the road segment, the longer the actual expected transit time for the road segment may be. In some embodiments, the weight of a segment may further indicate a probability that the segment will be part of an optimal path recommended to the user terminal in response to the path planning request. In some embodiments, the greater the weight of a road segment, the longer the actual expected transit time for the road segment may be, and the less likely the road segment is to be part of the optimal path. In some embodiments, the weight for a segment may further indicate a ratio of the candidate path including the segment to all of the at least two candidate paths, being substantially a percentage of the path including the segment. In some embodiments, the weight for a road segment reflects all factors such as, but not limited to, expected transit time, the likelihood that the road segment is part of an optimal path, and the percentage of candidate paths that include the road segment.

In some embodiments, the predicted transit time and vehicle-road segment information may be based on the following equation (1)

To determine the weight of the road segment:

wherein, w_iMeans the weight, count, of the ith road segment_hcThe number of historical vehicles, count, traveling on the ith road segment within the historical target time corresponding to the departure time_ccMeans the number of vehicles driving on the ith road segment in the current time, count_rpRefers to the number of planned vehicles planned to the ith road segment within a preset historical time period,

refers to the expected transit time for the ith road segment at the target time associated with the departure time, and alpha refers to a parameter (e.g., 0.3) that may be a default setting for system 100, or may be adjusted in different circumstances.

The number of historic vehicles (count) according to equation (1)_hc) The greater the weight (w) of the ith link_i) The smaller the probability that the ith road segment is part of the optimal path recommended to the user is. Current vehicle (count)_rp) Or the number of planned vehicles (count)_rp) The larger the i-th road section (w)_i) The greater the weight of (c), the less likely the ith road segment is to be part of the optimal path recommended to the user. In some embodiments, the weight may be a relative value greater than 1.

In some embodiments, at the beginning of the path plan, the processing engine 112 may determine an initial weight for each road segment. The initial weight may be a default setting for the system 100. The processing engine 112 may determine whether to update the initial weight of the road segment based on a predetermined threshold. If the difference between the initial weight of the road segment and the weight of the road segment is greater than a predetermined threshold, the processing engine 112 may update the initial weight of the road segment to the weight of the road segment determined according to the equation (1). Alternatively, if the difference between the initial weight of the road segment and the weight of the road segment is less than or equal to a predetermined threshold, the processing engine 112 may not update the initial weight of the road segment. In some embodiments, the predetermined threshold may be a preset value or may be adjustable, and may be stored in a memory of the system 100 (e.g., memory 140, ROM 230, RAM240, etc.) or dynamically determined based on different circumstances (e.g., congestion of a road segment).

At 560, the processing engine 112 (e.g., the processor 220, the optimal path determination module 440) may determine an optimal path for the path planning request from the at least two candidate paths based on the weight of each of the at least two segments of each candidate path.

In some embodiments, the optimal path may refer to the most suitable path that saves user time and/or effectively relieves congestion. The optimal path may be a candidate path having a smallest actual expected transit time compared to other candidate paths of the at least two candidate paths. In some embodiments, the actual expected transit time of the candidate route may be indicated in part by the route weight of the candidate route. The path weight of the candidate path may be determined based on the weight of each of at least two segments of the candidate path. For example, in some embodiments, the path weight of the candidate path may be the sum of the weights of all road segments included in the candidate path. In some embodiments, the path weight of a candidate path takes into account the weight of certain road segments shared by more than one candidate path. In some embodiments, the greater the weight, the longer the actual expected transit time of the respective candidate route. In some embodiments, the processing engine 112 may determine at least two path weights corresponding to the at least two candidate paths. Each path weight may correspond to a candidate path. The processing engine 112 may select the optimal path from at least two candidate paths, where the path weight of the optimal path is the smallest of the at least two path weights corresponding to the at least two candidate paths. More descriptions of determining the optimal path may be found elsewhere in this application (e.g., fig. 8 and 9 and their descriptions).

In some embodiments, the systems and methods of the present application may balance the overall transit time for a group of users with the transit time for an individual user. In some cases, when the time difference between multiple candidate paths for a user is very small, the optimal path may be to prevent congestion and ensure that the overall transit time is the shortest for the user group as a whole (e.g., 2, 5, 10, 50, 100 users, or more). For example, if after calculation, one user has two candidate routes, a and B, with transit times of 100 and 95 minutes respectively, it may be (but is not mandatory to select route a as the optimal route if selecting route a would result in a total transit time of 50 minutes for a group of 50 users. In some embodiments, the "sacrifice" of the user may be kept to a minimum, for example, according to a threshold (e.g., 5 minutes or 5% of the total travel time). In some embodiments, the user's "sacrifice" may be pre-approved by the user. For example, processing engine 112 may send a signal to a mobile device associated with the user instructing the mobile device to display a message summarizing the alternative. For example, the message may indicate that route a and route B have similar predicted transit times or that route a has a travel time slightly longer than route B, but selecting route a will result in less overall congestion, asking that it is acceptable to select route a. Path a may be selected as the optimal path upon user approval.

At 570, processing engine 112 (e.g., processor 220, display module 450) may instruct the user terminal to display the optimal path on a user interface of the user terminal in response to the path planning request.

In some embodiments, the user may begin the trip based on the optimal path, for example, by confirming the optimal path on the user interface. In some embodiments, the optimal path displayed on the user interface may include a departure location associated with the path planning request, an end location associated with the path planning request, an actual estimated time of the optimal path, a distance of the optimal path, or the like, or any combination thereof. In some embodiments, the processing engine 112 may update and display the optimal path on the user interface of the user terminal during the pass. For example, when the processing engine 112 determines that the currently displayed optimal path is no longer the optimal path, the processing engine 112 may determine and display another optimal path for the user.

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 modifications and changes may occur to those skilled in the art in light of the description herein. For example,

operation

530 and 550 may be integrated into one step. For another example, the weight of the link may be determined according to the predicted travel speed of the link and the vehicle-link information of the link, similar to the link information based on the link and the predicted transit time of the vehicle and the link described in operation 550. The predicted travel speed for the road segment may be determined based on the predicted transit time for the road segment and the length of the road segment. However, such modifications and changes do not depart from the scope of the present application.

Fig. 6 is a flow diagram illustrating an example process 600 for determining vehicle-road segment information according to some embodiments of the present application. Process 600 may be performed by system 100. For example, the process 600 may be implemented as a set of instructions (e.g., an application program) stored in the storage ROM 230 or RAM 240. The set of instructions may be executed by processor 220 and, when executed, may be configured to perform process 600. The operation of the process shown below is for illustration purposes only. In some embodiments, process 600, when implemented, may add one or more additional operations not described herein and/or delete one or more of the operations described herein. Additionally, the order in which the process operations are illustrated in FIG. 6 and described below is not intended to be limiting.

In 610, the processing engine 112 (e.g., the processor 220, the weight determination module 430) may determine a number of historical vehicles that traveled on the road segment at a historical target time corresponding to the departure time.

In some embodiments, the historical target time corresponding to the departure time may be the same historical time as the target time. For example, if the target time associated with the departure time is 9:10 a.m. today (working day), the historical target time corresponding to the departure time may be 9:10 a.m. on a particular historical date prior to today (e.g., yesterday, the same day of the last month, the same day of the last year, etc.), or at least two historical dates prior to today (e.g., at least two working days of the last month, at least two working days of the last year, at least two same dates in the last several months, etc.).

In some embodiments, historical vehicles may refer to vehicles that have traveled over a road segment over a past time period (e.g., past days, past weeks, past months, etc.). The number of the history vehicles traveling on the link at the history target time corresponding to the departure time may be an average number of the history vehicles traveling on the link at the same time as the target time in the history for a preset time period. In some embodiments, the average number of historical vehicles traveling on the road segment at the historical target time may be determined by a statistical algorithm (e.g., without limitation, an arithmetic mean algorithm, a weighted mean algorithm, a sampled statistical algorithm, or the like, or any combination thereof) based on the number of at least two historical vehicles traveling on the road segment at least two historical target times in the history over a preset time period (e.g., past week, past month).

In some embodiments, processing engine 112 may determine whether the departure time is on a weekday or on a weekend. In response to determining that the departure time is on a weekday, the processing engine 112 may obtain at least two historical target times for historical vehicles traveling on the road segment at least two historical quantities of historical vehicles on the past few weekdays (e.g., 30 weekdays other than the weekend before the weekday on which the departure time was located). For example, the number of historical vehicles traveling over the road segment at the historical target time may be determined according to equation (2):

wherein, count_hcRefers to the number of historical vehicles traveling on the road segment at the historical target time, M refers to the number of past work days, count_iRefers to the historical number of historical vehicles driving on the road segment at the historical target time of the ith working day, Σ_Mi refers to the history of the historical vehicles driving on the road segment at the historical target time of M working daysThe sum of the quantities.

In response to determining that the departure time is on a weekend, the processing engine 112 may obtain at least two historical quantities of historical vehicles traveling over the road segment at least two historical target times over the past few weekends (e.g., 30 weekends prior to the weekend on which the departure time was located). The processing engine 112 may determine the number of historic vehicles traveling over the road segment at the historic target time based on at least two historic numbers of historic vehicles traveling over the road segment at least two historic target times over the past weekends, similar to equation (2).

At 620, the processing engine 112 (e.g., the processor 220, the weight determination module 430) may determine a number of current vehicles traveling on the road segment at the current time.

In some embodiments, the current vehicle traveling on the road segment at the current time may refer to the vehicle traveling on the road segment at the current time. For example, the processing engine 112 may obtain the number of current vehicles traveling on the road segment in real time. For another example, the processing engine 112 may obtain the number of current vehicles traveling on the road segment for a predetermined period of time (e.g., 5 minutes, 10 minutes) around the current time. For example, if the current time is 8:30 am, the processing engine 112 may determine the number of vehicles traveling on the road segment from 8:20 PM to 8:30 PM and designate the determined number of vehicles as the number of current vehicles traveling on the road segment of 8:30 PM.

At 630, the processing engine 112 (e.g., the processor 220, the weight determination module 430) may determine a number of planned vehicles planned to the road segment within a preset historical time period.

In some embodiments, a planned vehicle planned onto the road segment may refer to a vehicle recommended by the path planning system (e.g., system 100) to the road segment. In some embodiments, when the route planning system plans a route for a user associated with a vehicle that includes the road segment, the vehicle may be the planned vehicle regardless of whether the route is confirmed by the user. For example, once the system 100 receives a path planning request from a user terminal, the system 100 may recommend at least one route to the user in response to the path planning request. If any of the recommended routes includes the road segment, the vehicle associated with the user terminal may be considered a planned vehicle planned onto the road segment.

In some embodiments, the preset historical time period may be a predetermined time period (e.g., half an hour, one hour, two hours) prior to the current time. In some embodiments, the number of planned vehicles planned to travel on the road segment over the preset historical time period may be retrieved from one or more components of the system 100 (e.g., the memory 140). Taking the predetermined time period of one hour and the current time of 8:00 am as an example, the preset historical time period may range from 7:00 am to 8:00 am. The planned vehicles planned to travel on the road segment may be stored in memory 140. The processing engine 112 may retrieve the projected number of vehicles projected to travel on the road segment from 7:00 am to 8:00 am directly from the memory 140 of the system 100. In some embodiments, the preset historical time period may be a preset period of time stored in the system 100, or may be dynamically determined based on different circumstances (e.g., different current times, different road segments, etc.).

At 640, the processing engine 112 (e.g., the processor 220, the weight determination module 430) may determine vehicle-road segment information related to the number of vehicles on the road segment based on the number of historical vehicles, the current number of vehicles, and the projected number of vehicles.

In some embodiments, the processing engine 112 may determine the weight for the road segment based on the vehicle-road segment information related to the number of vehicles on the road segment according to equation (1). Equation (1) can also be expressed as

This indicates that: the greater the number of historical vehicles traveling on the road segment, the smaller the weight of the road segment; the greater the number of current vehicles traveling on the road segment, the greater the weight of the road segment may be; the greater the number of planned vehicles planned onto the road segment, the greater the weight of the road segment. In some embodiments, a portion of equation (1) relates to the number of vehicles associated with a road segment, e.g.May be designated as vehicle-section information. The larger the vehicle-section information, the larger the weight of the section may be.

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. Many variations and modifications may be made to the teachings of the present application by those of ordinary skill in the art in light of the present disclosure. However, variations and modifications may be made without departing from the scope of the present application. In some embodiments, one or more other optional operations (e.g., storage operations) may be added elsewhere in the exemplary process 600.

Fig. 7 is a flow diagram illustrating an example process 700 for determining a projected transit time in accordance with some embodiments of the present application. Process 700 may be performed by system 100. For example, process 700 may be implemented as a set of instructions (e.g., an application program) stored in storage ROM 230 or RAM 240. The set of instructions may be executed by processor 220 and, when executed, may be configured to perform process 700. The operation of the process shown below is for illustration purposes only. In some embodiments, process 700 may be accomplished with one or more additional operations not described, and/or without one or more of the operations discussed. Additionally, the order in which the process operations are illustrated in FIG. 7 and described below is not intended to be limiting.

At 710, the processing engine 112 (e.g., the processor 220, the weight determination module 430) may obtain a historical transit time for the road segment at the historical target time corresponding to the target time.

In some embodiments, the historical transit time may be an average time taken by at least two historical vehicles to traverse the road segment at a historical target time, the historical target time being similar to a target time in a predetermined time period in the history. In some embodiments, the historical transit times may be determined based on at least two historical transit times for the road segment for at least two historical target times within a predetermined time period in the history (e.g., within the past week, within the past month, etc.) by a statistical algorithm, such as, but not limited to, an arithmetic mean algorithm, a weighted mean algorithm, a sampled statistical algorithm, or the like, or any combination thereof. For example, the target time is 9 am on monday, the processing engine 112 may retrieve the historical transit times for the road segments for each past work day of 9:00 over the historical 30 days directly from one or more components of the system 100 (e.g., the memory 140). The processing engine 112 may determine the average historical transit time of the acquired link historical transit times as a historical transit time of 9:00 am. More description of determining historical transit times may be found elsewhere in this application (e.g., fig. 8 and its description).

At 720, the processing engine 112 (e.g., the processor 220, the weight determination module 430) may obtain a current transit time on the road segment at the current time.

In some embodiments, the current transit time may be an average time the vehicle took to travel the road segment at the current time. The current transit time for the current time may be determined based on an average time of transit times within a preset time period prior to the current time. For example, if the current time is 8:30 am and the preset time period is 10 minutes, the processing engine 112 may obtain the transit time on the road segment from 8:20 am to 8:30 am. The processing engine 112 may determine the average of the obtained transit times as the current transit time of the current time. In some embodiments, the preset time period may be a default value stored in a memory (e.g., memory 140) of the system 100, or may be dynamically determined according to different circumstances.

In 730, the processing engine 112 (e.g., processor 220, weight determination module 430) may determine a time interval between the departure time and the current time.

In some embodiments, the time interval between the departure time and the current time may be measured in different dimensions (e.g., minutes or hours). For example, if the departure time is 8:30 am today and the current time is 8:00 am today, the time interval between the departure time and the current time may be 30 minutes or 0.5 hours. As another example, if the departure time is 23:00 on Monday, and the current time is 7:00, the time interval between the departure time and the current time may be 480 minutes or 8 hours.

In 740, the processing engine 112 (e.g., processor 220, weight determination module 430) can determine an expected transit time based on the historical transit time, the current transit time, and the time interval.

In some embodiments, the processing engine 112 may determine whether the time interval is less than a predetermined interval (e.g., 60 minutes, 2 hours). In some embodiments, the predetermined interval may be a default value stored in a memory (e.g., memory 140) of system 100, or may be dynamically determined from different circumstances. In response to determining that the time interval is less than the predetermined interval, the processing engine 112 may determine an expected transit time based on the historical transit time and the current transit time. In response to determining that the time interval is greater than or equal to the predetermined interval, the processing engine 112 may determine the expected transit time based only on the historical transit time. For example, the processing engine 112 may determine the expected transit time according to equation (4) below:

wherein the content of the first and second substances,

the predicted transit time of the ith link that refers to the target time in relation to the departure time,

a historical transit time of a historical target time corresponding to the target time,

the current transit time of the ith road segment referring to the current time, an Are referred to as being in 1 and

minimum value between, where t_fRefers to the time interval between the departure time and the current time, and alpha refers to the predetermined interval. t is t_fAnd alpha have the same measurement dimension (e.g., both in minutes or both in hours). For example, the preset interval (. alpha.) is 60 minutes if the time interval (t)_f) Greater than or equal to 60 minutes (e.g., 80 minutes), the processing engine 112 may determine θ to be 1 and the estimated transit time to be

Can pass based on history only

To determine an estimated transit time. As another example, if the time interval (t)_f) Less than 60 minutes (e.g., 30 minutes), the processing engine 112 may determine θ asAnd determining the estimated travel time as

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 modifications and changes may occur to those skilled in the art in light of the description herein. However, such modifications and changes do not depart from the scope of the present application. In some embodiments, one or more other optional operations (e.g., storage operations) may be added elsewhere in the exemplary process 700.

Fig. 8 is a flow diagram illustrating an exemplary process 800 for determining historical transit times according to some embodiments of the present application. Process 800 may be performed by system 100. For example, process 800 may be implemented as a set of instructions (e.g., an application program) stored in storage ROM 230 or RAM 240. The set of instructions may be executed by processor 220 and, when executed, may be configured to perform process 800. The operation of the process shown below is for illustration purposes only. In some embodiments, process 800, when implemented, may add one or more additional operations not described herein and/or delete one or more operations described herein. Additionally, the order in which the process operations are illustrated in FIG. 8 and described below is not intended to be limiting.

At 810, the processing engine 112 (e.g., processor 220, weight determination module 430) may determine that the departure time is on a weekday or weekend.

In some embodiments, the weekday may be the day that most people are working, and the weekend may be the day that most people are on vacation or on vacation. For example, a weekday may be a default setting for any day from monday through friday, and a weekend may be a default setting for saturday or sunday. For another example, a weekday may not include a day belonging to a legal holiday, and even this day from monday to friday may be set as a weekend.

At 820, in response to determining that the departure time is on a weekday, the processing engine 112 (e.g., the processor 220, the weight determination module 430) may determine the historical target time corresponding to the target time for the road segment for a first preset number of historical weekdays as an average historical transit time.

In some embodiments, the first preset number of historical weekdays may comprise a first preset number of consecutive weekdays prior to the weekday on which the departure time was located. For example, if the first preset number is 5 and the day on which the departure time is located is friday, the historical workdays may include four days of monday through thursday of the week and one day of friday of the last week. In some embodiments, the first preset number may be a default value stored in a memory (e.g., memory 140) of the system 100, or may be dynamically determined according to different circumstances.

In some embodiments, the processing engine 112 may retrieve the historical transit times for the historical target times in each historical weekday from one or more components of the system 100 (e.g., the memory 140). The processing engine 112 may determine an average historical transit time for the road segments at the historical target times for the first preset number of historical weekdays based on the historical transit times for the road segments at the historical target times for the historical weekdays. The processing engine 112 may designate as the historical transit time the average historical transit time of the historical target times for the first preset number of historical weekdays. For example, the processing engine 112 may determine the historical transit time for the road segment at the historical target time according to equation (3) below:

wherein the content of the first and second substances,the historical transit time of the ith link (i.e., the average historical transit time of the ith link) which is the historical target time, H is a first preset number of historical weekdays,

is the historical passing time, sigma of the historical working day_Ht refers to the sum of the historical transit times of the historical weekdays. For example, the processing engine 112 may obtain each historical transit time for the road segment at the historical target time on each weekday of monday through thursday and friday of the last week, and determine the average transit time for these weekdays according to equation (3).

At 830, in response to determining that the departure time is on a weekend, the processing engine 112 (e.g., the processor 220, the weight determination module 430) may determine an average historical transit time for the road segment corresponding to the historical target time for the target time for a second preset number of historical weekends as the historical transit time.

In some embodiments, the second preset number of historical weekends may include a consecutive second preset number of weekends before the weekend on which the departure time is located. For example, if the second preset number is 5 and the weekend on which the departure time is located is sunday of the week, the historical weekends may include saturday of the week, saturday of the last week, and two days of sunday. In some embodiments, the second preset number may be a default value stored in a memory (e.g., memory 140) of the system 100, or may be dynamically determined according to different circumstances.

In some embodiments, the processing engine 112 may retrieve the historical transit times for the historical target times for each historical weekend from one or more components of the system 100 (e.g., the memory 140). The processing engine 112 may determine an average historical transit time for the road segments at the historical target times for the second preset number of historical weekends based on the historical transit times for the road segments at the historical target times for the historical weekends. Similar to equation (3). The processing engine 112 may designate as the historical transit time the average historical transit time of the historical target times for the second preset number of historical weekends. For example, the processing engine 112 may obtain each historical transit time for the road segment at each weekend including saturday of the present week, saturday and sunday of the previous week, and determine the average transit time for these weekends according to equation (3).

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 modifications and changes may occur to those skilled in the art in light of the description herein. However, such modifications and changes do not depart from the scope of the present application. For example, one or more other optional operations (e.g., a store operation) may be added elsewhere in the example process 800.

Fig. 9 is a flow diagram illustrating an exemplary process 900 for determining an optimal path according to some embodiments of the present application. Process 900 may be performed by system 100. For example, the process 900 may be implemented as a set of instructions (e.g., an application program) stored in the storage ROM 230 or RAM 240. The set of instructions may be executed by processor 220 and, when executed, may be configured to perform process 900. The operation of the process shown below is for illustration purposes only. In some embodiments, process 900 may, when implemented, add one or more additional operations not described, and/or subtract one or more operations described herein. Additionally, the order in which the process operations are illustrated in FIG. 9 and described below is not intended to be limiting.

The process in 910-920 demonstrates one possible method of determining the optimal path. It should be noted, however, that other alternatives do exist and other factors may be considered in determining the optimal path. In 910, for each of the at least two candidate paths, the processing engine 112 (e.g., the processor 220, the optimal path determination module 440) may determine a weighted sum of at least two weights for at least two segments of the candidate path.

In some embodiments, the sum of the weights of the at least two weights for the at least two segments of the candidate route may be designated as the route weight for the candidate route. The path weight of the candidate path may indicate an actual expected transit time of the candidate path, which may further indicate a congestion degree of the candidate path. The greater the path weight of the candidate path, the longer the actual expected transit time of the candidate path may be, and the smaller the probability that the candidate path is determined to be the optimal path. Taking the candidate path including five links (weights represented by W1, W2, W3, W4, W5, respectively) as an example, the path weight of the candidate path may be the sum of W1, W2, W3, W4, and W5. In some embodiments, the path weights for the candidate paths may be determined according to other methods. For example, the path weight of the candidate path may be an average of W1, W2, W3, W4, and W5.

In 920, the processing engine 112 (e.g., the processor 220, the optimal path determination module 440) may determine an optimal path based on a sum of weights corresponding to at least two candidate paths.

In some embodiments, the processing engine 112 may determine at least two path weights corresponding to the at least two candidate paths based on the weights corresponding to the at least two candidate paths. The processing engine 112 may rank the at least two path weights according to a predetermined order (e.g., ascending, descending). For example, the greater the weight, the higher the ranking of the respective candidate path may be. Further, the processing engine 112 may select the candidate path having the minimum value of the path weight as the optimal path.

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 modifications and changes may occur to those skilled in the art in light of the description herein. However, such modifications and changes do not depart from the scope of the present application. In some embodiments, one or more other optional operations (e.g., storage operations) may be added elsewhere in the exemplary process 900.

Fig. 10 is a schematic diagram illustrating an exemplary candidate path according to some embodiments of the present application. As shown in fig. 10, each line segment with an arrow represents a road segment, and each circle represents a node (e.g., includes an intersection connected to at least one road segment). A plurality of segments along the direction of the arrow from the start position 1010 to the end position 1020 may form a path, which may be a candidate path.

In some embodiments, each road segment may include an initial weight. Each candidate route may include a weight based on at least two initial weights for at least two segments of the candidate route and a calculated initial route weight. For example, a candidate path (also referred to as a first candidate path) including the link L1, the link L5, the link L6, the link L7, and the link L8 having the smallest initial path weight among at least two candidate paths may be determined as the initial optimal path. The initial weight for each road segment may be updated according to the processes and/or methods described herein (e.g., fig. 5-9 and the description thereof). The path weight for each candidate path may be updated based on a weight sum of at least two updated weights for at least two segments of the candidate path. For example, the path weight of the first candidate path may be updated based on the weighted sum of the updated weights of w1, w5, w6, w7, and w 8. The path weight of another candidate path (also referred to as a second candidate path) including the link L1, the link L2, the link L3, the link L9, and the link L8 may be updated based on the weight sum of the updated weights of w1, w2, w3, w9, and w 8. The weight of the updated weight based on w1, w2, w3, w4, w6, w7, and w8 and the path weight of the candidate path (also referred to as a third candidate path) including the link L1, the link L2, the link L3, the link L4, the link L6, the link L7, and the link L8 may also be updated. The second candidate route (including the link L1, the link L2, the link L3, the link L9, and the link L8) having the smallest route weight value may be determined as the optimal route based on the updated route weight of the candidate route.

The embodiment in the application has at least one of the following technical effects: the method comprises the steps of determining road segment weights related to the transit time of road segments based on vehicle-road segment information related to the number of vehicles on the road segments at a certain historical time (including the number of vehicles traveling on the road segments at a certain historical time, the number of vehicles traveling on the road segments at the current time, and the number of vehicles planned to the road segments within a certain time period before the current time), and determining the path weights related to the transit time of each candidate path based on the weighted sum of all the weights corresponding to all the road segments contained in each candidate path. An optimal path is selected from the plurality of candidate paths based on the path weight of each candidate path. By the method, the travel time of the user can be effectively reduced, and traffic jam can be relieved simultaneously.

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. For example, "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 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 of ordinary skill in the art will understand 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, articles, or materials, or any new and useful modification thereof. 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 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 operation of aspects of the present application may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C + +, C #, VB.NET, Python, or similar conventional programming languages, such as the "C" programming language, Visualbasic, Fortran 1703, Perl, COBOL 1702, PHP, ABAP, dynamic programming languages 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 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 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 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.

All patents, patent applications, patent application publications, and other materials (e.g., articles, books, specifications, publications, records, things, and/or the like) mentioned herein are incorporated herein by reference in their entirety for all purposes except to the extent any document referred to above is deemed to be a document referred to, to be inconsistent or contrary to this document, or to the extent any document referred to in the claims that are not sooner or later referred to in this document. For example, descriptions, definitions, and/or use of terms in this document should take precedence if there is any inconsistency or conflict between the descriptions, definitions, and/or use of terms in relation to any incorporated material that is relevant to this document.

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. Thus, embodiments of the present application are not limited to the embodiments precisely as shown and described.

Claims

1. A path planning system, comprising:

a request acquisition module configured to acquire a path planning request including a departure time from a user terminal;

a candidate path determination module configured to determine at least two candidate paths for the path planning request, each candidate path comprising at least two segments;

a weight determination module configured to, for each of the at least two segments of each candidate path,

determining a predicted transit time for the road segment at a target time relative to the departure time;

obtaining vehicle-road segment information related to the number of vehicles on the road segment; and

determining a weight for the road segment based on the predicted transit time and the vehicle-road segment information; and

an optimal path determination module configured to determine an optimal path for the path planning request from the at least two candidate paths based on the weight of each of the at least two segments of each candidate path.

2. The system of claim 1, wherein to obtain the vehicle-segment information related to the number of vehicles on the segment, the weight determination module is further to:

determining a number of historical vehicles traveling on the road segment corresponding to a historical target time of the departure time;

determining a current number of vehicles traveling on the road segment at a current time;

determining a number of planned vehicles planned to the road segment within a preset historical time period; and

determining the vehicle-segment information related to the number of vehicles on the segment based on the number of historical vehicles, the number of current vehicles, and the number of planned vehicles.

3. The system according to claim 1 or 2, characterized in that, for determining the expected transit time, the at least weight determination module is further configured to:

acquiring historical passing time of the road section of historical target time corresponding to the target time;

acquiring the current passing time of the current time on the road section;

determining a time interval between the target time and the current time; and

determining the expected transit time based on the historical transit time, the current transit time, and the time interval.

4. The system of claim 3, wherein to obtain the historical transit time, the weight determination module is further configured to:

determining that the departure time is on a weekday or on a weekend; and

determining an average historical transit time of the road segments corresponding to the historical target time of the target time in a first preset number of historical workdays as the historical transit time in response to the departure time being on a workday.

5. The system of claim 3, wherein to obtain the historical transit time, the weight determination module is further configured to:

determining that the departure time is on a weekday or on a weekend; and

in response to determining that the departure time is on a weekend, determining an average historical transit time for the road segment corresponding to the historical target time at the target time in a second preset number of historical weekends as the historical transit time.

6. The system of claim 1, wherein to determine the optimal path from the at least one candidate path, the optimal path determination module is further configured to:

for each candidate route of the at least two candidate routes, determining a weighted sum of at least two weights for the at least two segments of the candidate route; and

determining the optimal path based on the weighted sum corresponding to the at least two candidate paths.

7. The system of claim 1, further comprising a display module configured to:

and instructing the user terminal to respond to the path planning request and display the optimal path on a user interface of the user terminal.

8. A method of path planning, the method comprising:

acquiring a path planning request including a departure time from a user terminal;

determining at least two candidate paths for the path planning request, each candidate path comprising at least two segments;

for each segment of the at least two segments of each candidate path,

determining a best path for the path planning request from the at least two candidate paths based on the weight for each of the at least two segments of each candidate path.

9. The method according to claim 8, wherein the acquiring the vehicle-section information on the number of vehicles on the section comprises:

determining a historical number of vehicles traveling on the road segment corresponding to a historical target time of the departure time;

10. The method of claim 8 or 9, wherein said determining said expected transit time comprises:

acquiring historical passing time of the road section of the historical target time corresponding to the target time;

acquiring the current passing time of the current time on the road section;

determining a time interval between the target time and the current time; and

11. The method of claim 10, wherein the obtaining the historical transit time comprises:

determining that the departure time is on a weekday or on a weekend; and

12. The method of claim 10, wherein the obtaining the historical transit time comprises:

determining that the departure time is on a weekday or on a weekend; and

13. The method according to any of claims 8 to 12, wherein said determining said optimal path from said at least one candidate path comprises:

for each candidate route of the at least two candidate routes, determining at least two weights for the at least two segments of the candidate route; and

determining the optimal path based on the weights and the at least two candidate paths.

14. The method of claim 8, further comprising:

15. A non-transitory readable medium comprising at least one set of computer instructions which, when executed by at least one processor, implement the method of any one of claims 8-14.

16. A path planning device is characterized by comprising

At least one storage medium comprising computer instructions; and

at least one processor in communication with the storage medium, wherein the at least one processor is configured to implement the method of any one of claims 8-14 when executing the computer instructions.