Tile production real-time monitoring and integrity checking system

Abstract

The invention provides a tile production real-time monitoring and integrity checking system, which belongs to the technical field of geographic information systems and computer graphic processing and comprises a production task registration module, a tile integrity detection module, a message communication module and a browser rendering module. The production task registration module is used for collecting, analyzing and storing tile production task information; the tile integrity detection module is used for checking tile data integrity; the message communication module is used for pushing the tile production task state and the verification result from the server side to the browser side in real time; and the browser rendering module is used for generating a tile production progress monitoring multi-dimensional view and a tile data health degree analysis view according to the received tile production task state and the tile integrity verification result. According to the invention, a tile production monitoring system integrating multi-thread scheduling, asynchronous message communication and rendering technologies is provided, and full-link optimization of the tile production progress is realized.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of geographic information systems and computer graphics processing, and particularly relates to a tile production real-time monitoring and integrity checking system. BACKGROUND

[0002] In the era of "puzzle" of digital map, a large number of tiles like countless small puzzles together to make the city appearance. When the number of puzzles jumps from ten thousand to ten million, and more than one tenth of the fragments must be replaced every day, the tile service (Tile Service) is a map service that stores and dynamically distributes map data by cutting it into standardized small blocks (tiles) according to levels. With the exponential growth of the application scale of tile service, the contradictions exposed in the production process of a large number of tiles are increasingly prominent: large data size (single regional tile quantity can reach ten million), time-sensitive update (city-level map daily update rate is more than 15%), and high error repair cost (a single tile error may cause regional service interruption). However, the existing tile production process monitoring system does not solve the above problems, and there are significant technical bottlenecks:

[0003] 1. Static estimation model lag: the server estimates the progress based on the total number of tiles and the historical task duration, which lags behind, resulting in a minute-level delay in progress feedback, and users need to actively poll the mechanism to get the latest status, which seriously hinders the response efficiency of operation and maintenance. For example, GeoServer, users can only see the approximate progress information, and need to click the "Refreshlist" button frequently to refresh the current task progress.

[0004] 2. Weak checking system: existing technologies rely on manual inspection (such as random sampling browsing) or periodic health checks (such as sending WMTS GetMap requests at regular intervals), both of which have significant defects: the former is limited by subjective judgment bias and low-frequency sampling, and the latter is difficult to capture transient faults (such as occasional data loss caused by network jitter) due to fixed detection period. SUMMARY

[0005] To solve the above technical problems, the present application provides a map tile production monitoring and checking system based on multi-threading, and the specific technical solution is:

[0006] A tile production real-time monitoring and integrity checking system, comprising a production task registration module, a tile integrity detection module, a message communication module, and a browser rendering module.

[0007] The production task registration module is used for collecting, analyzing and storing the tile production task information; the tile integrity detection module is used for checking the tile data integrity; the message communication module is used for pushing the tile production task state and the checking result from the server end to the browser end in real time; the browser rendering module generates a tile production progress monitoring multi-dimensional view and a tile data health degree analysis view according to the received tile production task state and tile integrity checking result; when the tile production task is started, the production task information is registered to the production task registration module; when the production task state changes, the progress update information of the state change is pushed to the production task registration module; the production task registration module pushes the received information to the browser end in an asynchronous mode; after the production task is completed, the production task registration center sends a quality inspection command to the tile integrity detection module; the tile integrity detection module starts quality inspection according to a preset rule; after the quality inspection is completed, the tile integrity checking result is pushed to the browser end through the message communication module; and the browser end presents the tile data health degree analysis view for the user through the browser rendering module.

[0008] The present application has the following advantages:

[0009] The tile production monitoring system of the present application fuses multi-thread scheduling, asynchronous message communication and WebGL rendering technology, realizes full-link optimization of tile production progress by constructing a task registration center, a message distribution center, a multi-level checking and quality inspection module and a browser end visualization engine.

[0010] The present application realizes sub-second level pushing of task state based on a mixed message queue and a load sensing routing mechanism of Kafka + RabbitMQ.

[0011] The present application adopts a multi-level cache strategy and a dynamic elimination algorithm, and reduces the load of the server by more than 70%; the present application adopts a WebGL visualization engine combined with a dynamic drawing technology, and supports 60FPS real-time rendering of a tile production progress monitoring multi-dimensional view and a tile data health degree analysis view.

[0012] The present application adopts a multi-level checking system (hash checking + space-time correlation checking + browser end extension checking), and realizes that the quality inspection automation rate is improved to more than 80% in combination with a dynamic rule engine.

[0013] The application realizes millisecond-level state synchronization of tile production tasks and maximization of resource utilization by constructing a distributed task queue and a dynamic load balancing mechanism, combining a multi-level cache strategy; adopts a multi-level checking mechanism + dynamic verification algorithm, constructs a checking system covering the whole link of data production-transmission-storage through hash checking, spatial index association and browser plug-in extension technology, and ensures tile data integrity and topological consistency; integrates WebGL visualization engine technology, supports multi-dimensional progress tracing and abnormal early warning visualization, and makes production progress and data quality status present in the form of dynamic view. BRIEF DESCRIPTION OF DRAWINGS

[0014] Figure 1 A tile production real-time monitoring and integrity checking flowchart is shown in DETAILED DESCRIPTION

[0015] In order to make the purpose, technical scheme and advantages of the application clearer, the application is further described in detail below in combination with the drawings and examples. It should be understood that the specific examples described herein are only used to explain the application and do not limit the application. In addition, the technical features involved in each embodiment of the application described below can be combined with each other as long as they do not conflict with each other. In order to achieve the above purpose, the application adopts the following technical scheme.

[0016] The application provides a tile production real-time monitoring and integrity checking system, which comprises a production task registration module, a message communication module, a browser rendering module and a tile integrity detection module. The production task registration module is used for collecting, analyzing and storing tile production task information; the message communication module is used for pushing tile production status and checking results from the server end to the browser end in real time; the tile integrity detection module is used for tile data integrity checking; and the browser rendering module generates a multi-dimensional view of tile production progress monitoring and a view of tile data health degree analysis according to the received tile production task status and tile integrity checking results. The basic flowchart is shown in Figure 1

[0017] ​When starting a tile production task, production task information is registered to the production task registration module, and when the production task state changes (for example, task progress changes, task state changes), the progress update information of the state change is pushed to the production task registration module in synchronization. The production task registration module pushes the received information to the browser end in an asynchronous manner. The browser end presents a multi-dimensional view of the tile production progress to the user through the browser rendering module. After the production task is completed, the production task registration center sends an inspection command to the tile integrity detection module. The tile integrity detection starts the inspection according to the preset rules. After the inspection is completed, the tile integrity verification result is pushed to the browser end through the message communication module. The browser end presents a tile data health degree analysis view to the user through the browser rendering module.

[0018] The production task registration module includes a production task registration center, which is the core hub of the whole process management of tile production. The design adopts a distributed architecture, which is used to realize efficient collection, analysis and storage of production task information, and realize whole process monitoring of production task state update, progress query and log traceability. The implementation process is as follows:

[0019] 1. Task registration: when the user creates a tile production task, the production task metadata information is sent to the production task registration center in synchronization, and the production task registration center saves the information to the relational database according to the predetermined format (Table 1).

[0020] 2. Task monitoring and updating: after the production task registration is successful, the production task registration center starts two threads for the current production task to monitor the task state change. The two threads are as follows:

[0021] (a) Thread one is a passive monitoring thread. After the production task registration center receives the tile production task state change message, the production task is queried according to the task number, and the information is updated.

[0022] (b) Thread two is an active monitoring thread. This thread actively listens to the file storage address of the tile production task, and when the file quantity, size and other changes occur, the production task completion degree is calculated in real time.

[0023] At the same time, in order to prevent confusion caused by multi-thread updating, the application introduces data update locks, lock order control and timeout mechanism. All threads acquire update locks in the order of task ID, and when the lock acquisition fails, the backoff retry is performed.

[0024] 3. Task log storage: Throughout the entire tile production task life cycle, the production task registry center collects key information such as task state changes, progress updates, and abnormal problems, and builds a full-link management system covering task planning, execution, monitoring, and optimization. At the same time, according to the information category, it is saved to the relational database in the specified format (see Table 2 for production progress log, and Table 3 for abnormal information).

[0025] Table 1 Production task metadata table

[0026]

[0027] Table 2 Production task progress log table

[0028]

[0029] Table 3 Production task exception log table

[0030]

[0031] The message communication module serves as a bridge between the task registry center and the browser execution terminal. To meet the real-time monitoring requirements of tile production, the core design needs to meet the requirements of high throughput, low latency, and strong consistency. The message communication module includes:

[0032] 1. Optimize the message broker layer, use Kafka as the main message queue, and combine the real-time characteristics of RabbitMQ. For tasks of different priorities, different processing mechanisms are used to ensure that P0-level tasks are processed first and to achieve balanced allocation of system computing power.

[0033] 2. Load-aware routing, optimize intelligent distribution strategy. Load-aware routing is a technology that dynamically adjusts the distribution strategy by real-time sensing of server load status. By collecting CPU usage, memory occupancy, bandwidth utilization, queue length, etc., use weighted algorithm to predict server node load trend and generate load level label. The message communication module pushes the subsequent distribution task to the server node with low load according to the load level label, so as to realize traffic shunting and improve message distribution efficiency from two aspects of load-aware routing and priority queue.

[0034] 3. Multi-level cache acceleration mechanism, using Guava Cache as a local hotspot cache, for high-frequency access task progress data, a two-level cache architecture is established: local heap memory cache (maximum capacity 100,000 entries, TTL = 5 minutes) and Redis distributed cache (persistent storage of full data). Through the Cache Loader, an automatic loading mechanism is implemented. When the local cache is not hit, the Redis distributed cache is loaded in an asynchronous manner (loading and backfilling, while using Bloom Filter to intercept invalid requests), reducing the cache penetration rate to below 0.3%. To address the cross-node data consistency issue, the CacheAside mode is designed: the update operation first modifies the Redis distributed cache, and then notifies other nodes to delete the local cache through the message queue, ensuring eventual consistency.

[0035] 4. Multi-thread asynchronous processing mechanism, through the Disruptor ring queue and virtual thread cooperative design, high-performance task scheduling and resource optimization are achieved. The Disruptor ring queue pre-allocates memory strategy to avoid the GC pressure of traditional queues, and the throughput can reach more than 10 times that of traditional blocking queues. Virtual thread technology uses JVM-level lightweight threads to achieve high-density concurrency, with a single physical thread capable of carrying tens of thousands of virtual threads, reducing memory occupancy and context switching consumption, and reducing latency compared to traditional threads.

[0036] The tile data integrity verification module ensures the reliability of tile data in the whole process of production, transmission, storage, and invocation through multi-level verification mechanism and dynamic verification algorithm. Combined with the browser rendering module, a tile health analysis view is generated to realize the visualization of quality inspection results. The tile integrity detection module includes:

[0037] 1. Multi-level verification mechanism

[0038] The multi-level verification system builds a reliability guarantee framework covering the whole life cycle of data through a hierarchical and multi-dimensional verification mechanism. The first-level verification mainly focuses on data block integrity. Tile verification code is generated by a tile data hash generation algorithm, and CRC32 verification (Cyclic Redundancy Check 32-bit, a check method for detecting errors in data transmission and storage) is used to realize the consistency verification of underlying data, to ensure that the tile is not damaged in the process of transmission and storage. The second-level verification establishes a space-time correlation verification, generates time and neighborhood topology for the tile, and when a tile verification is abnormal, it automatically triggers the neighborhood tile correlation verification to form the spatial pollution traceability capability. The third-level verification is an integrated browser extension component. Through the browser extension component, it enriches the tile verification capability in three dimensions of request interception, dynamic verification, and real-time feedback. The browser extension component mainly captures the map tile request (such as / 1 / 3 / 4.png) in real time through the browser Web Request API, and uses the Service Worker multithreading to perform integrity verification in the background. By comparing the tile verification code, the abnormal tile is marked, and the abnormal tile index information is returned through the interface callback method.

[0039] The tile data hash generation algorithm is a dynamic hash generation algorithm for geographic spatial tile data proposed by the present scheme. Through coordinate feature binding, it solves the homogenization collision risk of traditional hash algorithms in tile data verification. The algorithm generates a dynamic salt value combined with the tile coordinate coding rule, constructs a multi-level hash iteration model, and generates a spatial and temporal double-unique tile verification code. Algorithm steps:

[0040] (a) Data preprocessing

[0041] Tile blocking: tile data (PNG / JPG format) is blocked according to the preset size of the tile, and the last part is zero-padded;

[0042] Coordinate encoding: convert the tile coordinates {z} / {x} / {y} to a 16-bit string as the dynamic salt value prefix;

[0043] (b) Dynamic salt value generation

[0044] Salt value generation: salt = SM3(tile_coord + random_nonce);

[0045] Where tile_coord is the tile coordinate encoding string, and random_nonce is a 4-byte random number generated by the server;

[0046] Salt value insertion: insert the salt value into the tile blocking data at a fixed interval to obtain data D1. For example, insert the salt value every 256 bytes;

[0047] (c) Multi-level Hash Iteration

[0048] Primary Compression: Perform SM3 standard compression on D1 data to generate intermediate hash value H1;

[0049] Hash Enhancement: XOR the hash value H1 with the last 256 bits of the tile to obtain the hash value H2;

[0050] Final Hash: Perform SM3 standard compression on the enhanced hash value H2 to obtain the final value H3.

[0051] (d) Checkcode Packaging

[0052] Encode H3 according to ASN.1 (ASN.1 is an international standard formal language jointly developed by International Organization for Standardization and International Telecommunication Union, used to define the abstract syntax of data structure), then append timestamp, coordinate metadata to generate the final tile checkcode.

[0053] 2. Dynamic Verification Algorithm

[0054] The dynamic verification algorithm function of the tile data integrity verification module realizes flexible expansion of verification logic through the rule engine and pluggable architecture. The dynamic verification algorithm includes:

[0055] (a) Rule Configuration System

[0056] In addition to the hash consistency verification rule (which refers to comparing tile checkcodes), the rule configuration system supports extending verification rules through JSON or YAML configuration files.

[0057] The rule configuration system converts verification rules into structured data through JSON or YAML parsers, and then persists them to the rule table (see Table 4).

[0058] Table 4: Rule Master Table

[0059]

[0060] (b) Dynamic Execution Engine

[0061] The dynamic execution engine can parse and inject the content of the expression field in the rule master table into the verification module. The verification module first uses the ANTLR tool to build a rule syntax tree, then converts the rule expression into an abstract syntax tree (AST), and then traverses the syntax tree nodes through the Listener mode to generate JAVA verification code. At the same time, detailed syntax error prompts are provided to help users quickly locate syntax problems. For example, when an unclosed parenthesis is detected, the line number and context information are prompted.

[0062] The browser rendering module is used to provide tile production task progress information and tile service data integrity information to the tile manager in a clearer and more beautiful way. For example, the production progress is drawn into an analysis view. The browser rendering module includes a multi-threaded data processing architecture, a WebGL acceleration module, and a front-end data caching module, which are designed as follows:

[0063] 1. Multi-threaded data processing architecture

[0064] The core of the multi-threaded data processing architecture is to separate the calculation work from the rendering work by using the Web Workers technology to create rendering threads and calculation threads. The rendering thread is mainly responsible for UI rendering, user interaction, and visualization display logic. The calculation thread is used to process tile progress data and tile quality data analysis, statistical chart data production (e.g., tile production progress time series chart, tile progress information heat map, abnormal data category statistical chart).

[0065] 2. WebGL acceleration module

[0066] The WebGL acceleration module uses Three.js, MapLibre.js, AntV.js, and other front-end rendering libraries to achieve high-performance geospatial data visualization. Vector data rendering and dynamic style updating are achieved through Maplibre.js and Three.js. For example, a progress bar is drawn for each tile, and the progress bar progress is updated in real time according to the task status. AntV.js focuses on chart production, using WebGL technology to quickly generate various types of icons such as line charts, bar charts, and pie charts, and combining with Maplibre.js to render various icons to the map component.

[0067] 3. Front-end data caching module

[0068] The front-end caching module includes a hierarchical caching module and an intelligent updating module, which reduces the network request volume to more than 70% while ensuring real-time data, improving user experience, and reducing server request pressure. Specifically, it includes:

[0069] (a) Hierarchical caching module

[0070] The tiered caching module achieves a balance between performance and resource consumption through a refined data grading strategy and data compression technology. This includes: high-priority data (such as real-time progress data) is cached in memory (L1), and combined with high-priority settings during WebSocket communication, millisecond-level data synchronization is achieved. Medium-priority data (such as quality inspection data) is stored in an Indexed DB (L2), with hot zones divided by time windows: data is automatically evicted with a TTL (30 minutes). Low-priority data (such as historical tile data) is stored in the browser cache. This strategy enables the system to maintain a high cache hit rate, improving system rendering efficiency while significantly reducing bandwidth costs.

[0071] (b) Smart Update Module

[0072] This is explored through two aspects: dynamic elimination strategy and incremental update.

[0073] Dynamic eviction combines cache access frequency and historical cache access count to implement tiered eviction of cached data. For example, cache protection is enabled for data accessed more than 10 times per hour to prevent eviction, while cache protection is disabled for data accessed less than 10 times per hour.

[0074] Incremental updates mainly rely on a multi-dimensional difference merging algorithm to achieve intelligent management of cached data.

[0075] The steps of the multi-dimensional difference merging algorithm are as follows:

[0076] Feature extraction: After the browser receives data pushed from the backend, it extracts the data version identifier (generated using a hash algorithm; input parameters include the data name, spatial range, and hash value of the previous version, ensuring the uniqueness and tamper-proof nature of the version identifier). The version identifier and the current timestamp are then merged into the data to obtain temporary cache C1.

[0077] The difference comparison involves matching the temporary cache C1 with the local cache. Based on the version identifier comparison result, a differential processing flow is initiated: if the version identifiers are completely identical, only the maintenance timestamp attribute of the local cache is updated; if a version conflict is detected, the attribute difference comparison method is used to locate the smallest unit of change, automatically merge the data, and update the maintenance timestamp. The incremental update process is implemented using multi-threading technology to prevent thread blocking and UI freezes caused by time-consuming update actions.

[0078] Those skilled in the art will appreciate that embodiments of the present application can be readily used as software, hardware, or a combination of software and hardware. In a software embodiment, the methods can be tangibly embodied in a machine-readable storage medium having stored thereon instructions that can be used to program a computer to perform any of the methods. The software implementation can be initialized by loading and executing a set of instructions arranged to perform one of the methods into the computer's memory. Alternatively, hard-wired circuitry can be used in place of, or in combination with, software instructions. Thus, the

[0079] The present application is described in reference to the flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will 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 program instructions. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart illustrations and / or block diagrams. Figure 1 one or more functions specified in one or more of the flowchart illustrations and / or block diagrams. Figure 1 means for performing each of the functions specified in the flowchart illustrations and / or block diagrams.

[0080] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the flowchart illustrations and / or block diagrams. Figure 1 one or more functions specified in one or more of the flowchart illustrations and / or block diagrams. Figure 1 means for performing each of the functions specified in the flowchart illustrations and / or block diagrams.

[0081] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the flowchart illustrations and / or block diagrams. Figure 1 one or more functions specified in one or more of the flowchart illustrations and / or block diagrams. Figure 1 means for performing each of the functions specified in the flowchart illustrations and / or block diagrams.

[0082] While preferred embodiments of the application have been described, modifications and alterations thereto will occur to those skilled in the art upon reading the preceding description. In particular, it will be apparent to those skilled in the art that parts can be added to, or substituted for, parts of the described embodiment. It is therefore desired that the application be construed as including all such modifications and alterations as fall within the scope of the application.

[0083] It will be apparent to those skilled in the art that various modifications and variations can be made to the present application without departing from the spirit or scope of the application. Thus, it is intended that the present application cover modifications and variations of this application provided they come within the scope of the appended claims and their equivalents.

Claims

1. A real-time monitoring and integrity verification system for tile production, characterized in that, This includes a production task registration module, a tile integrity detection module, a message communication module, and a browser rendering module; The system comprises several modules: a production task registration module for collecting, parsing, and storing tile production task information; a tile integrity detection module for verifying tile data integrity; a message communication module for pushing the tile production task status and verification results from the server to the browser in real time; and a browser rendering module for generating a multi-dimensional view of tile production progress monitoring and a view of tile data health analysis based on the received tile production task status and tile integrity verification results. When a tile production task is started, the production task information is registered with the production task registration module. When the production task status changes, the progress update information is synchronously pushed to the production task registration module. The production task registration module then pushes the received information to the browser asynchronously. After the production task is completed, the production task registration center sends a quality inspection command to the tile integrity detection module. The tile integrity detection module begins quality inspection according to preset rules. After the quality inspection is completed, the tile integrity verification results are pushed to the browser via the message communication module. The browser then presents the tile data health analysis view to the user through the browser rendering module.

2. The real-time monitoring and integrity verification system for tile production according to claim 1, characterized in that, The production task registration module includes a production task registration center, and the workflow of the production task registration center is as follows: When a user creates a tile production task, the production task metadata information is sent synchronously to the production task registration center. The production task registration center saves the information to a relational database in a predetermined format. Production task monitoring and updating: After a production task is successfully registered, the production task registration center starts two threads for the current production task to monitor changes in task status. Task log storage: Throughout the entire lifecycle of a tile production task, the production task registry collects task status changes, progress updates, and anomalies, and saves them to a relational database according to a predetermined format based on the information category.

3. The real-time monitoring and integrity verification system for tile production according to claim 2, characterized in that, The two threads are as follows: Thread 1 is a passive monitoring thread. After receiving the message about the change in the status of the tile production task, the production task registration center will query the production task according to the task number and update the information. Thread 2 is an active monitoring thread. This thread actively listens to the server file storage address pointed to by the tile production task. When the number or size of files changes, it calculates the completion rate of the production task in real time.

4. The real-time monitoring and integrity verification system for tile production according to claim 1, characterized in that, The message communication module includes: The message broker layer has been optimized by adopting a backbone message queue approach. Different processing mechanisms are used for tasks of different priorities, ensuring that P0-level tasks are processed first. Load-aware routing is used to predict server node load trends, generate load level labels, and push tasks to server nodes with low load based on the load level labels. The multi-level caching acceleration mechanism includes a two-level caching architecture: local cache and Redis distributed cache. When the local cache is not found, it is loaded and backfilled asynchronously from the Redis distributed cache, and then other nodes are notified to delete the local cache through a message queue. The multi-threaded asynchronous processing mechanism uses a Disruptor circular queue for memory pre-allocation and virtual threads to achieve lightweight thread concurrency.

5. The real-time monitoring and integrity verification system for tile production according to claim 1, characterized in that, The tile integrity detection module achieves the reliability of tile data in production, transmission, storage, and retrieval through a multi-level verification mechanism and dynamic verification algorithm.

6. The real-time monitoring and integrity verification system for tile production according to claim 5, characterized in that, The multi-level verification mechanism includes: Level 1 verification is used to verify the integrity of data blocks. It generates tile verification codes through a tile data hashing algorithm and uses CRC32 verification to achieve underlying data consistency verification; Level 2 verification establishes spatiotemporal correlation verification, which includes tile generation time and neighborhood topology relationships. When a tile verification is abnormal, it automatically triggers the correlation verification of neighboring tiles, forming a spatial pollution tracing capability; Level 3 verification integrates browser extension components to perform tile verification through browser-side extension components.

7. The real-time monitoring and integrity verification system for tile production according to claim 6, characterized in that, The tile data hash generation algorithm is implemented based on the SM3 national cryptographic standard. The algorithm steps include: Data preprocessing includes: Tile segmentation: Divide the tile data into segments according to the preset tile size, and pad with zeros at the end if necessary; Coordinate encoding: Convert the tile coordinates {z} / {x} / {y} into a hexadecimal string, which is used as a dynamic salt prefix; Dynamic salt value generation includes: Salt value generation: salt = SM3(tile_coord + random_nonce); Where tile_coord is the tile coordinate encoding string, and random_nonce is a 4-byte random number generated by the server; Salt value insertion: Salt values ​​are inserted into the tile block data at fixed intervals to obtain data D1; Multi-level hash iteration, including: Primary compression: Perform SM3 standard compression on the D1 data to generate an intermediate hash value H1; Hash enhancement: Perform an XOR operation between the hash value H1 and the last 256 bits of the tile to obtain the hash value H2; Final hash: Perform SM3 standard compression on the enhanced hash value H2 to obtain the final value H3; The verification code encapsulation includes: The H3 is encoded in ASN.1 format, and then a timestamp and coordinate metadata are appended to generate the final tile check code.

8. The real-time monitoring and integrity verification system for tile production according to claim 5, characterized in that, Dynamic verification algorithms include: The rule configuration system includes: hash consistency verification rules and JSON or YAML configuration file extended verification rules; the JSON or YAML configuration file extended verification rules are converted into structured data through a JSON or YAML parser and then persisted to the rule table; The dynamic execution engine is used to parse and validate the relevant fields in the rule table. First, it constructs a rule syntax tree, then converts the rule expression into a syntax tree, and then traverses the syntax tree nodes to generate JAVA validation code.

9. The real-time monitoring and integrity verification system for tile production according to claim 1, characterized in that, The browser rendering module includes a multi-threaded data processing architecture, a WebGL acceleration module, and a front-end data caching module. The multi-threaded data processing architecture is used to separate computational and rendering tasks, creating rendering threads and computational threads. The rendering threads are used for UI rendering, user interaction, and visualization logic, while the computational threads are used for processing tile progress data and tile quality data parsing, and creating statistical chart data. The WebGL acceleration module is used for geospatial data visualization, vector data rendering, and dynamic style updates; The front-end data caching module includes two modules: tiered caching and intelligent update. The tiered caching module includes: high-priority data is cached in memory, and combined with high-priority settings, data is synchronized at the millisecond level; medium-priority data is divided into hot zones according to time windows, and data is automatically eliminated; low-priority data is stored in the browser cache. The intelligent update module is used for dynamic eviction and incremental updates. Dynamic eviction combines cache access frequency and cache historical access count to implement hierarchical eviction of cached data. Incremental updates utilize a multi-dimensional difference merging algorithm to achieve cached data management.

10. A real-time monitoring and integrity verification system for tile production according to claim 9, characterized in that, The steps of the multi-dimensional difference merging algorithm are as follows: Feature extraction: After the browser receives the data pushed from the backend, it extracts the data version identifier and merges the version identifier and the current timestamp into the data to obtain temporary cache C1; The difference comparison involves matching the temporary cache C1 with the local cache and initiating a differential processing procedure based on the version identifier comparison result: if the version identifiers are completely identical, only the maintenance timestamp attribute of the local cache is updated; if a version conflict is detected, the attribute difference comparison method is used to locate the smallest change unit, automatically merge the data and update the maintenance timestamp.

Images