Route display method, device and system

Abstract

The present application relates to the technical field of navigation. Disclosed are a route display method, device and system, which can acquire a more refined road surface state, so as to provide a user with better route planning usage experience. In the present application, when a user has a route planning requirement, a terminal device acquires, from a server, a route and data of a potholed road surface related to the route, and displays information of the potholed road surface when displaying the route to the user, so as to inform the user of the condition of the potholed road surface in advance, and to provide the user with sufficient time to review the route condition, select a route, avoid the route, etc., thereby ensuring a good user experience.

Description

Route display methods, equipment and systems

[0001] This application claims priority to Chinese Patent Application No. 202510476096.7, filed on April 15, 2025, entitled "Route Display Method, Device and System", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of navigation technology, and in particular to route display methods, devices and systems. Background Technology

[0003] With the continuous development of intelligent driving technology, the use of vehicle motion planning based on road information is becoming increasingly widespread. For example, when a user searches for a destination using a map application, the application can display one or more recommended routes. To further enhance the user's perception of the specific details of the recommended routes, especially the differences between them, the map application can display road attributes such as highway / low-speed conditions, congestion, toll booth locations, traffic light locations, and travel time based on road properties.

[0004] In practical applications, with the increase in road construction age and carrying capacity, road surface subsidence and undulating sections increase. Furthermore, some river bridges have been covered, causing unevenness, bumps, and depressions, especially on older highways where potholes and uneven surfaces are more prevalent. When choosing from multiple recommended routes, users often want to know the road surface conditions of each route in advance, improving their understanding of the route they are about to navigate to and allowing them to choose the right route. Additionally, vehicles traversing uneven roads are prone to chassis damage, especially with the development of new energy vehicles, where battery maintenance costs are high. High-speed driving over potholes can easily cause chassis damage, leading to extremely high maintenance costs. Current map applications do not provide users with more detailed road surface conditions when recommending routes. Therefore, existing route planning technology needs further improvement to provide a better user experience. Summary of the Invention

[0005] This application provides a route display method, device, and system that can obtain more detailed road surface conditions and provide users with a better route planning experience.

[0006] To achieve the above objectives, this application adopts the following technical solution:

[0007] In a first aspect, a route display method is provided, the method comprising: a terminal device responding to a user operation by sending a request message to a server, wherein the request message is used to request route planning or navigation route planning from a starting point to a destination; the terminal device receiving a response message from the server, wherein the response message carries route data and route-related pothole road surface data; and the terminal device displaying the route and route-related pothole road surface information according to the response message.

[0008] The solution provided in the first aspect above allows the terminal device to request data on the route and related potholes from the server when the user has a route planning need. This data is then displayed when showing the route to the user, so that the user is aware of the pothole conditions in advance and has enough time to understand the route, choose a route, and avoid them, thus ensuring a good user experience.

[0009] As an example, the terminal device includes a portable device or an in-vehicle infotainment system. This allows the solution provided in this application to display routes in various route planning scenarios, including but not limited to route planning scenarios based on portable in-vehicle devices or route planning scenarios based on in-vehicle infotainment systems, thereby improving the flexibility and adaptability of the solution.

[0010] As an example, the route data carried in the response message includes at least one recommended driving route from the starting point to the destination, as well as information on potholes and uneven surfaces associated with each of the recommended routes. This allows for more comprehensive, detailed, and accurate information on potholes and uneven surfaces when displaying routes to users in a route planning scenario.

[0011] As an example, the route data carried in the response message includes navigation route data from the starting point to the destination, as well as data on potholes and uneven surfaces along the route. This allows for more comprehensive, detailed, and accurate information about potholes and uneven surfaces when displaying the route to the user in navigation route planning scenarios.

[0012] One possible implementation is to include the location of potholes in the data. This allows users to know the exact location of potholes in advance, enabling them to plan their routes, choose the best path, and avoid them, thus ensuring a better user experience.

[0013] As one possible implementation method, the data on potholes may also include one or more of the following: the percentage of potholes, the longitudinal height of potholes, the longitudinal depth of potholes, or the road surface material of potholes. This would allow users to access more comprehensive, detailed, and accurate information about potholes, further facilitating their understanding of route conditions, route selection, and avoidance strategies, thus ensuring a better user experience.

[0014] As one possible implementation, the aforementioned user operation is the first operation, which requests route planning from the starting point to the destination. In response to the user operation, the terminal device sends a request message to the server, including: the terminal device responding to the first operation by sending a route planning request to the server; wherein the response message carries data on at least one recommended route and data on potholes and uneven surfaces associated with each of the recommended routes. Thus, when a user has a route planning need, the terminal device can obtain recommended routes and related pothole and uneven surface data from the server, and display pothole and uneven surface information when showing the recommended routes to the user. This allows the user to see the road conditions, such as location, longitudinal elevation, longitudinal depth, and road surface material, when querying routes to their destination. This helps the user understand road conditions in advance, rationally choose recommended routes, and have a clearer expectation of the route, facilitating travel time planning and selection of appropriate transportation, thereby enhancing the user experience.

[0015] As one possible implementation, when the response message carries data for at least one recommended driving route and data on potholes and uneven surfaces associated with each of those routes, the terminal device displays the route and related pothole and uneven surface information based on the response message. This includes the terminal device displaying the at least one recommended driving route and related pothole and uneven surface information via controls and / or map layers. In this way, on the one hand, pothole and uneven surface information can be displayed when showing recommended driving routes to the user, providing a more comprehensive, detailed, and accurate picture of the road conditions. On the other hand, diverse and user-friendly display methods can improve the convenience and accuracy of users obtaining pothole and uneven surface information based on actual scenarios.

[0016] As one possible implementation, the aforementioned user operation is the second operation, which requests navigation route planning from the starting point to the destination. In response to the user operation, the terminal device sends a request message to the server, including: the terminal device responding to the second operation by sending a navigation route planning request to the server; wherein the response message carries navigation route data and data on potholes and uneven road surfaces related to the navigation route. Thus, when the terminal device has navigation needs, it can obtain navigation route and related pothole and uneven road surface data from the server, and display pothole and uneven road surface information when showing the navigation route to the user. This allows the user to be aware of the pothole and uneven road surface conditions in advance, such as location, longitudinal height, longitudinal depth, road surface material, etc., allowing them to slow down in advance and avoid sudden braking and high-speed driving over potholes that could cause bounce and chassis damage, ensuring safe passage over uneven road surfaces and enhancing the user experience.

[0017] As one possible implementation, when the response message carries navigation route data and related road surface pothole information, the terminal device displays the route and related pothole information on a map layer based on the response message. This includes the terminal device displaying the navigation route and related pothole information on a map layer. In this way, on the one hand, pothole information can be displayed along with the navigation route shown to the user, providing a more comprehensive, detailed, and accurate picture of the road surface; on the other hand, a user-friendly display format can be used to improve the convenience and accuracy of users obtaining pothole information based on the actual scenario.

[0018] As one possible implementation, the above method further includes: the terminal device navigating based on navigation route data; during navigation, the terminal device sending its position and data on potholes within a preset range ahead of it to the vehicle control system based on data related to potholes along the navigation route; wherein, the data on potholes within the preset range ahead of the terminal device is used by the vehicle control system to further determine the condition of the potholes, or for the vehicle control system to perform vehicle control while traversing potholes, including one or more of the following: adjusting the suspension and adjusting the vehicle speed. In this way, the vehicle control system can refer to the data on potholes to perform vehicle control, for example, by adjusting one or more of the suspension and vehicle speed in a timely manner based on the pre-acquired data on potholes, reducing the bumps felt when the vehicle traverses potholes, enhancing driving safety and comfort, avoiding excessive impact on vehicle components caused by potholes, and helping to maintain vehicle performance and extend vehicle lifespan.

[0019] As one possible implementation, before the terminal device sends a request message to the server, the method further includes: the terminal device collecting data through multiple sensors during movement, including one or more of the following: a barometric pressure sensor, a magnetic sensor, a gyroscope sensor, or an accelerometer; the terminal device extracting wave segments and deceleration segments based on the data collected by the multiple sensors; the terminal device sending the wave segments and deceleration segments to the server, where the wave segments and deceleration segments are used by the server for coarse and fine identification of potholes; or, the terminal device performing coarse identification of potholes based on the wave segments and deceleration segments, sending the coarse identification result to the server, where the coarse identification result is used by the server for fine identification of potholes. This approach reduces network bandwidth consumption between the terminal device and the server, improves transmission efficiency, ensures real-time data transmission, and guarantees the efficiency and accuracy of pothole identification; it also allows for flexible implementation of the solution based on actual conditions. For example, when the terminal device has strong processing power, its advantages can be fully utilized to save server computing resources; conversely, when the terminal device has weak processing power, the server's powerful computing resources and storage capabilities can be used to analyze and process dual-feature fragments of fluctuation and deceleration segments, reducing the computing and energy consumption pressure on the terminal device.

[0020] One possible implementation involves using multiple sensors, including a barometric pressure sensor, a magnetic sensor, a gyroscope sensor, and an accelerometer. The terminal device extracts wave and deceleration segments based on data collected from these sensors. This includes acquiring barometric pressure wave segments, geomagnetic wave segments, three-axis angular velocity wave segments, three-axis acceleration wave segments, and deceleration segments along the forward direction axis. By acquiring data characterizing motion fluctuations and velocity reduction, the accuracy of pothole identification can be improved.

[0021] As one possible implementation, the terminal device performs coarse identification of potholes based on wave segments and deceleration segments. This includes: the terminal device using a multi-sensor fusion algorithm or model based on machine learning to filter overlapping regions of features within the wave segments as candidate segments based on their location information; filtering the candidate segments based on deceleration segments; and performing one or more feature processing operations, such as principal component analysis, feature concatenation and serialization, and feature weighting, on the filtered candidate segments with deceleration features. Finally, the device trains the feature-processed segments using machine learning methods to obtain a set of pothole segments. In this way, pothole segments can be initially screened through coarse identification, avoiding the processing overhead of handling redundant data and improving the accuracy of subsequent fine identification of potholes.

[0022] As one possible implementation, the above-mentioned fine identification of potholes includes: identifying the pothole segments with the highest periodic overlap probability in the coarse identification results to obtain precise pothole segments. This can improve the accuracy of the pothole identification results.

[0023] For example, based on the coarse identification results, such as a set of pothole fragments, one or more methods such as data mining and fragment clustering can be used to identify and retain the pothole fragments with the highest periodic overlap probability, complete fragment distillation, and obtain more accurate pothole fragments, which are the pothole road surfaces.

[0024] Secondly, a route display method is provided, which includes: a server receiving a request message from a terminal device, the request message being used to request route planning or navigation route planning from the starting point to the destination; the server planning the route from the starting point to the destination and obtaining data on road surface potholes related to the route; and the server sending a response message to the terminal device, the response message carrying the route data and the data on road surface potholes related to the route.

[0025] The solution provided in the second aspect above allows the server to provide route data from the starting point to the destination to the terminal device based on the terminal device's request message when the terminal device has route planning needs. This data may include at least one recommended driving route or navigation route. The server also provides data on road surface potholes related to the route, so that the terminal device can display the pothole information when showing the route to the user. This allows the user to know about the pothole conditions in advance and gives them enough time to understand the route, choose a route, and avoid obstacles, thus ensuring a good user experience.

[0026] As an example, the route data carried in the response message includes at least one recommended driving route from the starting point to the destination, as well as information on potholes and uneven surfaces associated with each of the recommended routes. This allows for more comprehensive, detailed, and accurate information on potholes and uneven surfaces when displaying routes to users in a route planning scenario.

[0027] As an example, the route data carried in the response message includes navigation route data from the starting point to the destination, as well as data on potholes and uneven surfaces along the route. This allows for more comprehensive, detailed, and accurate information about potholes and uneven surfaces when displaying the route to the user in navigation route planning scenarios.

[0028] One possible implementation is to include the location of potholes in the data. This allows users to know the exact location of potholes in advance, enabling them to plan their routes, choose the best path, and avoid them, thus ensuring a better user experience.

[0029] As one possible implementation method, the data on potholes may also include one or more of the following: the percentage of potholes, the longitudinal height of potholes, the longitudinal depth of potholes, or the road surface material of potholes. This would allow users to access more comprehensive, detailed, and accurate information about potholes, further facilitating their understanding of route conditions, route selection, and avoidance strategies, thus ensuring a better user experience.

[0030] One possible implementation is a route planning request. The server plans a route from the starting point to the destination and obtains data on potholes and uneven road surfaces related to the route. This includes: the server planning at least one recommended route from the starting point to the destination and obtaining data on potholes and uneven road surfaces related to each of the at least one recommended route; the response message carries data on at least one recommended route and data on potholes and uneven road surfaces related to each of the at least one recommended route. Thus, when a terminal device needs route planning, the server can provide the terminal device with recommended routes and related pothole and uneven road surface data. This allows the terminal device to display pothole and uneven road surface information when showing recommended routes to the user. This provides users with information on road conditions, such as location, elevation, depth, and road surface material, when searching for routes to their destination. This helps users understand road conditions in advance, choose recommended routes reasonably, and have a clearer expectation of the route, facilitating travel time planning and selection of appropriate transportation, thereby enhancing the user experience.

[0031] One possible implementation is a navigation route planning request. The server plans the route from the starting point to the destination and obtains data on road surface irregularities related to the route. This includes the server planning the navigation route from the starting point to the destination and obtaining data on road surface irregularities related to the navigation route. The response message carries both the navigation route data and the data on road surface irregularities related to the navigation route. Thus, when a terminal device has a navigation need, the server can provide the terminal device with the navigation route and related road surface irregularity data. This allows the terminal device to display road surface information when showing the navigation route to the user, enabling the user to know the condition of the road surface irregularities in advance, such as its location, longitudinal height, longitudinal depth, road surface material, etc., allowing them to slow down in advance and avoid sudden braking or high-speed driving over uneven surfaces that could cause bouncing and chassis damage, ensuring safe passage over uneven surfaces and enhancing the user experience.

[0032] As one possible implementation, before receiving the request message, the method further includes: the server receiving wave fragments and deceleration fragments from the terminal device and at least one other device; the server performing coarse and fine identification of potholes based on the wave fragments and deceleration fragments to obtain pothole data; and the server storing the pothole data. This approach reduces network bandwidth consumption between the terminal device and the server, improves transmission efficiency, and ensures real-time data transmission, while maintaining the efficiency and accuracy of pothole identification. Furthermore, it leverages the server's powerful computing resources and storage capabilities to analyze and process the dual-feature fragments of wave fragments and deceleration fragments, reducing the computational and energy consumption burden on the terminal device.

[0033] As one possible implementation, the server performs coarse identification of potholes based on wave segments and deceleration segments. This includes: the server using a multi-sensor fusion algorithm or model based on machine learning to filter overlapping regions of features within wave segments as candidate segments based on their location information; filtering the candidate segments based on deceleration segments; and performing one or more feature processing operations, such as principal component analysis, feature concatenation and serialization, and feature weighting, on the filtered candidate segments with deceleration features. Finally, the server trains the feature-processed segments using machine learning methods to obtain a set of pothole segments. In this way, pothole segments can be initially screened through coarse identification, avoiding the processing overhead of handling redundant data and improving the accuracy of subsequent fine identification of potholes.

[0034] As one possible implementation, the server performs fine-grained identification of potholes, including: identifying the pothole segments with the highest periodic overlap probability in the coarse identification results to obtain precise pothole fragments. This improves the accuracy of the pothole identification results.

[0035] For example, the server can use one or more methods such as data mining and fragment clustering to identify and retain the pothole fragments with the highest periodic overlap probability based on the coarse identification results, such as a set of pothole fragments, to complete fragment distillation and obtain more accurate pothole fragments, which are the pothole road surfaces.

[0036] As one possible implementation, obtaining route-related road surface data includes retrieving route-related road surface data from stored data. This allows the terminal device to receive pre-acquired road surface data when it requires route planning. This improves the speed of responding to terminal device requests and provides users with advance information about road conditions.

[0037] Thirdly, a method for identifying potholes is provided. This method includes: a terminal device collecting data via multiple sensors during movement, wherein the sensors include one or more of the following: a barometric pressure sensor, a magnetic sensor, a gyroscope sensor, or an accelerometer; the terminal device extracting wave segments and deceleration segments based on the data collected by the multiple sensors; the terminal device sending the wave segments and deceleration segments to a server, where the wave segments and deceleration segments are used by the server for coarse and fine identification of potholes; or, the terminal device performing coarse identification of potholes based on the wave segments and deceleration segments, sending the coarse identification result to the server, where the coarse identification result is used by the server for fine identification of potholes.

[0038] The solution provided in the third aspect above involves the terminal device collecting crowdsourced trajectory data through multiple sensors, analyzing the crowdsourced trajectory data to obtain the fluctuation segments and deceleration segments of the terminal device, and then sending them to the server. The server obtains data such as the location of potholes by fusing the fluctuation segments and deceleration segments. On the one hand, this can reduce the network bandwidth consumption between the terminal device and the server, improve transmission efficiency, and ensure the real-time transmission of data, while ensuring the efficiency and accuracy of pothole identification. On the other hand, it can flexibly implement the solution according to the actual situation.

[0039] One possible implementation involves using multiple sensors, including a barometric pressure sensor, a magnetic sensor, a gyroscope sensor, and an accelerometer. The terminal device extracts wave and deceleration segments based on data collected from these sensors. This includes acquiring barometric pressure wave segments, geomagnetic wave segments, three-axis angular velocity wave segments, three-axis acceleration wave segments, and deceleration segments along the forward direction axis. By acquiring data characterizing motion fluctuations and velocity reduction, the accuracy of pothole identification can be improved.

[0040] As one possible implementation, the aforementioned terminal device performs coarse identification of potholes based on wave segments and deceleration segments. This includes: the terminal device, based on a multi-sensor fusion algorithm or model using machine learning, filters overlapping regions within the wave segments as candidate segments based on their location information; filters the candidate segments based on deceleration segments; and performs one or more feature processing operations, such as principal component analysis, feature concatenation and serialization, and feature weighting, on the filtered candidate segments with deceleration characteristics. Finally, it trains the feature-processed segments using machine learning methods to obtain a set of pothole segments. In this way, pothole segments can be initially screened through coarse identification, avoiding the processing overhead of handling redundant data and improving the accuracy of subsequent fine identification of potholes.

[0041] As one possible implementation, the above-mentioned fine identification of potholes includes: identifying the pothole segments with the highest periodic overlap probability in the coarse identification results to obtain precise pothole segments. This can improve the accuracy of the pothole identification results.

[0042] For example, based on the coarse identification results, such as a set of pothole fragments, one or more methods such as data mining and fragment clustering can be used to identify and retain the pothole fragments with the highest periodic overlap probability, complete fragment distillation, and obtain more accurate pothole fragments, which are the pothole road surfaces.

[0043] Fourthly, a method for identifying potholes is provided, comprising: a server receiving wave fragments and deceleration fragments from a terminal device and at least one other device; the server performing coarse and fine identification of potholes based on the wave fragments and deceleration fragments to obtain data on potholes; and the server storing the data on potholes.

[0044] The solution provided in the fourth aspect above allows the server to acquire data such as the location of potholes by fusing fluctuation segments and deceleration segments. On the one hand, this reduces network bandwidth consumption between the terminal device and the server, improves transmission efficiency, and ensures the real-time nature of data transmission, while also ensuring the efficiency and accuracy of pothole identification. On the other hand, it can utilize the server's powerful computing resources and storage capabilities to analyze and process the dual-feature segments of fluctuation and deceleration segments, reducing the computing and energy consumption pressure on the terminal device.

[0045] As one possible implementation, the server performs coarse identification of potholes based on wave segments and deceleration segments. This includes: the server using a multi-sensor fusion algorithm or model based on machine learning to filter overlapping regions of features within wave segments as candidate segments based on their location information; filtering the candidate segments based on deceleration segments; and performing one or more feature processing operations, such as principal component analysis, feature concatenation and serialization, and feature weighting, on the filtered candidate segments with deceleration features. Finally, the server trains the feature-processed segments using machine learning methods to obtain a set of pothole segments. In this way, pothole segments can be initially screened through coarse identification, avoiding the processing overhead of handling redundant data and improving the accuracy of subsequent fine identification of potholes.

[0046] As one possible implementation, the server performs fine-grained identification of potholes, including: identifying the pothole segments with the highest periodic overlap probability in the coarse identification results to obtain precise pothole fragments. This improves the accuracy of the pothole identification results.

[0047] For example, the server can use one or more methods such as data mining and fragment clustering to identify and retain the pothole fragments with the highest periodic overlap probability based on the coarse identification results, such as a set of pothole fragments, to complete fragment distillation and obtain more accurate pothole fragments, which are the pothole road surfaces.

[0048] Fifthly, a terminal device is provided, comprising: a communication component for transmitting data with other devices (such as a server); a memory for storing computer program instructions; and a processor for executing the computer program instructions to support the terminal device in implementing the methods of any possible implementation of the first or third aspect.

[0049] In a sixth aspect, a server is provided, comprising: a communication component for transmitting data with other devices (such as terminal devices); a memory for storing computer program instructions; and a processor for executing the computer program instructions to support the server in implementing the methods of any possible implementation of the second or fourth aspect.

[0050] In a seventh aspect, an application system is provided, the system comprising at least one terminal device and a server, wherein the at least one terminal device is configured to implement the method as in any possible implementation of the first aspect, and the server is configured to implement the method as in any possible implementation of the second aspect; or, the at least one terminal device is configured to implement the method as in any possible implementation of the third aspect, and the server is configured to implement the method as in any possible implementation of the fourth aspect.

[0051] Eighthly, a computer-readable storage medium is provided that stores computer program instructions thereon, which, when executed by a processor, implement the methods of any possible implementation of the first, second, third, or fourth aspect.

[0052] Ninth aspect, a computer program product containing instructions is provided, which, when run on a computer, causes the computer to implement the method as in any possible implementation of the first, second, third, or fourth aspect.

[0053] A tenth aspect provides a chip system including processing circuitry and a storage medium storing computer program instructions; when executed by the processor, the computer program instructions implement a method as described in any of the possible implementations of the first, second, third, or fourth aspects. The chip system may be composed of chips or may include chips and other discrete devices. Attached Figure Description

[0054] Figure 1 shows an example interface that includes recommended driving routes;

[0055] Figure 2 shows a flowchart of a method for recognizing potholes on road surfaces based on visual images;

[0056] Figure 3 shows a flowchart of a method for identifying potholes on the road surface based on an accelerometer and a gyroscope sensor;

[0057] Figure 4 is a schematic diagram of a system architecture provided in an embodiment of this application;

[0058] Figure 5A is a schematic diagram of a pothole road surface recognition process based on crowdsourced trajectory data provided in an embodiment of this application;

[0059] Figure 5B is a schematic diagram of another pothole road surface recognition process based on crowdsourced trajectory data provided in an embodiment of this application;

[0060] Figure 6 is a schematic diagram of a process for extracting fluctuation fragments and deceleration fragments based on crowdsourced trajectory data according to an embodiment of this application;

[0061] Figure 7A is a schematic diagram of the hardware structure of a terminal device provided in an embodiment of this application;

[0062] Figure 7B is a schematic diagram of the software structure of a terminal device provided in an embodiment of this application;

[0063] Figure 8A is an interactive diagram of a route display method provided in an embodiment of this application;

[0064] Figure 8B is an interactive diagram of another route display method provided in an embodiment of this application;

[0065] Figure 8C is an interactive diagram of another route display method provided in an embodiment of this application;

[0066] Figure 9 is an interactive diagram of the route display process in a driving route planning scenario provided by an embodiment of this application;

[0067] Figure 10 is a schematic diagram of a recommended driving route display interface provided in an embodiment of this application;

[0068] Figure 11 is an interactive diagram of the route display process in a navigation route planning scenario provided by an embodiment of this application;

[0069] Figure 12 is a schematic diagram of a navigation route display interface provided in an embodiment of this application;

[0070] Figure 13 is a schematic diagram of a vehicle control process based on data from pothole-prone road surfaces provided in an embodiment of this application;

[0071] Figure 14 is a schematic diagram of another vehicle control process based on data from potholes provided in an embodiment of this application;

[0072] Figure 15 is a block diagram of the virtual functional structure of a terminal device provided in an embodiment of this application;

[0073] Figure 16 is a block diagram of the virtual functional structure of a server provided in an embodiment of this application;

[0074] Figure 17 is a hardware structure block diagram of a terminal device or server provided in an embodiment of this application. Detailed Implementation

[0075] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; "and / or" in this text is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more than two.

[0076] In the following text, the terms "first," "second," etc., are used only to distinguish different descriptive objects and do not limit the position, order, priority, quantity, or content of the described objects. For example, if the described object is a "communication unit," then the ordinal number preceding "communication unit" in "first communication unit" and "second communication unit" does not limit the functional or structural differences between the "communication units." Similarly, if the described object is an "operation," then the ordinal number preceding "operation" in "first operation" and "second operation" does not limit the event relationship or type between the "operations." Likewise, if the described object is a "recommended driving route," then the ordinal number preceding "recommended driving route" in "first recommended driving route" and "second recommended driving route" does not limit the position, order, or priority between the "recommended driving routes."

[0077] Furthermore, in the embodiments of this application, "connection" can be a direct connection or an indirect connection; in addition, it can refer to an electrical connection or a communication connection, and a communication connection can refer to a wired connection or a wireless connection; for example, the connection of two electrical components A and B can refer to A and B being directly connected, or it can refer to A and B being indirectly connected through other electrical components or connection media, or it can refer to A and B being indirectly connected through other communication devices or communication media, as long as it enables communication between A and B.

[0078] To enhance users' understanding of the specifics of recommended routes, especially the differences between them, map applications can, as an example, display recommendation principles and / or route details based on road attributes. For instance, please refer to Figure 1, which shows an example interface including recommended routes. As shown in Figure 1, the map application can display multiple recommended routes, such as Route 1, Route 2, and Route 3, along with the driving distance, time taken, and recommendation principles such as "highway priority," "avoid congestion," "lower toll fees," "main road priority," "time priority," and "fewer traffic lights." Figure 1 uses "highway priority," "avoid congestion," and "lower toll fees" as examples.

[0079] However, the interface shown in Figure 1 does not provide users with information about road surface conditions such as potholes, so the user experience of route planning needs to be improved.

[0080] To obtain information about road surface conditions, current methods mostly rely on visual images or sensors to identify potholes.

[0081] As one possible implementation, please refer to Figure 2, which shows a flowchart of a method for identifying potholes in road surfaces based on visual images. As shown in Figure 2, the method for identifying potholes in road surfaces based on visual images may include steps S201-S204:

[0082] S201. During vehicle operation, the end-side camera collects images of the road ahead.

[0083] S202, The location of potholes on the end side is determined based on the image.

[0084] S203. The terminal sends the image containing the potholes and their locations to the cloud server.

[0085] S204. The cloud-based server marks potholes on the map based on images containing potholes and the location of the potholes.

[0086] While the solution shown in Figure 2 can identify potholes, it relies on visual sensors such as onboard cameras, resulting in high on-device costs and inapplicability to vehicles without cameras. Furthermore, the cloud-side server in this solution needs to connect to vehicle information from different manufacturers and install processing modules, leading to high cloud-side costs and low versatility. Additionally, the solution in Figure 2 relies solely on real-time image data for pothole perception, resulting in low accuracy and limited time for users to react, such as slowing down or avoiding potholes, thus compromising user experience.

[0087] As another possible implementation, please refer to Figure 3, which shows a flowchart of a method for identifying potholes on a road surface based on an accelerometer and a gyroscope. As shown in Figure 3, the method for identifying potholes on a road surface based on an accelerometer and a gyroscope may include steps S301-S307:

[0088] S301: The end side acquires data through an accelerometer and a gyroscope sensor, and uses the data acquired by the gyroscope sensor to correct the data acquired by the accelerometer sensor.

[0089] This step can improve the accuracy of the data collected by the accelerometer.

[0090] S302, the end side predicts the triaxial acceleration at the next moment based on the data collected by the corrected accelerometer.

[0091] S303, the end side performs weighted processing on the triaxial acceleration.

[0092] S304, the vehicle's position and speed are measured by GPS at the end.

[0093] S305: The end-side determines the weighted triaxial acceleration based on the set threshold, and identifies potholes in the road surface by combining the vehicle's position and speed.

[0094] S306, The terminal sends the location of potholes to the cloud server.

[0095] S307, the cloud-based server marks potholes on the map based on their location.

[0096] While the scheme shown in Figure 3 can identify potholes, it is susceptible to misidentification due to changes in vehicle posture caused by actual road conditions. For example, sudden changes in road conditions can alter vehicle posture, and even with acceleration-weighted calculations and thresholding to determine potholes, the impact of these posture changes on the identification results is difficult to avoid, leading to insufficient accuracy. Furthermore, the scheme in Figure 3 relies solely on real-time acceleration data to perceive potholes, resulting in low accuracy and limited time for user preparation, such as slowing down or avoiding them, thus compromising user experience.

[0097] To provide users with a better route planning experience, this application provides a route display method. This method enables various types of end-side devices (hereinafter referred to as "terminal devices") to display road surface conditions to users based on data (such as location data) obtained from a cloud-side server when users have route planning needs. Route planning may include, but is not limited to, driving route planning and navigation route planning.

[0098] As an example, based on the route display method provided in this application embodiment, when a terminal device has a need for route planning, it can obtain data on recommended driving routes and related road surface data from a cloud server. When displaying the recommended driving route to the user, the information on road surface is displayed so that when the user queries the driving route to the destination, the device can provide the user with a more comprehensive, detailed, and accurate information on the road surface conditions. This helps the user to understand the road conditions in advance, rationally choose the recommended driving route, and have a clearer expectation of the driving route, which facilitates the planning of travel time and the selection of appropriate means of transportation, thereby enhancing the user experience.

[0099] As an example, a route display method is provided based on an embodiment of this application. When a terminal device has a navigation need, it can obtain navigation route data and related data on potholes from a cloud server. When displaying the navigation route to the user, the information on potholes is displayed so that the user can know the condition of the potholes in advance, slow down in advance, avoid sudden braking and high-speed driving through potholes causing bounce and chassis collisions, safely pass through uneven roads, and enhance the user experience.

[0100] To obtain more detailed road surface conditions, this application also provides a method for identifying potholes. This method includes: a terminal device collecting crowdsourced trajectory data through multiple sensors; analyzing the crowdsourced trajectory data to obtain fluctuation segments and deceleration segments of the terminal device, and then sending these to a cloud-based server. The fluctuation segments reflect changes in the terminal device's motion fluctuations, and the deceleration segments reflect changes in the terminal device's speed reduction. The cloud-based server then fuses the fluctuation and deceleration segments to obtain data such as the location of the potholes. In some embodiments of this application, after determining the data on the potholes, the cloud-based server can save the pothole data as a road attribute. This data can then be sent to the terminal device when responding to route planning or navigation route planning requests from the terminal device, if the route involves the pothole, allowing the user to fully understand the road's pothole condition.

[0101] In this context, the crowdsourced trajectory refers to trajectory-related data generated by participating crowdsourcing devices (including the terminal devices described in this application embodiment) during their movement. As one possible implementation, participating terminal devices can collect data during movement using at least two sensors, such as barometers, magnetometers, gyroscopes, and accelerometers. For example, they can collect barometric pressure data using a barometer, geomagnetic data using a magnetometer, triaxial angular velocity data using a gyroscope, and triaxial acceleration data using an accelerometer. As an example, the terminal device can collect data at multiple crowdsourcing collection points along its trajectory at regular time intervals using multiple sensors, forming a sequence of crowdsourcing collection points, which constitutes the crowdsourced trajectory data.

[0102] As one possible approach, when acquiring data on potholes by fusing wave segments and deceleration segments on a cloud-based server, a coarse identification of the potholes can be performed first using machine learning methods. Then, based on the results of the coarse identification, data distillation can be carried out to achieve accurate identification of potholes.

[0103] In some embodiments of this application, in order to improve the accuracy and reliability of the pothole road recognition results of the cloud-side server, numerous terminal devices can participate in the collection of crowdsourced trajectory data. For example, there may be multiple terminal devices sending crowdsourced trajectory data of the same road segment to the cloud-side server. The cloud-side server can integrate the sensor data collected by multiple terminal devices to perform pothole road recognition, which greatly improves the accuracy and reliability of the pothole road recognition results.

[0104] In some embodiments of this application, the route display method and pothole road surface recognition method provided in this application can be applied to an edge-cloud interaction architecture, and are completed collaboratively by the terminal device and the cloud-side server (hereinafter referred to as "server") . For example, the method can be applied to the architecture shown in Figure 4, which includes a terminal device 410 and a server 420.

[0105] As shown in Figure 4, the terminal device 410 may include a crowdsourced trajectory acquisition module 410-1, a crowdsourced trajectory processing module 410-2, a first communication module 410-3, and a human-computer interaction module 410-4. As an example, the terminal device 410 may have an application with navigation guidance function installed, such as, but not limited to, a map application (the following embodiment uses a map application as an example). The crowdsourced trajectory acquisition module 410-1 and the crowdsourced trajectory processing module 410-2 may be provided by the map application.

[0106] The crowdsourcing trajectory acquisition module 410-1 is used to collect crowdsourcing trajectory data. For example, during the movement of the terminal device 410, the crowdsourcing trajectory acquisition module 410-1 can collect data using at least two sensors, such as a barometric pressure sensor, a magnetic sensor, a gyroscope sensor, and an accelerometer. For instance, it can collect barometric pressure data using a barometric pressure sensor, geomagnetic data using a magnetic sensor, triaxial angular velocity data using a gyroscope sensor, and triaxial acceleration data using an accelerometer sensor.

[0107] In some embodiments of this application, the crowdsourcing trajectory acquisition module 410-1 can collect data at multiple crowdsourcing acquisition points on the crowdsourcing trajectory of the terminal device through multiple sensors at certain time intervals to form a crowdsourcing acquisition point sequence, which is the crowdsourcing trajectory data.

[0108] The crowdsourced trajectory processing module 410-2 is used to analyze the crowdsourced trajectory data to obtain the fluctuation segments and deceleration segments of the terminal device 410.

[0109] In some embodiments of this application, the crowdsourced trajectory processing module 410-2 can first preprocess the crowdsourced trajectory data, and then analyze the processed data to obtain the fluctuation segments and deceleration segments of the terminal device 410. The preprocessing includes, but is not limited to, data "cleaning" to remove one or more of the following: erroneous data, interference data, and outliers. By performing preprocessing before obtaining the fluctuation segments and deceleration segments, interference data can be effectively reduced, and more valuable information can be extracted and processed in a targeted manner. On the one hand, this improves the referenceability of the obtained fluctuation segments and deceleration segments and enhances the accuracy of subsequent pothole road surface identification results. On the other hand, it saves the computing power of the terminal device.

[0110] The first communication module 410-3 is responsible for communication between the terminal device 410 and other devices or apparatuses (such as the server 420 shown in FIG4). In some embodiments of this application, the first communication module 410-3 can support the terminal device 410 to send the fluctuation fragments and deceleration fragments obtained by the crowdsourced trajectory processing module 410-2 to the server 420.

[0111] The human-computer interaction module 410-4 is used to receive user operations and display corresponding content based on the user's operations. For example, the human-computer interaction module 410-4 may include one or more of a touchscreen, microphone, and camera. The touchscreen may also have a display function, enabling the terminal device 410 to display content.

[0112] In some embodiments of this application, the human-computer interaction module 410-4 can receive the driving route planning operation triggered by the user in the map application, send the driving route planning request to the server 420 through the first communication module 410-3, receive the data of the recommended driving route and the data of the potholes and uneven road surfaces related to the recommended driving route from the server 420 through the first communication module 410-3, and display the recommended driving route and the information of the potholes and uneven road surfaces related to the recommended driving route to the user through the human-computer interaction module 410-4, such as a display screen.

[0113] In some embodiments of this application, the human-computer interaction module 410-4 can receive navigation route planning operations triggered by the user in the map application, send a navigation route planning request to the server 420 through the first communication module 410-3, receive navigation route data and related pothole road surface data from the server 420 through the first communication module 410-3, and display the navigation route to the user through the human-computer interaction module 410-4, such as a display screen, and display pothole road surface information at the locations of pothole road surfaces on the navigation route.

[0114] Figure 4 shows a terminal device 410 participating in crowdsourcing. In some embodiments of this application, there may be multiple terminal devices participating in crowdsourcing. Other terminal devices participating in crowdsourcing may have a similar structure to the terminal device 410 shown in Figure 4. During the movement, data is collected through at least two types of sensors to obtain crowdsourcing trajectory data including the sequence of crowdsourcing collection points. The crowdsourcing trajectory data is analyzed to obtain their respective fluctuation segments and deceleration segments. The respective fluctuation segments and deceleration segments are sent to the server 420, which integrates the sensor data collected by multiple terminal devices to identify potholes, greatly improving the accuracy and reliability of pothole identification results.

[0115] In some embodiments, other terminal devices participating in the crowdsourcing can also send a route planning request to the server 420 based on the route planning operation triggered by the user, receive data on the recommended route and data on potholes and uneven surfaces related to the recommended route from the server 420, and display the recommended route and related pothole and uneven surface information to the user.

[0116] In some embodiments, other terminal devices participating in the crowdsourcing can also send a navigation route planning request to the server 420 based on the navigation route planning operation triggered by the user, receive navigation route data and related pothole data from the server 420, display the navigation route to the user, and show pothole information at the locations of potholes along the navigation route. For details regarding the specific processes of other terminal devices participating in pothole identification and route display, please refer to the relevant description of terminal device 410; it will not be repeated here.

[0117] As shown in Figure 4, the server 420 may include a second communication module 420-1, a fluctuation segment processing module 420-2, a road attribute library 420-3, a route planning module 420-4, and a road database 420-5.

[0118] The second communication module 420-1 is responsible for communication between the server 420 and other devices or apparatuses (such as the terminal device 410 shown in FIG. 4). In some embodiments of this application, the second communication module 420-1 is used to receive wave fragments and deceleration fragments sent by the terminal device 410 through the first communication module 410-3.

[0119] The wave segment processing module 420-2 is used to fuse wave segments and deceleration segments to acquire data on potholes in the road surface.

[0120] As an example, the fluctuation segment processing module 420-2 is used to first perform coarse identification of potholes on the road surface using machine learning methods, as shown in Figure 5A. The multi-sensor fusion algorithm based on machine learning performs coarse identification of potholes on the road surface. Then, based on the results of the coarse identification, data distillation is performed, as shown in Figure 5A. The potholes on the road surface are then finely identified based on the distillation of overlapping segments of periodic crowdsourced trajectories, and finally, the potholes on the road surface are accurately identified.

[0121] The Road Attribute Library 420-3 is used to manage and maintain road attributes.

[0122] In this embodiment, after the fluctuation segment processing module 420-2 obtains data such as the location of potholes, it can store the pothole data as a road attribute in the road attribute database 420-3. This allows the server 420 to send the relevant pothole data to the terminal device 410 when responding to a route planning request or navigation route planning request from the terminal device 410. For example, the pothole data includes the location of the potholes; optionally, the pothole data may also include, but is not limited to, one or more of the following: the proportion of potholes, the longitudinal height of potholes, the longitudinal depth of potholes, or the road surface material of potholes.

[0123] Optionally, road attributes may also include one or more other road attributes such as road slope data, which is not limited in the embodiments of this application.

[0124] In some embodiments of this application, the second communication module 420-1 is used to receive a driving route planning request sent by the terminal device 410 through the first communication module 410-3, send the request content of the driving route planning request to the route planning module 420-4, and send the data of the recommended driving route planned by the route planning module 420-4 and the related data of potholes and uneven road surfaces to the terminal device 410.

[0125] In some embodiments of this application, the second communication module 420-1 is used to receive a navigation route planning request sent by the terminal device 410 through the first communication module 410-3, send the request content of the navigation route planning request to the route planning module 420-4, and send the data of the navigation route planned by the route planning module 420-4 and the related data of potholes and uneven road surfaces to the terminal device 410.

[0126] Road database 420-5 is used to maintain road topology data. For example, road topology data represents the location of each road, lane information, positional relationships between roads, positional relationships between roads and surrounding entities, and the location of traffic lights on the road; road attributes may include, but are not limited to, road slope data. For example, surrounding entities may include, but are not limited to, hospitals, supermarkets, schools, shopping malls, office buildings, hotels, restaurants, parks, museums, etc., without specific limitations.

[0127] The route planning module 420-4 is used to define routes based on the route planning request from the terminal device 410.

[0128] In some embodiments of this application, the route planning module 420-4 is used to plan a recommended driving route from the starting point to the destination according to the driving route planning request of the terminal device 410. For example, the route planning module 420-4 can search for the location of the starting point and the destination in the road topology data maintained by the road database 420-5, block point of interest (POI) information that is more than a threshold away from the driving route, map the location of the unblocked POI information to the topology map corresponding to the road topology data, establish the route between the location of the unblocked POI information and the driving route, and form a recommended driving route with a fishbone structure. The route planning module 420-4 is also used to obtain data on potholes and uneven road surfaces related to the planned recommended driving route from the road attribute library 420-3.

[0129] In some embodiments of this application, the route planning module 420-4 is used to plan a navigation route from the starting point to the destination according to the navigation route planning request of the terminal device 410. For example, the route planning module 420-4 can plan a navigation route from the starting point to the destination according to the recommended driving route selected by the user, and obtain data on potholes and uneven road surfaces related to the navigation route from the road attribute library 420-3.

[0130] Figure 4 illustrates a possible edge-cloud interaction architecture for implementing a route display method. The structure shown in Figure 4 does not constitute a specific limitation on the terminal device or server. In other embodiments of this application, the terminal device or server may include more or fewer modules than illustrated, or combine some modules, or split some modules, or have different module arrangements. The illustrated components can be implemented in hardware, software, or a combination of both. For example, in some cases, the functions provided by the road database 420-5 shown in Figure 4 and the functions provided by the road attribute database 420-3 may be integrated into a single database, with the related functions provided by this single database.

[0131] As an example, please refer to Figure 5A, which illustrates a process for identifying potholes based on crowdsourced trajectory data according to an embodiment of this application. As shown in Figure 5A, the process for identifying potholes based on crowdsourced trajectory data includes steps S501-S505:

[0132] S501: The terminal device collects data through multiple sensors during movement.

[0133] As an example, as shown in Figure 6, the terminal device can collect crowdsourced trajectory data at multiple crowdsourced collection points along the crowdsourced trajectory during the movement process using multiple sensors.

[0134] Taking multiple sensors, including barometric pressure sensors, magnetic sensors, gyroscope sensors, and accelerometers, as an example, as shown in Figure 6, crowdsourced trajectory data can be data collected by barometric pressure sensors (such as barometric pressure data), magnetic sensors (such as geomagnetic data), gyroscope sensors (such as triaxial angular velocity data), accelerometers (such as triaxial acceleration data), and the location information (such as latitude and longitude) corresponding to each data point.

[0135] S502, The terminal device extracts wave fragments and deceleration fragments based on data collected by multiple sensors.

[0136] The wave segment reflects the motion fluctuations of the terminal device at multiple crowdsourced collection points during its movement; the deceleration segment reflects the decrease in speed of the terminal device at multiple crowdsourced collection points during its movement. For example, the wave segment includes the location information of multiple crowdsourced collection points and data representing motion fluctuations corresponding to each collection point; the deceleration segment includes the location information of multiple crowdsourced collection points and data representing speed decreases corresponding to each collection point. For example, the location information of the crowdsourced collection points includes their latitude and longitude.

[0137] Taking multiple sensors, including a barometric pressure sensor, a magnetic sensor, a gyroscope sensor, and an accelerometer, as an example, as shown in Figure 6, the terminal device can extract fluctuation segments based on the data collected by the barometric pressure sensor, the magnetic sensor, the gyroscope sensor, and the accelerometer, and extract deceleration segments based on the data collected by the accelerometer. For example, the terminal device can extract barometric pressure fluctuation segments based on the data collected by the barometric pressure sensor; extract geomagnetic fluctuation segments based on the data collected by the magnetic sensor; extract three-axis angular velocity fluctuation segments based on the data collected by the gyroscope sensor; extract three-axis acceleration fluctuation segments based on the data collected by the accelerometer; further extract fluctuation segments based on the extracted barometric pressure fluctuation segments, geomagnetic fluctuation segments, three-axis angular velocity fluctuation segments, and three-axis acceleration fluctuation segments as fluctuation segments to be reported to the server; and extract deceleration segments along the forward direction axis based on the data collected by the accelerometer as deceleration segments to be reported to the server.

[0138] As one possible implementation, the terminal device can extract the aforementioned fluctuation segments and deceleration segments based on the data collected by each sensor through processes such as activity threshold determination, trajectory feature variance recognition, and high-frequency feature recognition.

[0139] In some embodiments, before extracting the wave fragment and deceleration fragment as shown in FIG6, the terminal device may preprocess the data collected by multiple sensors, and then extract the wave fragment and deceleration fragment based on the preprocessed data.

[0140] As an example, preprocessing may include data "cleaning," which removes one or more of the following: erroneous data, interfering data, and outliers. For instance, data "cleaning" can filter out deceleration segments caused by normal traffic rules (such as stopping at red lights or yielding at intersections). Exemplarily, data "cleaning" methods may include, but are not limited to, median filtering, Kalman filtering, or one or more other methods. By performing preprocessing before acquiring fluctuation and deceleration segments, interference data can be effectively reduced, and more valuable information can be extracted for targeted processing. This improves the reliability of the acquired fluctuation and deceleration segments, enhancing the accuracy of subsequent pothole identification results, while also saving computing power on the terminal equipment.

[0141] As an example, preprocessing might include normalization. Normalization is used to unify data from different sensors, which have different dimensions and value ranges, to the same scale. For example, acceleration data and displacement data collected by an accelerometer are normalized to the [0,1] interval. This facilitates subsequent analysis and comparison.

[0142] As an example, preprocessing may include feature selection, such as using feature selection algorithms to select the most representative and influential data for pothole identification, and removing redundant data to improve the efficiency of subsequent data processing and the accuracy of pothole identification results.

[0143] Figure 6 uses multiple sensors, including a barometric pressure sensor, a magnetic sensor, a gyroscope sensor, and an accelerometer, as an example. In practical applications, multiple sensors may include more or fewer sensors than the example shown in Figure 6. For example, in addition to barometric pressure sensors, magnetic sensors, gyroscope sensors, and accelerometers, multiple sensors may include other types of sensors; or multiple sensors may include a gyroscope sensor and an accelerometer, or a barometric pressure sensor, a gyroscope sensor, and an accelerometer, or a barometric pressure sensor, a magnetic sensor, and an accelerometer, or a magnetic sensor, a gyroscope sensor, and an accelerometer, etc. The embodiments of this application are not limited to these examples.

[0144] S503, the terminal device sends the fluctuation segment and deceleration segment to the server.

[0145] S504. The server identifies potholes in the road surface based on wave segments and deceleration segments.

[0146] As one possible approach, the server can first use machine learning methods to coarsely identify potholes on the road surface, and then perform data distillation based on the results of the coarse identification to ultimately achieve accurate identification of potholes on the road surface.

[0147] As an example, as shown in Figure 5A, the server can first perform coarse identification of potholes based on a multi-sensor fusion algorithm using machine learning, and then perform fine identification of potholes based on distillation of overlapping segments of periodic crowdsourced trajectories, ultimately achieving accurate identification of potholes.

[0148] As one possible implementation, the server performs coarse identification of potholes on the road surface, including: using a multi-sensor fusion algorithm or model based on machine learning; selecting overlapping regions of features in the pothole segments as candidate segments based on the location information (such as latitude and longitude) corresponding to the pothole segments; filtering the candidate segments based on the deceleration segments; performing one or more feature processing operations such as principal component analysis (PCA), feature splicing and serialization, and feature weighting on the filtered candidate segments with deceleration features; and training the feature-processed segments based on machine learning methods to obtain a set of pothole segments.

[0149] As an example, a multi-sensor fusion algorithm or model can be trained and learned based on a large amount of sample data of known potholes and normal roads. The multi-sensor fusion algorithm or model can use wave segments and deceleration segments as input to determine whether each segment corresponds to a pothole.

[0150] In some embodiments, the parameters of the multi-sensor fusion algorithm or model can be continuously optimized based on the data of the identified potholes in the road surface, so as to continuously improve the recognition accuracy of the algorithm or model.

[0151] As one possible implementation, the server performs fine-grained identification of potholes, which includes: identifying the pothole segments with the highest periodic overlap probability in the coarse identification results to obtain precise pothole fragments. For example, based on the coarse identification results, such as a set of pothole fragments, the server can use one or more methods, such as data mining and fragment clustering, to identify and retain the pothole segments with the highest periodic overlap probability, performing fragment distillation to obtain more precise pothole fragments, i.e., the pothole road surface. Fragment clustering is used to discover similar trajectory patterns to identify pothole segments with a high periodic overlap probability. These clustered pothole fragments contain key information about changes in vehicle driving status, such as abnormal acceleration changes and changes in vehicle posture caused by bumps when traversing potholes. These overlapping fragments containing rich road surface state information are extracted using specific algorithms, preparing for subsequent analysis.

[0152] For example, periodicity can include, but is not limited to, daily or weekly periods.

[0153] S505, the server stores data on potholes in the road attribute database.

[0154] The road attribute library is used to manage and maintain road attributes, which include data on potholes and uneven surfaces.

[0155] Optionally, road attributes may also include data on one or more other road attributes, such as road slope data, which is not limited in this embodiment.

[0156] Figure 5A shows a terminal device participating in crowdsourcing. In some embodiments of this application, there may be multiple terminal devices participating in crowdsourcing. Other terminal devices participating in crowdsourcing may have a structure similar to the terminal device 410 shown in Figure 4. During the movement, data is collected through at least two types of sensors to obtain crowdsourcing trajectory data including the sequence of crowdsourcing collection points. The crowdsourcing trajectory data is analyzed to obtain their respective fluctuation segments and deceleration segments. The respective fluctuation segments and deceleration segments are sent to the server for the server to integrate the sensor data collected by multiple terminal devices to identify potholes on the road surface.

[0157] In some embodiments, the coarse identification of potholes may also be the responsibility of the terminal device. As an example, please refer to Figure 5B, which illustrates another pothole identification process based on crowdsourced trajectory data provided in this application embodiment. S501-S502 in the pothole identification process shown in Figure 5B are the same as S501-S502 in the pothole identification process shown in Figure 5A, and will not be repeated here; the difference between the pothole identification process shown in Figure 5B and the pothole identification process shown in Figure 5A is that after extracting the fluctuation fragment and deceleration fragment, the terminal device executes S503' followed by S504':

[0158] S503': The terminal equipment uses a multi-sensor fusion algorithm based on machine learning to coarsely identify potholes on the road surface.

[0159] S504' The terminal device sends the coarse recognition result to the server.

[0160] As shown in Figure 5B, after receiving the coarse recognition result from the terminal device, the server executes the following steps S505' and S506':

[0161] S505' server performs precise identification of potholes on road surfaces based on distillation of overlapping segments of periodic crowdsourced trajectories.

[0162] S506' The server stores data on potholes in the road attribute database.

[0163] For an introduction to S503'-S506' shown in Figure 5B, please refer to the explanation of S503-S505 above, which will not be repeated here.

[0164] As shown in Figure 5A or Figure 5B, the pothole identification process based on crowdsourced trajectory data allows multiple participating terminal devices to capture road conditions from different dimensions using multiple sensors. This provides more comprehensive and accurate basic data for subsequent analysis. The server can integrate the road conditions collected by multiple terminal devices, initially screening out pothole segments through coarse identification, and further improving the identification accuracy through fine identification using periodic big data and data mining. This accurately identifies potholes, greatly improving the accuracy and reliability of the pothole identification results. Furthermore, the server's storage of pothole data after identification and its advance transmission to terminal devices allow users sufficient time to understand the route, choose a route, and avoid obstacles, ensuring a good user experience.

[0165] Furthermore, the pothole road recognition process based on crowdsourced trajectory data, as shown in Figure 5A, involves the terminal device processing and extracting segments of the crowdsourced trajectory data, while the server performs pothole road recognition, including coarse and fine recognition. On the one hand, this reduces network bandwidth consumption between the terminal device and the server, improves transmission efficiency, and ensures real-time data transmission. On the other hand, it utilizes the server's powerful computing resources and storage capabilities to analyze and process dual-feature segments of undulating and decelerating segments, reducing the computational and energy consumption pressure on the terminal device and improving the efficiency and accuracy of pothole road recognition.

[0166] Furthermore, the pothole road identification process based on crowdsourced trajectory data shown in Figure 5B involves the terminal device processing and extracting fragments of the crowdsourced trajectory data, as well as performing coarse identification of pothole roads, while the server performs fine identification of pothole roads. Compared with the scheme shown in Figure 5A, this approach can fully utilize the advantages of the terminal device with stronger processing capabilities, save server computing resources, further reduce network bandwidth consumption between the terminal device and the server, improve transmission efficiency, ensure real-time data transmission, and simultaneously guarantee the efficiency and accuracy of pothole road identification.

[0167] In the embodiments of this application, the more refined road surface conditions can be applied to a variety of scenarios and achieve good application results in each scenario.

[0168] For example, in route planning scenarios such as driving route planning and navigation route planning, more refined road surface conditions can allow users to know the condition of potholes (such as location, longitudinal height, longitudinal depth, road surface material, etc., one or more of which), which helps users understand road conditions in advance, rationally choose recommended driving routes, conveniently plan travel time, choose appropriate means of transportation, slow down in advance, etc., thus enhancing the user experience.

[0169] For example, in traffic management scenarios, more refined road surface condition data allows transportation departments to obtain real-time information on urban road conditions, promptly identify potholes, and schedule road maintenance. Long-term analysis of road surface conditions also reveals patterns in road damage across different areas, enabling more rational planning of road maintenance budgets and engineering projects, improving the management of urban transportation infrastructure, and ensuring safe and smooth travel for citizens.

[0170] For example, in intelligent transportation scenarios, more refined road surface conditions can provide a reference for traffic signal control. For instance, when potholes are detected ahead of a vehicle, the traffic light timing can be adjusted appropriately to allow the vehicle sufficient time to pass smoothly.

[0171] For example, in autonomous driving scenarios, more refined road surface conditions can help autonomous vehicles perceive road conditions in advance, adjust driving strategies, avoid driving safety issues caused by potholes, and promote the development and application of autonomous driving technology.

[0172] Compared to the scheme shown in Figure 2, the pothole recognition process shown in Figures 5A and 5B does not require additional visual sensors such as cameras. It can quickly, reliably, and accurately identify potholes based on the existing low-cost multi-sensor technology of the terminal device, using the concept of big data. It is low-cost and highly universal, supports the advance transmission of pothole data to the terminal device, and supports viewing pothole information offline, online, before navigation, and during navigation, meeting the needs for understanding road pothole conditions in various scenarios. Compared to the scheme shown in Figure 3, the pothole recognition process shown in Figures 5A and 5B can integrate data collected by multiple sensors. Through processes such as extracting wave segments and deceleration segments, and performing coarse and fine recognition of potholes in segments, it can solve the problem of misidentification caused by the influence of vehicle posture due to actual road conditions, improve the accuracy of pothole recognition results, and support the advance transmission of pothole data to the terminal device. It supports viewing pothole information offline, online, before navigation, and during navigation, meeting the needs for understanding road pothole conditions in various scenarios.

[0173] As an example, the terminal device described in this application embodiment may include, but is not limited to, any electronic device with sensor components. For example, the terminal device may be an in-vehicle infotainment system in a vehicle, or a smartphone, netbook, tablet computer, smart drawing tablet, handwriting tablet, smartwatch, smart bracelet, phone watch, smart glasses, smart camera, PDA, in-vehicle computer, personal computer (PC), personal digital assistant (PDA), portable multimedia player (PMP), augmented reality (AR) / virtual reality (VR) device, or motion-sensing game console in a human-computer interaction scenario. Alternatively, the terminal device may also be other types or structures of electronic devices, which are not limited in this application.

[0174] As an example, the means of transportation described in the embodiments of this application may include, but are not limited to, vehicles, aircraft, etc.

[0175] For example, vehicles may include, but are not limited to, one or more types of vehicles such as personal vehicles, industrial vehicles, and engineering vehicles; personal vehicles may include, but are not limited to, one or more of the following: cars, buses, trams, subways, high-speed trains, motorcycles, flying cars, or trains; industrial vehicles may include, but are not limited to, one or more of the following: trucks, forklifts, trailers, or tractors; engineering vehicles may include, but are not limited to, one or more of the following: excavators, bulldozers, concrete mixers, or cranes; the embodiments of this application do not limit the specific type, form, and function of the means of transportation. Aircraft may include, but are not limited to, civil aircraft, helicopters, drones, transport aircraft, airships, and space shuttles.

[0176] For example, please refer to Figure 7A, which shows a schematic diagram of the hardware structure of a terminal device provided in an embodiment of this application.

[0177] As shown in Figure 7A, the terminal device includes a processor 710, a memory (including an external memory interface 720 and an internal memory 721), a universal serial bus (USB) interface 730, a charging management module 740, a power management module 741, a battery 742, antenna 1, antenna 2, a mobile communication module 750, a wireless communication module 760, an audio module 770, a speaker 770A, a receiver 770B, a microphone 770C, a headphone jack 770D, a sensor module 780, buttons 790, a motor 791, indicator lights 792, a camera 793, a display screen 794, etc.

[0178] The processor 710 includes one or more processing units. For example, the processor 710 may include an application processor (AP), a microcontroller unit (MCU), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors. For example, the application processor may include a graphics processor and a digital signal processor, and the microcontroller unit may include a graphics processor.

[0179] The controller can generate operation control signals based on the instruction opcode and timing signals to complete the control of instruction fetching and execution.

[0180] The processor 710 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 710 is a cache memory. This memory can store instructions or data that the processor 710 has just used or that are used repeatedly. If the processor 710 needs to use the instruction or data again, it can directly retrieve it from the memory. This avoids repeated accesses, reduces the waiting time of the processor 710, and thus improves the efficiency of the system.

[0181] In some embodiments of this application, the processor 710 can obtain, through preprocessing and other analysis processes, wave segments that reflect changes in the motion of the terminal device and deceleration segments that reflect changes in the speed of the terminal device, based on crowdsourced trajectory data collected by at least two sensors such as barometric pressure sensor 780A, magnetic sensor 780B, gyroscope sensor 780C, and accelerometer sensor 780D during the movement of the terminal device, so that the server can accurately identify potholes on the road surface based on the wave segments and deceleration segments.

[0182] The wireless communication function of the terminal device can be realized through antenna 1, antenna 2, mobile communication module 750, wireless communication module 760, modem processor and baseband processor.

[0183] Antennas 1 and 2 are used to transmit and receive electromagnetic wave signals. The wireless communication module 760 can provide solutions for wireless communication applications on terminal devices, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), and intrabody communication (IBC). The wireless communication module 760 can be one or more devices integrating at least one communication processing module. The wireless communication module 760 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 710. The wireless communication module 760 can also receive signals to be transmitted from processor 710, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0184] In some embodiments of this application, antenna 1 of the terminal device is coupled to mobile communication module 750, and antenna 2 is coupled to wireless communication module 760, enabling the terminal device to communicate with networks and other devices via wireless communication technology. The wireless communication technology may include Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Time-Division Code Division Multiple Access (TD-SCDMA), Long Term Evolution (LTE), BT, GNSS, WLAN, NFC, FM, IR technology, and / or IBC technology, etc. The GNSS may include the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), the BeiDou Navigation Satellite System (BDS), the Quasi-Zenith Satellite System (QZSS), and / or satellite-based augmentation systems (SBAS).

[0185] In some embodiments of this application, the terminal device can realize communication functions through antenna 1, antenna 2, mobile communication module 750, wireless communication module 760, etc.

[0186] In some embodiments of this application, the terminal device can send wave fragments and deceleration fragments to the server through antenna 1, antenna 2, mobile communication module 750, wireless communication module 760, etc.

[0187] In some embodiments of this application, the terminal device can send a driving route planning request to the server through antenna 1, antenna 2, mobile communication module 750, wireless communication module 760, etc., and receive data of the recommended driving route planned by the server and data of potholes and uneven road surfaces related to the recommended driving route.

[0188] In some embodiments of this application, the terminal device can send a navigation route planning request to the server through antenna 1, antenna 2, mobile communication module 750, wireless communication module 760, etc., and receive data of the navigation route planned by the server and data of potholes and uneven road surfaces related to the navigation route.

[0189] Display 794 includes a display panel. Exemplary displays may employ low-temperature poly-silicon (LTPS) displays, low-temperature polycrystalline oxide (LTPO) displays, liquid crystal displays (LCDs), organic light-emitting diodes (OLEDs), active-matrix organic light-emitting diodes (AMOLEDs), flexible light-emitting diodes (FLEDs), Miniled, MicroLEDs, Micro-OLEDs, quantum dot light-emitting diodes (QLEDs), etc.

[0190] In this embodiment of the application, the terminal device may include one or more displays 794.

[0191] In some embodiments of this application, the terminal device can implement display functions through a GPU, a display screen 794, an application processor, a microcontroller unit, etc., such as displaying the homepage of a map application, displaying an interface including recommended driving routes and related information on potholes and uneven road surfaces, or displaying an interface including navigation routes and related information on potholes and uneven road surfaces. The GPU is a microprocessor for image processing, connected to the display screen 794, the application processor, and the microcontroller unit. The GPU is used to perform mathematical and geometric calculations for drawing, rendering, or compositing graphics. The processor 710 may include one or more GPUs, which execute program instructions to generate or modify display information.

[0192] The terminal device can implement shooting functions through an ISP, a camera 793, a video codec, a GPU, a display 794, and an application processor. The ISP is used to process the data fed back by the camera 793, and the camera 793 is used to capture images, such as pictures, videos, or GIFs. In some embodiments, the terminal device may include one or N cameras 793, where N is a positive integer greater than 1.

[0193] In some embodiments of this application, the terminal device can detect one or more interactive operations such as body movements (e.g., waving hands) and blinking through the camera 793.

[0194] In some embodiments of this application, the sensor module 780 includes one or more of the following: a barometric pressure sensor 780A, a magnetic sensor 780B, a gyroscope sensor 780C, and an accelerometer sensor 780D. In some embodiments, the sensor module 780 may also include, but is not limited to, one or more of the following: a temperature sensor, a distance sensor, a proximity sensor, a fingerprint sensor, an ambient light sensor, and a bone conduction sensor.

[0195] The 780A barometric pressure sensor is used to measure air pressure. In some embodiments, the terminal device can calculate altitude using the air pressure value measured by the barometric pressure sensor to assist in positioning and navigation.

[0196] The magnetic sensor 780B is used to assist positioning systems such as GPS, BDS, QZSS, and SBAS, improving the accuracy and reliability of positioning. In some embodiments, the magnetic sensor 780B can provide additional directional information to terminal devices by sensing geomagnetic information, helping navigation applications and other applications with navigation guidance functions to more accurately calculate the user's location and driving direction, making navigation guidance more precise.

[0197] The gyroscope sensor 780C is used to determine the motion attitude of the terminal device. In some embodiments, the gyroscope sensor 780C can be used to determine the angular velocity of the terminal device about three axes (such as the x, y, and z axes) in order to determine the motion attitude of the terminal device.

[0198] The accelerometer 780D is used to detect the magnitude of acceleration of the terminal device in various directions (such as the x, y, and z axes). When the terminal device is stationary, the magnitude and direction of gravity can be detected. In some embodiments, the accelerometer 780D can also be used to identify the attitude of the terminal device.

[0199] In this embodiment, at least two sensors, such as barometric pressure sensor 780A, magnetic sensor 780B, gyroscope sensor 780C, and accelerometer sensor 780D, are capable of collecting crowdsourced trajectory data during the movement of the terminal device. For example, barometric pressure sensor 780A is used to collect barometric pressure data, magnetic sensor 780B is used to collect geomagnetic data, gyroscope sensor 780C is used to collect triaxial angular velocity data, and accelerometer sensor 780D is used to collect triaxial acceleration data.

[0200] The external memory interface 720 can be used to connect external memory cards, such as Micro SD cards, to expand the storage capacity of terminal devices. The external memory card communicates with the processor 710 through the external memory interface 720 to perform data storage.

[0201] Internal memory 721 may include one or more random access memory (RAM) and one or more non-volatile memory (NVM). The RAM can be directly read and written by the processor 710 and can be used to store executable programs (e.g., machine instructions) of the operating system or other running programs, as well as user and application data. The NVM can also store executable programs and user and application data, and can be pre-loaded into the RAM for direct read and write operations by the processor 310.

[0202] In some embodiments of this application, the external memory card and / or internal memory 721 can be used to store crowdsourced trajectory data collected by the terminal device through at least two sensors such as barometric pressure sensor 780A, magnetic sensor 780B, gyroscope sensor 780C, and accelerometer sensor 780D.

[0203] In some embodiments of this application, the external memory card and / or internal memory 721 can be used to store data such as fluctuation segments and deceleration segments obtained by the terminal device after analyzing crowdsourced trajectory data collected by at least two sensors.

[0204] In some embodiments of this application, the external storage card and / or internal memory 721 can be used to store data related to route planning, such as data on recommended driving routes from the server, data on potholes related to the recommended driving routes, data on navigation routes, and data on potholes related to the navigation routes.

[0205] For an introduction to the charging management module 740, power management module 741, battery 742, audio module 770, speaker 770A, receiver 770B, motor 791, indicator light 792, etc. shown in Figure 7A, please refer to conventional technology; they will not be elaborated here.

[0206] The structure illustrated in Figure 7A of this application does not constitute a specific limitation on the terminal device. In other embodiments of this application, the terminal device may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0207] The terminal device provided in this application embodiment can run an operating system (OS), which can be various operating systems used in the industry, such as those based on OpenHarmony. TM Developed operating systems, such as HarmonyTM OS; or other operating systems such as Android TM iOS TM Mobile operating system; it can also be various open-source operating systems or their derivatives, such as Linux. TM Operating systems (OS) include other embedded operating systems; they can also be future new operating systems, such as AI operating systems based on artificial intelligence. An operating system is a set of interconnected system software programs that manage and control the operation of terminal devices, utilize and run hardware and software resources, and provide public services to organize user interaction. In terminal devices, the operating system connects downwards to the physical hardware layer and provides a runtime environment for application software.

[0208] An operating system typically includes a kernel layer, a middleware layer, and an application layer. The application layer includes applications, which can include system applications and third-party applications. The middleware layer includes a suite of software providing various services to application developers, or frameworks providing services such as databases, multimedia, and graphics, or capabilities such as distributed scheduling and system scaling. For example, the middleware layer may include a framework layer and / or a system service layer. The framework layer provides APIs and programming frameworks for applications in the application layer. The system service layer includes the core capabilities of the system, providing services to applications through the framework layer. The kernel layer is the layer between hardware and software. The kernel layer may include hardware drivers and the operating system kernel. In addition to providing hardware drivers, the kernel layer also supports functions such as memory management and system process management.

[0209] The types and forms of terminal devices we use in our daily lives vary greatly, and the application scenarios for these devices are also very wide. Therefore, based on the different forms and functions of terminal devices, different application scenarios, and different user needs, the operating systems used on these terminal devices may also be different. The basic functions implemented by the terminal device provided in this application can be implemented using a general-purpose operating system or a dedicated operating system. To more clearly illustrate the implementation of the embodiments of this application under a specific operating system, the architecture of HarmonyOS is shown below. Those skilled in the art can deduce the implementation of the embodiments of this application under other specific operating systems, such as Android™.

[0210] As an example, please refer to Figure 7B, which shows a schematic diagram of the software architecture of a terminal device provided in an embodiment of this application. As shown in Figure 7B, the software architecture of the terminal device can be divided into several layers. In some embodiments, from bottom to top, they are: kernel layer, system service layer, framework layer, and application layer. The layers communicate with each other through software interfaces. System functions can be tailored, added, or combined at the subsystem granularity in different device deployment scenarios, and each subsystem can also be tailored, added, or combined at the functional granularity.

[0211] As an example, the kernel layer may include the kernel abstract layer (KAL), kernel subsystems, and driver subsystems.

[0212] The kernel abstraction layer provides basic kernel capabilities to upper layers by shielding the differences between multiple kernels, including but not limited to process / thread management, memory management, file system, network management, and peripheral device management. The kernel subsystem supports the selection of appropriate operating system kernels for different resource-constrained devices. The driver subsystem provides unified peripheral access capabilities and a framework for driver development and management, such as providing unified display drivers, camera drivers, audio drivers, Bluetooth drivers, sensor drivers, and storage drivers.

[0213] As an example, the system service layer comprises the core set of system capabilities, providing services to applications through the framework layer. This layer includes multiple subsystem sets, such as, but not limited to, one or more of the following: a basic system capability subsystem set, a basic software service subsystem set, an enhanced software service subsystem set, and a hardware service subsystem set.

[0214] The system comprises several subsystems, including: a basic capability subsystem set providing foundational capabilities for the operation, scheduling, and migration of distributed applications across multiple devices; a multi-language runtime environment (MRU) including distributed soft bus, distributed data management, distributed task scheduling, and Ark multi-language runtime; multi-modal input subsystem, graphics subsystem, security subsystem, and artificial intelligence (AI) business subsystem; a basic software service subsystem set providing common and general software services including event notification subsystem, telephone service subsystem, and multimedia subsystem; an enhanced software service subsystem set providing differentiated capability-enhancing software services for different devices including smart screen-specific business subsystem, wearable-specific business subsystem, and IoT-specific business subsystem; and a hardware service subsystem set providing hardware services including location service subsystem, identity and access management (IAM) subsystem, wearable-specific hardware service subsystem, biometric recognition, and Internet of Things (IoT)-specific hardware service subsystem.

[0215] The framework layer provides APIs and programming frameworks for applications in the application layer. The framework layer includes the ArkUI framework, the user application framework, and the Ability framework. The ArkUI framework provides a complete infrastructure for UI development of system applications, including UI functionalities such as components, layouts, animations, and interactive events, as well as a real-time interface preview tool. The Ability framework is a lightweight application that schedules and manages the operation and lifecycle of Abilities. Different devices may run different operating systems, and therefore support different APIs. APIs are a series of open capabilities provided to support operating system application development. APIs can be set in the framework layer or independently of the framework layer.

[0216] The application layer includes a series of applications, such as the video, map, music, and game applications shown in Figure 7B. Of course, the applications in the application layer can also include any other native applications (such as memo, contacts, camera, gallery, calendar, etc. integrated into the operating system) or functions, and / or other third-party applications (such as shopping, instant messaging, etc. applications downloaded and installed by the user through an app store), which are not limited in the embodiments of this application.

[0217] The structure illustrated in Figure 7B of this application does not constitute a specific limitation on the software structure of the terminal device. In other embodiments of this application, each level of the terminal device may include more or fewer subsystems than illustrated, or combine some subsystems, or split some subsystems, or have different subsystem layouts.

[0218] The route display method provided in this application embodiment will be described in detail below with specific examples.

[0219] As an example, please refer to Figure 8A, which shows an interactive diagram of a route display method provided in an embodiment of this application.

[0220] As shown in Figure 8A, the method may include S801A-S804A:

[0221] S801A: In response to user operation, the terminal device sends a request message to the server. The request message is used to request route planning or navigation route planning from the starting point to the destination.

[0222] Correspondingly, the server receives request messages from the terminal device.

[0223] In some embodiments, the user operation is a route planning operation triggered by the user in an application (such as a map application), and the request message sent by the terminal device to the server in response to the user operation is a route planning request. The route planning request carries information about the starting point and the destination, and the request message is used to request route planning from the starting point to the destination.

[0224] Optionally, the route planning request may also carry information to characterize user preferences, such as one or more of the following: highway priority, avoiding congestion, avoiding highways, main roads priority, time priority, saving time, shorter distance, fewer traffic lights, or good road conditions, etc., without limitation.

[0225] In some embodiments, the user action is a navigation route planning operation triggered by the user in an application (such as a map application), and the request message sent by the terminal device to the server in response to the user action is a navigation route planning request. The request message carries information about a recommended driving route from the user-selected starting point to the destination, and is used to request navigation route planning based on the user-selected recommended driving route; or the request message carries information about both the starting point and the destination, and is used to request navigation route planning from the starting point to the destination.

[0226] After receiving a request message from the terminal device, the server can perform route planning and obtain data on potholes and uneven road surfaces related to the route. The server then sends the route data and the data on potholes and uneven road surfaces related to the route to the terminal device through a response message. The terminal device can then display the route and the information on potholes and uneven road surfaces related to the route based on the response message.

[0227] S802A: The server plans the route from the starting point to the destination and obtains data on potholes and uneven road surfaces along the route.

[0228] As one possible implementation, the server can plan the route from the starting point to the destination based on the starting point and destination information carried in the request message, and obtain data on potholes and uneven road surfaces along the route.

[0229] Taking a request message used to request route planning from the starting point to the destination as an example, the server can plan the route based on the starting point and destination information carried in the request message, obtain at least one recommended route, and search the maintained road attribute data for the data on potholes and uneven surfaces of the roads traversed by each of the at least one recommended route.

[0230] In some embodiments, if the request message carries user preferences, the server can combine the user preferences to obtain a recommended driving route that satisfies one or more of the user preferences, such as prioritizing high speeds, avoiding congestion, avoiding highways, prioritizing main roads, prioritizing time, saving time, shorter distance, fewer traffic lights, or good road conditions.

[0231] Taking a request message used to request navigation route planning from the starting point to the destination as an example, the server can plan the navigation route from the starting point to the destination based on the information of the starting point and the destination, obtain the navigation route, and search for data on potholes and uneven surfaces of the roads traversed by the navigation route from the maintained road attribute data.

[0232] In some embodiments, if the request message carries user preferences, the server can combine the user preferences to obtain a navigation route that satisfies one or more of the user preferences, such as prioritizing high speeds, avoiding congestion, avoiding highways, prioritizing main roads, prioritizing time, saving time, shorter distances, fewer traffic lights, or good road conditions.

[0233] The data on potholes includes their location. The location of potholes refers to the range within which they are located.

[0234] In some embodiments, the data on potholes may also include, but are not limited to, one or more of the following: the percentage of potholes, the longitudinal height of potholes, the longitudinal depth of potholes, or the road surface material of potholes.

[0235] In this embodiment, the data on potholes in the road surface is obtained by the server based on fluctuation segments and deceleration segments reported by numerous terminal devices during movement. This process involves coarse identification of potholes, followed by data distillation based on the coarse identification results to achieve accurate identification of the potholes. The pothole identification process can be referred to in the descriptions of Figures 4, 5A, and 5B above, and will not be repeated here.

[0236] S803A: The server sends a response message to the terminal device, which carries route data and data on potholes and uneven road surfaces related to the route.

[0237] Correspondingly, the terminal device receives a response message from the server.

[0238] Taking a request message used to request route planning from the starting point to the destination as an example, the route data carried in the response message is the data of at least one recommended driving route, and the data of potholes and uneven road surfaces related to the route is the data of potholes and uneven road surfaces related to each of the at least one recommended driving route.

[0239] Taking a request message used to request navigation route planning from the starting point to the destination as an example, the response message carries route data as the navigation route from the starting point to the destination, and data on potholes and uneven road surfaces related to the route as the data on potholes and uneven road surfaces related to the navigation route.

[0240] S804A: The terminal device displays the route and information about potholes and uneven road surfaces based on the response message.

[0241] Taking a response message containing data on at least one recommended driving route and related pothole surface data for each of those routes as an example, the terminal device can display one or more recommended driving routes from the starting point to the destination based on the data of the at least one recommended driving route in the response message, and display pothole surface information based on the data of related pothole surfaces for each of those routes. For example, pothole surface information may include, but is not limited to, one or more of the following: the percentage of potholes, the location markings of potholes, the longitudinal height of potholes, the longitudinal depth of potholes, or the surface material of potholes.

[0242] Taking a response message that carries a navigation route from the starting point to the destination, as well as data on potholes along the navigation route, as an example, the terminal device can perform route navigation from the starting point to the destination based on the navigation route data carried in the response message, determine the location of potholes based on the data on potholes along the navigation route carried in the response message, and display pothole information at the pothole location. For example, pothole information may include, but is not limited to, one or more of the following: pothole location markers, pothole longitudinal height, pothole longitudinal depth, or pothole surface material.

[0243] Through the processes shown in S801A-S804A, when a terminal device user has route planning needs, more detailed data on the route and related potholes can be obtained. When displaying the route to the user, the information on potholes can be shown so that the user is aware of the pothole conditions in advance and is given enough time to understand the route, choose a route, and avoid them, thus ensuring a good user experience.

[0244] As shown in Figure 8B, in some embodiments, if the user operation is used to trigger the planning of a driving route from the starting point to the destination, the route display method provided in this application embodiment may include S801B-S805B.

[0245] In response to user operations, the S801B terminal device sends a request message to the server, which requests route planning from the starting point to the destination.

[0246] For information on S801B, please refer to the introduction of S801A above; it will not be repeated here.

[0247] S802B and the server plan the driving route from the starting point to the destination and obtain at least one recommended driving route.

[0248] As one possible implementation, the server can plan a driving route based on the starting point and destination information carried in the request message, and obtain at least one recommended driving route.

[0249] In some embodiments, if the request message carries user preferences, the server can combine the user preferences to plan the driving route from the starting point to the destination, and obtain a recommended driving route that satisfies one or more user preferences such as highway priority, avoiding congestion, avoiding highways, prioritizing main roads, time priority, saving time, shorter distance, fewer traffic lights, or good road conditions.

[0250] S803B: The server obtains data on potholes and uneven surfaces related to at least one of the recommended driving routes.

[0251] As one possible implementation, the server can search the maintained road attribute data for data on potholes and uneven surfaces along the roads traversed by each recommended driving route.

[0252] For other related information about S802B and S803B, please refer to the relevant explanation of S802A above, which will not be repeated here.

[0253] S804B: The server sends a response message to the terminal device, the response message carrying data of at least one of the above-mentioned recommended driving routes and data of potholes and uneven surfaces associated with each of the at least one recommended driving routes.

[0254] As an example, the data for each recommended driving route includes information about the roads traversed along the route from the starting point to the destination (such as the names of each road segment) and the driving distance.

[0255] As an example, the data on potholes associated with each recommended driving route includes the locations of potholes along the roads traversed by the route. Optionally, the data on potholes associated with each recommended driving route may also include one or more data such as the percentage of potholes along the roads traversed by the route, longitudinal height, longitudinal depth, and road surface material.

[0256] In some embodiments, data for a recommended driving route may also include one or more of the following information about the roads traversed by the route: highway / low-speed conditions, congestion conditions, toll booth locations, traffic light locations, and travel time, without limitation.

[0257] S805B: The terminal device displays at least one recommended driving route and information on potholes and uneven surfaces associated with each of the recommended driving routes based on the response message.

[0258] For example, information about potholes may include, but is not limited to, one or more of the following: the percentage of potholes, the location of potholes, the longitudinal height of potholes, the longitudinal depth of potholes, or the road surface material of potholes.

[0259] For further information about S805B, please refer to the introduction of S804A above, which will not be repeated here.

[0260] Through the processes shown in S801B-S805B, when a user has a route planning need, the terminal device obtains recommended driving routes and related data on potholes from the server. When displaying the recommended driving route to the user, the terminal device displays information on potholes, providing the user with a more comprehensive, detailed, and accurate picture of the road conditions. This helps the user understand road conditions in advance, choose recommended driving routes rationally, and have a clearer expectation of the driving route, facilitating travel time planning and selection of appropriate transportation, thus enhancing the user experience.

[0261] As shown in Figure 8C, in some embodiments, if the user operation is used to trigger navigation route planning from the starting point to the destination, the route display method provided in this application embodiment may include S801C-S805C.

[0262] In response to user actions, the S801C terminal device sends a request message to the server, which requests navigation route planning from the starting point to the destination.

[0263] For information on S801C, please refer to the introduction of S801A above; it will not be repeated here.

[0264] The S802C server plans the navigation route from the starting point to the destination and obtains the navigation route.

[0265] Taking the request message carrying information about the starting point and the destination as an example, as a possible implementation, the server can plan the navigation route from the starting point to the destination based on the information about the starting point and the destination, and obtain the navigation route.

[0266] In some embodiments, if the request message carries user preferences, the server can combine the user preferences to plan a navigation route from the starting point to the destination, and obtain a navigation route that satisfies one or more user preferences such as highway priority, avoiding congestion, avoiding highways, prioritizing main roads, time priority, saving time, shorter distance, fewer traffic lights, or good road conditions.

[0267] S803C, the server obtains data on potholes and uneven surfaces related to the navigation route.

[0268] As one possible implementation, the server can search for data on potholes and uneven surfaces along the roads traversed by the navigation route from the maintained road attribute data.

[0269] For other related information about S802C and S803C, please refer to the relevant explanation of S802A above, which will not be repeated here.

[0270] The S804C server sends a response message to the terminal device, which contains data on the navigation route and data on potholes and uneven surfaces related to the navigation route.

[0271] As an example, data on potholes associated with a navigation route includes the locations of potholes along the roads traversed by the navigation route. Optionally, the data on potholes associated with a navigation route may also include one or more of the following: the percentage of potholes along the roads traversed by the navigation route, the longitudinal height of potholes, the longitudinal depth of potholes, and the road surface material of potholes.

[0272] In some embodiments, the data on potholes related to the navigation route may also include one or more of the following information about the potholes along the roads traversed by the navigation route: high / low speed conditions, congestion conditions, toll booth locations, traffic light locations, and travel time, without limitation.

[0273] The S805C terminal device displays the navigation route based on the response message, and displays information about potholes at the locations of potholes along the navigation route.

[0274] For example, pothole information may include, but is not limited to, one or more of the following: the location of the pothole, the longitudinal height of the pothole, the longitudinal depth of the pothole, or the road material of the pothole.

[0275] For further information about the S805C, please refer to the introduction of the S804A above; it will not be repeated here.

[0276] Figure 8C shows S801C-S805C using the request message carrying information about the starting point and destination as an example. If the request message carries information about the recommended driving route selected by the user, since the server has already sent the data on potholes and uneven surfaces related to the recommended driving route to the terminal device when sending the data, the server can plan the navigation route from the starting point to the destination based on the recommended driving route selected by the user. After obtaining the navigation route data, the server sends it to the terminal device. The terminal device can display the navigation route based on the navigation route data and display the pothole and uneven surface information at the pothole and uneven surface locations on the navigation route based on the previously received data on potholes and uneven surfaces related to the recommended driving route.

[0277] Through the processes shown in S801C-S805C, when the terminal device has a navigation requirement, it can obtain navigation route and related data on potholes from the server. When displaying the navigation route to the user, the information on potholes is displayed so that the user can know the condition of the potholes in advance (such as location, longitudinal height, longitudinal depth, road material, etc., one or more of these), slow down in advance, avoid sudden braking and high-speed driving over potholes causing bounce and chassis collisions, safely pass through uneven roads, and enhance the user experience.

[0278] Taking a route planning scenario as an example, please refer to Figure 9, which shows an interactive diagram of a route display process provided in an embodiment of this application. As shown in Figure 9, the route display process includes S901-S907:

[0279] S901, the map application receives the user's first operation.

[0280] The first operation is used to obtain the driving route from the starting point to the destination.

[0281] As an example, the first operation might be that the user enters the starting point and destination in the map application interface and then clicks the first control to trigger route planning; or, the user operation might be that the user opens destination information shared by a friend, enters the starting point, and then clicks the first control to trigger route planning. Alternatively, the user operation might also be other forms of operation such as voice commands, gestures, body movements, blinking, etc., which are not limited in this application embodiment.

[0282] As one possible implementation, the way a user enters a starting point in a map application may include, but is not limited to, inputting through an input box, map touch input, voice input, or selection from the user's history such as frequently used locations or recently used addresses; the way a user enters a destination in a map application may include, but is not limited to, inputting through an input box, map touch input, voice input, opening destination information shared by a friend, or selection from the user's history such as frequently used locations or recently used addresses. This application embodiment does not limit the way and process by which the user enters a starting point and / or destination.

[0283] S902, The map application sends a route planning request to the server to request route planning from the starting point to the destination.

[0284] As an example, a route planning request includes information about the starting point and the destination.

[0285] Optionally, the route planning request may also carry information to characterize user preferences, such as one or more of the following: highway priority, avoiding congestion, avoiding highways, main roads priority, time priority, saving time, shorter distance, fewer traffic lights, or good road conditions, etc., without limitation.

[0286] S903, The server generates at least one recommended driving route from the starting point to the destination.

[0287] As one possible implementation, the server can use a route planning algorithm to plan a route based on the starting point and destination information carried in the route planning request, and obtain at least one recommended route.

[0288] In some embodiments, the server may generate a recommended driving route from the starting point to the destination, such as a first recommended driving route.

[0289] In some embodiments, the server may generate multiple recommended driving routes from the origin to the destination, such as a first recommended driving route and a second recommended driving route. Optionally, the multiple recommended driving routes may also include one or more other recommended driving routes, such as a third recommended driving route.

[0290] As one possible implementation, the server can use a route planning algorithm to search for the location of the starting point and destination in the road topology data maintained by the server, based on the starting point and destination information carried in the route planning request. It can then block POI information that is more than a threshold away from the route, map the location of the unblocked POI information onto the topology map corresponding to the road topology data, establish the route between the location of the unblocked POI information and the route, and form a recommended route with a fishbone structure.

[0291] In some embodiments, if the route planning request carries user preferences, the server can combine the user preferences to plan the route from the starting point to the destination, and obtain a recommended route that satisfies one or more user preferences such as highway priority, avoiding congestion, avoiding highways, prioritizing main roads, time priority, saving time, shorter distance, fewer traffic lights, or good road conditions.

[0292] S904. The server obtains data on potholes and uneven surfaces associated with each of the recommended driving routes in at least one recommended driving route.

[0293] Taking a server that includes a route planning module and a road attribute library as an example, as a possible implementation, the route planning module of the server can send a query request to the road attribute library to obtain data on potholes and uneven surfaces related to each recommended driving route from the road attribute data maintained by the road attribute library, such as the data on potholes and uneven surfaces of the roads traversed by each recommended driving route; in response to the query request, the road attribute library feeds back the data on potholes and uneven surfaces related to each recommended driving route to the route planning module.

[0294] The data on potholes includes the location of the potholes.

[0295] In some embodiments, the data on potholes may also include, but are not limited to, one or more of the following: the percentage of potholes, the longitudinal height of potholes, the longitudinal depth of potholes, or the road surface material of potholes.

[0296] S905. The server determines the percentage of potholes associated with each recommended driving route based on the data on potholes associated with each recommended driving route.

[0297] As one possible implementation, the server can calculate the percentage of potholes associated with each recommended driving route based on the length of the potholes associated with each recommended driving route and the total length of the recommended driving routes.

[0298] S906. The server sends a route planning response to the map application. The route planning response carries data on at least one of the above-mentioned recommended routes and the percentage of potholes on each recommended route.

[0299] For information on S906, please refer to the introduction of S804B above; it will not be repeated here.

[0300] S907. The map application displays at least one recommended driving route and the percentage of potholes on each recommended driving route based on the driving route planning response.

[0301] For information on the S907, please refer to the introduction of the S805B above; it will not be repeated here.

[0302] Figure 9 uses the example of the server preprocessing the data on potholes, such as determining the proportion of potholes, and then sending it to the map application. In some embodiments, the server may not execute S905 and directly send the data on potholes to the map application. In this case, when the map application displays at least one of the above-mentioned recommended driving routes, it can display the pothole information based on the pothole data related to each recommended driving route.

[0303] Furthermore, Figure 9 uses the example of the server sending the percentage of potholes to a map application. In some embodiments, the server may also send one or more data such as the longitudinal height, longitudinal depth, and road material of the potholes to the map application.

[0304] As an example, please refer to Figure 10. Figure 10 shows a schematic diagram of a recommended driving route display interface provided by an embodiment of this application, taking the driving route planning response as an example, which carries data of two recommended driving routes (Route 1 and Route 2 as shown in Figure 10).

[0305] As shown in Figure 10, the map application uses the data of route 1 from the current location to point A, carried in the route planning response, to display information such as the driving distance of route 1 (56 kilometers as shown in Figure 10), the time taken (1 hour and 7 minutes as shown in Figure 10), and the traffic light situation (3 traffic lights as shown in Figure 10) to the user through control 1. It also displays the percentage of potholes corresponding to route 1 (10% potholes as shown in Figure 10) to the user through control 1, based on the percentage of potholes corresponding to route 1 carried in the route planning response. Similarly, the map application uses the data of route 2 from the current location to point A, carried in the route planning response, to display information such as the driving distance of route 2 (63.9 kilometers as shown in Figure 10), the time taken (1 hour and 15 minutes as shown in Figure 10), and the traffic light situation (5 traffic lights as shown in Figure 10) to the user through control 2. It also displays the percentage of potholes corresponding to route 2 (e.g., 13% potholes) to the user through control 2, based on the percentage of potholes corresponding to route 2 carried in the route planning response.

[0306] In some embodiments, if the user has authorized the display of pothole information on the map layer, the map application can also display recommended driving routes and pothole information on the map layer.

[0307] As shown in Figure 10, the map application can also display the location markers of routes and potholes on the map layer based on the user's switching operation between control 1 corresponding to route 1 and control 2 corresponding to route 2. For example, when the user selects control 1, route 1 is displayed on the map layer based on the data of route 1, and the location markers of potholes are displayed at the corresponding positions of route 1; when the user selects control 2, route 2 is displayed on the map layer based on the data of route 2, and the location markers of potholes are displayed at the corresponding positions of route 2 (the interface shown in Figure 10 uses the user selecting control 1 as an example).

[0308] In some embodiments, the terminal device can also support users to share data on recommended driving routes and related road surface bumps with other devices. For example, in response to the user clicking the "Share" control shown in Figure 10, the terminal device can support the user to select a target object so that the data on recommended driving routes and related road surface bumps can be shared with other devices.

[0309] As one possible implementation, users can set permissions through the layer settings interface provided by the map application to authorize the display of pothole information on the map layer; alternatively, the map application can pop up a window to remind users to authorize the display of pothole information on the map layer when displaying recommended driving routes. This application embodiment does not limit the relevant authorization settings interface and specific methods.

[0310] Based on the route display process shown in Figure 9 and the recommended driving route display interface shown in Figure 10, it can be seen that when a user has a driving route planning need, the map application obtains the recommended driving route and the relevant pothole percentage from the server. When displaying the recommended driving route to the user, the map application displays the pothole percentage, so that when the user queries the route to the destination, it provides the user with a more comprehensive, detailed, and accurate information on the pothole conditions of the route. This helps the user to understand the road conditions in advance, choose the recommended driving route reasonably, and have a clearer expectation of the driving route, which is convenient for planning travel time and choosing the appropriate means of transportation, thus enhancing the user experience.

[0311] Taking a navigation route planning scenario as an example, please refer to Figure 11, which shows another route display process interaction diagram provided by an embodiment of this application. As shown in Figure 11, the route display process includes S1101-S1106:

[0312] S1101, The map application receives the user's second operation.

[0313] The second operation is used to obtain the navigation route from the starting point to the destination.

[0314] As an example, the second operation might be the user entering the starting point and destination in the map application interface and then clicking the second control to trigger navigation route planning; or, the user operation might be the user opening a driving route shared by a friend and then clicking the second control to trigger navigation route planning. Alternatively, the user operation might also be other forms of operation such as voice commands, gestures, body movements, blinking, etc., which are not limited in this application embodiment.

[0315] As one possible implementation, the way a user enters a starting point in a map application may include, but is not limited to, inputting through an input box, map touch input, voice input, or selection from the user's history such as frequently used locations or recently used addresses; the way a user enters a destination in a map application may include, but is not limited to, inputting through an input box, map touch input, voice input, opening destination information shared by a friend, or selection from the user's history such as frequently used locations or recently used addresses. This application embodiment does not limit the way and process by which the user enters a starting point and / or destination.

[0316] S1102. The map application sends a navigation route planning request to the server to request navigation route planning from the starting point to the destination.

[0317] As an example, a navigation route planning request carries information about the starting point and the destination.

[0318] Optionally, the navigation route planning request may also carry information to characterize user preferences. For example, user preferences may include, but are not limited to, one or more of the following: highway priority, avoiding congestion, avoiding highways, main roads priority, time priority, saving time, shorter distance, fewer traffic lights, or good road conditions, etc., without limitation.

[0319] S1103, The server generates a navigation route from the starting point to the destination.

[0320] As one possible implementation, the server can plan a navigation route based on the starting point and destination information carried in the navigation route planning request, using a navigation route planning algorithm.

[0321] In some embodiments, if the navigation route planning request carries user preferences, the server can combine the user preferences to plan a navigation route from the starting point to the destination, and obtain a navigation route that satisfies one or more user preferences such as highway priority, avoiding congestion, avoiding highways, prioritizing main roads, time priority, saving time, shorter distance, fewer traffic lights, or good road conditions.

[0322] S1104. The server obtains data on potholes and uneven surfaces related to the navigation route.

[0323] Taking a server that includes a route planning module and a road attribute library as an example, as a possible implementation, the route planning module of the server can send a query request to the road attribute library to obtain data on potholes and uneven surfaces related to the navigation route from the road attribute data maintained by the road attribute library, such as data on potholes and uneven surfaces of the roads traversed by the navigation route; in response to the query request, the road attribute library feeds back the data on potholes and uneven surfaces related to the navigation route to the route planning module.

[0324] The data on potholes includes the location of the potholes.

[0325] In some embodiments, the data on potholes may also include, but are not limited to, one or more of the following: the longitudinal height of the pothole, the longitudinal depth of the pothole, or the road surface material of the pothole.

[0326] S1105. The server sends a navigation route planning response to the map application. The navigation route planning response carries data on the navigation route and data on potholes and uneven surfaces related to the navigation route.

[0327] For other related information about S1105, please refer to the introduction of S804C above, which will not be repeated here.

[0328] S1106. The map application plans and displays the navigation route based on the navigation route plan, and displays information about potholes at the locations of potholes on the navigation route.

[0329] Among them, the map application has obtained user authorization to display information about potholes on the map layer.

[0330] As one possible implementation, users can set permissions through the layer settings interface provided by the map application to authorize the display of pothole information on the map layer; or, the map application can pop up a window to remind users to authorize the display of pothole information on the map layer when displaying navigation routes. This application embodiment does not limit the relevant authorization settings interface and specific methods.

[0331] For other related information about S1106, please refer to the introduction of S805C above, which will not be repeated here.

[0332] As an example, please refer to Figure 12, which shows a schematic diagram of a navigation route display interface provided in an embodiment of this application.

[0333] As shown in Figure 12, in addition to displaying the navigation route's duration (1 hour and 7 minutes), distance (56 kilometers), and estimated arrival time (14:13) based on the navigation route data carried in the navigation route planning response, the map application also displays the navigation route in the map layer based on the navigation route data carried in the navigation route planning response, and displays pothole location markers at the pothole locations on the navigation route based on the pothole data carried in the navigation route planning response.

[0334] In some embodiments, the terminal device can also support users to share navigation route data and related road surface data with other devices. For example, in response to the user clicking the "Share" control shown in Figure 12, the terminal device can support the user to select a target object so that the navigation route data and related road surface data can be shared with the target object.

[0335] Based on the route display process shown in Figure 11 and the navigation route display interface shown in Figure 12, it can be seen that when a user has a navigation need, the map application obtains navigation route and related road surface data from the server. When displaying the navigation route to the user through the map layer, it displays information such as the location and standard of the road surface, so that the user can know the condition of the road surface in advance (such as location, longitudinal height, longitudinal depth, road surface material, etc., one or more), slow down in advance, avoid sudden braking and high-speed driving over the road surface, avoid bouncing and chassis collision caused by the road surface, safely pass through the uneven road surface, and enhance the user experience.

[0336] Figures 11 and 12 illustrate navigation from the starting point to the destination triggered directly by a user through a second operation. In some embodiments, the map application may first trigger route planning from the starting point to the destination based on the user's first operation, send a route planning request to the server, and display the map application interface based on the data of at least one recommended route carried in the route planning response sent by the server. The map application interface includes at least one recommended route, and displays pothole information related to each recommended route on the map application interface based on the data of potholes and uneven surfaces related to each recommended route carried in the route planning response sent by the server. In response to the user's operation of selecting the first recommended route from the at least one recommended route, the navigation route planning operation is triggered. The map application sends a navigation route planning request to the server, displays the navigation interface based on the data of the navigation route carried in the navigation route planning response sent by the server, and displays pothole information at the pothole locations of the navigation route based on the data of potholes and uneven surfaces related to the first recommended route carried in the route planning response.

[0337] In some embodiments, in route navigation scenarios, data on potholes and uneven road surfaces related to the navigation route can also be used as a reference by the vehicle control system when controlling the vehicle.

[0338] For example, when the terminal device is an in-vehicle infotainment system, the map application in the terminal device can establish a connection with the vehicle control system. During the navigation process, the map application can provide real-time feedback to the vehicle control system on the location and the data of the bumpy road surface ahead of the terminal device. This data can be used by the vehicle control system to make one or more adjustments to the suspension, speed, etc., when passing through bumpy roads.

[0339] For example, if the terminal device is a portable device, it can establish a connection with the vehicle. The map application in the terminal device can connect to the vehicle control system through the connection between the vehicle and the system. During the navigation process, the map application can provide real-time feedback to the vehicle control system on the location and the data of the road surface with potholes ahead. This data can be used by the vehicle control system to make one or more adjustments to the suspension, speed, etc., when passing through the potholes.

[0340] As an example, please refer to Figure 13, which illustrates a vehicle control process based on data from a pothole-prone road surface according to an embodiment of this application. As shown in Figure 13, the process includes S1301-S1305:

[0341] S1301, Map application requests access to vehicle body control system.

[0342] As one possible implementation, the map application could respond to the user's action of opening the map application by initiating a request to access the vehicle control system in order to establish a communication channel with the vehicle control system.

[0343] S1302, The vehicle control system agrees to the map application's access request.

[0344] As one possible implementation, the vehicle control system can perform processes such as permission verification. After successful verification, it can grant the map application permission to transmit data through the map application's access request and return a message agreeing to the access request to the map application.

[0345] S1303, The map application navigates based on the data of the navigation route.

[0346] S1304. During navigation, the map application sends the location of the terminal device and data on potholes and uneven road surfaces within a preset range in front of the terminal device to the vehicle control system in real time.

[0347] As one possible implementation, during navigation, the map application can obtain the real-time location of the terminal device from the positioning system of the terminal device, and based on the location of the terminal device, obtain the data of potholes in a preset range in front of the terminal device from the existing data of potholes in the road surface, and send the location of the terminal device and the data of potholes in the preset range in front of the terminal device to the vehicle control system.

[0348] S1305: The vehicle control system adjusts one or more of the following parameters, such as suspension and vehicle speed, based on data sent by the map application while traversing uneven road surfaces:

[0349] As an example, the vehicle control system can adjust one or more parameters such as suspension stiffness and height while traversing uneven surfaces, and simultaneously regulate vehicle speed to allow the vehicle to pass over uneven surfaces at an appropriate speed.

[0350] By synchronizing map applications with information from the vehicle control system, the system can reference data on uneven road surfaces to control the vehicle. For example, based on pre-acquired data, it can adjust one or more parameters such as suspension and vehicle speed in a timely manner, reducing the bumps and vibrations when driving over uneven surfaces, enhancing driving safety and comfort, and preventing excessive impact on vehicle parts, thus helping to maintain vehicle performance and extend vehicle lifespan.

[0351] In some implementations, after the vehicle control system receives the location of the terminal device and data on potholes within a preset range in front of the terminal device from the map application, the vehicle control system can collect data through one or more modules such as cameras and LiDAR when it is about to reach the pothole. The system combines the data on the pothole with the data collected by the camera, LiDAR and other modules to jointly determine the pothole condition, thereby improving the accuracy of pothole identification. Based on the determined pothole condition, the system can make one or more adjustments to the suspension, vehicle speed and other parameters while passing through the pothole.

[0352] As an example, please refer to Figure 14, which illustrates another vehicle control process based on data from pothole-prone road surfaces provided in an embodiment of this application. As shown in Figure 14, the process includes S1401-S1407:

[0353] S1401, Map application requests access to vehicle body control system.

[0354] S1402, The vehicle control system agrees to the map application's access request.

[0355] S1403. The map application navigates based on the data of the navigation route.

[0356] S1404. During navigation, the map application sends the location of the terminal device and data on potholes and uneven road surfaces within a preset range in front of the terminal device to the vehicle control system in real time.

[0357] For information on S1401-S1404, please refer to the introduction of S1301-S1304 above, which will not be repeated here.

[0358] S1405 The vehicle control system collects data through one or more modules such as cameras and lidar when approaching a pothole.

[0359] For example, the vehicle control system can use cameras to collect images of the road ahead and use lidar to collect data on the road ahead in order to obtain more comprehensive, detailed and accurate road surface data.

[0360] S1406 The vehicle control system combines data from potholes and uneven road surfaces with data collected by one or more modules such as cameras and lidar to determine the condition of potholes and uneven road surfaces.

[0361] If it is determined that there are no potholes on the road surface, no action is taken; if it is determined that there are potholes on the road surface, then S1407 is executed.

[0362] S1407. The vehicle body control system adjusts one or more of the following parameters, such as suspension and vehicle speed, based on the determined road surface conditions when traversing the road surface:

[0363] For information on S1407, please refer to the introduction of S1305 above; it will not be repeated here.

[0364] By synchronizing information from map applications to the vehicle control system, and by combining data from the vehicle control system with data collected from uneven road surfaces and one or more modules such as cameras and lidar to jointly determine road conditions, on the one hand, it can more accurately identify uneven road surfaces, reduce misjudgments and omissions, and provide a reliable basis for subsequent vehicle control. On the other hand, it can enable the vehicle control system to refer to data from uneven road surfaces for vehicle control. For example, based on the data from uneven road surfaces acquired in advance, it can adjust one or more aspects such as suspension and vehicle speed in a timely manner to reduce the bumpy feeling when the vehicle passes over uneven road surfaces, enhance driving safety and comfort, avoid excessive impact on vehicle parts caused by uneven road surfaces, and help maintain vehicle performance and extend vehicle service life.

[0365] It should be understood that the various solutions in the embodiments of this application can be used in a reasonable combination, and the explanations or descriptions of the various terms appearing in the embodiments can be referenced or explained to each other in the various embodiments, without limitation.

[0366] It should also be understood that, in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0367] It is understood that terminal devices or servers, etc., in order to implement the functions of any of the above embodiments, include hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0368] This application embodiment can divide terminal devices or servers into functional modules. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0369] As an example, please refer to Figure 15, which shows a virtual functional structure block diagram of a terminal device provided in an embodiment of this application. As shown in Figure 15, the terminal device may include a data acquisition unit 1501, a processing unit 1502, a communication unit 1503, and a human-computer interaction unit 1504.

[0370] The data acquisition unit 1501 is used to support the terminal device in collecting data during movement, such as collecting crowdsourced trajectory data, and / or collecting other data related to the implementation of this application. For example, the data acquisition unit 1501 may include multiple sensors, which may include one or more of the following: a barometric pressure sensor, a magnetic sensor, a gyroscope sensor, or an accelerometer.

[0371] The processing unit 1502 is used to support the terminal device in extracting wave segments and deceleration segments based on the data collected by the data acquisition unit 1501. For example, it can obtain air pressure wave segments, geomagnetic wave segments, three-axis angular velocity wave segments, three-axis acceleration wave segments and forward direction axis deceleration segments based on the data collected by the data acquisition unit 1501, and / or other processes related to the implementation of this application.

[0372] In some embodiments, the processing unit 1502 is also configured to support the terminal device in performing coarse identification of potholes based on wave fragments and deceleration fragments.

[0373] The communication unit 1503 is used to support communication between the terminal device and other devices, such as supporting the terminal device to send wave fragments and deceleration fragments to the server, or supporting the terminal device to send coarse identification results to the server, and / or other processes related to the implementation of this application.

[0374] The human-computer interaction unit 1504 is used to support the interaction between the terminal device and the user. For example, it supports the terminal device to receive user operations such as the first operation and the second operation, and also supports the terminal device to display recommended driving routes, information on potholes and uneven surfaces related to the recommended driving routes, navigation routes, information on potholes and uneven surfaces related to the navigation routes, and / or other processes related to the implementation of this application.

[0375] In some embodiments, the communication unit 1503 is further configured to support the terminal device in sending requests to the server based on user operations received by the human-computer interaction unit 1504, such as sending a driving route planning request to the server based on a first operation, sending a navigation route planning request to the server based on a second operation, and receiving driving route planning responses and navigation route planning responses from the server.

[0376] In some embodiments, the communication unit 1503 is further configured to support the terminal device in sending the location of the terminal device and the data of the potholes in front of the terminal device within a preset range to the vehicle control system based on the data of the potholes in the navigation route, so as to further determine the state of the potholes in the vehicle control system, or to perform one or more vehicle control functions such as adjusting the suspension and adjusting the vehicle speed when passing through the potholes.

[0377] As an example, please refer to Figure 16, which shows a virtual functional structure block diagram of a server provided in an embodiment of this application. As shown in Figure 16, the server may include a communication unit 1601, a processing unit 1602, a storage unit 1603, and a route planning unit 1604.

[0378] The communication unit 1601 is used to support communication between the server and other devices, such as receiving wave fragments and deceleration fragments from the terminal device and at least one other device, or receiving coarse identification results from the terminal device and at least one other device, and / or other processes related to the implementation of this application.

[0379] The processing unit 1602 is used to support the server in performing coarse and fine identification of potholes based on wave fragments and deceleration fragments to obtain pothole data, or to perform fine identification of potholes based on the coarse identification results to obtain accurate pothole data, and / or other processes related to the implementation of this application.

[0380] Storage unit 1603 is used to support the server in data storage, such as storing road attributes like data on potholes, road data, and / or other data related to the implementation of this application.

[0381] In some embodiments, the communication unit 1601 is further configured to receive request messages from the terminal device, such as a driving route planning request or a navigation route planning request, and send to the terminal device at least one planned recommended driving route and data on potholes and uneven surfaces associated with each of the at least one recommended driving route, and send to the terminal device a planned navigation route and data on potholes and uneven surfaces associated with the navigation route.

[0382] The route planning unit 1604 is used to plan at least one recommended driving route from the starting point to the destination according to the driving route planning request of the terminal device, and obtain data on potholes and uneven surfaces related to each recommended driving route in the at least one recommended driving route, or to plan a navigation route from the starting point to the destination according to the navigation route planning request of the terminal device, and obtain data on potholes and uneven surfaces related to the navigation route.

[0383] Figures 15 and 16 respectively illustrate possible virtual functional structures for a terminal device and a server. The structures illustrated in Figures 15 and 16 do not constitute a specific limitation on the terminal device and server. In other embodiments of this application, the terminal device or server may include more or fewer units than illustrated, or combine some units, split some units, or have different unit arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware. For example, in some examples, the terminal device may also include a storage unit.

[0384] As an example, please refer to Figure 17, which shows a hardware structure block diagram of a terminal device or server provided in an embodiment of this application. As shown in Figure 17, the terminal device or server may include a processor 1701, a memory 1702, and communication components, such as a communication component including a communication line 1703 and at least one communication interface 1704 (Figure 17 is only an example illustrating the inclusion of one communication interface).

[0385] The processor 1701 may be a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits used to control the execution of the program of the present application.

[0386] In a specific implementation, as one example, processor 1701 may include one or more CPUs, such as CPU0 and CPU1.

[0387] Communication line 1703 may include a path for transmitting information between the aforementioned components.

[0388] Communication interface 1704 uses any transceiver-like device for communication with other devices, such as Ethernet, radio access network (RAN), wireless local area networks (WLAN), etc. For example, the communication interface of a terminal device is used to communicate with a server, and the communication interface of the server is used to communicate with the terminal device.

[0389] Memory 1702 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. Memory 1703 may exist independently and be connected to processor 1701 via communication line 1703. Memory 1703 may also be integrated with processor 1701.

[0390] The memory 1703 stores computer program instructions for executing the scheme of this application. The memory 1703 can store instructions for implementing two modular functions: send instructions and link instructions, and their execution is controlled by the processor 1701. The processor 1701 executes the computer program instructions stored in the memory 1703 to implement the method provided in the following embodiments of this application.

[0391] Optionally, the computer program instructions in the embodiments of this application may also be referred to as application code, and the embodiments of this application do not specifically limit this.

[0392] In a specific implementation, as one embodiment, the terminal device further includes a sensor component for collecting crowdsourced trajectory data during the movement of the terminal device. For example, the sensor component includes one or more of a barometric pressure sensor, a magnetic sensor, a gyroscope sensor, and an accelerometer. In some embodiments, the sensor component may also include, but is not limited to, one or more of the following: a temperature sensor, a distance sensor, a proximity sensor, a fingerprint sensor, an ambient light sensor, and a bone conduction sensor.

[0393] It should also be understood that the various modules in a terminal device or server can be implemented in software and / or hardware, without specific limitations. In other words, the terminal device or server is presented in the form of functional modules. Here, "module" can refer to application-specific integrated circuits (ASICs), circuits, processors and memory that execute one or more software or firmware programs, integrated logic circuits, and / or other devices that can provide the above functions.

[0394] In an alternative approach, when data transmission is implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are implemented. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disk (DVD)), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0395] The steps of the methods or algorithms described in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, compact disc read-only memory (CD-ROM), or any other form of storage medium known in the art. An exemplary embodiment couples a storage medium to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an application-specific integrated circuit (ASIC). Alternatively, the ASIC can reside in a terminal device or server. Of course, the processor and storage medium can also exist as discrete components.

[0396] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

Claims

1. A route display method, characterized in that, The method includes: In response to a user's operation, the terminal device sends a request message to the server. The request message is used to request route planning or navigation route planning from the starting point to the destination. The terminal device receives a response message from the server, the response message carrying route data and data on potholes and uneven surfaces related to the route; The terminal device displays the route and information about potholes and uneven surfaces associated with the route based on the response message.

2. The method according to claim 1, characterized in that, The data on potholes includes the location of the potholes.

3. The method according to claim 2, characterized in that, The data on potholes also includes one or more of the following: the percentage of potholes, the longitudinal height of potholes, the longitudinal depth of potholes, or the road material of potholes.

4. The method according to any one of claims 1-3, characterized in that, The user operation is a first operation, which requests route planning from the starting point to the destination. In response to the user operation, the terminal device sends a request message to the server, including: In response to the first operation, the terminal device sends a driving route planning request to the server; The response message contains data on at least one recommended driving route and data on potholes associated with each of the at least one recommended driving routes.

5. The method according to claim 4, characterized in that, The terminal device displays the route and related information about potholes and uneven surfaces based on the response message, including: Based on the response message, the terminal device displays at least one recommended driving route and related pothole road surface information for each recommended driving route through controls and / or map layers.

6. The method according to any one of claims 1-3, characterized in that, The user operation is a second operation, which requests navigation route planning from the starting point to the destination. In response to the user operation, the terminal device sends a request message to the server, including: In response to the second operation, the terminal device sends a navigation route planning request to the server; The response message contains data on the navigation route and data on potholes and uneven surfaces associated with the navigation route.

7. The method according to claim 6, characterized in that, The terminal device displays the route and related information about potholes and uneven surfaces based on the response message, including: Based on the response message, the terminal device displays the navigation route and related road surface information (potholes) on the map layer.

8. The method according to claim 6 or 7, characterized in that, The method further includes: The terminal device performs navigation based on the navigation route data; During navigation, the terminal device sends its position and data on potholes within a preset range in front of it to the vehicle control system based on data related to the potholes in the navigation route. The data on potholes and uneven surfaces within a preset range in front of the terminal device are used by the vehicle control system to further determine the condition of the potholes and uneven surfaces, or by the vehicle control system to control the vehicle while passing through potholes and uneven surfaces. The vehicle control includes one or more of the following: adjusting the suspension and adjusting the vehicle speed.

9. The method according to any one of claims 1-8, characterized in that, Before the terminal device sends the request message to the server, the method further includes: The terminal device collects data through multiple sensors during movement, including one or more of the following: barometric pressure sensor, magnetic sensor, gyroscope sensor, or accelerometer. The terminal device extracts wave fragments and deceleration fragments based on the data collected by the multiple sensors. The terminal device sends the wave fragment and the deceleration fragment to the server, whereby the wave fragment and the deceleration fragment are used by the server for coarse and fine identification of potholes; or, the terminal device performs coarse identification of potholes based on the wave fragment and the deceleration fragment, and sends the coarse identification result to the server, whereby the coarse identification result is used by the server for fine identification of potholes.

10. The method according to claim 9, characterized in that, The multiple sensors include a barometric pressure sensor, a magnetic sensor, a gyroscope sensor, and an accelerometer. The terminal device extracts wave segments and deceleration segments based on the data collected by the multiple sensors, including: The terminal device acquires air pressure fluctuation segments, geomagnetic fluctuation segments, three-axis angular velocity fluctuation segments, three-axis acceleration fluctuation segments, and forward direction axis deceleration segments based on data collected by the multiple sensors.

11. The method according to claim 9 or 10, characterized in that, The precise identification of potholes in the road surface includes: Identify the pitted fragments with the highest probability of periodic overlap in the coarse identification results to obtain precise pitted fragments.

12. The method according to any one of claims 1-11, characterized in that, The terminal device includes portable devices or in-vehicle systems.

13. A route display method, characterized in that, The method includes: The server receives a request message from the terminal device, the request message being used to request driving route planning or navigation route planning from the starting point to the destination; The server plans the route from the starting point to the destination and obtains data on potholes and uneven surfaces along the route. The server sends a response message to the terminal device, the response message carrying data of the route and data of potholes and uneven road surfaces related to the route.

14. The method according to claim 13, characterized in that, The data on potholes includes the location of the potholes.

15. The method according to claim 14, characterized in that, The data on potholes also includes one or more of the following: the percentage of potholes, the longitudinal height of potholes, the longitudinal depth of potholes, or the road material of potholes.

16. The method according to any one of claims 13-15, characterized in that, The request message is a route planning request. The server plans the route from the starting point to the destination and obtains data on potholes and uneven road surfaces related to the route, including: The server plans at least one recommended driving route from the starting point to the destination and obtains data on potholes and uneven surfaces associated with each of the at least one recommended driving routes. The response message contains data on the at least one recommended driving route and data on potholes and uneven surfaces associated with each of the at least one recommended driving routes.

17. The method according to any one of claims 13-15, characterized in that, The request message is a navigation route planning request. The server plans the route from the starting point to the destination and obtains data on potholes and uneven road surfaces related to the route, including: The server plans the navigation route from the starting point to the destination and obtains data on potholes and uneven surfaces related to the navigation route. The response message contains data about the navigation route and data about potholes and uneven surfaces associated with the navigation route.

18. The method according to any one of claims 13-17, characterized in that, Before receiving the request message, the method further includes: The server receives fluctuation fragments and deceleration fragments from the terminal device and at least one other device. The server performs coarse and fine identification of potholes based on the wave fragments and deceleration fragments to obtain data on the potholes. The server stores data on the potholes in the road surface.

19. The method according to claim 18, characterized in that, The server performs precise identification of potholes in the road surface, including: The server identifies the pitted fragments with the highest probability of periodic overlap in the coarse identification results, and obtains the precise pitted fragments.

20. The method according to claim 18 or 19, characterized in that, The acquisition of data on potholes and uneven surfaces related to the route includes: Retrieve data on potholes and uneven surfaces related to the route from the stored data.

21. A terminal device, characterized in that, The terminal device includes: Communication components are used for data transmission with other devices; Memory is used to store computer program instructions; A processor for executing the computer program instructions to support the terminal device in implementing the method as described in any one of claims 1-12.

22. A server, characterized in that, The server includes: Communication components are used for data transmission with other devices; Memory is used to store computer program instructions; A processor for executing the computer program instructions to support the server in implementing the method as described in any one of claims 13-20.

23. An application system, characterized in that, The application system includes: At least one terminal device, said at least one terminal device being used to implement the method as described in any one of claims 1-12; A server, the server being used to implement the method as described in any one of claims 13-20.

24. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processing circuit, implement the method as described in any one of claims 1-12, 13-20.

25. A computer program product containing instructions, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1-12, 13-20.

Images