Method, device and system for discovering map data using an activity management platform

Abstract

Methods, devices and systems for using an activity management platform to discover map data are provided. The present invention provides a method for using an activity management platform to discover an undiscovered geographic area. For example, the method includes determining, through the activity management platform, a geographic area where no known road segments are displayed in a geographic database, a geographic area where the number of known road segments is lower than a first threshold, or a geographic area where the probability of undiscovered road segments is higher than a second threshold. The method also includes generating a sensor data request, the sensor data request specifying a sensor data collection event to be performed within the geographic area. The sensor data collection event is part of an activity to discover digital map data for the geographic area. The method also includes sending the sensor data request to multiple vehicles. The multiple vehicles perform the sensor data collection event in the geographic area to collect sensor data. The method also includes processing the sensor data to generate digital map data for the geographic area.

Description

Technical Field

[0001] The present invention provides a method, device and system for discovering map data using an activity management platform. Background Art

[0002] Providing high-quality digital map data to ensure vehicle safety, especially for autonomous driving, has become a top priority for automobile manufacturers and related service providers. For example, having data about the location of road segments and related features (e.g., signs, poles, road markings, etc.) and possible situations in the road network allows autonomous vehicles and / or other vehicles to travel safely. However, maintaining such high-quality and up-to-date map data can consume a lot of computing and network resources. For example, crowdsourced sensor data used to generate or maintain digital map data consumes a lot of high-cost network bandwidth (e.g., cellular network bandwidth). Therefore, service providers face great technical challenges to more efficiently generate and maintain digital map data, especially when using crowdsourced sensor data transmitted from consumer vehicles. Summary of the invention

[0003] Therefore, a campaign management platform is needed to coordinate map data verification, discovery and / or update campaigns so that they send sensor data requests to target vehicles to advantageously reduce the resources required to transmit and / or process sensor data sets through such campaigns.

[0004] According to one embodiment, a method for using an activity management platform to discover an undiscovered geographic area includes: determining, by the activity management platform, a geographic area in which no known road segments are displayed in a geographic database, a geographic area in which the number of known road segments is below a first threshold, or a geographic area in which the probability of an undiscovered road segment is above a second threshold. The method also includes generating a sensor data request, the sensor data request specifying a sensor data collection event to be performed within the geographic area. The sensor data collection event is part of an activity to discover digital map data for the geographic area. The method also includes sending the sensor data request to a plurality of vehicles. The plurality of vehicles perform the sensor data collection event in the geographic area to collect sensor data. The method also includes processing the sensor data to generate digital map data for the geographic area.

[0005] According to another embodiment, an apparatus for using an activity management platform to discover undiscovered geographic areas includes: at least one processor; and at least one memory including computer program code for one or more programs, the at least one memory and the computer program code being configured to, together with the at least one processor, at least partially cause the apparatus to determine, through the activity management platform, a geographic area where no known road segments are displayed in a geographic database, a geographic area where the number of known road segments is below a first threshold, or a geographic area where the probability of undiscovered road segments is above a second threshold. The apparatus is also caused to generate a sensor data request, the sensor data request specifying a sensor data collection event to be performed within the geographic area. The sensor data collection event is part of an activity to discover digital map data for the geographic area. The apparatus is further caused to send the sensor data request to a plurality of vehicles. The plurality of vehicles perform the sensor data collection event in the geographic area to collect sensor data. The apparatus is further caused to process the sensor data to generate digital map data for the geographic area.

[0006] According to another embodiment, a non-transitory computer-readable storage medium for using an activity management platform to discover an undiscovered geographic area carries one or more sequences of one or more instructions, which when executed by one or more processors, at least partially causes a device to determine, through the activity management platform, a geographic area where no known road segments are displayed in a geographic database, a geographic area where the number of known road segments is below a first threshold, or a geographic area where the probability of undiscovered road segments is above a second threshold. The device is also caused to generate a sensor data request, the sensor data request specifying a sensor data collection event to be performed within the geographic area. The sensor data collection event is part of an activity to discover digital map data for the geographic area. The device is further caused to send the sensor data request to multiple vehicles. The multiple vehicles perform the sensor data collection event in the geographic area to collect sensor data. The device is further caused to process the sensor data to generate digital map data for the geographic area.

[0007] According to another embodiment, an apparatus for using an activity management platform to discover undiscovered geographic areas includes a module for determining, through the activity management platform, a geographic area where no known road segments are displayed in a geographic database, a geographic area where the number of known road segments is below a first threshold, or a geographic area where the probability of undiscovered road segments is above a second threshold. The apparatus also includes a module for generating a sensor data request, the sensor data request specifying a sensor data collection event to be performed within the geographic area. The sensor data collection event is part of an activity to discover digital map data for the geographic area. The apparatus also includes a module for sending the sensor data request to a plurality of vehicles. The plurality of vehicles perform the sensor data collection event in the geographic area to collect sensor data. The apparatus also includes a module for processing the sensor data to generate digital map data for the geographic area.

[0008] In addition, for various example embodiments of the present invention, the following may apply: a method comprising: facilitating processing and / or processing (1) data and / or (2) information and / or (3) at least one signal, (1) data and / or (2) information and / or (3) at least one signal being at least partially based on any one or any combination of (or at least partially derived from) the methods (or processes) disclosed in this application as being related to any embodiment of the present invention.

[0009] For various example embodiments of the present invention, the following may also be applicable: a method comprising facilitating access to at least one interface, the at least one interface being configured to allow access to at least one service, the at least one service being configured to perform any one or any combination of the network or service provider methods (or processes) disclosed in the present application.

[0010] For various example embodiments of the present invention, the following may also be applicable: a method comprising facilitating the creation and / or facilitating the modification of (1) at least one device user interface element and / or (2) at least one device user interface function, (1) at least one device user interface element and / or (2) at least one device user interface function being based at least in part on data and / or information generated by one or any combination of the methods or processes disclosed in this application as being associated with any embodiment of the present invention, and / or at least one signal generated by one or any combination of the methods (or processes) disclosed in this application as being associated with any embodiment of the present invention.

[0011] For various example embodiments of the present invention, the following may also be applicable: a method comprising creating and / or modifying (1) at least one device user interface element and / or (2) at least one device user interface function, (1) at least one device user interface element and / or (2) at least one device user interface function being at least partially based on data and / or information generated by one or any combination of methods or processes disclosed in this application as being associated with any embodiment of the present invention, and / or at least one signal generated by one or any combination of methods (or processes) disclosed in this application as being associated with any embodiment of the present invention.

[0012] In various exemplary embodiments, the method (or process) may be implemented on the service provider side or on the mobile device side or in any shared manner between the service provider and the mobile device (activities performed on both sides).

[0013] For various exemplary embodiments, the following applies: An apparatus comprising means for performing a method.

[0014] Other aspects, features and advantages of the present invention will become apparent from the following detailed description, merely by illustrating a number of specific embodiments and implementations, including the best mode contemplated for carrying out the present invention. The present invention is also capable of other and different embodiments, and the details of several aspects thereof may be modified in various obvious ways without departing from the spirit and scope of the present invention. Therefore, the drawings and description should be regarded as illustrative in nature, and not restrictive. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In the figures of the accompanying drawings, embodiments of the invention are shown by way of example and not limitation:

[0016] Figure 1 is a diagram of a system capable of verifying, discovering or updating map data using an activity management platform according to one embodiment;

[0017] Figure 2 is a diagram illustrating an example sensor data request that may be generated by an activity management platform according to one embodiment;

[0018] Figure 3 is a flow chart of a process for validating digital map data using a campaign management platform according to one embodiment;

[0019] Figure 4A is a diagram illustrating an example user interface for visualizing a sensor data request as a boundary of a target area according to one embodiment;

[0020] Figure 4B is a diagram of an example of change detection according to one embodiment;

[0021] Figure 5 is a flow chart of a process for discovering digital map data using a campaign management platform according to one embodiment;

[0022] Figure 6 is a diagram illustrating the use of vehicle posture path data to discover road segments according to one embodiment;

[0023] Figure 7 is a flow chart of a process for updating digital map data using a campaign management platform according to one embodiment;

[0024] Figure 8 is a diagram illustrating an example workflow of an activity management platform according to one embodiment;

[0025] Fig. 9 is a diagram illustrating components of a self-repairing digital map according to one embodiment;

[0026] Fig.10 is a flow chart of a process for creating an interface of an activity management platform to send a sensor data request according to one embodiment;

[0027] Fig.11 is a diagram illustrating different states of a sensor data request issued to a sensor data request interface according to one embodiment;

[0028] Fig.12 is a diagram illustrating example layers of a sensor data request interface according to one embodiment;

[0029] Fig.13 is a diagram of a geographic database according to one embodiment;

[0030] Fig.14 is a diagram of hardware that may be used to implement an embodiment;

[0031] Fig.15 is a diagram of a chip set that can be used to implement an embodiment; and

[0032] Fig.16 is a diagram of a mobile terminal (eg, a cell phone or a vehicle or a part thereof) that can be used to implement an embodiment. DETAILED DESCRIPTION

[0033] The present invention discloses examples of methods, apparatuses, and computer programs for validating map data using an activity management platform 101. In the following description, for the purpose of explanation, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the present invention. However, it is apparent to those skilled in the art that embodiments of the present invention may be implemented without these specific details or with equivalent arrangements. In other cases, well-known structures and devices are shown in block diagram form to avoid unnecessarily obscuring embodiments of the present invention.

[0034] Figure 1 is a diagram of a system capable of validating, discovering, or updating map data using an activity management platform, according to one embodiment. A vehicle (e.g., vehicle 103) will make driving decisions quickly, without human intervention. To support those decisions, the autonomous vehicle 103 requires reliable map information to assist them in a variety of situations, such as, but not limited to, understanding the layout of the road, what obstacles may be ahead, and updates on local traffic regulations. Map data (e.g., stored in a real-time map 105, such as a geographic database) is an important and essential navigation source for autonomous vehicles, and therefore, this map data must be correct, accurate, and up-to-date to accurately represent the world or environment in which the vehicle operates.

[0035] However, the world is not static. It is constantly changing and evolving. Therefore, a mapping system (e.g., a cloud-based mapping platform 107) that supports autonomous driving (or other driving use cases that rely on up-to-date map data) must constantly detect, verify, and update the changes that are happening in the world in near real-time and make appropriate updates to the digital map data of the live map 105. One way the mapping platform 107 obtains this freshness is crowd-sourced data from sensors installed on the fleet (e.g., vehicles 103) and / or mobile devices associated with the vehicles 103 (e.g., user equipment (UE) 111) to adapt and match the changing environment. In other words, the live map 105 or the digital map data stored therein needs to have the ability to "self-heal" by filling in map data for newly discovered areas, verifying map data in existing areas, and / or updating previously generated map data as needed.

[0036] In one embodiment, the stimulus for self-repair of the digital map data of the live map 105 may be derived from sensors on the vehicle 103 and / or the UE 111, especially when the digital map data includes high-definition (HD) map data with sub-meter or higher accuracy and real-time (e.g., real-time or substantially real-time) data about contextual parameters (e.g., traffic, accidents, road conditions, weather, etc.). For example, a consumer vehicle 103 and / or UE 111 traveling on a road network may collect sensor data (e.g., vehicle pose path or trajectory data, image data, LiDAR data, etc.) about a road segment or surrounding area, and then send the collected data to the mapping platform 107 via a communication network 113 (e.g., a cellular data network) for processing.

[0037] However, over-the-air bandwidth and transmission costs remain major issues, particularly for original equipment manufacturers (OEMs) (i.e., automakers), vehicle owners, and / or mapping service providers who may bear the costs of such transmission. For example, the continuous creation and transmission of large amounts of sensor data over the air for a large fleet of vehicles may be beyond the normal budget range. As a result, mapping service providers face significant technical challenges to provide a strategy and technical solution to minimize the necessary bandwidth and subsequent costs of discovering, validating, and / or updating map data. To address these technical challenges, Figure 1The system 100 has a function of managing the amount of data transmission using an activity management platform 101 to collect vehicle sensor data for digital map production. In one embodiment, the activity management platform 101 will create and manage activities or sensor data requests (SDRs) 115 for sensor data, which can reside in the cloud as a server-side component. The activity management platform 101 can be part of the entire cloud-based mapping platform 107, or can operate as a standalone component or component of any other system / platform. In one embodiment, the activity management platform 101 can determine the demand for sensor data for any given geographic range or road segment based on a variety of considerations including the age of map data, refresh history, and / or new road discoveries. The vehicle 103 will not transmit sensor data to the cloud unless responding to the sensor data request (SDR) 115 of the activity management platform 101. For example, the cloud includes any server-side components of the system 100, including but not limited to the collector cloud platform 117 (e.g., responsible for implementing SDR by collecting data from the vehicle 103 and / or UE 111), the activity management platform 101, and / or the mapping platform 107. In one embodiment, these sensor data requests 115 will be sent using a specified sensor data request interface format (SDRI) (e.g., discussed in more detail below) or an equivalent format. By implementing global awareness intelligence in the cloud, for example, via the activity management platform 101, the activity management platform 101 can advantageously optimize the creation and transmission of only the sensor data required by the map learning pathway of the mapping platform 107 to properly maintain the map.

[0038] In one embodiment, the activity management platform 101 may generate sensor data requests (e.g., data collection jobs) following three different models: "verification", "discovery", and "update". Typically, the sensor data requests generated by the activity management platform 101 will request data collection within a specified spatially restricted geographic range (e.g., a specified road segment or geographic area). In one embodiment, these geographic ranges may also be buffered by a specified distance threshold within which vehicle sensor data will also be executed. In this way, the activity management platform 101 may include margins to ensure that the specified geographic area is covered as completely as possible. For example, data collection will be initiated when the vehicle 103 receiving the sensor data request enters the buffer zone and ends when the vehicle 103 leaves the buffer zone.

[0039] In one embodiment, a validation model for requesting or generating sensor data for making a digital map includes requesting sensor data from a relatively small number of vehicles 103 on a road network to verify the accuracy or freshness of a known or previously mapped geographic area or road segment. Validation may include, for example, performing change detection to determine whether any previously known map features have changed. In one embodiment, change detection uses collected sensor data to identify when a map feature has moved or changed its location, is new to the monitored area, or is missing from the sensor data. A discovery model for requesting or generating sensor data includes requesting sensor data from vehicles 103 traveling off a known road network to discover new or previously unmapped road networks. An update model for requesting or generating sensor data includes requesting additional data as needed to update a digital map. For example, this requirement may be triggered based on detecting a change during map data validation or based on discovering a new or previously unmapped area or road segment during map data discovery.

[0040] In summary, through the capabilities of the activity management platform and the programmed intelligence / logic, vehicles 103 participating in sensor data collection for digital map production will not need to send a constant stream of data to the cloud. Instead, vehicles 103 will be required to collect sensor data only on specific roads or under specific conditions based on specific needs (e.g., map verification, map discovery, and / or map updates) determined by the activity management platform 101. In one embodiment, the collector cloud platform 117 can collect sensor data and / or collection feedback from vehicles 103 and / or UEs 111 to meet sensor data requests from requesting entities such as mapping platforms 107, activity management platforms 101, and / or any other data requesters.

[0041] In one embodiment, the activity management platform 101 generates or receives input for creating an activity to collect sensor data to meet a specific need (e.g., a map validation activity, a map discovery activity, and / or a map update activity). For example, the activity is the commitment of a fleet of vehicles 103 to collect sensor data in order to create or maintain digital map data of an area within a certain period of time. The sensor data refers to observations made by the fleet vehicles 103 using map feature detections determined, for example, from fused sensor data from one or more vehicle sensors. The sensor data generated by these activities can be fed into a map learning pathway, which includes, for example, an extraction module 119 for aggregating sensor data and collection feedback received in response to an activated sensor data request transmitted from the activity management platform 101 (e.g., extracted in response to an SDRI request or to a request through a sensor data extraction interface (SDII) or equivalent object).

[0042] The extraction module 119 may store the received sensor data observations in the observation database 121 or an equivalent data storage, or forward the sensor data directly to the activity management platform 101 (e.g., to assess whether the activity is complete or whether more data is needed). Examples of sensor data observations may include, but are not limited to:

[0043] (1) a vehicle travel or posture path 123, which includes detection or positioning points (e.g., GPS positioning points) arranged in time sequence, wherein each positioning point specifies a time-stamped position and orientation (e.g., posture) of the collecting vehicle 103;

[0044] (2) polylines 125 representing detected lane markings, road edges, and / or any other linear map features; and

[0045] (3) Points 127, which represent detected signs, signals, poles, markers, and / or any other map features that can be represented using point locations.

[0046] In some cases, the observations in the observation database 121 may include multiple observations of the same map feature. Therefore, the aggregation module may aggregate the multiple observations (e.g., distance-based clustering or other clustering means) to hide the multiple observations of different map features in one corresponding observation 131 for storage in the feature database 133. In addition, the aggregation module may localize the observations with respect to the digital map data of the real-time map 105 to perform change detection. Based on any detected changes, the aggregation module 129 may signal the activity management platform 101 to start additional activities (e.g., start an update activity if a map feature changes or is newly detected).

[0047] The map learning path is then continued by converting any new or updated map features stored in the feature database 133 into a map update 109 packet to update the digital map data of the live map 105. In one embodiment, the live map 105 is compiled from a digital map data stream in a standard format (e.g., Navigation Data Standard (NDS) format or equivalent) in real-time and / or substantially real-time data (e.g., real-time map data). To complete the mapping path, the published real-time map 105 can then be provided to end users (e.g., vehicles 103 and UEs 111) directly or via a collector cloud platform 117 on a communication network 113 or other downloaded media.

[0048] In one embodiment, Figure 2As shown, the activity management platform 101 includes one or more components for creating or maintaining digital map data according to various embodiments described herein. It is contemplated that the functions of these components may be combined or performed by other components of equivalent functionality. In this embodiment, the activity management platform 101 includes: a verification module 201 for performing functions related to map verification activities (e.g., verifying known digital map data); a discovery module 203 for performing functions related to map discovery activities (e.g., generating new digital map data); and an update module 205 for performing functions related to map update activities (e.g., updating known digital map data); and a sensor data request interface (SDRI) 207 for sending or publishing a sensor data request 209 to a vehicle 103 and / or UE 111 via a sensor data delivery 219 (e.g., through a collector cloud platform 117). In one embodiment, the sensor data request 209 is a request to collect sensor data and may be highly filtered based on geo-fencing, a specified date and / or time, and / or any other restrictions or vehicle-limited conditions (e.g., windshield wipers on / off, headlights on / off, etc.). As shown, the sensor data request 209 may have other subtypes including, but not limited to, a verification request 211 , a discovery request 213 , an update request 215 , and / or an in-vehicle change detection request 217 .

[0049] The modules and components of the mapping platform 107 presented above may be implemented in hardware, firmware, software, or a combination thereof. Figure 1 107, it is contemplated that the activity management platform 101 may be implemented as a standalone entity or as a module of any other component of the system 100. In another embodiment, one or more of the activity management platform 101 and / or any of the modules 201-207 may be implemented as a cloud-based service, a local service, a native application, or a combination thereof. The map validation, discovery, update, and interface functions of the activity management platform 101 and modules 201-207 will be described in detail below. Figures 3 to 14 Have a discussion.

[0050] Figure 3 is a flow chart of a map validation process 300 for validating digital map data using an activity management platform according to one embodiment. In various embodiments, the activity management platform 101 and / or any of the modules 201-207 may perform one or more portions of the map validation process 300 and may include, for example, Fig.15As such, the activity management platform 101 and / or any of the modules 201-207 may provide modules for completing portions of the map verification process 300, as well as modules for implementing embodiments of other processes described herein in conjunction with other components of the system 100. Although the map verification process 300 is illustrated and described as a sequence of steps, it is contemplated that various embodiments of the map verification process 300 may be performed in any order or combination, and need not include all of the illustrated steps.

[0051] In one embodiment, the map validation process 300 provides a "validation" model of the campaign management platform 101 that can be used to validate existing or known map data of the real-time map 105. It is contemplated that the map validation process 300 can be used as a standalone process or in conjunction with a "discovery" model and / or an "update" model.

[0052] In one embodiment, the map validation process 300 can be summarized as follows. The validation module 201 can generate validation requests (e.g., sensor data requests to collect sensor data for map validation) at scheduled intervals. For example, these requests will be for data for known highway corridors or geographic areas. Typically, validation requests only require a relatively small number of independent collection events. This is because the validation sensor data collection event is not intended to generate a map update, but rather to report a map data change detection process. In one embodiment, for a vehicle 103 or UE 111 that has a local copy of digital map data in the vehicle (e.g., a published instance of a real-time map 105), change detection can be performed in the vehicle. For vehicles 103 that do not have a real-time map 105 in the vehicle, the change detection process can be performed in the cloud. Once changes are confirmed to exist within the map validation activity area, the activity management platform 101 can initiate an "update" activity to obtain the data required by the map learning pathway of the mapping platform 107 to update the existing digital map data for the highway corridor or area.

[0053] Reference Figure 3To initiate the verification process 300, in step 301, the verification module 201 determines a previously mapped road segment (e.g., having an associated geographic data record stored in the real-time map 105). For example, the verification module 201 may query the real-time map 105 for verification intervals associated with one or more highway corridors or geographic regions of interest. The verification module 201 may then select a highway corridor (e.g., a road segment and a surrounding area within a threshold distance of the road segment) or a geographic region for which known digital map data is to be verified. In other words, the map verification process 300 may select a road segment or geographic region to be verified based on a data freshness threshold. The data freshness threshold may be based on a refresh schedule (e.g., a verification interval) for the geographic region in which the road segment is located. Additionally or alternatively, the data freshness threshold may be based on the age of the digital map data, the refresh history of the digital map data, or a combination thereof. For example, when the recorded age of the digital map data reaches a maximum age, a verification request for the highway corridor or region may be triggered. Furthermore, if the refresh history indicates that a particular frequency of map data for a particular highway corridor or region has occurred, the frequency may be used as a verification interval to trigger a verification request.

[0054] In step 303, the verification module 201 generates a sensor data request that specifies a sensor data collection event to be performed on the road segment. As previously described, the sensor data collection event can be part of an activity to verify digital map data of the road segment, a geographic area including the road segment, or a combination thereof. In one embodiment, the verification request can specify any combination of the following elements, including but not limited to:

[0055] (1) The highway corridor or geographic area to be verified, such as specified using polygons, map tiles, or other bounding areas (including any applicable buffer areas or margins);

[0056] (2) the type of sensor data to be collected, including but not limited to sensor data indicating detected road segments, lane markings, signs, poles, road equipment, etc.;

[0057] (3) the data scope of the sensor data collection event (e.g., the date when the sensor data request was activated);

[0058] (4) the time range of the sensor data collection event (e.g., the time range during which the sensor data request is valid);

[0059] (5) a target number of participating vehicles 103; and

[0060] (6) One or more vehicle limiting conditions that specify conditions that the participating vehicle 103 must meet before collecting and / or sending sensor data in response to the request (e.g., limiting conditions such as but not limited to vehicle wipers off, headlights off, etc.).

[0061] Figure 4A is a diagram illustrating an example user interface (UI) 401 for visualizing sensor data requests according to one embodiment. Figure 4A In the example of , UI 401 presents a map on which representations of sensor data requests 403a-404e (also collectively referred to as sensor data requests 403) are superimposed. Each sensor data request is represented by a polygon representing its valid area for collecting sensor data. In addition, each representation of a sensor data request indicates the type of sensor data to be collected. For example, sensor data request 403a is for collecting sensor data to verify map data for signs and poles, sensor data requests 403b, 403c, and 403e are for collecting sensor data to verify map data for traffic signals, and sensor data request 403d is for collecting sensor data to verify map data for road markings.

[0062] return Figure 3 In step 305, the verification module 201 sends or transmits the generated sensor data request to the target number of vehicles 103. The target vehicles 103 receiving the request can then perform a sensor data collection event on the specified road segment or geographic area to collect sensor data. In one embodiment, in response to the sensor data request, the activity limits the use of data network bandwidth to transmitting sensor data from the target number of vehicles. In this way, the activity management platform 101 can reduce data transmission costs and required network bandwidth to advantageously provide improved efficiency.

[0063] In one embodiment, the target number of vehicles is determined based on the minimum number of vehicles that can provide sensor data within a data freshness threshold (indicated by a refresh interval or a specified date / time range in the request.) In other words, the activity management platform 101 calculates the minimum number of vehicles based on traffic volume in the area, historical data collection events, or equivalent data.

[0064] In step 307, the verification module 201 processes the sensor data to verify the digital map data of the road segment. For example, as part of the verification process, the verification module 201 may initiate processing of the sensor data to perform change detection on the digital map data. In one embodiment, change detection may include determining whether a known map feature has moved or is missing, or whether a new or previously undrawn feature has been detected. To determine whether a feature has moved, the verification module 201 processes the sensor data to locate the detection of a known feature. If the located geographic coordinates of the detected known feature are greater than a threshold distance (e.g., exceeding an accuracy threshold or other specified threshold for the corresponding sensor) from a recorded known location in the digital map data, the verification module 201 may determine that the feature has moved. In other words, the measured deviation of the detected / observed feature from its known location represented in the digital map data exceeds an accuracy criterion. To determine that the feature is new, the verification module 201 may determine that the feature observed in the sensor data is not associated with any known feature of the digital map data. To determine that a known feature is missing, the verification module 201 may determine that the sensor data does not indicate that the feature is drawn in the digital map data and is still not present in the collected sensor data.

[0065] In one embodiment, change detection may be determined in the cloud (e.g., by the activity management platform 101 and / or mapping platform 107). In one embodiment, change detection may be performed in the cloud based on a determination that the reporting vehicle 103 or UE 111 does not have an instance of the in-vehicle HD real-time map 137. For cloud-based change detection, the activity management platform 101 may perform a continuous validation activity (or discovery activity as described below) to collect sensor data for a road network (e.g., in the road network or outside the road network). As noted, the activity may only use a relatively small number of participating vehicles 103 as frequently as needed to ensure data freshness. The received sensor data is localized and compared to the digital map data of the real-time map 105 in the cloud.

[0066] In one embodiment, in response to detecting a change, the mapping platform 107 may request additional information to verify that the change is real (e.g., collecting additional sensor data, sending personnel to verify in person, etc.). If the mapping platform 107 determines that the detected change is a false alarm, the activity management platform 101 may create a change mask and transmit the change mask to the vehicle 103 to suppress any other false alarms. If the detected change is confirmed or deemed to have occurred, the mapping platform 107 may adjust the quality indicators of the digital map data accordingly. In addition, the activity management platform 101 and / or the mapping platform 107 may continue to request additional sensor observations of the detected changes until the new model or change reaches a confidence threshold to issue and publish the map update 109.

[0067] In one embodiment, change detection may be performed as an in-vehicle process of the vehicle 103 and / or UE 111 based on determining that the vehicle 103 and / or UE 111 has accessed an instance of the digital map data of the real-time map 105 . Figure 4B is a diagram illustrating an example 421 of in-vehicle change detection according to one embodiment. In one embodiment, to perform in-vehicle change detection, the vehicle 103 should have an onboard instance of the real-time map 105. The vehicle 103 may then receive a change detection request or other type of activity request depending on change detection (e.g., a verification request or a discovery request). In some cases, certain types of change requests may be blocked in certain areas to prevent known false positives. The vehicle 103 may then collect sensor data for the type specified in the sensor data request (e.g., in Figure 4B In the example of , the requested data type is intersection markings). Vehicle 103 collects fused sensor observations (e.g., fusing GPS data with image data) into its copy of the digital map data to report changes for each activity request. Figure 4B In the example of , the vehicle 103 is able to match the detected features 423a-423i (also collectively referred to as matching features 423) with the digital map, so that these matching features 423 do not detect changes. However, the detected feature 425 does not match any known features in the map data and is therefore detected as a change.

[0068] In one embodiment, in-vehicle change detection can be combined with localization of sensor data to determine which data the vehicle 103 should send in response to an activity request. If the vehicle 103 cannot be successfully localized, all observations (e.g., matched detected features 423) near the change (e.g., detected feature 425) can be transmitted to the cloud to understand the local constraints between the observations. In order for the vehicle 103 to be successfully localized, there should be enough observations to match the digital map data. In one embodiment, if localization is successful, only the localized vehicle pose, map version, and detected changes (e.g., feature 425) are transmitted. For example, to handle localization observations in the cloud, proxy localization features can be injected from a specified digital map data version when performing localization. The localization changes are then extracted and the proxy features are discarded.

[0069] Figure 5 is a flow chart of a map discovery process 500 for discovering digital map data using an activity management platform according to one embodiment. In various embodiments, the activity management platform 101 and / or any of the modules 201-207 may perform one or more portions of the map discovery process 500 and may include, for example, Fig.151 and 2. In this manner, the activity management platform 101 and / or any of the modules 201-207 may provide modules for completing various portions of the map discovery process 500, as well as modules for implementing embodiments of other processes described herein in conjunction with other components of the system 100. Although the map discovery process 500 is illustrated and described as a sequence of steps, it is contemplated that various embodiments of the map discovery process 500 may be performed in any order or combination, and need not include all of the illustrated steps.

[0070] In one embodiment, the map discovery process 500 provides a "discovery" model of the activity management platform 101 that can be used to create new map data for previously unmapped or undiscovered areas of the real-time map 105. It is contemplated that the map discovery process 500 can be used as a stand-alone process, or can be used in conjunction with a "validation" model and / or an "update" model.

[0071] In one embodiment, the map discovery process 500 can be summarized as follows. Discovery operations or sensor data requests are used for sensor data collection in areas where there are no known roads. The map discovery process 500 is similar to the map validation process 300 in some respects, but the geographic area is carefully selected to focus on areas outside the current known road network. In one embodiment, the map discovery activity focuses on identifying driving patterns (pattern of driving) in new or previously unmapped geographic areas. To this end, in one embodiment, the sensor data requests issued under the discovery model may only request vehicle pose path or trajectory data (e.g., a chronological sequence of location points associated with the driving of a single vehicle). Once the driving pattern is confirmed in the new area, the activity management platform 101 can initiate an "update" activity to obtain data for the map learning pathway of the mapping platform 107 to use to map the new area.

[0072] In step 501, the discovery module 203 determines a geographic area in which no known road segments are displayed in the geographic database, a geographic area in which the number of known road segments is less than a first threshold, or a geographic area in which the probability of no discovered road segments is greater than a second threshold. For example, the discovery module 203 may define a bounded area in which there are no current map road segments. Additionally or alternatively, the discovery module 203 may define an area less than a road segment threshold (e.g., an area with incomplete mapping). In another embodiment, the discovery module 203 may use attributes or parameters, such as no known road segments, the comparability of the number of known road segments to known or mapped geographic areas with similar attributes (e.g., location, rural / urban, size, etc.) to calculate the probability of classifying a geographic area as undiscovered versus mapped / known. If the probability is greater than the relevant threshold, the discovery process may be initiated.

[0073] In step 503, the discovery module 203 generates a sensor data request that specifies a sensor data collection event to be performed within the geographic area. As described above, the sensor data collection event can be part of an activity to discover digital map data for a geographic area. The sensor data request can be constructed as described in the embodiment of the verification process 300, except that the target area is an unknown area rather than a known or previously mapped area. For example, the sensor data request can specify a polygon that indicates a geographic area of ​​interest, a sensor data type, a date range, a time range, a target number of vehicles, a vehicle qualification, or a combination thereof.

[0074] In step 505, the discovery module 203 sends sensor data requests to a plurality of vehicles, wherein the plurality of vehicles perform sensor data collection events in a geographic area to collect sensor data. In one embodiment, the sensor data requests are sent to the plurality of vehicles via a manufacturer platform. The target number of vehicles may be based on the number of vehicles in a previous discovery activity in a similar geographic area. Similar areas are areas with similar characteristics, such as but not limited to rural and urban areas, terrain characteristics, similarity to adjacent known areas, etc. In one embodiment, the number of vehicles may be minimized to obtain a target number of dates within a target time period to minimize bandwidth and / or other resource usage requirements required to conduct the discovery activity.

[0075] In step 507, the discovery module 203 processes the sensor data to generate digital map data for the geographic area. In one embodiment, the sensor data request specifies that the vehicle posture path data is collected as the sensor data. Therefore, the discovery module 203 processes the vehicle posture path data to identify driving characteristics within the geographic area. At least some digital map data (e.g., candidate road segments in the area) can be determined from the driving characteristics. For example, Figure 6 is a diagram showing the use of vehicle posture path data to discover road segments according to one embodiment. Figure 6 In the example of , the discovery module receives a set 601 of vehicle pose paths of vehicles 103 that report participating in a discovery activity. The discovery module 203 can then process the set 601 of vehicle pose paths (e.g., by clustering or equivalent means) to determine the outline of a road segment 603. The discovery module 203 is configured to assume that if a target number of vehicles 103 travel along the same path through an unknown area, then the path is likely to correspond to a road segment or other path that supports vehicle travel. The discovery module 203 can specify a target number of vehicle pose paths to be obtained in the set 601 to achieve the following target confidence: the set 601 of vehicle pose paths or trajectories corresponds to a new or previously unmapped road segment (e.g., the confidence increases as the number of observed paths increases).

[0076] The discovery module 203 then confirms that the driving feature corresponds to a road segment within the geographic area. For example, the candidate road segment can be confirmed by collecting additional sensor data, sending personnel to manually verify, comparing with crowdsourced observations, etc. In one embodiment, after identifying and / or confirming the newly detected road segment, the activity management platform 101 can initiate other activities to collect data about other sensor data types in the area (e.g., lane markings, signs, poles, traffic signals, etc.). In other words, the discovery module 203 can initiate update activities to collect other sensors for the road segment, geographic area, or a combination thereof based on the confirmation of the driving feature or the corresponding road segment to generate map data.

[0077] Figure 7 700 is a flow chart of a map update process 700 for updating digital map data using an activity management platform according to one embodiment. In various embodiments, the activity management platform 101 and / or any of the modules 201-207 may perform one or more portions of the map update process 700 and may include, for example, Fig.15 1 and 2. In this manner, the activity management platform 101 and / or any of the modules 201-207 may provide modules for completing portions of the map update process 700, as well as modules for implementing embodiments of other processes described herein in conjunction with other components of the system 100. Although the map update process 700 is shown and described as a sequence of steps, it is contemplated that the various embodiments of the map update process 700 may be performed in any order or combination, and need not include all of the steps illustrated.

[0078] In one embodiment, the map update process 700 provides an "update" model of the activity management platform 101 that can be used to update existing or newly created map data of the real-time map 105. It is contemplated that the map update process 700 can be used as a standalone process or in conjunction with a "verification" model and / or a "discovery" model.

[0079] In one embodiment, the map update process 700 can be summarized as follows. The update request specifically collects sensor data used by the map learning pathway of the mapping platform 107 to update the digital map data of the real-time map 105. In one embodiment, the identification of the geographic area for the map update activity can be completed by previously run verification and / or discovery activities and other conditions or inputs that trigger the map update (e.g., administrator requirements, data reaching a freshness threshold, etc.). For example, the number of vehicles requested to collect sensor data in the update activity can be increased relative to the number of vehicles required for the verification and / or discovery activity in order to obtain a sufficient amount of data for the map learning pathway of the mapping platform 107 to update the map. In one embodiment, the depth and breadth of data collected by each vehicle 103 in the update activity request can also be increased relative to the sensor data request issued under the verification and / or discovery model. Once the specified amount of sensor data has been collected, the activity management platform 101 can issue a request cancellation.

[0080] In step 701, the update module 205 receives a map update request to update the digital map data of the geographic area. In one embodiment, the map update request is received from the verification module 201 based on the verification module 201 detecting a change in the digital map data. For example, as discussed with respect to the embodiment of the map verification process 300, the change detection may be performed in the cloud or in the vehicle. In another embodiment, according to the map discovery process 500 of the embodiment, the map update request is received from the discovery module 203 based on the discovery module 203 detecting and / or confirming a new road segment in the geographic area.

[0081] In step 703, the update module 205 generates a sensor data request that specifies a sensor data collection event to be performed within the geographic area, and the sensor data collection event is part of an activity to update a digital map for the geographic area. The update module 305 may use a process that is equivalent to or similar to the request generation process described in the above embodiments of the map verification process 300 and / or the map discovery process 500. In one embodiment, the depth and / or breadth of the sensor data requested in the sensor data request may be based on or determined by the corresponding depth and / or breadth of other sensor data used by the verification module to verify the digital map data, the discovery module to generate the digital map data, or a combination thereof. For example, the depth and / or breadth of the sensor data, or a combination thereof, may be increased relative to the verification module and / or the discovery module.

[0082] In one embodiment, depth may refer to the number or amount of sensor data observations collected by participating vehicles 103, such that the number of observations or amount of sensor data is increased relative to a comparable verification and / or discovery activity. To increase depth, for example, the update module 205 may specify longer activities, expand the time range for collecting sensors, etc. In one embodiment, the breadth of sensor data may refer to the number of sensor data types specified in the sensor data request. For example, if a verification activity detects changes in one type of sensor data (e.g., lane markings), the update module 205 may increase the breadth of the corresponding update activity by collecting multiple types of sensor data (e.g., lane markings combined with road signs, traffic lights, poles, etc.).

[0083] In step 705, the update module 205 sends a sensor data request to a target number of vehicles, wherein the target number of vehicles executes a sensor data collection event in a geographic area to collect sensor data. In one embodiment, the target number of vehicles may be increased relative to a corresponding number of vehicles used by a verification module, a discovery module, or a combination thereof. More specifically, the target number of vehicles may be determined based on a corresponding number of vehicles used by the verification module 201 to verify digital map data and / or by the discovery module 203 to generate digital map data. If the activity duration remains unchanged, the increased participants may be used to complete the activity faster or increase the depth of the amount of data collected. In one embodiment, the update module 205 sends a cancellation request to the target number of vehicles based on determining that the target amount of sensor data has been collected, wherein the cancellation request cancels the sensor data collection event.

[0084] In step 707, the update module 205 processes the sensor data to update the digital map data for the geographic area. For example, the update module 205 may detect any changes in the acquired sensor indications alone or in conjunction with the mapping platform 107, and then aggregate these changes into a map update once the confidence level associated with the detected range reaches a confidence threshold.

[0085] Figure 8 800 is a diagram illustrating an example workflow 800 of an activity management platform 101 according to one embodiment. As shown, a requester 803 (e.g., an administrator of a self-repairing HD map (e.g., a real-time map 105)) can submit an activity definition 805 (e.g., activity type - verify / discover / update - and related parameters, sensor data request, etc.) to a data storage directory 807 via an activity management UI 809 of a UI tool 811 of the activity management platform 101. The UI tool 811 can also include an activity visualization 813 for displaying activity requests, status, collected sensor data, and / or user interfaces (e.g., Figure 4AOther relevant data in UI 401).

[0086] The requester 801 then adds activity compilation logic to the activity compiler 815 via one or more batch filters 817 that can perform activity-related operations on the activity definitions (eg, validation, logging, tile-based aggregation, etc.).

[0087] In one embodiment, the output of the activity compiler 815 is routed to the activity collection layer 819, which is a data storage directory layer 821 that holds activity collections. For example, a collection can be assigned to a specific OEM. The OEM can use its corresponding OEM cloud platform 823 to poll the activity collection layer 819 to find new or changed activities. In one embodiment, the OEM cloud platform 823 can also subscribe to receive change notifications about changing activity news. The OEM cloud platform 823 extracts the new / changed activities from the data storage directory layer 821 and proxies the request to the target vehicle (e.g., OEM vehicle 825).

[0088] The OEM vehicle 825 may then collect sensor data in response to the activity request and return the sensor data to the OEM cloud platform 823. The OEM cloud platform 823 may relay the sensor data to a sensor archiver 827 associated with the requester 803 via an extraction interface 829 (e.g., SDII). The sensor data may then be further routed to a sensor archive 831 of a data storage directory 807 to generate or maintain map data 833.

[0089] exist Figure 8 In the example of , requester 801 is a self-repairing map. Fig. 9 is a diagram illustrating example components of a self-repairing digital map and its interaction with an activity management platform 101 according to one embodiment. As shown, components of a self-repairing digital map platform (e.g., mapping platform 107) include an extraction process 901 for collecting sensor data reported by vehicles 103 (e.g., via sensor data extraction process 903) for storage in a sensor observation database (process 905).

[0090] The collected sensor observations 905 may then be routed to various map learning pathway processes, including but not limited to the feature aggregation process 907 and the validation and discovery process 909 of the activity management platform 101. The feature aggregation process 907 may process the observations to locate detected features, detect feature changes, and aggregate features to determine map features for possible map updates. If the detected features have an uncertainty above a threshold, the feature aggregation process 907 may request a sensor data collection activity to collect additional data to reduce the uncertainty.

[0091] After the feature aggregation process 907 has enough data to reduce the uncertainty of the changed map features to below a target level, the map learning pathway can use the outputs of processes 905 (stored in the sensor observation database) and 907 (the feature aggregation process) to generate a map update.

[0092] Fig.10 700 is a flowchart of a process for creating an interface for an activity management platform to communicate sensor data requests according to one embodiment. In various embodiments, the activity management platform 101 and / or any of the modules 201-207 may perform one or more portions of the map update process 700 and may include, for example, Fig.15 1000. In this manner, the activity management platform 101 and / or any of the modules 201-207 may provide modules for completing portions of the process 1000, as well as modules for implementing embodiments of other processes described herein in conjunction with other components of the system 100. Although the process 1000 is shown and described as a sequence of steps, it is contemplated that various embodiments of the process 1000 may be performed in any order or combination, and need not include all of the steps illustrated.

[0093] In the above-described verification, discovery, and update model embodiments, the activity management platform 101 delivers activity sensor data requests to the target vehicle. In one embodiment, the activity management platform 101 can use process 1000 to create a hierarchical external-facing interface for the vehicle 103 and / or collector cloud platform 117 to access these requests to participate in the activity's data collection event.

[0094] In step 1001, the activity management platform 101 (e.g., via the verification module 201, the discovery module 203, and / or the update module 205) retrieves a sensor data request that specifies a sensor data collection event to be performed on a road segment, a geographic area, or a combination thereof. In one embodiment, the sensor data request may be used for any purpose requiring such data, including, but not limited to, discovery, verification, updating, or a combination thereof of digital map data (e.g., the real-time map 105) for a road segment, a geographic area, or a combination thereof. These requests may be retrieved and / or generated according to the embodiments of the map verification process 300, the map discovery process 500, and the map update process 700 described above.

[0095] In step 1003, the interface module 207 publishes or sends the sensor data request to the activity management interface. In one embodiment, the interface includes multiple layers, including an activity request layer, a new release request layer, a revocation request layer, or a combination thereof. The vehicle and / or a corresponding manufacturer platform (e.g., the collector cloud platform 117) can access at least one of the multiple layers to satisfy the sensor data request. In one embodiment, access can be made through a stream subscription, a data extraction mechanism, or any equivalent mechanism.

[0096] In one embodiment, different layers of the interface may be based on different states of sensor data requests generated and processed by the activity management platform. Fig.11 As shown in FIG1101 , these different layers may be based on the state of the sensor data request. In one embodiment, the main state may classify the sensor data request as active or inactive. For an active sensor data request, sensor data collection is requested. For an inactive sensor data request, sensor data collection is not requested. In addition, the sensor data request may also have a new or revoked sub-state. The new sub-state indicates that the sensor data request is newly issued within a recent time period (e.g., within the last 24 hours). The revoked sub-state indicates that the sensor data request has become inactive before its specified expiration time. In one embodiment, another sub-state may include a validity state. A valid sensor data request has not expired due to time and is valid according to its specified time range; and requires sensor data collection. The time validity of the invalid sensor data has expired based on the specified time range, and sensor data collection is no longer required.

[0097] Different layers of the active interface can then be determined based on these different states and sub-states of the sensor requests. For example, the active request layer provides multiple sensor data requests that are active and waiting to be satisfied (e.g., waiting for data to be collected to satisfy the request). The newly published request layer displays multiple sensor data requests that have been published to the interface since the last publication event (e.g., the last publication time of the request layer), or within a recent time period. In one embodiment, the sensor data requests displayed in the newly published layer are also displayed in the active request layer (e.g., during the most recent publication).

[0098] In one embodiment, the revocation request layer displays sensor data requests that have been revoked before the expiration of the sensor data request. As described above, the revocation request layer can include sensor data requests that have become inactive before their specified expiration time. In other embodiments, the revocation request layer can also include sensor data requests that have been revoked before any other expiration condition (including but not limited to time-based expiration).

[0099] In one embodiment, requests may be moved between layers of an interface based on their respective states. For example, a revoked sensor data request may be moved from a revoked request layer to an active layer of an interface based on a determination that the revoked sensor data meets validity criteria, or in reverse order. In one embodiment, sensor data requests may be moved between layers based on, for example, a specified time cadence corresponding to a release cycle. For example, a new version of one or more output layers of an interface is created based on a specified time cadence and then moved to an appropriate layer based on its state or sub-state.

[0100] Fig.12 is a diagram illustrating example layers of a sensor data request interface according to one embodiment. More specifically, Fig.12 The example shows how to 1 To T n The designation is V 1 To V n The sensor data requests are included or moved between layers (eg, active job layer 1201, newly released layer 1203, and revoked job layer 1205) at different time periods (eg, representing different versions). Table 1 below summarizes the movement of sensor data requests (SDRs) 1 to 8.

[0101]

[0102]

[0103] Table 1

[0104] In one embodiment, a new version of the sensor data request is created once per release cycle, which is defined by the release rate. If there is no new sensor data request or revocation, a new version can be skipped until a new sensor data request or revocation occurs. The width of the version (covering time or time period) depends on the specified time rhythm (e.g., a 24-hour time rhythm). This rhythm or time interval width also defines the resolution of the system 100.

[0105] In one embodiment, sensor data requests in multiple layers of the interface are geographically partitioned (e.g., based on a map tile structure and / or sensor data request volume). For example, the system 100 may select a tile zoom level (e.g., zoom level 10) as a default. However, the zoom level may be changed based on collected sensor data and / or successful or failed execution of the activity management platform 101 to satisfy activity requests. In one embodiment, the zoom age or geographical partitioning structure may vary from layer to layer. Each version of a layer contains data only when there is relevant data, otherwise no partitions are published.

[0106] Reference Figure 1In one embodiment, the mapping platform 107 and / or the activity management platform 101 may be a platform having multiple interconnected components. For example, the mapping platform 107 and / or the activity management platform 101 may include multiple servers, intelligent networked devices, computing devices, components, and corresponding software for providing map verification, discovery, and / or update activities and corresponding activity management interfaces for external access.

[0107] For example, UE 111 may be any type of embedded system, mobile terminal, fixed terminal or portable terminal, including a built-in navigation system, a personal navigation device, a mobile handset, a station, a unit, a device, a multimedia computer, a multimedia tablet, an Internet node, a communicator, a desktop computer, a laptop computer, a notebook computer, a netbook computer, a tablet computer, a personal communication system (PCS) device, a personal digital assistant (PDA), an audio / video player, a digital camera / camcorder, a positioning device, a fitness device, a television receiver, a radio receiver, an e-book device, a gaming device or any combination thereof, including accessories and peripherals of these devices or any combination thereof. It is also contemplated that UE 111 may support any type of interface with a user (e.g., a "wearable" circuit device, etc.). In one embodiment, UE 111 may be associated with vehicle 103 or may be a component of vehicle 103.

[0108] In one embodiment, vehicle 103 may support various driving modes (e.g., automatic mode, semi-automatic, manual, etc.). Vehicle 103 may be, for example, an unmanned vehicle or a highly assisted driving vehicle that is capable of sensing its environment and navigating a road network without driver or occupant input. It is worth noting that autonomous vehicles and highly assisted driving vehicles are part of a range of automotive classifications from no automation to fully autonomous driving. For example, the National Highway Traffic Safety Administration ("NHTSA") defined five levels of vehicle autonomy in its "Preliminary Statement of Policy Regarding Automated Driving Vehicles" issued in 2013:

[0109] Level 0 (No Automation) – “The driver is in full control of the vehicle’s primary control systems at all times, including braking, steering, throttle and power.”;

[0110] Level 1 (Automation of Specific Functions) – “This level of automation involves one or more specific control functions. Examples include electronic stability control or pre-charge brakes, where the vehicle automatically assists with braking, enabling the driver to regain control of the vehicle or stop the vehicle more quickly than they could alone.”;

[0111] Level 2 (Combined Function Automation) – “This level involves the automation of at least two primary control functions that are designed to work together to relieve the driver of control of those functions. An example of a combined function enabled Level 2 system is the combination of adaptive cruise control with lane centering.”;

[0112] Level 3 (Limited Self-Driving Automation) – “Vehicles at this level of automation enable the driver to relinquish full control of all safety-critical functions under certain traffic or environmental conditions where the driver will rely heavily on the vehicle to monitor changes in conditions that require a transition back to driver control. The driver may occasionally take control, but with sufficient transition time for comfort.”; and

[0113] Level 4 (Full Self-Driving Automation) – “The vehicle is designed to perform all safety-critical driving functions and monitor road conditions throughout the journey. This design anticipates that the driver will provide destination or navigation input, but the driver is not expected to take control at any time during the journey. This includes both manned and unmanned vehicles.”

[0114] The various embodiments described herein are applicable to vehicles classified at any of the automation levels described above (Levels 0-4).

[0115] In one embodiment, the vehicle 103 is configured with various sensors for generating or collecting sensor data, vehicle sensor data, related geographic / map data, etc. In one embodiment, the sensed data represents sensor data related to the geographic location or coordinates where the sensor data is collected. In this way, the sensor data can be used as observation data, which can be divided into location-aware training and evaluation data sets according to their data collection locations, and can be used to detect physical dividers according to the embodiments described herein. For example, the sensor may include a radar system, a lidar system, a global positioning sensor (e.g., GPS) for collecting location data, a network detection sensor for detecting wireless signals or a receiver for different short-range communications (e.g., Bluetooth, Wi-Fi, Li-Fi, near field communication (NFC), etc.), a time information sensor, a camera / imaging sensor for collecting image data, a recorder for collecting audio data, a speed sensor mounted on the steering wheel of the vehicle, a switch sensor for determining whether to engage one or more vehicle switches, etc.

[0116] Other examples of sensors for the vehicle 103 may include light sensors, orientation sensors with height sensors and acceleration sensors added (e.g., accelerometers can measure acceleration and can be used to determine the direction of the vehicle), tilt sensors for detecting the degree of inclination or descent of the vehicle along the path of travel, humidity sensors, pressure sensors, etc. In another example embodiment, sensors around the perimeter of the vehicle 103 can detect the relative distance of the vehicle from the VRU, physical dividers, lanes or roads, the presence of other vehicles, pedestrians, traffic lights, potholes, and any other objects, or a combination thereof. In one case, the sensors can detect weather data, traffic information, or a combination thereof. In one embodiment, the vehicle 103 may include a GPS or other satellite-based receiver to obtain geographic coordinates from a satellite to determine the current location and time. In addition, the location can be determined by visual odometry, triangulation systems (e.g., A-GPS, source areas, or other location inference techniques). In yet another embodiment, the sensors can determine the status of various control elements of the vehicle, such as activation of wipers, use of brake pedals, use of accelerator pedals, angle of the steering wheel, activation of warning lights, activation of headlights, etc.

[0117] In one embodiment, the communication network 113 of the system 100 includes one or more networks, such as a data network, a wireless network, a telephone network, or any combination thereof. It is contemplated that the data network may be any local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a public data network (e.g., the Internet), a short-range wireless network, or any other suitable packet-switched network, such as a commercially owned proprietary packet-switched network, such as a proprietary cable or fiber optic network, or the like, or any combination thereof. In addition, the wireless network may be, for example, a cellular network and may employ a variety of technologies, including Enhanced Data Rates for Global Evolution (EDGE), General Packet Radio Service (GPRS), Global System for Mobile Communications (GSM), Internet Protocol Multimedia Subsystem (IMS), Universal Mobile Telecommunications System (UMTS), etc., as well as any other suitable wireless medium, such as Worldwide Interoperability for Microwave Access (WiMAX), Long Term Evolution (LTE) networks, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Wireless Fidelity (WiFi), Wireless LAN (WLAN), Internet Protocol (IP) datacast, satellite, mobile ad hoc network (MANET), etc. or any combination thereof.

[0118] For example, the activity management platform 101, the mapping platform 107, the collector cloud platform 117, the vehicle 103 and / or the UE 111 communicate with each other and with other components of the system 100 using well-known, new or still developing protocols. In this context, the protocol includes a set of rules for defining how network nodes within the communication network 113 interact with each other based on information sent on the communication links. The protocols work at different operational layers within each node, from generating and receiving various types of physical signals, to selecting links for transmitting those signals, to the information format indicated by those signals, to identifying which software applications executed on the computer system send or receive the information. The conceptually different protocol layers for exchanging information on a network are described in the Open Systems Interconnection (OSI) reference model.

[0119] Communication between network nodes is typically effected by exchanging discrete data packets. Each data packet typically includes (1) header information associated with a particular protocol, and (2) payload information following the header information and containing information that can be processed independently of the particular protocol. In some protocols, the packet includes (3) trailer information following the payload and indicating the end of the payload information. The header includes information such as the source of the packet, its destination, the payload length, and other attributes used by the protocol. Typically, the data in the payload for a particular protocol includes headers and payloads for different protocols associated with different higher layers of the OSI reference model. The header for a particular protocol typically indicates the type of the next protocol contained in its payload. Higher-level protocols are considered to be encapsulated in lower-level protocols. As defined by the OSI reference model, the headers included in a packet traversing multiple heterogeneous networks (such as the Internet) typically include a physical (layer 1) header, a data link (layer 2) header, an internetwork (layer 3) header, and a transport (layer 4) header, as well as various application (layer 5, layer 6, layer 7) headers.

[0120] Fig.131 is a diagram of a real-time map 105 (e.g., a geographic database) according to one embodiment. In one embodiment, the real-time map 105 includes geographic data 1301 for (or configured to be compiled for) mapping and / or navigation related services. In one embodiment, a polygon (e.g., a two-dimensional feature) or a polygon extrusion (e.g., a three-dimensional feature) is used to represent a geographic feature (e.g., a two-dimensional or three-dimensional feature). For example, the edge of a polygon corresponds to a boundary or edge of a corresponding geographic feature. In the case of a building, a two-dimensional polygon can be used to represent the floor area of ​​the building, and a three-dimensional polygon extrusion can be used to represent the three-dimensional surface of the building. It is contemplated that although various embodiments are discussed for two-dimensional polygons, it is contemplated that these embodiments may also be applied to three-dimensional polygon extrusion. Therefore, the terms polygon and polygon extrusion used herein are used interchangeably.

[0121] In one embodiment, the following terms are applied to represent geographic features in the real-time map 105 .

[0122] “Node” – the point where a link terminates.

[0123] “Line segment” – a straight line connecting two points.

[0124] "Link" (or "edge") - a continuous, unbranched string of one or more line segments that terminate at nodes at both ends.

[0125] "Shape Point" – a point along a link between two nodes (e.g., used to change the shape of a link without defining a new node).

[0126] “Directed link” – a link with a starting node (called a “reference node”) and an ending node (called a “non-reference node”).

[0127] "Simple polygon"—a region within an outer boundary formed by a series of directed links that start and end at a node. In one embodiment, a simple polygon does not cross itself.

[0128] "Polygon" - a region (e.g., a hole or an island) bounded by an exterior boundary, no boundary, or at least one interior boundary. In one embodiment, a polygon is composed of one exterior simple polygon and none or at least one interior simple polygon. A polygon is simple if it consists of only one simple polygon and is complex if it has at least one interior simple polygon.

[0129] In one embodiment, real-time map 105 follows certain conventions. For example, links will not cross themselves, and will not cross each other unless at a node. Moreover, there are no repeated shape points, nodes or links. Two links connected to each other have common nodes. In real-time map 105, overlapping geographical features are represented by overlapping polygons. When polygons overlap, the border of one polygon intersects with the border of another polygon. In real-time map 105, the position where the border of a polygon intersects with the border of another polygon is represented by a node. In one embodiment, in addition to the position where the border of a polygon intersects with the border of another polygon, nodes can be used to represent other positions along the border of a polygon. In one embodiment, shape points are not used to represent the point where the border of a polygon intersects with the border of another polygon.

[0130] As shown, the real-time map 105 includes: (1) a geographic layer 1303 for defining nodes, road segments, connections between them, and additional attributes; (2) a geometry layer 1305 for defining the geometry of map features such as roads, terrain features, geographic boundaries, etc.; (3) a POI layer 1307; (4) an activity data record layer 1309; (5) a quality indicator 1311; for example, other layers 1313. More, fewer, or different data layers may be provided. In one embodiment, additional data layers (not shown) may include cartographic ("carto") data records, routing data, and manipulation data.

[0131] In an exemplary embodiment, the geographic layer 1303 may include a segment data record, which stores data on a link or segment representing a road, street or path. This data may be used in a calculated route or recorded route information to determine one or more personalized routes. The geographic layer 1303 may also include a node data record, which stores endpoints corresponding to the corresponding link or segment of the segment data record. The road link data record and the node data record represent a road network, such as a road network used by a vehicle, a car, and / or other entity. Alternatively, in addition to or in place of the vehicle road record data, the real-time map 105 may include a path segment and a node data record or other data representing a walking path or area.

[0132] Road / link segments and nodes may be associated with attributes such as geographic coordinates, street names, address ranges, speed limits, turn restrictions at intersections, and other navigation-related attributes and POIs such as gas stations, hotels, restaurants, museums, stadiums, offices, car dealerships, car repair stations, buildings, stores, parks, etc. The real-time map 105 may include data about POIs and their corresponding locations in the POI layer 1307. The real-time map 105 may also include data about locations such as cities, towns, or other communities, and other geographic features such as bodies of water, mountains, etc. Such place or feature data may be part of the POI layer 1307, or may be associated with a POI data record (e.g., a data point used to display or represent a city location).

[0133] In one embodiment, the real-time map 105 may also include an activity data record layer 1309 for storing sensor activity definition parameters, sensor data requests, collective sensor data, and / or any other relevant data (e.g., change detection, detected map features, etc.). In one embodiment, the activity data record layer 1309 may be associated with a road link or a segment of a specified geographic area. In one embodiment, the activity data record layer 1309 may be associated with one or more node records, segment records of the geographic layer 1303 and / or the geometry layer 1305 or portions thereof (e.g., a segment smaller or different than the segment indicated in the segment record, individual lanes of the segment, etc.) to provide activity management to verify, discover, and / or update map data. In this way, activities associated with the activity data record layer 1309 may also be associated with features or metadata of the corresponding geographic layer 1303.

[0134] In one embodiment, the real-time map 105 may be maintained by a content provider (e.g., a map developer). The map developer may collect geographic data to generate and enhance the real-time map 105. The map developer may use different methods to collect data. These methods may include obtaining data from other sources (such as municipalities or corresponding geographic authorities). In addition, the map developer may hire field personnel to drive along roads throughout the geographic area to observe features and / or record information about them. In addition, remote sensing techniques such as aerial or satellite photography may be used.

[0135] In one embodiment, the real-time map 105 includes high-resolution or high-definition (HD) map data that provides centimeter-level or better map feature accuracy. For example, the real-time map 105 can be based on light detection and ranging (LiDAR) or equivalent technology to collect billions of 3D points and model the road surface and other map features, down to the lanes and their widths. In one embodiment, the HD map data captures and stores details such as the slope and curvature of the road, lane markings, roadside objects such as road signs (including what the road signs indicate). For example, HD map data enables highly automated vehicles to accurately position themselves on the road and determine road attributes (e.g., learned speed limit values) to a high degree of accuracy.

[0136] In one embodiment, the real-time map 105 is stored as a projection or structure based on a hierarchical or multi-level tile. More specifically, in one embodiment, the real-time map 105 can be defined according to a normalized Mercator projection. Other projections can be used. For example, a Mercator or similarly projected map tile grid is a multi-level grid. Each unit or tile in a certain level of the map tile grid can be divided into the same number of tiles in the grid of the same level. In other words, the initial level of the map tile grid (e.g., the level of the lowest zoom level) can be divided into four units or rectangles. Each of these units can be divided into four units, and so on, until the highest zoom or resolution level of the projection is reached.

[0137] In one embodiment, the map tile grid can be numbered in a systematic manner to define a tile identifier (tile ID). For example, the upper left tile can be numbered 00, the upper right tile can be numbered 01, the lower left tile can be numbered 10, and the lower right tile can be numbered 11. In one embodiment, each unit is divided into four rectangles and numbered by connecting the parent tile ID and the new tile position in series. There can also be multiple numbering schemes. Any number of levels with smaller and smaller geographical areas can represent a map tile grid. Any level (n) of the map tile grid has 2 (n+1) units. Accordingly, any tile at level (n) has a geographical area of ​​A / 2 (n+1), where A is the total geographical area of ​​the world or the total area of ​​the map tile grid 10. Due to the numbering system, the exact location of any tile in any level of the map tile grid or projection can be uniquely determined based on the tile ID. In one embodiment, the system 100 can identify a tile by a quadtree key determined based on the tile ID of the tile of the map tile grid. For example, a quadtree key is a one-dimensional array containing numerical values. In one embodiment, a quadtree key may be calculated or determined by interleaving the bits of the row and column coordinates of a tile in a grid at a particular level. The interleaved bits may be converted to a predetermined radix (e.g., radix 10, radix 4, hexadecimal). In one example, leading zeros are inserted or retained regardless of the level of the map tile grid so as to maintain a constant length for the one-dimensional array of quadtree keys. In another example, the length of the one-dimensional array of quadtree keys may indicate a corresponding level in the map tile grid 10. In one embodiment, a quadtree key is an example of a hash or encoding scheme for the respective geographic coordinates of a geographic data point, which may be used to identify the tile in which the geographic data point is located.

[0138] The real-time map 105 can be a master geographic database stored in a format that is conducive to updating, maintenance, and development. For example, the master geographic database or the data in the master geographic database has an Oracle spatial format or other spatial format, such as for the purpose of development or production. The Oracle spatial format or the development / production database can be compiled into a transmission format, such as a geographic data file (GDF) format. The data and / or transmission format in production can be compiled or further compiled to form a geographic database product or database, which can be used in an end-user navigation device or system.

[0139] For example, geographic data is compiled (e.g., converted to a platform specification format (PSF) format) to organize and / or configure data for performing navigation-related functions and / or services by a navigation device (e.g., by vehicle 103), such as route calculation, route guidance, map display, speed calculation, distance and travel time functions, and other functions. The navigation-related functions may correspond to vehicle navigation, pedestrian navigation, or other types of navigation. The compilation to produce the end-user database may be performed by a party or entity separate from the map developer. For example, a client of a map developer (such as a navigation device developer or other end-user device developer) may perform the compilation of a received graphical database in a transmission format to produce one or more compiled navigation databases.

[0140] The process described herein for providing a map data activity management platform can be advantageously implemented by software, hardware (e.g., a general purpose processor, a digital signal processing (DSP) chip, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc.), firmware, or a combination thereof. Such exemplary hardware for performing the described functions will be described in detail below.

[0141] Fig.14 A computer system 1400 is shown on which an embodiment of the present invention may be implemented. The computer system 1400 is programmed (e.g., by computer program code or instructions) to provide a map data activity management platform as described herein, and includes a communication mechanism such as a bus 1410 for transmitting information between other internal and external components of the computer system 1400. Information (also referred to as data) is represented as a physical representation of a measurable phenomenon, typically voltage, but in other embodiments includes phenomena such as magnetic, electromagnetic, pressure, chemical, biological, molecular, atomic, subatomic, and quantum interactions. For example, north and south magnetic fields or zero and non-zero voltages represent two states (0, 1) of a binary digit (bit). Other phenomena may represent digits of higher cardinality. A superposition of multiple simultaneous quantum states prior to measurement represents a quantum bit (qubit). One or more sequences of digits constitute digital data used to represent a character number or character code. In some embodiments, information referred to as analog data is represented by a near-continuous range of measurable values.

[0142] The bus 1410 includes one or more parallel information conductors to quickly transfer information between devices coupled to the bus 1410. One or more processors 1402 are coupled to the bus 1410 for processing information.

[0143] The processor 1402 performs a set of operations on information specified by a computer program code related to providing a map data activity management platform. The computer program code is a set of instructions or statements that provide instructions to the operation of the processor and / or computer system to perform specified functions. For example, the code can be written in a computer programming language and compiled into a native instruction set of the processor. The code can also be written directly using a native instruction set (e.g., machine language). The operation group includes introducing information from the bus 1410 and placing the information on the bus 1410. The operation group generally also includes comparing two or more information units, shifting information units, and combining two or more information units, such as by adding or multiplying or logical operations such as "OR", "XOR" and "AND". Each operation in the operation group that can be performed by the processor is represented to the processor by information called instructions (e.g., one or more digits of operation code). The sequence of operations (e.g., operation code sequence) performed by the processor 1402 constitutes a processor instruction, which is also called a computer system instruction or simply a computer instruction. Processors may be implemented as mechanical, electrical, magnetic, optical, chemical, or quantum components, alone or in combination.

[0144] The computer system 1400 also includes a memory 1404 coupled to the bus 1410. The memory 1404, such as a random access memory (RAM) or other dynamic storage device, stores information including processor instructions for providing a map data activity management platform. Dynamic memory allows information stored therein to be changed by the computer system 1400. RAM allows a unit of information stored at a location called a memory address to be stored and retrieved independently of information at neighboring addresses. The memory 1404 is also used by the processor 1402 to store temporary values ​​during the execution of processor instructions. The computer system 1400 also includes a read-only memory (ROM) 1406 or other static storage device coupled to the bus 1410, which is used to store static information including instructions that are not changed by the computer system 1400. Some memories include volatile memory, which loses information stored thereon when power is removed. Also coupled to bus 1410 is a non-volatile (persistent) storage device 1408, such as a magnetic disk, optical disk, or flash memory card, for storing information, including instructions, that persists even when computer system 1400 is turned off or otherwise loses power.

[0145] Information including instructions for providing a map data activity management platform is provided to the bus 1410 from an external input device 1412, such as a keyboard or sensor containing alphanumeric keys operated by a human user, for use by the processor. The sensor detects conditions around it and converts these detections into physical representations compatible with measurable phenomena that represent information in the computer system 1400. Other external devices coupled to the bus 1410, primarily for human interaction, include a display device 1414 such as a cathode ray tube (CRT) or liquid crystal display (LCD), or a plasma screen or printer for presenting text or images, and a pointing device 1416 such as a mouse or trackball or cursor direction keys, or a motion sensor, for controlling the position of a small cursor image presented on the display device 1414 and issuing commands related to graphical elements presented on the display device 1414. In some embodiments, for example, in embodiments where the computer system 1400 automatically performs all functions without human input, one or more of the external input device 1412, the display device 1414, and the pointing device 1416 may be omitted.

[0146] In the illustrated embodiment, special purpose hardware such as an application specific integrated circuit (ASIC) 1420 is coupled to bus 1410. Special purpose hardware is configured to perform operations that the processor 1402 cannot perform quickly for a specific purpose. Examples of special purpose ICs include: a graphics accelerator card for generating images for display device 1414; a cryptographic board for encrypting and decrypting messages sent over a network; speech recognition; and interfaces with special external devices, such as robotic arms and medical scanning devices, which repeatedly perform some complex sequence of operations that are more efficiently implemented in hardware.

[0147] The computer system 1400 also includes one or more instances of a communication interface 1470 coupled to the bus 1410. The communication interface 1470 provides one-way or two-way communication coupled to various external devices such as printers, scanners, and external disks, which operate using their own processors. Generally speaking, the coupling utilizes a network link 1478 connected to a local network 1480, where various external devices with their own processors are connected to the local network 1480. For example, the communication interface 1470 can be a parallel port or a serial port or a universal serial bus (USB) port on a personal computer. In some embodiments, the communication interface 1470 is an integrated services digital network (ISDN) card, a digital subscriber line (DSL) card, or a telephone modem that provides an information communication connection to a corresponding type of telephone line. In some embodiments, the communication interface 1470 is a cable modem for converting signals on the bus 1410 to signals for a communication connection through a coaxial cable, or to optical signals for a communication connection through an optical fiber cable. As another example, the communication interface 1470 can be a local area network (LAN) card for providing a data communication connection to a compatible LAN such as Ethernet. It can also be implemented as a wireless link. For wireless links, the communication interface 1470 sends or receives or both sends and receives electrical, acoustic or electromagnetic signals, including infrared and optical signals, that carry information streams such as digital data. For example, in wireless handheld devices such as mobile phones similar to cell phones, the communication interface 1470 includes a radio band electromagnetic transmitter and receiver known as a radio transceiver. In some embodiments, the communication interface 1470 enables connection to the communication network 113 for providing a map data activity management platform.

[0148] The term computer-readable medium used herein refers to any medium that participates in providing information including the inside of the execution instruction to the processor 1402. Such medium can take many forms, including but not limited to non-volatile media, volatile media and transmission media. Non-volatile media include, for example, optical disks or disks, such as storage devices 1408. Volatile media include, for example, dynamic memory 1404. Transmission media include, for example, coaxial cables, copper wires, optical cables, and carriers such as sound waves and electromagnetic waves (including radio waves, light waves and infrared waves) that are not transmitted through space using wires or cables. Signals include transient changes in amplitude, frequency, phase, polarization or other physical properties transmitted by transmission media. Computer-readable media in common forms include, for example, floppy disks, floppy disks, hard disks, magnetic tapes, any other magnetic media, CD-ROMs, CDRWs, DVDs, any other optical media, punch cards, paper tapes, optical markers, any other physical media with patterns of holes or other optically recognizable markers, RAMs, PROMs, EPROMs, FLASH-EPROMs, any other storage chips or cartridges, carriers or any other medium that is computer-readable.

[0149] Fig.15 A chip set 1500 is shown on which embodiments of the present invention may be implemented. The chip set 1500 is programmed to provide a map data activity management platform as described herein and includes, for example, reference 1500 incorporated in one or more physical packages (eg, chips). Fig.14 As an example, physical packaging includes the arrangement of one or more materials, components and / or circuits on a structural assembly (e.g., a substrate) to provide one or more characteristics, such as physical strength, size conservation, and / or limitation of electrical interactions. It is contemplated that in some embodiments, a chipset may be implemented in a single chip.

[0150] In one embodiment, the chipset 1500 includes a communication mechanism such as a bus 1501 for transmitting information between components of the chipset 1500. The processor 1503 has connectivity with the bus 1501 to execute instructions and process information stored in the memory 1505, for example. The processor 1503 may include one or more processing cores, each of which is configured to execute independently. A multi-core processor is capable of multi-processing in a single physical package. Examples of multi-core processors include dual-core, quad-core, octa-core or more processor cores. Alternatively or in addition, the processor 1503 may include one or more microprocessors configured to be connected in series via the bus 1501 to be able to independently execute instructions, pipelines and multithreading. The processor 1503 may also be provided with one or more dedicated components to perform certain processing functions and tasks, such as one or more digital signal processors (DSPs) 1507 or one or more application specific integrated circuits (ASICs) 1509. The DSP 1507 is typically configured to process real-world signals (e.g., sound) in real time independently of the processor 1503. Likewise, ASIC 1509 can be configured to perform specialized functions that are not possible to be performed by a general purpose processor. Other specialized components that aid in performing the inventive functions described herein include one or more field programmable gate arrays (FPGAs) (not shown), one or more controllers (not shown), or one or more other specialized computer chips.

[0151] The processor 1503 and accompanying components are connected to the memory 1505 via the bus 1501. The memory 1505 includes dynamic memory (e.g., RAM, magnetic disk, writable optical disk, etc.) and static memory (e.g., ROM, CD-ROM, etc.) to store executable instructions, which, when executed, perform the inventive steps described herein to provide a map data activity management platform. The memory 1505 also stores data associated with the execution of the inventive steps or data generated by the execution of the inventive steps.

[0152] Fig.16 According to one embodiment, Figure 11600 is a diagram of exemplary components of a mobile terminal (e.g., a mobile phone) operating in a system of FIG. 1601 . In general, a radio receiver is generally defined in terms of front-end and back-end characteristics. The front end of the receiver includes all radio frequency (RF) circuits, while the back end includes all baseband processing circuits. The relevant internal components of the phone include a main control unit (MCU) 1603, a digital signal processor (DSP) 1605, and a receiver / transmitter unit including a microphone gain control unit and a speaker gain control unit. Display 1607 provides a display for the user to support various applications and mobile station functions that provide automatic contact matching. Audio function circuit 1609 includes a microphone 1611 and a microphone amplifier that amplifies the voice signal output of microphone 1611. The amplified voice signal output from microphone 1611 is fed to a coder / decoder (CODEC) 1613.

[0153] The radio section 1615 performs power amplification and frequency conversion to communicate with a base station included in the mobile communication system via an antenna 1617. A power amplifier (PA) 1619 and a transmitter / modulation circuit are operatively responsive to the MCU 1603, wherein the output of the PA 1619 is coupled to a duplexer 1621 or a circulator or an antenna switch as is known in the art. The PA 1619 is also coupled to a battery interface and power control unit 1620.

[0154] In use, the user of mobile station 1601 speaks to microphone 1611, and his or her voice is converted into an analog voltage together with any detected background noise. The analog voltage is then converted into a digital signal by analog-to-digital converter (ADC) 1623. Control unit 1603 routes the digital signal to DSP 1605 to perform the following speech coding, channel coding, encryption and interleaving therein. In one embodiment, a cellular transmission protocol (such as global evolution (EDGE), general packet radio service (GPRS), global mobile communication system (GSM), Internet protocol multimedia subsystem (IMS), universal mobile telecommunication network (UMTS), etc.) and any other suitable wireless medium (such as microwave access (WiMAX), long term evolution (LTE) network, code division multiple access (CDMA), wireless fidelity (WiFi), satellite, etc.) is used to encode the processed speech signal by a unit not shown separately.

[0155] The coded signal is then routed to an equalizer 1625 to compensate for any frequency-related losses, such as phase and amplitude distortion, that occur during transmission over the air. After equalizing the bit stream, the modulator 1627 combines the signal with an RF signal generated by an RF interface 1629. The modulator 1627 generates a sine wave by frequency or phase modulation. To prepare the signal for transmission, the up-converter 1631 combines the modulator 1627 sine wave output with another sine wave generated by a synthesizer 1633 to achieve the desired transmission frequency. The signal is then sent through PA1619 to increase the signal to an appropriate power level. In a practical system, PA1619 is a variable gain amplifier whose gain is controlled by DSP 1605 based on information received from a network base station. The signal is then filtered in the duplexer 1621 and optionally sent to an antenna coupler 1635 for compensation matching to provide maximum power transmission. Finally, the signal is sent to a local base station via antenna 1617. An automatic gain control (AGC) can be provided to control the gain of the final stage of the receiver. From there the signal may be forwarded to a remote telephone, which may be another cellular telephone, other mobile phone, or a landline connected to the Public Switched Telephone Network (PSTN) or other telecommunications network.

[0156] The voice signal transmitted to the mobile station 1601 is received by the antenna 1617 and immediately amplified by the low noise amplifier (LNA) 1637. The down converter 1639 reduces the carrier frequency, and the demodulator 1641 removes the RF, leaving only the digital bit stream. The signal then passes through the equalizer 1625 and is processed by the DSP 1605. The digital-to-analog converter (DAC) 1643 converts the signal and sends the resulting output to the user through the speaker 1645, all under the control of the main control unit (MCU) 1603, which can be implemented as a central processing unit (CPU) (not shown).

[0157] MCU 1603 receives various signals including the internal signals input from keyboard 1647. Keyboard 1647 and / or MCU1603 are combined with other user input components (e.g., microphone 1611) to include a user interface circuit for managing user input. MCU 1603 runs user interface software to assist users in controlling at least some functions of mobile station 1601 to provide a map data activity management platform. MCU 1603 also transmits display commands and switching commands to display 1607 and voice output switching controller respectively. In addition, MCU 1603 exchanges information with DSP 1605, and can access SIM card 1649 and memory 1651 optionally combined. In addition, MCU 1603 performs various control functions required by the station. Depending on the implementation, DSP 1605 can perform any function in a variety of conventional digital processing functions to voice signals. In addition, DSP 1605 determines the background noise level of the local environment based on the signals detected by microphone 1611 and sets the gain of microphone 1611 to a selected level to compensate for the natural tendencies of the user of mobile station 1601.

[0158] CODEC 1613 includes ADC 1623 and DAC 1643. Memory 1651 stores various data including incoming audio data, and can store other data including replacing music data received from the global Internet network, for example. The software module can reside in RAM memory, flash memory, registers, or any other form of writable computer-readable storage medium known in the art including non-transitory computer-readable storage medium. For example, memory 1651 can be, but is not limited to, a single memory, CD, DVD, ROM, RAM, EEPROM, optical storage, or any other non-volatile or non-transitory storage medium capable of storing digital data.

[0159] The optionally incorporated SIM card 1649 carries important information such as the cellular phone number, services provided by the operator, subscription details, and security information. The SIM card 1649 primarily serves to identify the mobile station 1601 on the radio network. The SIM card 1649 also includes memory for storing a personal phone number registry, text messages, and user-specific mobile station settings.

[0160] Although the present invention has been described in conjunction with many embodiments and implementations, the present invention is not limited thereto, but covers various obvious modifications and equivalent arrangements that fall within the scope of the appended claims. Although the features of the present invention are expressed as specific combinations between the claims, it is expected that these features can be arranged in any combination and order.

Claims

1. A method of using a campaign management platform to discover undiscovered geographic areas, include: Determining, by the activity management platform, a geographical area in which no known road segment is displayed in the geographical database, a geographical area in which the number of known road segments is below a first threshold, or a geographical area in which the probability of no road segment being found is above a second threshold; generating a sensor data request specifying a sensor data collection event to be performed within the geographic area, wherein the sensor data collection event is part of an activity to discover digital map data for the geographic area; sending the sensor data request to a plurality of vehicles, wherein upon receiving the sensor data request, the plurality of vehicles execute the sensor data collection event in the geographic area to collect sensor data, wherein the sensor data request specifies collecting vehicle posture path data as the sensor data, wherein the vehicle posture path data specifically represents a time-ordered sequence of location points associated with vehicle travel; receiving the sensor data collected from the plurality of vehicles in response to the sensor data request; processing the sensor data to generate digital map data for the geographic area, processing the vehicle posture path data to identify driving characteristics within the geographic area, wherein the digital map data is generated based on the driving characteristics and confirming that the driving characteristics correspond to road segments within the geographic area; and The digital map data is updated by initiating an update activity based on the identification of the driving characteristics to collect additional sensor data for the road segment, the geographical area, or a combination thereof.

2. The method according to claim 1, in, The additional sensor data includes data related to lane markings, signs, poles, and traffic signals.

3. A device for using an activity management platform to discover undiscovered geographic areas, include: at least one processor; as well as at least one memory including computer program code for one or more programs, The at least one memory and the computer program code are configured to, together with the at least one processor, cause the apparatus to at least perform the following operations, including: Determining, by the activity management platform, a geographical area in which no known road segment is displayed in the geographical database, a geographical area in which the number of known road segments is below a first threshold, or a geographical area in which the probability of no road segment being found is above a second threshold; generating a sensor data request specifying a sensor data collection event to be performed within the geographic area, wherein the sensor data collection event is part of an activity to discover digital map data for the geographic area; sending the sensor data request to a plurality of vehicles, wherein upon receiving the sensor request, the plurality of vehicles execute the sensor data collection event in the geographic area to collect sensor data, wherein the sensor data request specifies collecting vehicle posture path data as the sensor data, wherein the vehicle posture path data specifically represents a time-ordered sequence of position points associated with vehicle travel; receiving the sensor data collected from the plurality of vehicles in response to the sensor data request; processing the sensor data to generate digital map data for the geographic area, processing the vehicle posture path data to identify driving characteristics within the geographic area, wherein the digital map data is generated based on the driving characteristics and confirming that the driving characteristics correspond to road segments within the geographic area; and The digital map data is updated by initiating an update activity based on the identification of the driving characteristics to collect additional sensor data for the road segment, the geographical area, or a combination thereof.

4. The device as claimed in claim 3, in, The additional sensor data includes data related to lane markings, signs, poles, and traffic signals.

5. A non-transitory computer-readable storage medium for discovering undiscovered geographic areas using an activity management platform, carrying one or more sequences of one or more instructions that, when executed by one or more processors, cause an apparatus to: Determining, by the activity management platform, a geographical area in which no known road segment is displayed in the geographical database, a geographical area in which the number of known road segments is below a first threshold, or a geographical area in which the probability of no road segment being found is above a second threshold; generating a sensor data request specifying a sensor data collection event to be performed within the geographic area, wherein the sensor data collection event is part of an activity to discover digital map data for the geographic area; Sending a sensor data request to a plurality of vehicles, wherein upon receiving the sensor request, the plurality of vehicles execute the sensor data collection event in the geographic area to collect sensor data, wherein the sensor data request specifies collecting vehicle posture path data as the sensor data, wherein the vehicle posture path data specifically represents a time-ordered sequence of location points associated with vehicle travel; receiving the sensor data collected from the plurality of vehicles in response to the sensor data request; processing the sensor data to generate digital map data for the geographic area, processing the vehicle posture path data to identify driving characteristics within the geographic area, wherein the digital map data is generated based on the driving characteristics and confirming that the driving characteristics correspond to road segments within the geographic area; and The digital map data is updated by initiating an update activity based on the identification of the driving characteristics to collect additional sensor data for the road segment, the geographical area, or a combination thereof.

6. The non-transitory computer-readable storage medium of claim 5, in, The additional sensor data includes data related to lane markings, signs, poles, and traffic signals.

Images