Offline road violation photographing early warning method and system, electronic equipment and computer readable medium

Abstract

The invention provides an off-line road violation photographing early warning method and system, electronic equipment and a readable medium, and belongs to the field of intelligent driving. Alarm data containing longitude and latitude are pre-stored locally; acquiring longitude and latitude information of the current position; converting the acquired longitude and latitude into hash values; locally matching a hash matrix corresponding to the alarm data according to the hash value; according to the method, an algorithm for retrieving a large amount of data is optimized, the alarm data are processed in advance, the alarm data are converted into two-dimensional data through the Hash algorithm to be stored locally, the index address of each data block is stored, and therefore the data retrieval efficiency is improved. In the data retrieval process, whether the current data block meets the requirement or not can be judged only by retrieving the index value of each data block, and compared with a common binary search method, the efficiency is greatly improved.

Description

Technical Field

[0001] This invention relates to the field of intelligent driving technology, and in particular to an offline road violation photography and early warning method, system, electronic device, and computer-readable medium. Background Technology

[0002] With the increasing prevalence of vehicles, many novice drivers encounter various speeding violations and traffic camera violations. Therefore, early warning functions have become crucial. Currently, this mainly relies on the warning function built into mobile phone maps. However, the navigation and warning functions integrated into mobile phones make voice broadcasts very complex and the user experience poor. Furthermore, this function depends on mobile networks, and its real-time performance is not ideal in areas with poor signal. Therefore, implementing offline warnings is necessary. Integrating this function into the vehicle's infotainment system presents a challenge because the performance of vehicle infotainment chips generally lags behind that of mobile phones, and their iteration is slower. The focus of offline warning algorithms is to reduce the CPU usage of the vehicle's infotainment system and reduce the cost of local data storage. Therefore, efficient data storage, algorithm optimization, and secure data access are the key issues that this technology aims to address. Summary of the Invention

[0003] The present invention aims to solve at least one of the technical problems existing in the prior art, and proposes an offline road violation photography warning method, system, electronic device and computer-readable medium.

[0004] In a first aspect, embodiments of the present invention provide an offline method for issuing early warnings of traffic violations via photography, which includes the following steps:

[0005] Alarm data, including longitude and latitude, is pre-stored locally;

[0006] Obtain the longitude and latitude information of the current location;

[0007] Convert the obtained longitude and latitude into hash values;

[0008] The hash value is used to match the hash matrix corresponding to the alarm data locally;

[0009] Road alarm information is obtained based on the matched hash matrix.

[0010] In some of these embodiments,

[0011] The step of pre-storing the hash-processed alarm data locally specifically includes:

[0012] The alarm data is converted into a hash matrix using a hash algorithm and stored locally. The converted longitude and latitude values ​​are defined as geoCode, which is the index of the corresponding hash matrix. The geoCode of each alarm data is saved to the local index table GeoTable.

[0013] In some of these embodiments,

[0014] The step of converting the acquired longitude and latitude into hash values ​​specifically includes:

[0015] The obtained longitude and latitude are converted into two dimensions, and the geoCode corresponding to the current location is obtained.

[0016] In some of these embodiments,

[0017] The step of matching the hash value with the corresponding hash matrix of the alarm data locally specifically includes:

[0018] The geoCode of the current location, converted from longitude to latitude, is matched with the pre-stored geoCode in the GeoTable using a binary search method.

[0019] In some embodiments, the alarm data includes longitude, latitude, direction, angle, and speed limit.

[0020] In some embodiments, when pre-storing alarm data, the floating-point numbers of the alarm data are converted into integers, and the data of direction, angle, and speed limit are all divided by two.

[0021] In some embodiments, road alarm information matching a hash matrix is ​​played aloud.

[0022] Secondly, embodiments of the present invention provide an offline road violation photography and early warning system, comprising:

[0023] The storage module is used to pre-store alarm data, including longitude and latitude, locally;

[0024] The location acquisition module is used to obtain the longitude and latitude information of the current location;

[0025] A conversion module is used to convert the longitude and latitude into hash values;

[0026] The matching module is used to match the hash value converted in the conversion module with the hash matrix corresponding to the alarm data in the storage module;

[0027] The early warning module is used to obtain corresponding alarm data based on the hash matrix matched in the matching module.

[0028] Thirdly, embodiments of the present invention provide an electronic device, including:

[0029] One or more processors;

[0030] Memory, used to store one or more programs;

[0031] When the one or more programs are executed by the one or more processors, the one or more processors implement any of the methods.

[0032] Fourthly, embodiments of the present invention also provide a computer-readable medium storing a computer program, which, when executed by a processor, implements the steps of any of the methods described.

[0033] The offline road violation photo warning method provided by this invention pre-stores alarm data containing longitude and latitude locally; obtains the longitude and latitude information of the current location; converts the obtained longitude and latitude into hash values; matches the hash values ​​with the hash matrix corresponding to the alarm data locally; and obtains road alarm information based on the matched hash matrix. This invention optimizes the algorithm for retrieving large amounts of data by pre-processing the alarm data, converting it into two-dimensional data stored locally using a hash algorithm, and saving the index address of each data block. When retrieving data, it is only necessary to search the index value of each data block to determine whether the current data block meets the requirements, which greatly improves efficiency compared to the general binary search method. Attached Figure Description

[0034] Figure 1 This is a flowchart illustrating the steps of an embodiment of the offline road violation photography and early warning method of the present invention;

[0035] Figure 2 This is a flowchart illustrating the steps of an embodiment of the present invention for converting longitude and latitude into hash values;

[0036] Figure 3 This is a flowchart illustrating the steps of an embodiment of the present invention, which involves matching hash values ​​with a hash value data matrix.

[0037] Figure 4 This is a flowchart illustrating the steps of an embodiment of the present invention for converting a hash value into a geocoded value;

[0038] Figure 5 This is a schematic diagram of the structure of an embodiment of the offline road violation photography and early warning system provided by the present invention;

[0039] Figure 6 This is a schematic diagram of the structure of an embodiment of the electronic device of the present invention. Detailed Implementation

[0040] To enable those skilled in the art to better understand the technical solutions of the present invention, exemplary embodiments of the present invention are described below in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0041] Where there is no conflict, the various embodiments of the present invention and the features thereof may be combined with each other.

[0042] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0043] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0044] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having the meaning consistent with their meaning in the context of the relevant art and the invention, and will not be interpreted as having an idealized or overly formal meaning unless expressly so defined herein.

[0045] In the technical solution of this invention, the collection, storage, use, processing, transmission, provision, and disclosure of user personal information all comply with relevant laws and regulations and do not violate public order and good morals. The use of user data in this technical solution follows relevant national laws and regulations (e.g., the "Information Security Technology - Personal Information Security Specification"). For example: appropriate measures are taken for personal information access control; restrictions are imposed on the display of personal information; the purpose of using personal information does not exceed the scope of direct or reasonable association; and explicit identity targeting is eliminated when using personal information to avoid precisely locating a specific individual.

[0046] In related technologies, existing technologies mainly rely on the chip's computing power to forcefully retrieve alarm information by traversing the database. This is highly dependent on chip performance and lacks optimized data retrieval algorithms. At the same time, due to considerations of data security and commercial interests, existing solutions store all data in the cloud. The terminal needs to obtain alarm information from the cloud via a mobile network, and network latency is an unstable factor, making it unreliable in areas with poor signal. In addition, due to the scalability of cloud storage, optimizing storage space is not a priority, and therefore there is no good data compression storage technology.

[0047] To address at least one of the technical problems existing in the aforementioned related technologies, the present invention provides an offline road violation photography and early warning method. Figure 1 This is a schematic diagram of an offline road violation photo warning method provided in an embodiment of the present invention.

[0048] like Figure 1 As shown, the offline road violation photo warning method includes the following steps S10 to S40. The implementation of each step is described in detail below.

[0049] Step S10: Pre-store the alarm data containing longitude and latitude locally.

[0050] It should be noted that alarm data collected in existing technologies is typically stored in the cloud for commercial solutions, thus preventing offline operation. Local data storage, however, enables offline operation. The locally stored alarm data provided in this application generally includes longitude, latitude, direction, angle, and speed limit.

[0051] Furthermore, the step of pre-storing the hashed alarm data locally specifically includes: converting the alarm data into a hash matrix using a hash algorithm and pre-storing it locally; defining the converted longitude and latitude values ​​as geoCode, where geoCode is the index of the corresponding hash matrix; and saving the geoCode of each alarm data conversion to the local index table GeoTable.

[0052] Understandably, since longitude and latitude are floating-point numbers, they need to be converted into a discrete value (geoCode) that can be used for indexing. Typically, a geographic area can be divided into grids, with each grid having a unique code (geoCode). For example, a grid with a certain precision can be used (e.g., 0.001 degrees per grid), and then latitude and longitude coordinates can be mapped to the corresponding grids; the grid's code is the geoCode.

[0053] A hash matrix is ​​actually a dictionary with keys that are geoCode (which can be a string or an integer representing grid coordinates) and values ​​that are a list storing alarm data (or alarm data IDs).

[0054] The GeoTable records the geoCode corresponding to each alarm data. This table can be a simple list or array, where each element is a geoCode (corresponding one-to-one with the alarm data). Alternatively, if each alarm data already has a unique identifier (such as an ID), then the GeoTable can be a mapping: alarm data ID -> geoCode, allowing us to quickly locate its position in the hash matrix using the alarm data ID. It's understandable that when pre-storing alarm data, certain floating-point number segments need to be converted to integers, and values ​​such as direction, angle, and speed limit need to be divided by two (i.e., divided by 2 and then rounded down or stored). The purpose of this is to compress data storage space while maintaining a certain level of precision.

[0055] Step S20: Obtain the longitude and latitude information of the current location.

[0056] In this embodiment, the step of obtaining longitude and latitude information specifically includes the following steps: receiving satellite signals through the vehicle-mounted GPS module to obtain three-dimensional location and time, wherein the three-dimensional location includes longitude, latitude, elevation and time.

[0057] For example, the vehicle GPS module can be a GPS / BeiDou dual-mode chip (such as U-blox NEO-M9N) or a vehicle antenna.

[0058] Step S30: Convert the obtained longitude and latitude into hash values.

[0059] In this embodiment, converting the obtained longitude and latitude into hash values ​​specifically includes: performing a two-dimensional conversion on the obtained longitude and latitude, and obtaining the geoCode corresponding to the current location.

[0060] Please see Figure 2 Specifically, converting the longitude and latitude into hash values ​​includes the following steps:

[0061] Step S21. Determine the coordinate range:

[0062] Longitude range: [-180, 180]

[0063] Latitude range: [-90, 90]

[0064] Step S22. Alternating binary segmentation:

[0065] The binary search is performed alternately in the order of longitude, latitude, longitude, latitude... Each binary search generates one bit (0 or 1). The specific process is as follows:

[0066] Divide the longitude interval into two equal parts. If the target longitude is in the left half of the interval, record it as 0; if it is in the right half, record it as 1. Then divide the latitude interval into two equal parts, and record it as 0 or 1 depending on whether the target latitude is on the left or right. Then continue to divide the longitude interval into two parts, and repeat this process alternately.

[0067] Step S23. Merge the bits and convert to Base32 encoding:

[0068] Every 5 binary splits (resulting in 5 bits) form a binary number (5 bits, range 0-31), then the Base32 encoding table (removing a, i, l, o from 0-9 and bz) is used to convert it into a character. Base32 encoding table: `0123456789bcdefghjkmnpqrstuvwxyz`

[0069] Step S24. Repeat until the desired accuracy is achieved.

[0070] For example: convert coordinates (116.3906, 39.92324) to Geohash.

[0071] 1. Initialize longitude range: [-180, 180], latitude range: [-90, 90].

[0072] 2. Longitude 116.3906:

[0073] Between [-180,0) and [0,180], 116.3906>0, so we take the right half of the interval [0,180] and denote it as 1.

[0074] Divide [0,180] into [0,90] and [90,180]. Since 116.3906 > 90, take the right half of the interval [90,180] and denote it as 1.

[0075] Continue to divide [90,180] into [90,135] and [135,180]. Since 116.3906 < 135, take the left half of the interval [90,135] and record it as 0.

[0076] ... (Alternating)

[0077] 3. Latitude 39.92324:

[0078] Between [-90, 90], 39.92324 > 0, so we take the right half of the interval [0, 90] and denote it as 1.

[0079] Divide [0,90] into [0,45] and [45,90]. Since 39.92324 < 45, take the left half of the interval [0,45] and denote it as 0.

[0080] ... (Alternating)

[0081] 4. After alternating steps, the resulting binary sequence is: 11010 01011 ... (40 bits in total, grouped into sets of 5).

[0082] 5. Convert to Base32: The first 5 bits are binary 11010 → 26 → corresponding to the 26th character ('w') in the Base32 table. The rest follows the same logic.

[0083] The final Geohash string is: `wx4g0`.

[0084] It should be noted that Geohash is a public domain algorithm proposed by Gustavo Niemeyer in 2008, which encodes two-dimensional latitude and longitude coordinates into a string. Its core idea is to divide the Earth into a grid, with each grid represented by a string; the longer the string, the more precise the grid representation.

[0085] Step S40: Match the hash value with the hash matrix corresponding to the alarm data locally.

[0086] In this embodiment, the step of matching the hash matrix corresponding to the alarm data locally based on the hash value specifically includes: using a binary search method to match the geoCode converted from the current location's longitude and latitude to the pre-stored geoCode in the index table GeoTable.

[0087] Specifically, please refer to Figure 3 Specifically, it includes the following steps S41 to S43, and the implementation of each step is explained in detail below.

[0088] Step S41: Convert the geoCode according to the hash value.

[0089] In this embodiment, the step of converting the hash value to geoCode specifically includes using the Geohash algorithm to generate a fixed-length string from the hash value, which is the geocoded value.

[0090] Please see Figure 4 Here is a flowchart of the steps for converting the hash value into geoCode, including:

[0091] 1. Beginning: Raw data (latitude and longitude points).

[0092] 2. Complete data discretization: This indicates that several steps have been completed and the next step is now being performed.

[0093] 3. Determine if the discrete depth i is 0?

[0094] 4. Longitude step: Update the longitude range [MinY, MaxY] (initially [-180, 180]), and calculate CompY = (MinY + MaxY) / 2.

[0095] Determine if the longitude of a data point is greater than CompY.

[0096] If longitude <= CompY, then the condition is true (execute update MaxY=CompY); otherwise, it is false (execute update MinY=CompY).

[0097] 5. Latitude steps:

[0098] Update the latitude range [MinX, MaxX] (initially [-90, 90]), and calculate CompX = (MinX + MaxX) / 2.

[0099] How do I determine if the latitude of a data point is greater than CompX?

[0100] If greater than, then execute: n<=1; n | = 0<=0 -> Update MinX=CompX

[0101] Otherwise, execute: n<=1; n | = 1<=0; -> Update MaxX=CompX.

[0102] It should be noted that the algorithm for matching hash data matrices is based on the premise of using a two-dimensional data discretization algorithm to package all data into a specific format. The specific format is shown in the table below:

[0103]

[0104] The geoCode and the number of block data are combined to form a data index. These indexes are then stored in an index table named GeoTable. This table is ordered and can be used for binary search with a time complexity of O(logn). Therefore, all data can be traversed by only searching this data index table, which greatly improves efficiency.

[0105] Specifically, taking latitude and longitude 19.9305, 54.6825 as an example, the data after two-dimensional transformation is 10001100101010011, named geoCode. The advantage of this algorithm is that it uses displacement algorithms to process data, which is highly efficient. The number of bits in the transformation can be controlled by the value of the input parameter deep. In this example, deep=9. The core idea of ​​this algorithm is to compare the latitude and longitude values ​​using a binary search method and then combine them into a single value. The meaning of the geoCode value is to represent the index of all data in this area. The value of deep can be adjusted according to the size of the map range. With the above meaning, MinX = 10; MaxX = 160; MinY = 0; MaxY = 80. This area is based on a map of Russia, with a longitude range of [10, 160] and a latitude range of [0, 80]. Therefore, the smallest range is approximately a square area of ​​3 kilometers. Thus, the data processed by this algorithm can be distributed within a square area of ​​3 kilometers to complete the two-dimensional transformation of the data, and then managed by region.

[0106] Step S42: Construct an index table containing an ordered list of all geographic regions that need to be monitored. Each geographic region is represented by a geocode value, and the sequence list is sorted in lexicographical order according to the geocode values.

[0107] To understand this, we construct an index table (GeoTable), which is an ordered list containing all the geographical areas that need to be monitored (each area is represented by a geoCode, such as a Geohash string). This list must be sorted lexicographically by the geoCodes to facilitate subsequent binary search. Each geoCode corresponds to an alarm data storage location in the GeoTable (such as a pointer, index, or file path) for fast alarm data retrieval.

[0108] For example, suppose we have multiple areas that need to be monitored, each represented by a fixed-length (e.g., 5-digit) geohash. We collect all these 5-digit geohash strings, remove duplicates, and sort them lexicographically to build an ordered list (array). Simultaneously, each geohash is associated with an alarm data identifier (such as the alarm data's index in the array, file path, or database ID).

[0109] Step S43: Use binary search to match the geocode value in the location data table and determine whether the match is successful. If yes, proceed to the next step; otherwise, return to the previous step.

[0110] Understandably, since the GeoTable is sorted, binary search can be used for fast retrieval. It's important to note that a complete match may not be necessary, as a single geoCode might correspond to regions with varying degrees of precision. For example, prefix matching can be used: checking if there's an item in the GeoTable with the same prefix (e.g., the first 5 characters) as the current geoCode. Therefore, when constructing the GeoTable, a fixed-length geoCode (e.g., 5 characters) might be stored, while the real-time calculated geoCode might be a longer string (e.g., 8 characters). During matching, we only use the first 5 characters. If the binary search succeeds (finding the corresponding geoCode prefix in the GeoTable), the corresponding alarm data is read from the matched record. Alarm data might be stored in an in-memory database, a file, or a remote server. The reading method depends on the system design. If the binary search does not find a matching geoCode, it means there is no alarm data in the current region, and the process ends.

[0111] Step S50: Obtain road alarm information based on the matched hash value data matrix.

[0112] In this embodiment, in the step of obtaining road alarm information based on the hash value data matrix, each geocoding value corresponds to an alarm data storage location in the location data table, which is used to quickly read alarm data. The alarm data storage location includes a pointer, index, or file path.

[0113] It is understood that in this embodiment, the hash value is converted into a geocoded value, a location data table is constructed, a binary search method is used to match the geocoded value in the location data table, and a successful match is determined. Alarm data is then directly accessed and read via a dictionary. If there are many monitoring areas, more advanced data structures, such as a trie or spatial index, can be considered. If alarm data changes frequently, the GeoTable and alarm data can be separated. The GeoTable stores the region identifier (which remains unchanged), while the alarm data can be updated independently (e.g., through a memory-mapped file or database).

[0114] In some embodiments, the following step S60 is also included: playing the road alarm information of the matching hash matrix by voice.

[0115] It should be noted that the compression of alarm data requires a combination of data simplification and two-dimensional discretization. The data simplification is implemented as follows: Key information of alarm data includes: longitude, latitude, direction, angle, and speed limit; the value range of each value is as follows: longitude: [0, 180.0000], latitude: [0, 90.0000], direction, angle, and speed limit: [0-360]. The above floating-point numbers will be converted into integers, for example, 123.1234 -> 1231234. The direction, angle, and speed limit are all divided by two, which can save half the space. In addition, the original data will be encrypted after being packaged and compressed to ensure data security.

[0116] It is understandable that, given the large volume of alarm data, data compression and storage facilitates local storage. Data compression algorithms can compress the original data by more than half.

[0117] The offline road violation photo warning method provided by this invention optimizes the algorithm for retrieving large amounts of data. By preprocessing alarm data, the alarm data is converted into two-dimensional data stored locally through a hash algorithm, and the index address of each data block is saved. When retrieving data, it is only necessary to retrieve the index value of each data block to determine whether the current data block meets the requirements, which greatly improves efficiency compared with the general binary search method.

[0118] Furthermore, the offline road violation photography warning method provided by this invention relies on the early warning of speed limits and the collection of alarm data in advance. It can work offline by using locally stored data. As for data security, it can be ensured by encrypting the data and performing two-way authentication for data access. This avoids the shortcomings of existing commercial solutions on the market, which all rely on cloud storage and therefore cannot work offline.

[0119] The present invention also provides an offline road violation photography and early warning system. Figure 5 This is a schematic diagram of an offline road violation photography and early warning system provided in an embodiment of the present invention. It is applied to the offline road violation photography and early warning method provided in the above embodiment, and specifically includes:

[0120] Storage module 51 is used to pre-store alarm data containing longitude and latitude locally.

[0121] It should be noted that alarm data collected in existing technologies is typically stored in the cloud for commercial solutions, thus preventing offline operation. Local data storage, however, enables offline operation. The locally stored alarm data provided in this application generally includes longitude, latitude, direction, angle, and speed limit.

[0122] Furthermore, the step of pre-storing the hashed alarm data locally specifically includes: converting the alarm data into a hash matrix using a hash algorithm and pre-storing it locally; defining the converted longitude and latitude values ​​as geoCode, where geoCode is the index of the corresponding hash matrix; and saving the geoCode of each alarm data conversion to the local index table GeoTable.

[0123] Understandably, since longitude and latitude are floating-point numbers, they need to be converted into a discrete value (geoCode) that can be used for indexing. Typically, a geographic area can be divided into grids, with each grid having a unique code (geoCode). For example, a grid with a certain precision can be used (e.g., 0.001 degrees per grid), and then latitude and longitude coordinates can be mapped to the corresponding grids; the grid's code is the geoCode.

[0124] A hash matrix is ​​actually a dictionary with keys that are geoCode (which can be a string or an integer representing grid coordinates) and values ​​that are a list storing alarm data (or alarm data IDs).

[0125] The GeoTable records the geoCode corresponding to each alarm data. This table can be a simple list or array, where each element is a geoCode (corresponding one-to-one with the alarm data). Alternatively, if each alarm data already has a unique identifier (such as an ID), then the GeoTable can be a mapping: alarm data ID -> geoCode, allowing us to quickly locate its position in the hash matrix using the alarm data ID. It's understandable that when pre-storing alarm data, certain floating-point number segments need to be converted to integers, and values ​​such as direction, angle, and speed limit need to be divided by two (i.e., divided by 2 and then rounded down or stored). The purpose of this is to compress data storage space while maintaining a certain level of precision.

[0126] The data acquisition module 52 is used to obtain the longitude and latitude information of the current location.

[0127] It should be noted that existing alarm data collected in commercial solutions is typically stored in the cloud, making offline operation impossible. Local data storage, however, enables offline operation. The locally stored alarm data provided in this application generally includes fields such as address, timestamp, alarm type, device ID, and alarm content.

[0128] In this embodiment, the location acquisition module 52 receives satellite signals through the vehicle-mounted GPS module to obtain three-dimensional location and time. The three-dimensional location includes longitude, latitude, elevation, and time. For example, the vehicle-mounted GPS module can be a GPS / BeiDou dual-mode chip (such as U-blox NEO-M9N) or a vehicle-mounted antenna.

[0129] The conversion module 53 is used to convert the acquired longitude and latitude into hash values.

[0130] In this embodiment, converting the obtained longitude and latitude into hash values ​​specifically includes: performing a two-dimensional conversion on the obtained longitude and latitude, and obtaining the geoCode corresponding to the current location.

[0131] The matching module 54 is used to match the hash value with the hash matrix corresponding to the alarm data locally.

[0132] In this embodiment, the step of matching the hash matrix corresponding to the alarm data locally based on the hash value specifically includes: using a binary search method to match the geoCode converted from the current location's longitude and latitude to the pre-stored geoCode in the index table GeoTable.

[0133] Understandably, since the GeoTable is sorted, binary search can be used for fast retrieval. It's important to note that a complete match may not be necessary, as a single geoCode might correspond to regions with varying degrees of precision. For example, prefix matching can be used: checking if there's an item in the GeoTable with the same prefix (e.g., the first 5 characters) as the current geoCode. Therefore, when constructing the GeoTable, a fixed-length geoCode (e.g., 5 characters) might be stored, while the real-time calculated geoCode might be a longer string (e.g., 8 characters). During matching, we only use the first 5 characters. If the binary search succeeds (finding the corresponding geoCode prefix in the GeoTable), the corresponding alarm data is read from the matched record. Alarm data might be stored in an in-memory database, a file, or a remote server. The reading method depends on the system design. If the binary search does not find a matching geoCode, it means there is no alarm data in the current region, and the process ends.

[0134] Alarm module 55 is used to obtain road alarm information based on the hash value data matrix.

[0135] It should be noted that the compression of alarm data requires a combination of data simplification and two-dimensional discretization. The data simplification is implemented as follows: Key information of alarm data includes: longitude, latitude, direction, angle, and speed limit; the value range of each value is as follows: longitude: [0, 180.0000], latitude: [0, 90.0000], direction, angle, and speed limit: [0-360]. The above floating-point numbers will be converted into integers, for example, 123.1234 -> 1231234. The direction, angle, and speed limit are all divided by two, which can save half the space. In addition, the original data will be encrypted after being packaged and compressed to ensure data security.

[0136] The offline road violation photo warning system provided by this invention optimizes the algorithm for retrieving large amounts of data. By preprocessing alarm data, the alarm data is converted into two-dimensional data stored locally through a hash algorithm, and the index address of each data block is saved. When retrieving data, it is only necessary to retrieve the index value of each data block to determine whether the current data block meets the requirements, which greatly improves efficiency compared with the general binary search method.

[0137] Furthermore, the offline road violation photography warning system provided by this invention relies on the alarm data collected in advance to provide early warnings and speed limit photography. It can work offline by using locally stored data. As for data security, it can be ensured by encrypting the data and performing two-way authentication for data access. This avoids the shortcomings of existing commercial solutions on the market, which all rely on cloud storage and therefore cannot work offline.

[0138] Based on the same inventive concept, embodiments of the present invention also provide an electronic device. Figure 6 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Figure 6 As shown, an embodiment of the present invention provides an electronic device including: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, enable the one or more processors to implement any of the offline road violation photo warning methods described in the above embodiments; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0139] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0140] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0141] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0142] This invention also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements the steps of any of the offline road violation photo warning methods described in the above embodiments. The computer-readable storage medium can be volatile or non-volatile.

[0143] This invention also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code. When the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described intelligent driving assistance method.

[0144] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0145] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0146] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0147] The computer program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the invention.

[0148] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0149] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0150] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0151] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0152] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0153] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of the invention as set forth in the appended claims.

Claims

1. An offline method for issuing early warnings by taking photos of traffic violations, characterized in that, It includes the following steps: Alarm data, including longitude and latitude, is pre-stored locally; Obtain the longitude and latitude information of the current location; Convert the obtained longitude and latitude into hash values; The hash value is used to match the hash matrix corresponding to the alarm data locally; Road alarm information is obtained based on the matched hash matrix.

2. The offline road violation photography and early warning method according to claim 1, characterized in that, The step of pre-storing the hash-processed alarm data locally specifically includes: The alarm data is converted into a hash matrix using a hash algorithm and stored locally. The converted longitude and latitude values ​​are defined as geoCode, which is the index of the corresponding hash matrix. The geoCode of each alarm data is saved to the local index table GeoTable.

3. The offline road violation photography and early warning method according to claim 2, characterized in that, The step of converting the acquired longitude and latitude into hash values ​​specifically includes: The obtained longitude and latitude are converted into two dimensions, and the geoCode corresponding to the current location is obtained.

4. The offline road violation photography and early warning method according to claim 3, characterized in that, The step of matching the hash value with the corresponding hash matrix of the alarm data locally specifically includes: The geoCode, converted from the current location's longitude to latitude, is matched against a pre-stored geoCode in the GeoTable using a binary search method.

5. The offline road violation photography and early warning method according to claim 1, characterized in that, The alarm data includes longitude, latitude, direction, angle, and speed limit.

6. The offline road violation photography and early warning method according to claim 5, characterized in that, When pre-storing alarm data, the floating-point numbers of the alarm data are converted into integers, and the data of direction, angle, and speed limit are all divided by two.

7. The offline road violation photography and early warning method according to claim 1, characterized in that, The system plays the road alarm information based on the matched hash matrix via voice.

8. An offline road violation photo warning system, characterized in that, The method for implementing the offline road violation photography and early warning method as described in any one of claims 1-7 includes: The storage module is used to pre-store alarm data, including longitude and latitude, locally; The location acquisition module is used to obtain the longitude and latitude information of the current location; A conversion module is used to convert the longitude and latitude into hash values; The matching module is used to match the hash value converted in the conversion module with the hash matrix corresponding to the alarm data in the storage module; The early warning module is used to obtain corresponding alarm data based on the hash matrix matched in the matching module.

9. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1 to 7.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.

Images