A webgis-oriented meteorological data real-time decoding and integrated visual system and method

Abstract

This invention discloses a real-time decoding and integrated visualization system and method for meteorological data in WebGIS. Relating to the field of meteorological data processing technology, the system includes: a data access and real-time decoding module for acquiring meteorological data files and parsing them using a real-time decoding engine to obtain standardized data objects; a visualization configuration module for constructing a visualization template database; a rendering message publishing module for encapsulating the storage path and visualization configuration ID of the standardized data objects into rendering task messages; a distributed rendering module for performing graphics generation operations based on the rendering task messages and outputting panoramic images; a tile generation module for segmenting the panoramic image using a tile cutting engine; and a front-end display module for overlaying map tiles onto a base map to obtain a meteorological view and displaying it on a visualization interface. This achieves a balance between data processing efficiency and high-fidelity visual representation.

Description

Technical Field

[0001] This invention relates to the field of meteorological data processing technology, and in particular to a real-time decoding and integrated visualization system and method for meteorological data oriented towards WebGIS. Background Technology

[0002] With the rapid development of meteorological science and the widespread application of Web Geographic Information Systems (WebGIS), the real-time, dynamic, and intuitive display of meteorological data on internet platforms has become a core requirement for many fields such as meteorological services, disaster early warning, aerospace, and smart agriculture. However, in the process of this technological evolution, traditional meteorological data web visualization solutions have gradually exposed many technical bottlenecks, restricting further improvements in user experience and system performance.

[0003] Currently, most traditional web visualization solutions for meteorological data send raw meteorological data directly to the browser for rendering. Limited by the computing power of user terminals (especially CPU / GPU), these solutions struggle to efficiently process high-resolution, high-dimensional meteorological data, easily leading to browser lag and crashes, and failing to achieve complex, high-quality visualization effects. Furthermore, while pre-generating complete panoramic meteorological maps on the server side ensures image quality, the resulting images are enormous and lack spatial scale adaptability (they cannot provide different levels of detail based on the user's zoom level). This results in high network latency, high bandwidth consumption, and difficulty in supporting smooth dynamic interactions (such as smooth zooming and panning) and time-series animations. Moreover, the traditional "decoding-rendering-distribution" process is tightly coupled and lacks flexibility. In real-world scenarios involving multiple concurrent user accesses, high-frequency meteorological data updates, and diverse user demands for visualization styles, the system's scalability, real-time performance, and responsiveness are severely inadequate.

[0004] Therefore, existing meteorological data web visualization solutions have significant shortcomings in terms of "quality" and "efficiency," and more advanced methods are needed to improve the "quality" and "efficiency" of meteorological data web visualization. It is necessary to provide a real-time decoding and integrated visualization system and method for meteorological data oriented towards WebGIS to solve the above problems.

[0005] This invention provides a real-time decoding and integrated visualization system and method for meteorological data for WebGIS, in order to solve the fundamental imbalance between "efficiency" and "quality" in traditional solutions. Summary of the Invention

[0006] In a first aspect, embodiments of the present invention provide a real-time decoding and integrated visualization system for meteorological data oriented towards WebGIS, comprising:

[0007] The data access and real-time decoding module is used to continuously monitor at least one preset meteorological data source, obtain meteorological data files, parse the meteorological data files through the real-time decoding engine, encapsulate the parsed meteorological data files into standardized data objects and write them into a temporary high-speed cache area.

[0008] The visualization configuration module is used to construct a visualization template database based on preset templates and user-defined templates, wherein each template in the visualization template database corresponds to a visualization configuration ID.

[0009] The rendering message publishing module is used to encapsulate the storage path of the standardized data object in the temporary high-speed cache and the visualization configuration ID corresponding to the standardized data object into a rendering task message and publish it to the message bus.

[0010] The distributed rendering module is used to pull the rendering task messages from the message bus through the task scheduler, allocate rendering tasks to target rendering nodes according to the node idleness score, and the target rendering nodes call different rendering backends to perform graphics generation operations based on the rendering task messages, and output panoramic images with georeferenced information.

[0011] The tile generation module is used to perform layered cutting of the panoramic image through a tile cutting engine, generate a set of map tiles, and cache them.

[0012] The front-end display module is used to load the base map, obtain map tiles by constructing a tile request, overlay the map tiles on the base map to obtain a dynamic weather view, and display it on the visualization interface.

[0013] Optionally, the data access and real-time decoding module includes:

[0014] A verification unit is used to verify the validity of the meteorological data file.

[0015] The deduplication unit is used to remove duplicate meteorological data files;

[0016] The breakpoint resume unit is used to acquire complete meteorological data files.

[0017] Optionally, the visualization configuration module includes:

[0018] The first caching unit is used to store each of the templates in the visualization template database in the caching server, and update the templates in the caching server according to a preset time interval and a preset threshold.

[0019] Optionally, the message bus is implemented using an Apache Kafka cluster, consisting of at least three Broker nodes, wherein the Apache Kafka cluster is configured with a topic having a replication factor of 3, and the topic is divided into 12 partitions.

[0020] Optionally, the distributed rendering module includes:

[0021] The rendering backend selection unit is used to select the corresponding rendering backend based on the task priority in the rendering task message.

[0022] Optionally, the tile generation module includes:

[0023] The second cache unit is used to store frequently accessed tiles in the map tile set into a memory cache and to store all tiles in the map tile set into a disk cache.

[0024] Optionally, the tile generation module integrates a block processing strategy, a pyramid-style pre-sampling strategy, a geographic coordinate boundary processing strategy, a polar projection strategy, a cache invalidation strategy, and a digital watermark embedding strategy.

[0025] Optionally, the front-end display module integrates hover viewing, offline caching, periodic performance monitoring, responsive layout, dark mode, and multi-language switching.

[0026] Optionally, the front-end display module adopts an on-demand loading and progressive rendering strategy.

[0027] Secondly, embodiments of the present invention provide a real-time decoding and integrated visualization method for meteorological data oriented towards WebGIS, executed by the real-time decoding and integrated visualization system for meteorological data oriented towards WebGIS described in any embodiment of the present invention, including:

[0028] Continuously monitor at least one preset meteorological data source, acquire meteorological data files, parse the meteorological data files through a real-time decoding engine, encapsulate the parsed meteorological data files into standardized data objects, and write them into a temporary high-speed cache area;

[0029] A visual template database is constructed based on preset templates and user-defined templates, and each template in the visual template database corresponds to a visual configuration ID;

[0030] The storage path of the standardized data object in the temporary cache area and the visualization configuration ID corresponding to the standardized data object are encapsulated into a rendering task message and published to the message bus;

[0031] The task scheduler pulls the rendering task messages from the message bus and assigns rendering tasks to target rendering nodes based on node idleness scores. The target rendering nodes call different rendering backends to perform graphics generation operations based on the rendering task messages and output panoramic images with georeferenced information.

[0032] The panoramic image is layered and segmented using a tile cutting engine to generate a set of map tiles, which are then cached.

[0033] Load the base map, obtain map tiles by constructing a tile request, overlay the map tiles on the base map to obtain a dynamic weather view, and display it on the visualization interface.

[0034] (1) This invention constructs an integrated system that includes a data access and real-time decoding module, a visualization configuration module, a rendering message publishing module, a distributed rendering module, a tile generation module, and a front-end display module. The system decouples the data processing flow into an asynchronous pipeline through a message bus, enabling data decoding, task distribution, graphics rendering, and tile generation to be flexibly expanded in parallel and independently. This fundamentally reconstructs the task allocation logic of the traditional meteorological visualization system. Through loose coupling design, computationally intensive tasks are separated from resource-constrained clients or single servers and processed on demand by a dedicated distributed rendering node pool. This greatly improves the throughput and stability of the system in scenarios with high concurrency access and high frequency data updates. It solves the inherent defects in the prior art where it is difficult to balance "computational load" and "visual quality". It achieves the unity of data processing efficiency and high-end visual fidelity and has the horizontal expansion capability to cope with business peaks and future demand growth, providing a solid technical foundation for key meteorological services.

[0035] (2) This invention constructs a data ingestion pipeline with self-repair capability by using the built-in verification, deduplication and breakpoint resume units in the data access and real-time decoding module. This enables the system to actively identify and handle various abnormal conditions at the data source end, and puts the data quality control link forward and embedded at the very beginning of the data processing link. This ensures the integrity, uniqueness and correctness of the input data from the source, effectively avoids the failure of subsequent rendering tasks or the distortion of visualization results caused by dirty data or network jitter, significantly improves the reliability and robustness of the entire data pipeline, provides a solid data foundation for highly reliable meteorological analysis and decision-making, and reduces the operation and maintenance intervention costs caused by data problems.

[0036] (3) This invention adopts a highly available message bus with an Apache Kafka cluster as its core, which includes multiple partitions and topics with high replication factors to carry rendering task messages. It constructs an asynchronous, decoupled data flow hub with persistent capabilities. The message bus, as the "central nervous system" of the system, realizes the complete separation of data production (decoding module) and data consumption (rendering module) in time and space. Even if the backend rendering cluster experiences a short delay due to individual node failures or task backlog, the frontend decoding process can still run continuously without being affected. Task messages will be reliably stored in the queue, thereby avoiding data loss or blockage. It provides the system with powerful peak shaving and valley filling capabilities and fault tolerance capabilities, ensuring that the system can maintain stable service when facing data floods and maximizing business continuity.

[0037] (4) This invention systematically integrates multi-level caching strategies at multiple levels, such as the front-end display module, tile generation module, and visualization configuration module, to form a three-dimensional caching network covering data, configuration, and presentation results. This means that from the original data objects and visualization templates to the final map tiles, they are all included in an efficient cache management system. By reducing redundant calculations and data retrieval at different levels and stages, valuable computing and I / O resources are used to handle truly new requests, significantly reducing data access latency, alleviating the pressure on the back-end storage system, and significantly improving the response speed of user requests. This solves the problem that in the prior art, caching applications are often relatively simple and fragmented, and cannot form a synergy to cope with large-scale concurrent access scenarios. Through collaborative caching design, this invention greatly improves the overall throughput and resource utilization of the system, provides underlying support for achieving a fast-response user interaction experience, and reduces the dependence on external storage bandwidth and overall operating costs.

[0038] (5) This invention dynamically collects the resource indicators of each rendering node and calculates the idleness score through the task scheduler, and performs intelligent task allocation, giving the distributed rendering module inherent load balancing and elastic scaling capabilities. The rendering node pool is regarded as a dynamically schedulable unified resource pool rather than a static collection of individuals. It can automatically route newly arrived rendering tasks to the most idle and suitable node for execution, avoiding the waste of resources when some nodes are overloaded while others are idle. It solves the problem of uneven load that may be caused by using static round-robin or simple hash allocation strategies in the prior art, realizes the optimized utilization of computing resources and maximizes the efficiency of task execution, and gives the system good horizontal scalability. The overall processing capacity of the system can be linearly improved by adding rendering nodes to cope with the ever-increasing business load in the future.

[0039] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0040] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0041] Figure 1 This is a framework diagram of a real-time decoding and integrated visualization system for meteorological data oriented towards WebGIS, provided in Embodiment 1 of the present invention.

[0042] Figure 2 The flowchart illustrates a real-time decoding and integrated visualization method for meteorological data oriented towards WebGIS, as provided in Embodiment 2 of the present invention.

[0043] Figure 3 A schematic diagram of an electronic device that can be used to implement embodiments of the present invention is shown. Detailed Implementation

[0044] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0045] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0046] Application Overview:

[0047] Existing meteorological data visualization systems suffer from a fundamental imbalance between computational load distribution and visual quality assurance. This imbalance manifests itself in two ways: client-side rendering schemes, while offering interactive flexibility, are limited by terminal computing power, making it difficult to efficiently process high-resolution, high-dimensional meteorological data and easily leading to browser performance bottlenecks; server-side rendering schemes, while achieving high-quality image output, generate large panoramic images that lack spatial scale adaptability and suffer from significant latency and visual degradation in network transmission and dynamic interaction. These shortcomings collectively make it difficult for the system to balance real-time performance, visual fidelity, and interactive smoothness in real-world application scenarios such as high concurrency, high-frequency updates, and multi-user heterogeneous terminal access.

[0048] To overcome the aforementioned technical obstacles, this invention proposes a system architecture that integrates real-time decoding, dynamic configuration, distributed rendering, geographic tile generation, and cache optimization. By reconstructing the hierarchical structure and task allocation logic of the data processing link, it achieves full-process automation, standardization, and efficient collaboration from raw data access to terminal visualization. Example 1:

[0049] Figure 1 This is a framework diagram of a real-time decoding and integrated visualization system for WebGIS-based meteorological data provided in Embodiment 1 of the present invention. This embodiment is applicable to meteorological data visualization. The system can implement a real-time decoding and integrated visualization method for WebGIS-based meteorological data provided in any embodiment of the present invention. Figure 1 As shown in the embodiment of the present invention, a real-time decoding and integrated visualization system 100 for meteorological data oriented to WebGIS may include: a data access and real-time decoding module 110, a visualization configuration module 120, a rendering message publishing module 130, a distributed rendering module 140, a tile generation module 150, and a front-end display module 160. Each module achieves loosely coupled communication with a message middleware through standardized interfaces, wherein:

[0050] The data access and real-time decoding module 110 is used to continuously monitor at least one preset meteorological data source, obtain meteorological data files, parse the meteorological data files through a real-time decoding engine, encapsulate the parsed meteorological data files into standardized data objects, and write them into a temporary high-speed cache area.

[0051] The visualization configuration module 120 is used to construct a visualization template database based on preset templates and user-defined templates, wherein each template in the visualization template database corresponds to a visualization configuration ID;

[0052] The rendering message publishing module 130 is used to encapsulate the storage path of the standardized data object in the temporary cache area and the visualization configuration ID corresponding to the standardized data object into a rendering task message and publish it to the message bus.

[0053] The distributed rendering module 140 is used to pull the rendering task message from the message bus through the task scheduler, allocate the rendering task to the target rendering node according to the node idleness score, and the target rendering node calls different rendering backends to perform graphics generation operations based on the rendering task message to output a panoramic image with geographic reference information.

[0054] The tile generation module 150 is used to perform layered cutting of the panoramic image through a tile cutting engine, generate a set of map tiles, and cache them.

[0055] The front-end display module 160 is used to load the base map, obtain map tiles by constructing tile requests, overlay the map tiles on the base map to obtain a dynamic weather view, and display it on the visualization interface.

[0056] In this embodiment, the present invention constructs a modular pipeline that includes data access and real-time decoding, visualization configuration, rendering message publishing, distributed rendering, tile generation, and front-end display. It utilizes a message bus to achieve asynchronous decoupling between each stage, decomposing complex meteorological data processing tasks into standardized and professional continuous stages. Through loose coupling design, computationally intensive tasks such as data decoding, task scheduling, high-performance rendering, and tile cutting can be processed in parallel and scaled independently and elastically. This significantly improves the overall throughput and stability of the system when processing frequently updated and highly concurrent meteorological data. It solves the problem of computational load and visual quality imbalance caused by client-side rendering being limited by terminal computing power and server-side pre-rendering being constrained by large image transmission bottlenecks in existing technologies. It achieves low-latency, high-fidelity conversion from raw data to terminal visualization, providing WebGIS platforms with integrated dynamic meteorological data visualization capabilities with industrial-grade reliability.

[0057] The following sections will describe each module in detail.

[0058] The data access and real-time decoding module 110 is used to continuously monitor at least one preset meteorological data source, obtain meteorological data files, parse the meteorological data files through a real-time decoding engine, encapsulate the parsed meteorological data files into standardized data objects, and write them into a temporary high-speed cache area.

[0059] Specifically, the input end of the data access and real-time decoding module can be connected to one or more preset meteorological data sources. The meteorological data sources include, but are not limited to, remote meteorological data center servers based on file transfer protocols (FTP / SFTP), real-time meteorological data interfaces conforming to RESTful or WebSocket specifications, and local file system directories.

[0060] The data access and real-time decoding module includes a monitoring unit, which is configured with a continuously running file monitoring service to poll the status of the connected data source at fixed time intervals (e.g., 10 seconds) or monitor file write events in the local file system directory through the inotify mechanism. When a new meteorological data file arrives or an existing meteorological data file is updated, the decoding process is immediately triggered. The meteorological data file is a file using a standard meteorological data exchange format, such as GRIB2 (GRIdded Binary Version 2) or NetCDF (Network Common Data Form). The meteorological data file encapsulates at least one meteorological element field and its associated metadata. A meteorological element field refers to a data set of one or more meteorological physical quantities (temperature, air pressure, wind speed, wind direction, humidity, precipitation, cloud cover) distributed continuously or discretely in two-dimensional or three-dimensional geographic space at a specific time or period; essentially, it is the "numericalization" of a physical quantity (temperature, air pressure, wind speed, wind direction, humidity, precipitation, cloud cover) on the Earth's surface or atmosphere and its mapping onto a spatial grid.

[0061] For example, a meteorological element field can be understood as a "grid paper" filled with numerical values ​​overlaid on a map. The number in each cell of this "paper" represents the meteorological conditions at that location. Metadata can be understood as information describing the data itself, such as the data's time (reporting time, forecast time), spatial range (latitude and longitude boundaries), spatial resolution, etc. Specifically, metadata mainly includes: reporting time (UTC timestamp format), forecast lead time (in hours), geographic projection type (usually isotropic projection), latitude and longitude grid range (longitude: -180° to 180°, latitude: -90° to 90°), spatial resolution (Δλ=0.1°, Δφ=0.1°), vertical layer information (barometric coordinates or model layer number), and data compression method (JPEG2000 or PNG).

[0062] In one specific embodiment, when the file listening service of the data access and real-time decoding module detects a new meteorological data file, this file may be named "IFS_HR_2021040500_003.grib2", where IFS_HR represents the high-resolution version of the ECMWF integrated forecast system; 2021040500 represents the start time of the forecast as 00:00 on April 17, 2021 (UTC); 003 represents the forecast lead time as 3 hours, that is, this is a forecast for 3 hours after the start time (03:00 UTC on April 17, 2021); and it is a GRIB2 format binary file. The file is like a container, encapsulating global grid data of multiple meteorological element fields (such as temperature, air pressure, wind speed, etc.) at a specific time. Each meteorological element field has its corresponding small metadata header.

[0063] The decoding process is executed by a decoding unit, which can be an embedded real-time decoding engine. This engine integrates the GRIB2 decoding library and the NetCDF parsing library, employing a multi-threaded parallel processing mechanism to parse the meteorological data file segment by segment. During parsing, the header information of the meteorological data file is first read, and global metadata is extracted. This metadata includes the dataset's start time (UTC timestamp format), forecast lead time (in hours), geographic projection type (usually isotropic projection), latitude and longitude grid range (longitude: -180° to 180°, latitude: -90° to 90°), spatial resolution (Δλ=0.1°, Δφ=0.1°), vertical hierarchy information (barometric coordinates or model layer), and data compression method (JPEG2000 or PNG). Based on the metadata, the data blocks corresponding to each meteorological element field are located, and the corresponding decoding algorithms are called for reverse encoding and restoration. These algorithms include JPEG2000 entropy decoding, PNG prediction inverse transformation, and grid data differential restoration, recovering the original floating-point two-dimensional or three-dimensional numerical array, i.e., the parsed data. For example, assuming only the temperature field at the 850 hPa isobaric surface height is needed, the decoding engine will perform the following operations: Locate the data block with the temperature field (Temperature) and vertical level information "level=850 hPa" based on the metadata. Read the metadata of this data block and determine: the grid type is an equal latitude and longitude grid, the range is longitude from 0° to 359.9°, latitude from 90° to -90° (i.e., globally), the resolution is 0.1° x 0.1°, the grid size is 3600 columns (longitude) x 1800 rows (latitude), and the data compression method is JPEG2000. Call algorithms such as JPEG2000 entropy decoding to restore the compressed binary data into an original floating-point two-dimensional numerical array. The parsed data is a large two-dimensional array (matrix) containing precise physical values, for example:

[0064] temperature_850hPa_global_grid = [

[0065] [285.2, 285.3, 285.5, ... ], # Line 1 (around 90 degrees North latitude)

[0066] [286.1, 286.0, 285.8, ... ], # Line 2 ...,

[0067] [299.8, 299.5, 299.1, ... ] # Line 1800 (around 90 degrees south latitude) ]

[0069] After decoding, the numerical array and its metadata are encapsulated into standardized data objects. These standardized data objects are stored using an internally defined binary serialization format. The standardized data objects include: data identifiers, timestamps, geographic bounding boxes, resolution parameters, variable names, units, and extended attribute fields. The data identifier is generated by combining the reporting start time, feature name, and hierarchical index, for example, "2021040500_TEMP_850hPa". The timestamp can use a Unix timestamp with millisecond precision, for example, "forecast_reference_time": 1747440000000, / / Reporting start timestamp (2021-04-17 00:00:00 UTC), "lead_time": 10800, / / Forecast lead time (seconds), 3 hours = 10800 seconds. The geographic bounding box can be the minimum bounding rectangle in the WGS84 coordinate system, with xmin=-180, xmax=180, ymin=-90, ymax=90; resolution parameters, for example, dx=0.1, dy=0.1; variable name, for example, "temperature"; unit, for example, "K" (Kelvin). Vertical hierarchy information, "level": 85000, / / Vertical hierarchy (Pascals). Extended attribute fields include decoding time (e.g., 2021-04-17T00:05:23Z), decoding engine version (e.g., ecCodes v2.24.0), data source identifier ("ECMWF_IFS") and validation status ("valid", indicating that the data passed the validity check), and original filename (e.g., IFS_HR_2025041700_003.grib2), forming a complete data traceability record.

[0070] The standardized data object can be written to a temporary cache for subsequent modules to call. For example, the standardized data object can be written to a temporary cache built on a Redis cluster, and a unique "access credential", i.e., storage path, is generated synchronously. The data identifier in the standardized data object and its corresponding storage path are written as key-value pairs to the temporary cache (Redis). The validity period can be set to 24 hours for subsequent modules to call.

[0071] In this embodiment, the data access and real-time decoding module continuously monitors, automatically acquires, and parses multi-source meteorological data files in real time. An embedded decoding engine converts the raw binary data into standardized data objects containing complete metadata, which are then written to a high-speed cache. This constructs a unified and efficient data entry point, encapsulating the differences and complexities of heterogeneous data sources within the module. The standardized data objects generated after decoding provide a unified and clean data interface for downstream processes, ensuring data format consistency and semantic clarity from diverse data sources to the system's internal processing flow. This significantly reduces the processing burden on subsequent modules, achieving automated data access and real-time parsing. This provides a reliable data foundation for the efficient and stable operation of the entire visualization pipeline, guaranteeing the accuracy and timeliness of the final visualization results from the source.

[0072] Furthermore, the data access and real-time decoding module also includes:

[0073] A verification unit is used to verify the validity of the meteorological data file.

[0074] The deduplication unit is used to remove duplicate meteorological data files;

[0075] The breakpoint resume unit is used to acquire complete meteorological data files.

[0076] The data optimization unit is equipped with a data validity verification mechanism, which includes: file integrity check, reporting time rationality check, and data value range physical meaning check.

[0077] Specifically, the file integrity check involves calculating a checksum using the CRC32 algorithm and comparing it with the checksum carried in the metadata. For example, running the CRC32 algorithm on a newly received raw meteorological data file (such as IFS_HR_2025041700_003.grib2) generates a checksum, such as 0x58C83B91. The original checksum (e.g., 0x58C83B91) provided by the sender is read from the metadata in the file header. If the file is intact, the integrity check passes; if it doesn't match, the file may be corrupted, and the check fails.

[0078] Start time reasonableness check: The start time (e.g., 2021-04-17T00:00:00Z) is parsed from the file metadata and compared with the current system time (e.g., 2021-04-17T05:30:00Z). The start time is verified to be within a reasonable range (±2 hours deviation). A deviation of 5.5 hours is observed, outside the reasonable range, thus the verification fails. If the start time is verified to be within a reasonable range, the start time reasonableness check passes.

[0079] Physical meaning check of data value range: A fast scan is performed on the decoded floating-point numerical array; it is checked whether the data value range exceeds the physical meaning. For example, for a temperature field, a temperature below 150K or above 350K is considered abnormal. If all values ​​are within the range of [150, 350], the check is passed.

[0080] If any verification fails, an error log is recorded to the central logging system (ELK Stack), the log level is set to ERROR, and the task is discarded to prevent invalid data from entering subsequent processes.

[0081] The data optimization unit also includes a data deduplication mechanism. It calculates the content fingerprint of processed files using the SHA-256 hash function and stores the hash value in the Redis collection "processed_files". Each time a new file arrives, its hash value is compared to the previous one to avoid duplicate decoding and wasted computing resources. For example, when the new file IFS_HR_2021041700_003.grib2 arrives, the system calculates its content's SHA-256 hash value. This is a unique "digital fingerprint"; even if the filename is the same but the content is different, the hash value will be completely different. The system checks if this hash value exists in the Redis collection "processed_files". If it exists, it means the file has already been processed, the system records an INFO-level log and skips the file. This can be further understood as: if the same file is detected a second time by the monitoring service, and its SHA-256 hash value can be found in Redis, the system will silently ignore it. If it does not exist, it means this is a new file, the system proceeds with decoding and subsequent processes normally, and adds this new hash value to the "processed_files" collection. This can be further understood as follows: if a file is updated (even if only one byte is changed), its SHA-256 will change, and it will be treated as a new file.

[0082] The interruptible download unit is equipped with a mechanism to resume downloads from where interruption occurred. For incomplete meteorological data files downloaded due to network interruptions, an HTTP Range request is used to resume downloading the remaining meteorological data from the point of interruption, ensuring data integrity. For example, the system downloads the file IFS_HR_2025041700_003.grib2 from a data source via HTTP / FTP. When the file download reaches 80% (e.g., 800MB downloaded, total size 1GB), the network connection is interrupted. The number of bytes successfully downloaded (800MB) is recorded. When the network is restored, the system does not restart the download but instead sends a special HTTP Range request to the server, telling the server, "Please send me the remaining part of the file starting from byte 800,000,000." A server supporting interruptible downloads will return a status code 206 Partial Content and only transfer the remaining 200MB of data. After the system appends the newly downloaded 200MB of data to the existing 800MB file on the local machine, and passes the integrity check (such as CRC32), it marks the file as "completely downloaded" and triggers the subsequent decoding process.

[0083] In this embodiment, by performing validity verification, deduplication, and breakpoint resumption on the meteorological data files, data quality control and acquisition reliability are taken as core pre-processing steps. Through automated processes, abnormal situations such as file corruption, content duplication, and network transmission interruption that may exist at the data source are proactively identified and handled. This ensures the integrity, uniqueness, and correctness of the input data from the source, effectively blocking invalid or duplicate data from entering the subsequent processing flow. It avoids the waste of rendering resources and the distortion of visualization results caused by dirty data, ensuring the robustness and continuity of the data acquisition process. This provides a stable and reliable data supply foundation for the entire visualization system, significantly reduces the operation and maintenance intervention costs caused by data problems, and ensures the continuity and high credibility of meteorological service products.

[0084] The visualization configuration module 120 is used to construct a visualization template database based on preset templates and user-defined templates, wherein each template in the visualization template database corresponds to a visualization configuration ID.

[0085] The visualization configuration ID is a globally unique string identifier, generated by combining a timestamp (YYYYMMDDHHMMSS), data type (such as "TEMP" or "WIND"), and version number (vX.YZ). The timestamp typically uses the time of template creation or the last major modification. This ensures the global uniqueness of the ID, making duplication virtually impossible. The data type directly relates to the meteorological elements served by the template and is a key field for matching data with the template. The version number uses semantic versioning. When a user modifies the template, the system automatically upgrades the version number based on the modification type; for example, bug fixes upgrade the revision number, adding features upgrades the minor version number, and incompatibility changes upgrade the major version number. For instance, a user created a new temperature template at 2:30 PM on April 18, 2021, with the configuration ID: 20250418143000_TEMP_v1.0.0.

[0086] The visualization template database can be organized using a PostgreSQL relational database, with each record corresponding to a visualization template. Each record stores a set of rendering parameters for a visualization template, including: a color map, contour intervals, alpha ramp, vector arrow density, wind plume symbol style, legend layout, and annotation font and color. The color map defines the mapping relationship between meteorological element values ​​and the RGB color space, and can use piecewise linear interpolation. It supports user-defined control points, each containing a numerical threshold and a corresponding color value (RGBA format). For example, for the land surface temperature field, 11 control points can be configured, as shown in Table 1.

[0087] Table 1

[0088] Data value (K) RGBA colors illustrate 240 #0000FFFF Extremely cold, opaque blue 260 #00FFFFFF Cold, blue 280 #FFFF00FF Mild, yellow 300 #FF0000FF Hot, red 320 #800000FF Extremely hot, dark red

[0089] The system generates continuous color bands during rendering using linear interpolation. For example, when the system receives a temperature value (e.g., 285K), it performs linear interpolation between adjacent control points (280K and 300K) to calculate the corresponding color (approximately #FFBF00FF, an orange-yellow). The contour line intervals are floating-point numbers, representing the numerical difference between adjacent contour lines; for example, if the temperature field is set to 5K, the system will automatically draw a series of contour lines at 240K, 245K, 250K, etc., to clearly display the temperature gradient distribution. For example, the transparency function is an array of length 256, defining the mapping from "data intensity" to "transparency." For example, when the temperature layer is overlaid with a base map or other layers (e.g., precipitation), it may be desirable for lower temperature areas to be more transparent to avoid obscuring important information; in this case, the input is the normalized data intensity (0 represents the minimum value of 240K, 1 represents the maximum value of 320K), and the output is the transparency (0 for completely transparent, 255 for completely opaque). The specific transparency function formula is as follows:

[0090]

[0091] Here, α is the output value, representing transparency (Alpha), ranging from 0 to 255; normalized_value is the input value, representing the normalized data intensity. An exponent of 1.5 allows transparency to increase more quickly when data values ​​are low, thus more effectively highlighting high-value areas (such as high-temperature areas) and preventing low-value areas from excessively obscuring the underlying map or other meteorological layers.

[0092] This visual configuration module provides a RESTful API interface based on the HTTPS protocol, allowing authorized users to upload, modify, or delete preset templates through the front-end management interface. All changes are logged and version increments are triggered, with the new version permanently stored as a new record in the PostgreSQL database (visual template database). For example, if a user creates a new temperature template with ID 20250418143000_TEMP_v1.0.0 at 2:30 PM on April 18, 2025; subsequently, if the user modifies the contour interval, the modified version will have ID 20250418143000_TEMP_v1.0.1 (version updated, timestamp unchanged); and if the user completely changes the color scheme structure, the modified version will have ID 20250418143000_TEMP_v2.0.0 (major version number updated).

[0093] Optionally, the visualization configuration module 120 includes: a first caching unit, used to store each of the templates in the visualization template database in a caching server, and update the templates in the caching server according to a preset time interval and a preset threshold.

[0094] When a user clicks "Save" or "Publish" a new template in the management interface, the system immediately and automatically compiles it into an optimized binary rendering instruction package, serializes it using Protocol Buffers format, compresses it, and stores it in a Redis distributed cache server with the key "config:{config_id}". The preset time interval (TTL) is set to 7 days to ensure that rendering nodes can quickly retrieve it. The preset threshold refers to the number of times a template is used by rendering tasks. If a template has not been used by any rendering task within 7 days (0 times), it is considered a "low-frequency" template and can be removed from the cache to save resources. If a template has been used by rendering tasks more than 0 times within 7 days, it is considered a "high-frequency" template and can be updated (i.e., the template is not in the cache within 7 days) or kept in the cache (i.e., the template is in the cache within 7 days). In addition, newly published / modified templates will be automatically added to the cache, and their retention depends on their subsequent popularity (i.e., the number of times they are used). For example, suppose a template (such as 20250418143000_TEMP_v1.0.0) expires in the Redis cache (it is automatically deleted after 7 days). When the next rendering task needs this template, the rendering node's request to Redis will fail (cache miss). However, the rendering node will not report an error; instead, it will send a request to the backend visualization configuration module. The configuration module will search for the original record of the template again from the PostgreSQL database, recompile it into a binary instruction package, and put it back into the Redis cache. At the same time, it will reset the 7-day TTL. By setting an efficient cache cleanup strategy with a 7-day TTL, it ensures that only "hot" data is retained in Redis. Even if the cache expires, the system has a robust fault tolerance and automatic recovery mechanism to ensure that business operations are not affected, achieving an optimal balance between performance and resource consumption.

[0095] Furthermore, the visual configuration module supports a configuration inheritance mechanism. Specifically, users can select "Create based on existing template" in the front-end interface and then select a parent template from the list, such as BASE_TEMP_v1.0.0. Users only need to modify the parameters that need adjustment, such as changing the color mapping from "blue-white-red" to "purple-pink-red", and the system will automatically inherit the rest to generate the final effective configuration, reducing the workload of repetitive configuration.

[0096] Furthermore, template versions are managed using semantic version numbers (SemVer), which include a major version number, a minor version number, and a revision number. These provide clear meaning for configuration changes and form the cornerstone of system collaboration. The version number change rules are as follows: When the major version number (X) is incompatible with API or structural changes, it is updated from v1.0.0 to v2.0.0, indicating a destructive update. Rendering nodes using the old version configuration may not be able to resolve the new configuration and must be upgraded. When the minor version number (Y) is backward compatible with new features, it is updated from v1.0.0 to v1.1.0, indicating functional enhancement. Older rendering nodes can ignore the new features but cannot utilize them. When the revision number (Z) fixes backward compatibility issues, it is updated from v1.0.0 to v1.0.1, indicating bug fixes. This is transparent to users and the system, and it is recommended to update to the latest revision as soon as possible. For example, "TEMP_v2.0.0" can indicate a reconstruction of the color mapping structure, requiring recalibration of control points; "TEMP_v1.1.0" indicates the addition of nighttime dark mode adaptation; and "TEMP_v1.0.1" indicates the correction of a certain threshold mapping error.

[0097] In this embodiment, the inheritance mechanism solves the problem of "horizontal" code reuse, which can easily create various variants, enabling rapid response to changes in business needs while ensuring the stability and maintainability of core services.

[0098] The rendering message publishing module 130 is used to encapsulate the storage path of the standardized data object in the temporary cache area and the visualization configuration ID corresponding to the standardized data object into a rendering task message and publish it to the message bus.

[0099] Specifically, a simple query can be initiated to Redis using the data identifier within the standardized data object as the key, and Redis will immediately return the corresponding storage path. The visual configuration ID corresponding to the standardized data object is determined through a preset mapping rule. This preset mapping rule is a preset mapping relationship table, specifically a mapping relationship table between variable names in the standardized data object and visual configuration IDs. For example, this mapping relationship table is shown in Table 2:

[0100] Table 2

[0101] Variable name Visual configuration ID air temperature default_temperature_map_v2 wind_speed default_wind_speed_barbs_v1 relative_humidity default_humidity_spectrum_v1

[0102] The rendering message publishing module can extract the `standard_name` (e.g., `air_temperature`) by reading the metadata of the standardized data object, and then query the aforementioned mapping table to obtain the default configuration ID (e.g., `default_temperature_map_v2`). Furthermore, users can manually select a visualization style on the front-end interface. This selection generates a specific visualization configuration ID. The rendering message publishing module will prioritize using the visualization template corresponding to the user-selected visualization configuration ID, rather than the template corresponding to the visualization configuration ID in the default mapping table.

[0103] The standardized data object's storage path, along with its corresponding visualization configuration ID, task priority, and task submission timestamp, is encapsulated into a rendering task message and published to a high-availability message bus. This message bus can utilize a distributed stream processing platform, supporting message persistence and multi-consumer subscriptions. It is implemented using an Apache Kafka cluster, consisting of at least three Broker nodes. In the event of a single node failure, other nodes can immediately take over the service, ensuring high availability. Deployed on a dedicated server running Ubuntu 22.04 LTS with Kafka version 3.7.0, the topic "render-task" is configured with a replication factor of 3, meaning each message exists simultaneously on three nodes. Even if two nodes fail simultaneously (an extremely low probability), data is not lost, providing strong data persistence. With 12 partitions, equivalent to 12 parallel pipelines, the system's throughput and scalability are significantly improved. When tasks accumulate, the consumption capacity can be increased by adding rendering nodes.

[0104] The rendering task messages are serialized using Protocol Buffers format, which greatly saves network bandwidth and storage space. The rendering task message includes the following fields: data object storage path (pointing to the specific location in the distributed file system), visualization configuration ID, task priority (automatically set according to data timeliness), and task submission timestamp (filled with the current time in Unix milliseconds). The task priority is automatically set based on data timeliness: P0 (real-time observation data): highest priority, suitable for disaster early warning, real-time monitoring, etc., requiring minimal latency. P1 (nowcast 0-6 hours): high priority, crucial for short-term decision-making. P2 (medium-term forecast 6-72 hours): normal priority, suitable for routine planning and forecasting. P3 (historical archived data): low priority, suitable for scientific research analysis or historical review, and can be processed in the background.

[0105] After completing the writing of the standardized data object, the rendering message publishing module can immediately construct the rendering task message and send the serialized rendering task message to the preset Kafka topic named "render-task" through the Kafka Producer client.

[0106] In this embodiment, messages are sent to the render-task topic through Kafka Producer, which completely decouples the data decoding process from the rendering execution process. Even if the distributed rendering module experiences a brief delay due to high load, the rendering task messages will still be reliably queued in the message queue and will continue to be processed after the system resources are released, thereby ensuring the integrity and robustness of the data processing link.

[0107] The distributed rendering module 140 is used to pull the rendering task message from the message bus through the task scheduler, allocate the rendering task to the target rendering node according to the node idleness score, and the target rendering node calls different rendering backends to perform graphics generation operations based on the rendering task message, and outputs a panoramic image with geographic reference information.

[0108] Specifically, the distributed rendering module consists of a task scheduler and multiple rendering nodes, deployed in an independent computing resource pool. This resource pool comprises physical servers or virtual machines, with each node interconnected via a local area network (LAN) with a bandwidth of at least 10Gbps. The task scheduler, as the core coordination unit of the module, continuously subscribes to the "render-task" topic and pulls tasks from the message queue using either round-robin or load-based scheduling strategies. The scheduler periodically collects CPU utilization, GPU utilization (obtained via nvidia-smi), memory usage, and disk I / O latency of each rendering node through the Prometheus client, and comprehensively weights and scores the idle time of the computing nodes. When a new rendering task message is received, the scheduler selects the node with the highest score as the target rendering node and sends the task allocation instruction to that node via an internal RPC communication mechanism. The selected target rendering node starts the rendering process. First, based on the visualization configuration ID in the rendering task message, it sends an HTTP GET request to the visualization configuration module to obtain the corresponding binary rendering instruction package. If the request fails, it reads the latest version of the configuration from a local cache copy to ensure that the rendering process is not interrupted. After obtaining the visualization configuration template, the rendering node reads the standardized data object from the cache according to the standardized data object storage path and loads it into the memory buffer. The rendering node then performs graphics generation operations based on the visualization configuration template, which are completed by different rendering backends.

[0109] The distributed rendering module 140 includes: a rendering backend selection unit, used to select the corresponding rendering backend according to the task priority in the rendering task message:

[0110] Specifically, the rendering backend includes a professional 3D rendering engine encapsulation interface and a high-performance scientific plotting library. Rendering tasks with priorities P0 and P1 activate the 3D rendering engine; rendering tasks with priorities P2 and P3 activate the scientific plotting library. The professional 3D rendering engine encapsulation interface calls a containerized Blender rendering instance via inter-process communication. The Blender instance loads a preset meteorological scene template, which includes an elevation-driven terrain model, atmospheric scattering parameters (Rayleigh and Mie scattering coefficients), dynamic light source configuration (sun position changing over time), and a particle system (for simulating cloud movement). The rendering node uses the meteorological element field as volumetric texture input, driving Blender to perform Cycles ray tracing rendering to generate a panoramic image with realistic lighting effects; the output resolution is 16384×8192 pixels, the frame rate is 15fps, and the rendering time is approximately 90 seconds. The high-performance scientific plotting library is a high-speed rasterization engine developed in C++, supporting OpenMP multi-threaded acceleration. It uses bilinear interpolation to resample the original meteorological grid to the target resolution (e.g., 10000×5000 pixels), and combines GPU-accelerated GLSL shader programs to perform color mapping and transparency blending, ultimately outputting 24-bit true-color image data with an alpha channel. For high-priority tasks or scenarios requiring cinematic visual performance, a professional 3D rendering engine is enabled; for routine forecast products or tasks with high real-time requirements, the high-performance scientific plotting library is enabled.

[0111] After rendering, the generated panoramic image is stored in a distributed storage system in lossless compressed PNG format or lossy but high-compression WebP format (quality factor 85). The image file embeds georeferenced information, written using the GeoTIFF standard IFD tag format, including the latitude and longitude coordinates (-180, 90) of the top-left corner of the image, pixel resolution (0.018° / pixel), projection parameters (WKT format WGS84 or other latitude and longitude projections), and a list of control points (GCPs) to ensure geographic coordinate accuracy. After completing the task, the rendering node uploads the execution log to the central log system. The log includes fields such as: task ID, start time, end time, GPU core consumption (GPU-hours), rendering resolution, output file size (bytes), and success status. The log is used for subsequent performance analysis and cost accounting.

[0112] In this embodiment, the resource status of the rendering node cluster is dynamically evaluated by the task scheduler, and intelligent task allocation is performed based on idleness scores. At the same time, based on the priority attributes carried in the rendering task messages, a matching high-performance scientific plotting library or professional 3D rendering engine or other differentiated backends are automatically selected. This achieves fine-grained management of computing resources and precise matching of task requirements, transforming the static rendering node pool into a dynamic resource pool that can perceive load and distinguish the urgency of tasks. This ensures that high-priority tasks (such as real-time alarm data) can be responded to quickly and enjoy high-quality rendering, while also ensuring the overall optimization of system throughput. It avoids idle or congested computing resources, significantly improving the operating efficiency and resource utilization of the distributed rendering cluster. Even in high-concurrency scenarios, it can still provide low-latency, high-fidelity visualization output for critical meteorological services.

[0113] The tile generation module 150 is used to perform layered cutting of the panoramic image through a tile cutting engine, generate a set of map tiles, and cache them.

[0114] Specifically, the tile generation module takes a pre-generated panoramic image with georeferenced information as input and outputs a set of XYZ format map tiles conforming to WebGIS standards. The tiles are 256×256 pixels in PNG or WebP encoding format. This module is equipped with a tile cutting engine developed based on the GDAL (Geospatial Data Abstraction Library) library, supporting various projection transformations and resampling algorithms. The cutting process is executed according to a preset scaling hierarchy, covering levels 0 to 18, where level 0 corresponds to the global view (256×256 pixels), and level 18 corresponds to the highest detail resolution (approximately 0.0007° / pixel), with the number of tiles increasing fourfold at each level. For example, Level 0: Global view, 1 tile (256×256 pixels); Level 1: 4 tiles (2×2 grid); Level 2: 16 tiles (4×4 grid); ...; Level 18: 268,435,456 tiles (16,384×16,384 grid); Resolution: approximately 0.0007° / pixel (equator). For each level, the row and column numbers of all tiles within the current image coverage area are calculated according to the tile matrix organization rules of the OGC WMTS standard. For each tile to be generated, the cutting engine performs the following operations: First, it calculates the geographic bounding box based on the tile's row and column numbers and level number (z / x / y number); then, it projects the bounding box onto the pixel coordinate system of the panoramic image; next, it crops a 256×256 pixel sub-image of the corresponding area from the image buffer; finally, it applies an anti-aliasing resampling filter (using a Lanczos3 core) to the sub-image to improve visual quality and encodes it into PNG or WebP format.

[0115] Furthermore, the tile generation module 150 includes: a second cache unit, used to store frequently accessed tiles in the map tile set into a memory cache, and to store all tiles in the map tile set into a disk cache.

[0116] Specifically, to avoid redundant calculations and improve efficiency, the cache unit integrates a multi-level caching mechanism, consisting of a memory cache and a disk cache. The memory cache is implemented based on a Redis server, employing an LRU (Least Recently Used) eviction policy to store the binary content of frequently accessed tiles; the cache hit rate target is ≥90%. The disk cache uses a high-performance file system built with an SSD array, persistently storing all generated tiles in a hierarchical / row / column directory structure. Tile generation requests first query the memory cache; if a hit occurs, it is returned directly. If a miss occurs, the disk cache is queried; if the tile exists, it is loaded into memory and returned. Only when both cache levels fail to find the tile is the real-time tile splitting process triggered, and the generated tile is immediately written to both the disk and memory caches.

[0117] Furthermore, the tile generation module 150 is also configured with a tile pre-generation service. This service analyzes hotspot areas and frequently used levels based on historical access logs, and generates and caches high-value tiles in batches in advance, significantly reducing the response latency of online requests.

[0118] Furthermore, the tile generation module 150 integrates a block processing strategy, a pyramid-style pre-sampling strategy, a geographic coordinate boundary processing strategy, a polar projection strategy, a cache invalidation strategy, and a digital watermark embedding strategy.

[0119] Specifically, the tile cutting engine employs a block-based processing strategy when handling large images. This involves dividing the image into horizontal strips of 2048 pixels high, with each strip being independently cut and written into the target tile. This reduces peak memory usage per operation and prevents memory overflow. For example, it can directly cut a panoramic image with tens of thousands of pixels in width and height... Figure 1 Loading an image into memory for segmentation all at once can instantly consume a large amount of memory (potentially exceeding 10GB), easily leading to an OutOfMemory (OOM) crash. By adopting a block processing strategy, the image is horizontally segmented into strips with a height of 2048 pixels, and processed strip by strip. This reduces the peak memory usage per operation from the size of the entire image to the size of a single strip, greatly reducing the pressure on memory and enabling the system to stably process ultra-large-scale images.

[0120] When generating high-level tiles, the tile generation module 150 employs a pyramid-style pre-downsampling strategy. This involves first downsampling the original image in powers of 2 to generate multi-level overview pyramids, and then cutting tiles from each overview pyramid to represent the corresponding level. This avoids repeated large-scale resampling of the original large image, improving the efficiency of high-level tile generation. For example, when generating high-level tiles (e.g., z=10), resampling from the original highest resolution image (e.g., 16384x8192) each time would be computationally intensive and inefficient. By using the pyramid-style pre-downsampling strategy, a series of "overview pyramids" with progressively halved resolutions are pre-generated for the original image, forming a pyramid structure: Level 0: Original image (16384x8192), Level 1: Overview pyramid (8192x4096), Level 2: Overview pyramid (4096x2048), ... When a certain level of tiles needs to be generated, the system selects the overview image with the closest resolution to the target tile as the input source for cutting, avoiding unnecessary and large-scale resampling calculations, which significantly improves the generation speed of high-level tiles. It is a classic optimization of "trading space for time".

[0121] For images that cross the International Date Line (±180°), the tile generation module 150 employs a geographic coordinate boundary processing strategy, automatically detecting the longitude range. If the longitude range is crossed, the image is split into two parts ([-180,0] and [0,180]) and cut separately. For example, a globally covered image with equal latitude and longitude projection has a longitude range of [-180°, 180°]. When a user browses the central Pacific region, the map crosses the ±180° longitude line. If directly cut, the tile coordinates will be broken, causing the map to be discontinuous. The tile generation module 150 uses a geographic coordinate boundary processing strategy to automatically detect whether the image's longitude range crosses ±180°. If it does, it logically splits the image at longitude 0° into a "Western Hemisphere part" and an "Eastern Hemisphere part," and cuts them separately to generate tiles that are correctly stitched together at ±180°.

[0122] For polar stereo projection images, the tile generation module 150 employs a polar projection strategy, using a spherical triangulation algorithm to map the circular coverage area onto the tile grid, ensuring the geometric correctness of tiles in high-latitude regions. For example, the commonly used Web Mercator projection suffers from significant distortion in the Arctic and Antarctic regions, rendering it unusable. Polar stereo projection is the standard practice, but its coverage area is circular, while the tile grid is square. The tile generation module 150 uses a polar projection strategy, employing a spherical triangulation algorithm to accurately map the circular coverage area onto the square tile grid; for tiles outside the circular coverage area, either no tiles are generated, or transparent tiles are generated, ensuring that geographic features in high-latitude regions are correctly drawn on the tiles.

[0123] The tile generation module 150 employs a cache invalidation strategy. When the underlying data or visualization configuration is updated, the system automatically marks the relevant tiles as expired and triggers regeneration on the next request, ensuring data consistency. For example, if the underlying meteorological data is corrected, or the user updates the visualization color scheme, but the tile cache is not updated, the user will see outdated and incorrect images. By adopting a cache invalidation strategy, the tile generation module 150 can automatically identify all affected tiles when data or configuration is updated and mark them as "expired." When the user requests these tiles again, the system triggers real-time regeneration and stores the new tiles in the cache.

[0124] The tile generation module 150 adopts a digital watermark embedding strategy, embedding an invisible and robust digital watermark during the tile generation process. By making tiny, regular perturbations to the pixel values ​​that are imperceptible to the human eye, metadata (such as the data source organization, generation time, and copyright information) is encoded into the image, preventing the generated tile image from being used without authorization or enabling traceability in the event of a data breach.

[0125] The front-end display module 160 is used to load the base map, obtain map tiles by constructing tile requests, overlay the map tiles on the base map to obtain a dynamic weather view, and display it on the visualization interface.

[0126] Specifically, the front-end display module runs in the user's web browser, is developed using JavaScript, and is built based on the Leaflet or OpenLayers open-source map library. During initialization, the module loads a WebGIS basemap, which is an online map conforming to the XYZ tile specification (such as OpenStreetMap or a custom basemap). This basemap is a pre-rendered static image, loads quickly, and provides the user with a geographic reference background.

[0127] Users trigger meteorological layer overlay operations through interactive controls, including a timeline slider (e.g., supporting 0–72 hour forecast sequences), layer on / off switches, and transparency adjusters. Dragging the timeline slider changes the currently displayed data time, for example, from "00:00" to "03:00 Forecast". The layer on / off switch selects the meteorological features to be displayed, for example, turning on the "Temperature" layer and turning off the "Wind Field" layer. The transparency adjuster changes the opacity of the meteorological layers to better blend them with the base map.

[0128] After a user selects a specific time and meteorological element, the front-end display module calculates the z (layer), x (column), and y (row) ranges of the tiles to be loaded based on the map's projection, center point, zoom level, and viewport size. A request URL is constructed for each required tile. In addition to z / x / y, the URL must also include the currently selected time and meteorological element information. For example, aaaa: / / bbbb / cccc / temperature / 202104180300 / {z} / {x} / {y}.eeee clearly tells the server: Please give me the temperature element at 03:00 (UTC) on April 18, 2021, at zoom level z and row / column numbers x / y.

[0129] The request is forwarded to the tile generation module via a reverse proxy gateway. The gateway first checks if the corresponding tile exists in its local cache (which could be memory, Redis, or a disk directory). If it exists, it returns the tile immediately. If it does not exist, the gateway forwards the request to the backend tile generation module. The tile generation module finds the corresponding panoramic image based on the parameters (time, features) in the URL, performs real-time cropping, and generates the required tile. The tile generation module returns the new tile to the gateway, which then returns it to the user and stores it in its cache for subsequent requests.

[0130] After receiving the tiles (whether from the cache or generated in real time), Leaflet / OpenLayers automatically stitches them onto the correct geographical location based on their z / x / y coordinates, forming a continuous meteorological element image layer covering the entire current map view. Meteorological tiles (e.g., temperature color patches, wind field arrows) are overlaid as independent image layers on top of the base map layer (geographic base map tiles, providing reference information such as streets, administrative divisions, and terrain). The browser ultimately combines the base map and all active meteorological layers into a single final image displayed to the user. However, this image is not static; it is tightly bound to the user's actions (zooming, panning, selecting time, switching features). The current view is merely a final representation of all user interactions at the current moment.

[0131] Furthermore, the front-end display module 160 also supports multi-layer overlay display. Users can simultaneously enable temperature, wind field, and precipitation layers, and achieve composite visualization by adjusting the transparency weight of each layer. Z-index controls the rendering order, and finally presents the blended effect in HTML5 Canvas.

[0132] As users drag the timeline to browse data at different times, the front-end module preloads tile groups for adjacent times according to the time sequence. Utilizing the browser's concurrent request capabilities and caching mechanism, it achieves smooth frame transitions, creating a continuous animation effect. The animation playback frame rate is consistently above 24fps, ensuring the visual continuity of the weather system's evolution.

[0133] Furthermore, the front-end display module 160 integrates hover viewing, offline caching, periodic performance monitoring, responsive layout, dark mode, and multi-language switching.

[0134] Specifically, users can hover the mouse over any location to view precise values, infer geographic coordinates from pixel coordinates, locate the four nearest grid points in the original meteorological grid, and use bilinear interpolation to calculate a weighted average as a prompt. This provides a reverse channel from graphics to data, allowing users to obtain precise values ​​from any location for quantitative analysis.

[0135] The front-end display module 160 also supports time-series animation playback, preloads adjacent time tile groups, and uses the browser's concurrent request capabilities to achieve smooth frame switching, with a stable playback frame rate of over 24fps.

[0136] Automatically enables responsive layout on mobile devices, limits the maximum zoom level to 16, and supports two-finger zoom, swipe panning, and long press to pop up an information box.

[0137] Integrating IndexedDB enables offline caching, storing recently accessed tiles. Even during network outages, cached historical images can still be viewed, providing crucial information for decision-making. Once the network is restored, the images are synchronized and updated.

[0138] The client-side performance monitoring script periodically monitors frame rate (FPS), memory usage, and JS execution time. When a stutter is detected, it automatically downgrades to a lower resolution level or disables animations. For example, it downgrades from requesting high-detail level 18 tiles to requesting level 16 tiles with clear outlines, reducing data volume and rendering pressure.

[0139] It supports dark mode, multi-language switching (Chinese / English), keyboard shortcuts, and measurement tools (calculating length, area, and regional statistics). It offers full-screen mode and print / export functionality; exported images are regenerated on the server to ensure high-quality output. Users can also generate short links containing time, layer, and view parameters to share the current view.

[0140] Furthermore, the front-end display module 160 adopts an on-demand loading and progressive rendering strategy.

[0141] Specifically, the front-end does not load all tiles at once, but only loads the tiles currently visible in the field of view. When the user drags the map, newly added tiles are dynamically loaded. This "on-demand loading" mechanism is perfectly suited to the web environment, saves bandwidth, and achieves a smooth interactive experience.

[0142] Furthermore, the system also includes a monitoring module, used to collect operational metrics for each module via Prometheus: data access latency (average <30s), decoding time (GRIB2 file <15s), message queue backlog (<100 messages), rendering node load (CPU <75%, GPU <80%), tile cache hit rate (>85%), and frontend loading time (first tile <800ms). These metrics are visualized on a Grafana dashboard, allowing operations personnel to quickly and intuitively grasp the overall system status. Intelligent alerts are also provided, for example, triggering an alert when the cache hit rate falls below 70% or the message backlog exceeds 500 messages.

[0143] The system also supports horizontal scaling. By adding Kafka Broker nodes, message queue throughput can be improved to handle data surges; adding rendering nodes linearly enhances the system's parallel rendering capabilities, quickly absorbing backlogged tasks; and scaling up Redis and SSDs directly improves the responsiveness of the tile service and the number of concurrent users supported. The system can be deployed in either private or cloud-native modes, supporting storage backends such as AWS S3 and Azure Blob. A disaster recovery strategy is employed, setting up incremental backups of critical data every 15 minutes, with an Recovery Point Objective (RPO) of <30 minutes. This means that after a disaster, the system will lose a maximum of 30 minutes of data, determined by the 15-minute incremental backup cycle, which is crucial for business continuity. The system as a whole complies with OGC WMS and WMTS standards, greatly improving its interoperability and integration capabilities; it also supports GeoJSON vector output and linkage with external early warning systems. Example 2:

[0144] Figure 2 This is a flowchart illustrating a real-time decoding and integrated visualization method for web GIS-based meteorological data, provided in Embodiment 2 of the present invention. The technical solution of this embodiment is applicable to meteorological data visualization. This method can be executed by the real-time decoding and integrated visualization system for web GIS-based meteorological data provided in any embodiment of the present invention. Figure 2 As shown, the method includes:

[0145] S210. Continuously monitor at least one preset meteorological data source, obtain meteorological data files, parse the meteorological data files through a real-time decoding engine, encapsulate the parsed meteorological data files into standardized data objects, and write them into a temporary high-speed cache area.

[0146] S220. A visual template database is constructed based on preset templates and user-defined templates, and each template in the visual template database corresponds to a visual configuration ID;

[0147] S230. Encapsulate the storage path of the standardized data object in the temporary cache area and the visualization configuration ID corresponding to the standardized data object into a rendering task message and publish it to the message bus.

[0148] S240. The task scheduler pulls the rendering task message from the message bus and assigns the rendering task to the target rendering node according to the node idleness score. The target rendering node calls different rendering backends to perform graphics generation operations based on the rendering task message and outputs a panoramic image with geographic reference information.

[0149] S250. Using a tile cutting engine, the panoramic image is layered and cut to generate a set of map tiles and cache them.

[0150] S260. Load the base map, obtain map tiles by constructing a tile request, overlay the map tiles on the base map to obtain a dynamic weather view, and display it on the visualization interface.

[0151] Optionally, after acquiring the meteorological data file, the following may also be included:

[0152] The validity of the meteorological data file is verified.

[0153] Remove duplicate meteorological data files;

[0154] Obtain the complete meteorological data file.

[0155] Optionally, after constructing a visual template database based on preset templates and user-defined templates, wherein each template in the visual template database corresponds to a visual configuration ID, the system further includes:

[0156] Each template in the visualization template database is stored in a cache server, and the templates in the cache server are updated according to a preset time interval and a preset threshold.

[0157] Optionally, the message bus is implemented using an Apache Kafka cluster, consisting of at least three Broker nodes, wherein the Apache Kafka cluster is configured with a topic having a replication factor of 3, and the topic is divided into 12 partitions.

[0158] Optionally, different rendering backends can be invoked to perform graphics generation operations, including:

[0159] The corresponding rendering backend is selected based on the task priority in the rendering task message.

[0160] Optionally, the map tile set can be cached, including:

[0161] The frequently accessed tiles in the map tile set are stored in the memory cache, and all tiles in the map tile set are stored in the disk cache.

[0162] Optionally, after obtaining map tiles by constructing a tile request, overlaying the map tiles on the base map to obtain a dynamic weather view, and displaying it on the visualization interface, the system also includes: hover viewing, offline caching, periodic performance monitoring, responsive layout, dark mode, and multilingual switching.

[0163] The real-time decoding and integrated visualization method for webGIS-oriented meteorological data provided in this embodiment of the invention can be executed by a real-time decoding and integrated visualization system for webGIS-oriented meteorological data provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the execution system. Example

[0164] Figure 3 A schematic diagram of an electronic device that can be used to implement embodiments of the present invention is shown. The electronic device 10 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0165] like Figure 3 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., which is communicatively connected to the at least one processor 11. The memory stores a computer program that can be executed by the at least one processor 11, and the computer program is executed by the at least one processor 11 to enable the at least one processor 11 to perform the method provided by the present invention.

[0166] The processor 11 can perform various appropriate actions and processes based on a computer program stored in the read-only memory (ROM) 12 or a computer program loaded from the storage unit 18 into the random access memory (RAM) 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0167] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0168] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as a real-time decoding and integrated visualization method for meteorological data for WebGIS.

[0169] In some embodiments, the real-time decoding and integrated visualization method for WebGIS-oriented meteorological data can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the real-time decoding and integrated visualization method for WebGIS-oriented meteorological data described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to perform the real-time decoding and integrated visualization method for WebGIS-oriented meteorological data by any other suitable means (e.g., by means of firmware).

[0170] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard parts (ASSPs), systems-on-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0171] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0172] In the context of this invention, a computer-readable storage medium stores computer instructions that, when executed by a processor, implement the real-time decoding and integrated visualization method for webGIS-oriented meteorological data provided by this invention. The computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. The computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, the computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0173] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device for displaying information to the user (e.g., a cathode ray tube (CRT) or a liquid crystal display (LCD monitor)); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0174] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0175] A computing system can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is established by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system. It addresses the shortcomings of traditional physical hosts and Virtual Private Server (VPS) services, such as high management difficulty and weak business scalability.

[0176] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0177] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A real-time decoding and integrated visualization system for meteorological data oriented towards WebGIS, characterized in that, include: The data access and real-time decoding module is used to continuously monitor at least one preset meteorological data source, obtain meteorological data files, parse the meteorological data files through the real-time decoding engine, encapsulate the parsed numerical array and the global metadata extracted from the file header information of the meteorological data files into standardized data objects and write them into a temporary high-speed cache area. The visualization configuration module is used to construct a visualization template database based on preset templates and user-defined templates, wherein each template in the visualization template database corresponds to a visualization configuration ID. The rendering message publishing module is used to encapsulate the storage path of the standardized data object in the temporary high-speed cache and the visualization configuration ID corresponding to the standardized data object into a rendering task message and publish it to the message bus. The distributed rendering module is used to pull the rendering task messages from the message bus through the task scheduler, allocate rendering tasks to target rendering nodes according to the node idleness score, and the target rendering nodes call different rendering backends to perform graphics generation operations based on the rendering task messages, and output panoramic images with georeferenced information. The tile generation module is used to perform layered cutting of the panoramic image through a tile cutting engine, generate a set of map tiles, and cache them. The front-end display module is used to load the base map, obtain map tiles by constructing a tile request, overlay the map tiles on the base map to obtain a dynamic weather view, and display it on the visualization interface. In the visualization template database, each record corresponds to a visualization template, and each record stores a set of rendering parameters corresponding to the visualization template. The visualization configuration ID corresponding to the standardized data object is determined by a preset mapping rule, which is a preset mapping relationship table between variable names in the standardized data object and the visualization configuration ID.

2. The system according to claim 1, characterized in that, The data access and real-time decoding module includes: A verification unit is used to verify the validity of the meteorological data file. The deduplication unit is used to remove duplicate meteorological data files; The breakpoint resume unit is used to acquire complete meteorological data files.

3. The system according to claim 1, characterized in that, The visual configuration module includes: The first caching unit is used to store each of the templates in the visualization template database in the caching server, and update the templates in the caching server according to a preset time interval and a preset threshold.

4. The system according to claim 1, characterized in that, The message bus is implemented using an Apache Kafka cluster, consisting of at least three Broker nodes. The Apache Kafka cluster is configured with a topic having a replication factor of 3, and the topic is divided into 12 partitions.

5. The system according to claim 1, characterized in that, The distributed rendering module includes: The rendering backend selection unit is used to select the corresponding rendering backend based on the task priority in the rendering task message.

6. The system according to claim 1, characterized in that, The tile generation module includes: The second cache unit is used to store frequently accessed tiles in the map tile set into a memory cache and to store all tiles in the map tile set into a disk cache.

7. The system according to claim 1, characterized in that, The tile generation module integrates a block processing strategy, a pyramid-style pre-sampling strategy, a geographic coordinate boundary processing strategy, a polar projection strategy, a cache invalidation strategy, and a digital watermark embedding strategy.

8. The system according to claim 1, characterized in that, The front-end display module integrates hover viewing, offline caching, periodic performance monitoring, responsive layout, dark mode, and multi-language switching.

9. The system according to claim 1, characterized in that, The front-end display module adopts an on-demand loading and progressive rendering strategy.

10. A method for real-time decoding and integrated visualization of meteorological data for WebGIS, characterized in that, Performed by the real-time decoding and integrated visualization system for webGIS-oriented meteorological data as described in any one of claims 1-9, comprising: Continuously monitor at least one preset meteorological data source, obtain meteorological data files, parse the meteorological data files through a real-time decoding engine, encapsulate the parsed numerical array and global metadata extracted from the file header information of the meteorological data files into standardized data objects and write them into a temporary high-speed cache area. A visual template database is constructed based on preset templates and user-defined templates, and each template in the visual template database corresponds to a visual configuration ID; The storage path of the standardized data object in the temporary cache area and the visualization configuration ID corresponding to the standardized data object are encapsulated into a rendering task message and published to the message bus; The task scheduler pulls the rendering task messages from the message bus and assigns rendering tasks to target rendering nodes based on node idleness scores. The target rendering nodes call different rendering backends to perform graphics generation operations based on the rendering task messages and output panoramic images with georeferenced information. The panoramic image is layered and segmented using a tile cutting engine to generate a set of map tiles, which are then cached. Load the base map, obtain map tiles by constructing a tile request, overlay the map tiles on the base map to obtain a dynamic weather view, and display it on the visualization interface; In the visualization template database, each record corresponds to a visualization template, and each record stores a set of rendering parameters corresponding to the visualization template. The visualization configuration ID corresponding to the standardized data object is determined by a preset mapping rule, which is a preset mapping relationship table between variable names in the standardized data object and the visualization configuration ID.

Images