Massive meter device information rendering method and system based on spatial index, and medium

Abstract

The application provides a mass electric energy meter equipment information rendering method and system based on a space index, and a medium, the method comprising: generating an MBR corresponding to a single electric meter ID and an MBR corresponding to a regional electric meter group ID according to the electric meter ID and coordinate information of each electric meter; constructing an R-tree according to the MBR, wherein the leaf node in the R-tree stores the electric meter ID and metadata pointers of the electric meter, and the non-leaf node stores the MBR of its child node; receiving a front-end request, screening out an electric meter set composed of the electric meter ID of a target electric meter in a current map window by using the R-tree according to the coordinate information of the current map window; and determining a rendering strategy of the electric meter set according to the scale level of the current map window. The application can significantly improve the performance, efficiency and flexibility of electric meter space query by introducing the R-tree space index to hierarchically organize the electric meter MBR data, and simultaneously realizes dynamic rendering and low-latency interaction.

Description

Technical Field

[0001] This invention relates to the field of smart grid management technology, specifically to a method, system, and medium for rendering massive amounts of electricity meter device information based on spatial indexing. Background Technology

[0002] Existing solutions for managing massive amounts of electricity meter information, while supporting aggregated display formats such as clustered icons, lack in-depth optimization of spatial data structures, thus failing to achieve on-demand data loading and hierarchical rendering. Specific problems are as follows:

[0003] 1. Full data retrieval increases service pressure: When the front-end makes a request, the server needs to query all meter location data from the database at once, resulting in excessive database load;

[0004] 2. Huge transmission overhead: Returning hundreds of thousands of JSON records in a single transmission significantly increases network latency;

[0005] 3. Dense points cause front-end rendering lag: The browser cannot smoothly complete the drawing of points, resulting in a poor user experience;

[0006] 4. Data granularity is out of sync with scale: When the map is zoomed to different levels such as city level and district / county level, the same granularity data is returned, resulting in a waste of resources. Summary of the Invention

[0007] The technical problem to be solved by this invention is to provide a method, system and medium for rendering massive amounts of electricity meter device information based on spatial indexing, so as to achieve efficient querying, dynamic rendering and low-latency interaction.

[0008] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows:

[0009] A method for rendering massive amounts of electricity meter device information based on spatial indexing, comprising:

[0010] Based on the meter ID and coordinate information of each meter, generate an MBR corresponding to a single meter ID and an MBR corresponding to the regional meter group ID;

[0011] Based on the MBR corresponding to a single meter ID and the MBR corresponding to a regional meter group ID, a corresponding R-tree is constructed. The leaf nodes in the R-tree store the meter ID and metadata pointer of the corresponding meter, and the non-leaf nodes store the MBR corresponding to their child nodes.

[0012] Receive a request sent from the front end, the request carrying the coordinate information and scale of the current map window;

[0013] Based on the coordinate information of the current map window, the R-tree is used to filter out the set of electricity meters consisting of the electricity meter IDs of the target electricity meters located within the current map window;

[0014] The rendering strategy for the electricity meter set is determined based on the scale level of the current map window.

[0015] Optionally, the step of using an R-tree to filter out the set of electricity meters consisting of the meter IDs of target electricity meters located within the current map window based on the coordinate information of the current map window specifically includes:

[0016] Based on the coordinate information of the current map window, obtain the corresponding spatial geometric object;

[0017] Using MySQL's spatial functions, with the spatial geometry object as the query area, and combining it with R-tree queries, we obtain a set of electricity meters consisting of the meter IDs of the target electricity meters.

[0018] Optionally, the MySQL spatial function may also include filtering conditions for non-spatial fields; the filtering conditions may include one or more of the following: device type, device status, management affiliation, installation time, device model, and SIM card number.

[0019] Optionally, determining the rendering strategy for the electricity meter set based on the scale level of the current map window specifically includes:

[0020] Determine whether the scale level of the current map window is less than a preset scale level threshold;

[0021] If so, it is determined to be a low scaling level, and a low scaling rendering strategy is executed: obtain the aggregate information corresponding to the set of electricity meters, and render and display the aggregate information on the front end;

[0022] If not, it is determined to be a high scaling level, and a high scaling rendering strategy is executed: the detailed icons of each target meter in the meter set are rendered and displayed on the front end.

[0023] Optionally, the low-scaling rendering strategy specifically includes:

[0024] Based on the meter ID of each target meter in the meter set, obtain the coordinate information and metadata of each target meter; the metadata includes multiple items such as device type, device status, management affiliation, installation time, device model, and SIM card number;

[0025] Based on the coordinate information and metadata of each target meter, the corresponding aggregation information is obtained through clustering algorithms;

[0026] The aggregated information is rendered and displayed on the front end.

[0027] Optionally, the high-scaling rendering strategy specifically includes:

[0028] Based on the meter ID of each target meter in the meter set, obtain the coordinate information and metadata of each target meter; the metadata includes multiple items such as device type, device status, management affiliation, installation time, device model, and SIM card number;

[0029] Based on the coordinates and metadata of each target meter, the metadata of each target meter is rendered and displayed as icons in the corresponding position of the current map window on the front end.

[0030] Optionally, the aggregated information can be rendered and displayed in the current map window on the front end in the form of a heatmap, clustering diagram, or heatmap-clustering combination diagram.

[0031] Optionally, it also includes:

[0032] If the query frequency of a map window is higher than a preset frequency threshold, the map window will be marked as a high-frequency access map area.

[0033] The coordinate information, scale level, and spatial function used during the query for frequently accessed map areas are used as keys to cache the corresponding query results; the query results include a set of electricity meters and the coordinate information and metadata of each target electricity meter in the set.

[0034] Another technical solution provided by this invention is:

[0035] A computer-readable storage medium storing a computer program thereon, which, when executed by a processor, can implement the above-described method for rendering massive amounts of electricity meter device information based on spatial indexing.

[0036] Another technical solution provided by this invention is:

[0037] A massive energy meter device information rendering system based on spatial indexing includes a front-end, a processor, and the aforementioned computer-readable storage medium; the front-end and the computer-readable storage medium are respectively connected to the processor.

[0038] The beneficial effects of this invention are as follows: This invention provides a method, system, and medium for rendering massive amounts of electricity meter device information based on spatial indexing. It transforms the coordinate information of individual meters and regional meter groups into an MBR (Mean Backbone Graph), and organizes it into a highly balanced tree-like index using an R-tree. Through the R-tree, not only can the target meter set be located efficiently and quickly, avoiding the performance bottleneck of full-meter scanning, but the two-stage mode of first querying the MBR and then the details significantly reduces network load and improves response speed. Furthermore, it supports dynamic display according to map zoom levels, aggregating and presenting at low zoom levels and loading details at high zoom levels, optimizing front-end rendering efficiency. Additionally, non-spatial filtering conditions such as device type and status can be added to spatial queries to achieve joint filtering of spatial and attribute information, balancing query flexibility and practicality. Attached Figure Description

[0039] Figure 1 A flowchart illustrating a method for rendering massive amounts of electricity meter device information based on spatial indexing, provided in an embodiment of the present invention;

[0040] Figure 2 This is an example diagram of the R-tree index structure constructed in an embodiment of the present invention;

[0041] Figure 3 for Figure 2 Example diagram of the corresponding spatial index structure;

[0042] Figure 4 This is an example image of query results rendered in the current map view at a high zoom level in an embodiment of the present invention;

[0043] Figure 5 This is an example image of query results rendered in the current map view at a low zoom level in an embodiment of the present invention. Detailed Implementation

[0044] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0045] The most crucial concept of this invention lies in introducing an R-tree spatial index to organize the meter MBR data hierarchically, adopting a two-stage query mode of "first querying the MBR for coarse screening, then querying the details for fine screening," combining front-end window scaling levels to adapt to different rendering strategies, and supporting joint filtering of spatial and non-spatial conditions to improve the performance, efficiency, and flexibility of meter spatial queries.

[0046] Please refer to Figures 1 to 3 The present invention provides a method for rendering massive amounts of electricity meter device information based on spatial indexing.

[0047] like Figure 1As shown, this embodiment provides a method for rendering massive amounts of electricity meter device information based on spatial indexing, which includes at least the following steps S1 to S5.

[0048] S1: Based on the meter ID and coordinate information of each meter, generate the MBR corresponding to the individual meter ID and the MBR corresponding to the regional meter group ID.

[0049] The term "regional meter group" refers to a grouping method of multiple meters according to their physical location / management affiliation. It can be simply understood as a collection of meters belonging to the same geographical / management area. Meters within a regional meter group typically have the characteristics of centralized physical location / unified management affiliation. Each meter is still an independent single device with a corresponding MBR, but they are also treated as a "regional unit" and generate their own corresponding MBR.

[0050] For example, all the electricity meters in Building 1 of a certain residential community belong to a "power supply area" and are considered as a regional meter group with a unique ID; all the production electricity meters in a large factory area belong to a "user-exclusive area" and are considered as a regional meter group with a unique ID.

[0051] In this embodiment, the MBR conversion logic for a single meter and a regional meter group is as follows:

[0052] (1) The latitude and longitude coordinates of a single meter are point coordinates (e.g., lon=116.40, lat=39.90), and its MBR is a very small rectangle (because a point has no area). The conversion rule is as follows:

[0053] The minimum longitude of the MBR equals the maximum longitude, which equals the longitude of the meter.

[0054] The minimum latitude of the MBR is equal to the maximum latitude, which is equal to the latitude of the meter.

[0055] (2) For a regional meter group, its MBR is the smallest rectangle enclosing the coordinates of all meters within the group. The transformation rule is as follows:

[0056] min_lon = the minimum longitude of all meters in the group;

[0057] max_lon = the maximum longitude of all meters in the group;

[0058] min_lat = the minimum latitude of all meters in the group;

[0059] max_lat = the maximum value of all latitudes of all meters in the group.

[0060] In this embodiment, MBR abstracts the spatial location of "point (coordinates of a single meter) / area (regional range of a group of meters)" into a minimum rectangle.

[0061] In some specific implementations, during the database initialization phase, by traversing all meter device records, their latitude and longitude coordinate information is extracted, and an MBR corresponding to a single meter ID and an MBR corresponding to a regional meter group ID are constructed.

[0062] In some other implementations, the MBR data is stored in the database in the form of a class / dictionary and associated with the corresponding meter ID / regional meter group ID.

[0063] S2: Based on the MBR corresponding to a single meter ID and the MBR corresponding to a regional meter group ID, a corresponding R-tree is constructed. The leaf nodes in the R-tree store the meter ID and metadata pointer of the corresponding meter, and the non-leaf nodes store the MBR corresponding to their child nodes.

[0064] This step enables the hierarchical construction of the specific R-tree spatial index structure in this embodiment. The R-tree referred to here is an R-tree or R... Tree. In this embodiment, via R-tree / R The tree spatial index structure is used to organize the MBR from the previous step, ultimately forming a highly balanced tree index, which provides basic technical support for efficient management and querying of the spatial location of electricity meters (such as range queries and proximity queries).

[0065] In this embodiment, the R-tree spatial index structure has one node corresponding to one MBR.

[0066] Specifically, in an R-tree, a non-leaf node corresponds to the "parent MBR" of its child MBR, which is the smallest rectangle that encloses all its child MBRs. During the construction process, the MBR of a non-leaf node is automatically updated to the smallest bounding rectangle of its child MBRs to ensure the accuracy of the index.

[0067] Specifically, the leaf nodes in the R-tree correspond to the MBR of a single electricity meter, storing the corresponding meter ID and metadata pointers. The meter's metadata includes, but is not limited to, attribute data such as: device type, device status (online / offline), management affiliation (e.g., the power supply area), installation time, device model, and SIM card number.

[0068] In some specific implementations, the construction rules for the R-tree spatial index structure are as follows:

[0069] 1. When inserting an MBR, select the leaf node that "can accommodate the MBR and has the smallest expansion";

[0070] 2. Split the tree when the node is full. When splitting, minimize MBR overlap and ensure the tree height is balanced.

[0071] 3. The final tree structure: root node → non-leaf node (parent MBR) → leaf node (meter MBR + meter ID).

[0072] In some specific implementations, during automatic node processing, the height balance of the R-tree is ensured through "forced re-insertion" and "optimal splitting" strategies, achieving stable query efficiency without manual adjustment of the tree structure. Preferably, the R-tree spatial index structure is automatically constructed using MySQL's SPATIAL INDEX or PostGIS's GIST index, ensuring automatic maintenance of tree balance during insertion / update. Preferably, when the number of meters exceeds 100,000, batch insertion into the MBR can be achieved using idx.bulk_insert(), resulting in efficiency up to 10 times higher than single-line insertion.

[0073] Specifically, in this embodiment, regional meter groups are pre-abstracted into "regional MBRs." During R-tree construction, these can be directly used as non-leaf nodes, with the MBRs of meters within the group serving as their child nodes. A balanced R-tree matching the meter management hierarchy is constructed in a "hierarchical nesting" manner. This approach preserves the regional grouping characteristics while maximizing the spatial query efficiency of the R-tree. Furthermore, the regional MBR supports multi-level management and can meet the spatial query needs of meters at different granularities (such as transformer substations, streets, and industrial parks).

[0074] In some specific implementations, the method for inserting the regional MBR corresponding to the regional meter group ID into the R-tree is as follows:

[0075] 1. First, insert the highest-level regional MBR (such as the substation MBR) as the top-level non-leaf node of the R-tree;

[0076] 2. Then insert the next-level MBR (such as the building MBR) into the child node of the corresponding parent node (the transformer area MBR);

[0077] 3. Finally, insert the individual meter MBR into the child node of the corresponding building MBR;

[0078] 4. During the insertion process, the R-tree automatically splits / balances nodes to ensure that the parent node of each MBR level is the "smallest rectangle that surrounds all child nodes".

[0079] The resulting R-tree has a hierarchical structure that perfectly matches the regional management hierarchy of electricity meters (province → city → substation → building → single meter). During queries, the regional MBR can be located first, allowing for quick filtering of individual meters within that region. An exemplary R-tree index structure is shown below. Figure 2 As shown, an example of its corresponding spatial index structure is as follows: Figure 3 As shown.

[0080] S3: Receive a request sent from the front end, the request carrying the coordinate information and scale of the current map window.

[0081] The request sent by the front end carries the following information: the diagonal coordinates of the current map view, namely the southwest corner coordinates (top left latitude and longitude): (lon_sw, lat_sw) and the northeast corner coordinates (bottom right latitude and longitude): (lon_ne, lat_ne) and the current map scale level (Zoom Level).

[0082] In some specific implementations, the request also carries: an operational status filtering condition. This filtering condition is a non-spatial field filtering condition. Optionally, the filtering condition includes, but is not limited to: device type (meter / concentrator), device status (online / offline), management affiliation, installation time, device model, SIM card number, etc.; optionally, the filtering condition can be one or a combination of the above conditions.

[0083] For example, when using spatial functions (such as MySQL) to perform spatial index queries, it is possible to append non-spatial field filtering conditions (such as device_type = 'meter' AND status = 'online') to the spatial index query Range Query to add a filter condition of "device type is meter and device status is online".

[0084] Based on the specific implementation methods described above, it is possible to support the addition of non-spatial field filtering conditions to spatial index queries, achieving joint filtering of spatial and attribute dimensions, and balancing query flexibility and practicality. Furthermore, these conditions can be implemented at the SQL level through index optimization or nested loops without affecting the main structure of the R-tree.

[0085] S4: Based on the coordinate information of the current map window, use an R-tree to filter out the set of electricity meters consisting of the electricity meter IDs of the target electricity meters located within the current map window.

[0086] After receiving the request from the front end, the back end will use the R tree to perform a range query, only retrieving the meter MBRs that fall within the current view. If an MBR is completely outside the view, its subtree will be skipped. If an MBR partially overlaps, its child nodes will be recursively visited. Finally, the set of meters to be returned will be obtained.

[0087] In some specific implementations, step S4, i.e., performing a spatial range query, specifically includes the following sub-steps:

[0088] S41: The backend converts the coordinate information of the current map view carried in the request into the corresponding spatial geometry object.

[0089] Optionally, the spatial geometry object is a polygon geometry object in the standard WKT (Well-Known Text) format.

[0090] S42: Using MySQL's spatial functions, with the spatial geometry object as the query area, and combining R-tree queries, obtain the set of electricity meters consisting of the electricity meter IDs of the target electricity meters.

[0091] Optionally, the spatial function is MBRIntersects() or ST_Intersects().

[0092] For example, one of the SQL query functions used is as follows:

[0093] SELECT device_id, mbr, status, device_type FROM am_asset_dev WHEREMBRIntersects(ST_GeomFromText('POLYGON((xxx.xx xx.xx, xxx.xx xx.xx, xxx.xxxx.xx, xxx.xx xx.xx, xxx.xx xx.xx))'), mbr)AND device_type = 'meter'ANDstatus IN ('online').

[0094] Specifically, "ST_GeomFromText" is used to convert the text-formatted query area (POLYGON polygon) into a MySQL spatial geometry type; "MBRIntersects" is used to determine whether the device's MBR intersects with the query area, and R-tree indexes are used to quickly narrow down the search range, avoiding full table scans; additional filtering conditions "device_type = 'meter' and status IN ('online', 'offline')" are added to achieve joint filtering of spatial range and device attributes, accurately obtaining the meter device ID and MBR that meet the conditions.

[0095] The SQL above, using MySQL spatial functions and R-tree spatial indexes, can efficiently query devices within a specified geographical rectangle that are electricity meters and are online.

[0096] This step in the embodiment combines spatial functions with R-tree indexes to achieve efficient joint queries of meter spatial range and business attributes, ensuring query accuracy while significantly improving retrieval performance through spatial indexes.

[0097] S5: Determine the rendering strategy for the electricity meter set based on the scale level of the current map window.

[0098] The scale levels, or zoom levels, generally range from 0 to 22. Level 0 displays the entire world, while level 22 displays the most detailed content; each level increases the map resolution by a factor of two.

[0099] In this embodiment, the low scale level (low zoom level) corresponds to a large geographical area, such as a large city at the provincial or municipal level; the high scale level (high zoom level) corresponds to a small geographical area, such as a county or district level.

[0100] In this embodiment, by setting a "scale level threshold" or setting different "scale level ranges", it is possible to quickly and efficiently determine whether the current map window belongs to a high zoom level or a low zoom level.

[0101] In some specific implementations, the mapping relationship between the preset scaling level (scale level) and the rendering strategy is shown in Table 1 below.

[0102] Table 1

[0103]

[0104] Preferably, the mapping relationship is stored in the system configuration table `render_config`. This not only allows for dynamic adjustment of the rendering strategy without modifying the code, but also facilitates maintenance and debugging.

[0105] In this embodiment, the rendering strategy configured differently for different scale levels is as follows:

[0106] (1) Set the "high scaling rendering strategy" corresponding to the "high scaling level": render and display the detailed icons of each target meter in the meter set to the front end.

[0107] Specifically, the high-scaling rendering strategy requires first obtaining the coordinate information and metadata of each target meter based on its meter ID in the meter set. This metadata includes, but is not limited to, device type, device status, management affiliation, installation time, device model, and SIM card number. Then, based on the coordinate information and metadata of each target meter, the metadata of each target meter is rendered and displayed as an icon at its corresponding location (coordinate position) in the current map viewport on the front end.

[0108] For example, the query results rendered in the current map view at a high zoom level are as follows: Figure 4 As shown.

[0109] (2) Set the "low scaling rendering strategy" corresponding to the "low scaling level": obtain the aggregate information corresponding to the set of electricity meters, and render and display the aggregate information on the front end.

[0110] Specifically, in the low-scaling rendering strategy, the coordinate information and metadata of each target meter in the meter set are first obtained based on the meter ID. This metadata includes, but is not limited to, device type, device status, management affiliation, installation time, device model, and SIM card number. Then, based on the coordinate information and metadata of each target meter, a clustering algorithm is used to obtain corresponding aggregation information. This aggregation information includes, but is not limited to, the total number of meters in the area, management affiliation, total number of concentrators, and coordinates of the left aggregation point. Finally, the aggregation information is rendered and displayed in the current map window on the front end.

[0111] For example, the query results rendered in the current map view at a low zoom level are as follows: Figure 5 As shown.

[0112] Optionally, the rendering and display formats of the aggregated information include, but are not limited to: heatmaps, clustering diagrams, and heatmaps with clustering combinations.

[0113] It is understood that this embodiment configures a differentiated rendering strategy for different zoom levels of the map window, which can dynamically present the query results of electricity meter data according to the zoom level: at low zoom levels (such as provincial / municipal level), the electricity meter data is aggregated and displayed, and at high zoom levels (such as county / district level), detailed electricity meter information is loaded and specific icons are rendered; this strategy effectively controls the number of front-end DOM elements rendered under different zoom levels, and significantly optimizes the rendering efficiency and visual presentation effect of the map front end.

[0114] In some specific implementations, when a user switches from a "low-zoom map window" to a "high-zoom map window", the following two-stage data loading method will be used to further optimize the front-end rendering effect, significantly reduce network load, and improve response speed.

[0115] Phase 1: When the current map window is at a "low zoom level", such as a provincial / municipal map window, the front end only loads the MBR list (including device_id) presented in aggregate form within the window.

[0116] The second stage: The current map is switched to a "high zoom level", such as a county / district level map window. Then, detailed attributes (such as model, status, SIM card number) are queried in batches based on the device_id in the MBR list (re-query), and retrieved using the IN(id1, id2, ..., idN) method.

[0117] Preferably, a certain time interval (e.g., 200ms) is set between the two stages to delay debouncing and avoid generating a large number of invalid requests when frequently switching windows.

[0118] In some specific implementations, the device also features a special rendering identifier for offline devices. Specifically, for devices whose running status is "offline," a marker is added to the data returned to the front end (e.g., is_offline:true); the front end will then render the corresponding device using a specific icon style based on the marker, such as a gray icon. Preferably, the last online time will also be displayed in the "tooltip" of the icon.

[0119] In other specific implementations, a caching mechanism is also included to optimize high-frequency window requests and improve response speed. Specifically, this includes: if the query frequency of a map window is higher than a preset frequency threshold, then the map window is marked as a high-frequency access map area (such as an area frequently viewed by the dispatch center); and the corresponding query results are cached in Redis using the coordinate information, scale level, and spatial function used during the query of the high-frequency access map area as the key; the query results include a set of electricity meters (composed of the meter IDs of the target electricity meters) and the coordinate information and metadata of each target electricity meter in the set.

[0120] Optionally, setting the TTL (Time To Live) of the cache to 30 seconds can strike a balance between data timeliness and system performance, ensuring that cached data will not cause dirty reads due to expiration, while avoiding frequent cache update operations from affecting system response speed.

[0121] Another embodiment of the present invention provides a computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program can implement the method for rendering massive energy meter device information based on spatial indexing as described in the above embodiments. Specific steps are not detailed here; please refer to the description in the above embodiments for more information.

[0122] Another embodiment of the present invention provides a massive energy meter device information rendering system based on spatial indexing, including a front-end, a processor, and the computer-readable storage medium described in the previous embodiment; the front-end and the computer-readable storage medium are respectively connected to the processor. When the computer program is executed by the system's processor, it can implement the massive energy meter device information rendering method based on spatial indexing described in the above embodiment. Specific steps are not detailed here; please refer to the description in the above embodiments for details.

[0123] As can be understood from the above description, those skilled in the art will recognize that all or part of the processes in the above technical solutions can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the methods described above. After being executed by a processor, the program can also achieve the beneficial effects of the corresponding methods.

[0124] The storage medium can be a disk, optical disc, read-only memory (ROM), or random access memory (RAM), etc.

[0125] In summary, the present invention provides a method, system, and medium for rendering massive amounts of electricity meter equipment information based on spatial indexing. It introduces an R-tree spatial index to organize the meter MBR data in layers, adopts a two-stage query mode of "first querying the MBR for coarse screening, then querying the details for fine screening", combines the front-end window scaling level to adapt to different rendering strategies, and supports joint filtering of spatial and non-spatial conditions, which can achieve efficient and flexible querying, dynamic rendering, and low-latency interaction.

[0126] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for rendering massive amounts of electricity meter device information based on spatial indexing, characterized in that, include: Based on the meter ID and coordinate information of each meter, generate an MBR corresponding to a single meter ID and an MBR corresponding to the regional meter group ID; The regional meter group is a collection of meters belonging to the same geographical or management area; Based on the MBR corresponding to a single meter ID and the MBR corresponding to a regional meter group ID, the corresponding R-tree is constructed. The leaf nodes in the R-tree correspond to the MBR of a single meter, which stores the meter ID and metadata pointer of the corresponding meter. The non-leaf nodes correspond to the MBR of a regional meter group, which stores the MBR corresponding to its child nodes, and its child nodes are the MBRs of the meters in the group. The method for inserting the MBR corresponding to the multi-level regional meter group ID into the R-tree to construct an R-tree whose hierarchical structure perfectly matches the regional management level of the meter is as follows: (1) First insert the MBR corresponding to the ID of the highest level regional meter group as the top-level non-leaf node of the R tree; (2) Then insert the MBR corresponding to the ID of the next level of regional meter group into the child node of the corresponding parent node; (3) Finally, insert the MBR corresponding to a single meter ID into the child node of the corresponding parent node; (4) During the insertion process, the R-tree automatically splits or balances the nodes to ensure that the parent node of each level is the smallest rectangle that surrounds all child nodes; Receive a request sent from the front end, the request carrying the coordinate information and scale of the current map window; Based on the coordinate information of the current map window, the R-tree is used to filter out the set of electricity meters consisting of the electricity meter IDs of the target electricity meters located within the current map window; The rendering strategy for the electricity meter set is determined based on the scale level of the current map window. The step of determining the rendering strategy for the electricity meter set based on the scale level of the current map window specifically includes: Determine whether the scale level of the current map window is less than a preset scale level threshold; If so, it is determined to be a low scaling level, and a low scaling rendering strategy is executed: obtain the aggregation information corresponding to the set of electricity meters, and render and display the aggregation information on the front end; the aggregation information includes one or more of the following: total number of electricity meters in the area, management affiliation, total number of concentrators, and coordinates of the left point of the aggregation. If not, it is determined to be a high scaling level, and a high scaling rendering strategy is executed: the detailed icons of each target meter in the meter set are rendered and displayed on the front end.

2. The method for rendering massive amounts of electricity meter device information based on spatial indexing as described in claim 1, characterized in that, The step of using an R-tree to filter out the set of electricity meters consisting of the meter IDs of target electricity meters located within the current map window, based on the coordinate information of the current map window, specifically includes: Based on the coordinate information of the current map window, obtain the corresponding spatial geometric object; Using MySQL's spatial functions, with the spatial geometry object as the query area, and combining it with R-tree queries, we obtain a set of electricity meters consisting of the meter IDs of the target electricity meters.

3. The method for rendering massive amounts of electricity meter device information based on spatial indexing as described in claim 2, characterized in that, The MySQL spatial functions also include filtering conditions for non-spatial fields; the filtering conditions include one or more of the following: device type, device status, management affiliation, installation time, device model, and SIM card number.

4. The method for rendering massive amounts of electricity meter device information based on spatial indexing as described in claim 1, characterized in that, The low-scaling rendering strategy specifically includes: Based on the meter ID of each target meter in the meter set, obtain the coordinate information and metadata of each target meter; the metadata includes multiple items such as device type, device status, management affiliation, installation time, device model, and SIM card number; Based on the coordinate information and metadata of each target meter, the corresponding aggregation information is obtained through clustering algorithms; The aggregated information is rendered and displayed on the front end.

5. The method for rendering massive amounts of electricity meter device information based on spatial indexing as described in claim 1, characterized in that, The high-scaling rendering strategy specifically includes: Based on the meter ID of each target meter in the meter set, obtain the coordinate information and metadata of each target meter; the metadata includes multiple items such as device type, device status, management affiliation, installation time, device model, and SIM card number; Based on the coordinates and metadata of each target meter, the metadata of each target meter is rendered and displayed as icons in the corresponding position of the current map window on the front end.

6. The method for rendering massive amounts of electricity meter device information based on spatial indexing as described in claim 1, characterized in that, The aggregated information is rendered and displayed in the current map window on the front end in the form of a heatmap, clustering graph, or heatmap-clustering combination graph.

7. The method for rendering massive amounts of electricity meter device information based on spatial indexing as described in claim 1, characterized in that, Also includes: If the query frequency of a map window is higher than a preset frequency threshold, the map window will be marked as a high-frequency access map area. The coordinate information, scale level, and spatial function used during the query for frequently accessed map areas are used as keys to cache the corresponding query results; the query results include a set of electricity meters and the coordinate information and metadata of each target electricity meter in the set.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it can implement the method for rendering massive energy meter device information based on spatial indexing as described in any one of claims 1 to 7.

9. A massive energy meter device information rendering system based on spatial indexing, characterized in that, It includes a front-end, a processor, and the computer-readable storage medium as described in claim 8; the front-end and the computer-readable storage medium are respectively connected to the processor.

Images