A tile production real-time monitoring and integrity checking system

Abstract

The application provides a tile production real-time monitoring and integrity checking system, belonging to the technical field of geographic information systems and computer graphics processing, comprising 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 the integrity of tile data; 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; and 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. The application proposes a tile production monitoring system integrating multi-thread scheduling, asynchronous message communication and rendering technology, and realizes full-link optimization of the tile production progress.

Description

Technical Field

[0001] This invention belongs to the field of geographic information systems and computer graphics processing technology, and specifically relates to a real-time monitoring and integrity verification system for tile production. Background Technology

[0002] In the era of digital map "puzzle building," massive amounts of tiles, like countless tiny puzzle pieces, piece together the cityscape. As the number of puzzle pieces jumps from tens of thousands to tens of millions, and more than 10% of the pieces need to be replaced daily, tile services, which divide map data into standardized small pieces (tiles), store them hierarchically, and dynamically distribute them on demand, have become increasingly problematic due to the exponential growth in the scale of tile service applications. These problems include: massive data volume (tens of millions of tiles in a single area), sensitivity to update timeliness (daily update rate of city-level maps exceeds 15%), and high cost of error repair (a single tile error can lead to service interruption in the region). However, existing tile production process monitoring systems have not solved these problems and suffer from significant technical bottlenecks.

[0003] 1. Static prediction model lag: The server calculates progress based on the total number of tiles and historical task durations. This lag results in minute-level delays in progress feedback, and users need to actively poll for the latest status, severely restricting operational response efficiency. Taking GeoServer as an example, users can only see approximate progress information and need to frequently click the "Refreshlist" button to refresh the current task progress.

[0004] 2. The verification system is fragile: 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 these have significant drawbacks: the former is limited by subjective judgment bias and low-frequency sampling, while the latter is difficult to capture instantaneous faults (such as occasional data loss caused by network jitter) due to the fixed detection cycle. Summary of the Invention

[0005] To address the above technical problems, this invention provides a multi-threaded map tile production monitoring and verification system, the specific technical solution of which is as follows:

[0006] A real-time monitoring and integrity verification system for tile production includes a production task registration module, a tile integrity detection module, a message communication module, and a browser rendering module;

[0007] 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.

[0008] The present invention has the following beneficial effects:

[0009] This invention is a tile production monitoring system that integrates multi-threaded scheduling, asynchronous message communication, and WebGL rendering technology. It achieves end-to-end optimization of tile production progress by constructing a task registration center, a message distribution center, a multi-level verification and quality inspection module, and a browser-side visualization engine.

[0010] This invention uses a hybrid message queue based on Kafka + RabbitMQ and a load-aware routing mechanism to achieve sub-second push of task status.

[0011] This invention employs a multi-level caching strategy and a dynamic eviction algorithm, reducing server load by more than 70%. It also utilizes a WebGL visualization engine combined with dynamic rendering technology to support real-time rendering of multi-dimensional views for tile production progress monitoring and tile data health analysis views.

[0012] This invention employs a multi-level verification system (hash verification + spatiotemporal correlation verification + browser-side extended verification), combined with a dynamic rule engine to increase the quality inspection automation rate to over 80%.

[0013] This invention achieves millisecond-level status synchronization and maximizes resource utilization for tile production tasks by constructing a distributed task queue and dynamic load balancing mechanism, combined with a multi-level caching strategy. It employs a multi-level verification mechanism and dynamic verification algorithm, using hash verification, spatial index association, and browser plugin extension technology to build a verification system covering the entire data production-transmission-storage chain, ensuring tile data integrity and topology consistency. It integrates WebGL visualization engine technology to support multi-dimensional progress tracking and anomaly warning visualization, presenting production progress and data quality status in a dynamic view. Attached Figure Description

[0014] Figure 1 Flowchart for real-time monitoring and integrity verification of tile production; Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Furthermore, the technical features involved in the various embodiments of this invention described below can be combined with each other as long as they do not conflict with each other. To achieve the above objectives, this invention adopts the following technical solution.

[0016] This invention proposes a real-time monitoring and integrity verification system for tile production, comprising 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, parsing, and storing tile production task information; the message communication module is used to push the tile production status and verification results from the server to the browser in real time; the tile integrity detection module is used for verifying the integrity of tile data; and the browser rendering module generates 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. Its basic flowchart is shown below. Figure 1 As shown:

[0017] When a tile production task is initiated, the production task information is registered with the production task registration module. When the production task status changes (e.g., changes in task progress or status), the progress update information is synchronously pushed to the production task registration module. The production task registration module then asynchronously pushes the received information to the browser. The browser rendering module presents a multi-dimensional view of the tile production progress to the user. 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 begins quality inspection according to preset rules. After the quality inspection is completed, the tile integrity verification result is pushed to the browser via the message communication module. The browser rendering module then presents a tile data health analysis view to the user.

[0018] The production task registration module includes a production task registration center, which is the core hub for the entire tile production process management. Its distributed architecture enables efficient collection, parsing, and storage of task information, achieving full-process monitoring with updatable task status, queryable progress, and traceable logs. The implementation process is as follows:

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

[0020] 2. Task Monitoring and Updates: 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. The two threads have the following division of labor:

[0021] (a) Thread 1 is a passive monitoring thread. After receiving the tile production task status change message, the production task registry center queries the production task according to the task number and updates the information.

[0022] (b) Thread 2 is an active monitoring thread. This thread actively listens to the server file storage address pointed to by the tile production task, and calculates the completion rate of the production task in real time when changes occur in the number or size of files.

[0023] To prevent chaos during multi-threaded updates, this invention introduces a data update lock, along with lock order control and a timeout mechanism. All threads acquire the update lock in order of task ID, and a backoff and retry mechanism is implemented when lock acquisition fails.

[0024] 3. Task Log Storage: Throughout the entire lifecycle of tile production tasks, the production task registration center collects key information such as task status changes, progress updates, and anomalies to build a full-link management system covering task planning, execution, monitoring, and optimization. Simultaneously, information is saved to the relational database according to its category and a predetermined format (production progress logs are shown in Table 2, and anomaly information is shown in Table 3).

[0025] Table 1 Production Task Metadata Table

[0026] Serial Number Fields Data types describe 1 task_id UUID Globally unique task identifier 2 task_name String Task Name (e.g., "Beijing 2024 Aerial Image Production") 3 task_type Enum Task type (full update / incremental update / partial fix) 4 task_priority Int(1-5) Priority (P1-P5) 5 task_status Enum Current status (Pending execution / In production / Completed / Failed) 6 task_process Int Task progress, value 0-100 7 create_time Timestamp Task creation time 8 end_time Timestamp Mission End Time 9 tile_matrix_set string Tile matrix set identifier (e.g., "CGCS2000_256") 10 crs String Coordinate reference system (e.g., EPSG:4326) 11 min_zoom int Minimum scaling level 12 max_zoom Int Maximum zoom level 13 tile_size int Tile size (default 256x256) 14 task_file_path String Server path the task points to 15 task_theads JSON Thread number associated with the task

[0027] Table 2 Production Task Progress Log

[0028] Serial Number Fields Data types describe 1 id UUID Globally unique task log identifier 2 task_id UUID Globally unique task identifier 3 tile String Tile identifier (format: z / x / y) 4 processing time JSON Tile processing timestamps (start time, end time) 5 status Enum Current status (Pending execution / In production / Completed / Failed)

[0029] Table 3 Production Task Anomaly Log Table

[0030] Serial Number Fields Data types describe 1 id UUID Globally unique task log identifier 2 task_id UUID Globally unique task identifier 3 error_code String Error codes (such as "ERR_TILE_IO") 4 error_message Text Error Description 5 stack_trace Text Error stack information

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

[0032] 1. Optimize the message broker layer by using Kafka as the backbone message queue and combining it with the high real-time performance of RabbitMQ. Different processing mechanisms are adopted for tasks of different priorities to ensure that P0-level tasks are processed first and achieve balanced distribution of system computing power.

[0033] 2. Load-Aware Routing for Optimized Intelligent Distribution Strategies. Load-aware routing is a technology that dynamically adjusts distribution strategies by monitoring server load status in real time. It collects data such as CPU utilization, memory usage, bandwidth utilization, and queue length, and uses a weighted algorithm to predict server node load trends, generating load level labels. Based on these load level labels, the message communication module pushes subsequent distribution tasks to server nodes with lower loads, thereby improving message distribution efficiency through both load-aware routing and priority queuing.

[0034] 3. A multi-level caching acceleration mechanism is implemented, using Guava Cache as the local hotspot cache. For frequently accessed task progress data, a two-level caching architecture is established: a local heap memory cache (maximum capacity 100,000 entries, TTL=5 minutes) and a Redis distributed cache (persistently storing all data). An automatic loading mechanism is implemented through Cache Loader. When the local cache misses, it asynchronously loads and refills from the Redis distributed cache, while simultaneously using a Bloom filter to intercept invalid requests, reducing the cache penetration rate to below 0.3%. To address cross-node data consistency issues, a Cache Aside mode is designed: update operations first modify the Redis distributed cache, and then notify other nodes to delete their local caches via a message queue, ensuring eventual consistency.

[0035] 4. A multi-threaded asynchronous processing mechanism, through the collaborative design of the Disruptor circular queue and virtual threads, achieves high-performance task scheduling and resource optimization. The Disruptor circular queue's pre-allocated memory strategy avoids the GC pressure of traditional queues, achieving throughput more than 10 times that of traditional blocking queues. The virtual thread technology utilizes JVM-level lightweight threads to achieve high-density concurrency; a single physical thread can support tens of thousands of virtual threads, reducing memory consumption and context switching overhead, and lowering latency compared to traditional threads.

[0036] The tile data integrity verification module ensures the reliability of tile data throughout the entire process of production, transmission, storage, and retrieval through a multi-level verification mechanism and dynamic verification algorithm. Simultaneously, in conjunction with the browser rendering module, it generates a tile health analysis view, enabling visualization of quality inspection results. The tile integrity detection module includes:

[0037] 1. Multi-level verification mechanism

[0038] The multi-level verification system constructs a reliability assurance framework covering the entire data lifecycle through a hierarchical and multi-dimensional verification mechanism. Level 1 verification primarily focuses on data block integrity. It generates tile checksums using a tile data hashing algorithm and utilizes CRC32 (Cyclic Redundancy Check 32-bit, a verification method used to detect errors in data transmission and storage) to achieve underlying data consistency verification, ensuring that tiles are not corrupted during transmission and storage. Level 2 verification establishes spatiotemporal correlation verification, including tile generation time and neighborhood topology relationships. When a tile verification fails, it automatically triggers correlation verification of neighboring tiles, forming a spatial pollution tracing capability. Level 3 verification integrates browser extension components. Through browser-side components, tile verification capabilities are enriched in three dimensions: request interception, dynamic verification, and real-time feedback. The browser-side component mainly captures map tile requests (such as / 1 / 3 / 4.png) in real time through the browser's Web Request API and uses Service Worker multi-threading to perform integrity verification in the background. By comparing tile checksums, abnormal tiles are marked, and the index information of the abnormal tiles is returned through interface callbacks.

[0039] The tile data hash generation algorithm proposed in this scheme is a dynamic hash generation algorithm for geospatial tile data. It addresses the homogeneity collision risk inherent in traditional hash algorithms during tile data verification by binding coordinate features. This algorithm combines tile coordinate encoding rules to generate dynamic salt values, constructs a multi-level hash iteration model, and generates spatially and temporally unique tile verification codes. Algorithm steps:

[0040] (a) Data preprocessing

[0041] Tile segmentation: Divide the tile data (PNG / JPG format) into blocks according to the preset tile size, padding the end with zeros if necessary;

[0042] Coordinate encoding: Convert the tile coordinates {z} / {x} / {y} into a hexadecimal string and use it as a dynamic salt prefix;

[0043] (b) Dynamic salinity 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: Salt values ​​are inserted into the tile block data at fixed intervals to obtain data D1. For example, salt values ​​are inserted every 256 bytes;

[0047] (c) Multi-level hash iteration

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

[0049] 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;

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

[0051] (d) Verification code encapsulation

[0052] The H3 is encoded according to the ASN.1 format (ASN.1 is an international standard formal language, jointly developed by the International Organization for Standardization and the International Telecommunication Union, used to define an abstract syntax for data structures), and then timestamps and coordinate metadata are appended to generate the final tile check code.

[0053] 2. Dynamic Verification Algorithm

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

[0055] (a) Rule configuration system

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

[0057] The rule configuration system uses a JSON or YAML parser to convert validation rules into structured data, which is then persisted to the rule table (see Table 4).

[0058] Table 4 Main Rules Table

[0059] Serial Number Fields Data types describe 1 rule_id UUID Globally unique rule identifier 2 rule_name UUID Rule Name 3 priority Int(1-5) Priority P1-P5 4 status Enum Rule status (enabled / disabled) 5 expression String Regular expressions 7 create_time Timestamp Rule creation time 8 Creator String Rule creator

[0060] (b) Dynamic execution engine

[0061] The dynamic execution engine parses the contents of the `expression` field in the main rule table and injects them into the validation module. The validation module first uses the ANTLR tool to build a rule syntax tree, then converts the rule expressions into an abstract syntax tree (AST), and then traverses the syntax tree nodes using a listener pattern to generate Java validation code. It also provides detailed syntax error prompts to help users quickly locate syntax problems. For example, it displays the line number and context information when an unclosed parenthesis is detected.

[0062] The browser rendering module is used to provide tile management with tile production task progress information and tile service data integrity information in a clearer and more aesthetically pleasing way. For example, it can render the production progress as an analytical view. The browser rendering module includes a multi-threaded data processing architecture, a WebGL acceleration module, and a front-end data caching module, as specifically designed below:

[0063] 1. Multi-threaded data processing architecture

[0064] The core of the multi-threaded data processing architecture is to separate computational and rendering tasks. This is achieved by using Web Workers technology to create rendering and computation threads. The rendering thread is primarily responsible for UI rendering, user interaction, and visualization logic. The computation thread is used to process tile progress and quality data parsing, and to create statistical charts (e.g., tile production progress time series charts, tile progress information heatmaps, and anomaly data category statistical charts).

[0065] 2. WebGL acceleration module

[0066] The WebGL acceleration module utilizes front-end rendering libraries such as Three.js, MapLibre.js, and AntV.js to achieve high-performance geospatial data visualization. MapLibre.js and Three.js are used for vector data rendering and dynamic style updates. For example, a progress bar is drawn for each tile, and the progress bar updates in real time according to the task status. AntV.js focuses on chart creation, using WebGL technology to quickly generate various types of icons, such as line charts, bar charts, and pie charts, and renders these icons into the map component through integration with MapLibre.js.

[0067] 3. Front-end data caching module

[0068] The front-end caching module comprises two parts: tiered caching and intelligent updates. While ensuring data real-time performance, it reduces network request volume by over 70%, improving user experience and reducing server-side request pressure. Specifically, it includes:

[0069] (a) Tiered 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 understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. The solutions in the embodiments of the present invention can be implemented using various computer languages, such as the object-oriented programming language Java and the interpreted scripting language JavaScript.

[0079] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. 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, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0080] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0081] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0082] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0083] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

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. 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. 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.

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 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.

5. The real-time monitoring and integrity verification system for tile production according to claim 4, 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.

6. The real-time monitoring and integrity verification system for tile production according to claim 5, characterized in that, Tile data hash generation algorithms 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.

7. The real-time monitoring and integrity verification system for tile production according to claim 4, 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.

8. The real-time monitoring and integrity verification system for tile production according to claim 1, 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