An intelligent interpretation and dynamic space-time analysis platform for planetary landforms

CN122990077APending Publication Date: 2026-10-27SHAANXI NORMAL UNIV
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202611013487.6
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-07-08
Publication Date
2026-10-27

AI Technical Summary

Technical Problem

当前国际上虽已出现MarsWRF、LMD Mars GCM等火星大气模式,但其主要用于全球或区域气候模拟,在局地风沙地貌精细解译、多源遥感数据标注和交互式时空分析方面仍难以满足工程化应用需求

Benefits of technology

[0020]1.本方案中,通过在影像侧引入金字塔预生成与视口驱动的自适应瓦片尺寸选择,在缺失概览层时自动构建外部.ovr并统计动态范围,结合按可见区域中心优先级入队和仅加载相交瓦片的策略,使超大遥感影像在首次打开和连续缩放平移时,数据读取量大幅减少,画面刷新保持流畅,兼顾了全景快速浏览与局部细节精细观察的双重需求;

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122990077A_ABST
    Figure CN122990077A_ABST
Patent Text Reader

Abstract

The present application relates to the technical field of remote sensing image processing, and particularly relates to a planet geomorphology intelligent interpretation and dynamic space-time analysis platform, which comprises an image processing and rendering module, a labeling task management module and a data storage and backloading module.In the present application, pyramid pre-generation and viewport-driven adaptive tile size selection are introduced on the image side, an external.ovr is automatically constructed when the overview layer is missing, and the dynamic range is counted, the strategy of center priority in the visible area is combined with the strategy of loading only the intersecting tiles, so that when the super large remote sensing image is first opened and continuously scaled and translated, the data reading amount is greatly reduced, the picture refresh is kept smooth, and the dual needs of panoramic quick browsing and local detailed observation are taken into account.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of remote sensing image processing technology, and in particular to a platform for intelligent interpretation and dynamic spatiotemporal analysis of planetary terrain. Background Technology

[0002] Accurate identification and dynamic evolution simulation of planetary aeolian landforms are crucial for landing site selection and surface environment assessment in deep space exploration missions. With the advancement of the Tianwen-3 Mars sample return mission, there is an urgent need to establish an autonomous and controllable intelligent interpretation platform for Martian aeolian landforms to support the distribution survey, morphological parameter extraction, and spatiotemporal evolution analysis of typical landforms such as dunes, lateral ridges, and wind streaks on the Martian surface. While internationally available Martian atmospheric models such as MarsWRF and LMD Mars GCM exist, they are primarily used for global or regional climate simulations and still fall short of meeting the demands of engineering applications in terms of detailed interpretation of local aeolian landforms, annotation of multi-source remote sensing data, and interactive spatiotemporal analysis.

[0003] Existing remote sensing image processing tools generally lack effective pyramid pre-generation and adaptive display mechanisms when dealing with ultra-large planetary images. This results in slow initial loading, stuttering during zooming and panning, and an inability to smoothly switch between panoramic overviews and local details. In annotation tasks, common tools often employ a "single element, single record" storage method, lacking support for organizing multiple geometric elements within the same target. This makes it difficult to maintain target-level consistency during subsequent training data processing, and reloading for verification and incremental editing is extremely inconvenient. Furthermore, issues such as inconsistent coordinate systems when overlaying multi-source data, potential conflicts between annotation and browsing operations, and old tile requests contaminating the new view when the viewport changes further reduce interactive stability and operational efficiency. To address these shortcomings, this application proposes a planetary terrain intelligent interpretation and dynamic spatiotemporal analysis platform that collaboratively combines mechanisms such as pyramid preprocessing, dynamic tile requests, intergenerational isolation asynchronous loading, target-level multi-element task tables, and unified storage of separate tables. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention provides an intelligent interpretation and dynamic spatiotemporal analysis platform for planetary terrain, thereby solving the technical problems mentioned in the background section.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] A planetary terrain intelligent interpretation and dynamic spatiotemporal analysis platform, the platform includes an image processing and rendering module, an annotation task management module, and a data storage and reload module;

[0007] The image processing and rendering module is configured to: perform pyramid pre-generation and coordinate system configuration on the imported planetary remote sensing images; perform adaptive tile requests based on the viewport range and load intersecting tiles according to the priority of the visible area center; perform quantile statistics on the current visible area pixel values ​​to perform dynamic range stretching; and perform image rendering through an intergenerational isolated asynchronous tile loading and texture caching rendering mechanism.

[0008] The annotation task management module is configured to: establish a target-element two-level organizational structure, collect multi-element geometric data under the same geographic entity in response to user interaction, and maintain a global task status indexed by the target identifier;

[0009] The data storage and reload module is configured to: use GeoPackage format to store the annotation results in separate tables, and aggregate and reload them according to the target identifier to reconstruct the project-level annotation task structure.

[0010] In one possible implementation, the pyramid pre-generation includes: detecting whether the image has an internal overview layer; if there is no overview layer, calculating the total number of pyramid levels based on the image width and height using a preset tile size and downsampling layer by layer to generate an external .ovr file stored in the same directory as the original image, wherein downsampling is performed in batches by level using a resampling function; if the external .ovr file generation fails, switching to on-demand reading mode, directly reading the corresponding area data from the original image and performing real-time resampling, while continuing to attempt to complete the pyramid construction in a background thread, and prioritizing the use of the overview layer after successful construction.

[0011] In one possible implementation, the adaptive tile request based on the viewport range includes: determining a scaling factor based on the ratio of the current viewport resolution to the original image resolution; calculating a dynamic tile pixel size based on the scaling factor and the standard tile size; selecting a matching overview layer factor from a pre-generated pyramid hierarchy based on the relationship between the dynamic tile pixel size and the resolution factors of each overview layer; dividing the visible range into a regular grid; including only the tiles corresponding to the grids intersecting with the visible range in the request queue; and arranging them in ascending order according to the distance from the tile center to the current viewport center to prioritize loading tiles in the user's area of ​​interest.

[0012] In one possible implementation, performing quantile statistics on the currently visible area cell values ​​to perform dynamic range stretching includes: sampling the cell values ​​within the currently visible area, calculating the 2% quantile and 98% quantile to form a statistical signature representing the dynamic range distribution of the area; comparing the newly obtained statistical signature with the statistical signature currently used for display; if the signatures do not match, clearing the existing tile cache, updating the grayscale or color stretching lookup table based on the latest 2%-98% quantile values, and triggering a redraw.

[0013] In one possible implementation, the image rendering mechanism using asynchronous tile loading and texture caching with generational isolation includes: introducing a layer-level generational counter in the tile loading channel, incrementing the generational identifier and clearing the old request queue each time the viewport changes; submitting the reading and decoding operations of the pixel data blocks corresponding to the tiles to a background worker thread for execution, and passing the generated tile image data, its row and column indices, and its generational identifier to the main thread during the callback; the main thread determining whether the generational identifier is consistent with the current layer generation, and if consistent, sending it to the OpenGL texture cache and triggering a redraw, otherwise discarding it directly; wherein, the image rendering adopts a raster-vector separation rendering method.

[0014] In one possible implementation, establishing the target-element two-level organizational structure includes: receiving, through a two-step dialog box, the number of elements included in the current annotation task, the name and geometric type of each element, and the display color of each element, wherein the geometric type includes points, lines, and surfaces; dynamically generating attribute columns corresponding to the number of elements in the interface panel according to the settings, with each column constraining the geometric type of the element and preset storage location; maintaining a global task status table with the target identifier as an index, recording the current completion status of each target and the length and area geometric parameters of each element.

[0015] In one possible implementation, the response to user interaction in collecting multi-element geometric data under the same geographic entity includes: distinguishing between dragging and panning the view and adding vertices by using a mouse behavior discrimination mechanism, specifically by accumulating the displacement pixel distance from mouse press to release. If the accumulated displacement exceeds a preset pixel distance threshold before release, it is determined to be a dragging and panning operation; otherwise, it is determined to be a click operation, and the ground point corresponding to the image coordinates is added to the coordinate sequence of the current element. For line elements and polygon elements, a Shapely geometry object is generated by calling the geometry construction interface when the closure condition is met or the double-click ends. For point elements, a point geometry object is directly generated after a single click. After the collection of an element is completed, the geometric parameters of that element are updated in the global task status table, and the save operation is enabled when all elements of the same target have been collected.

[0016] In one possible implementation, the unified storage of annotation results using GeoPackage format includes: establishing a target master table, point element tables, line element tables, and polygon element tables in an SQLite database container; the target master table uses the target identifier as the primary key and records the target creation time, element list index mapping, and task remarks field; the point element tables store the geometric fields of point type elements, the corresponding target identifier, and the element name; the line element tables store the geometric fields of line type elements, the target identifier, the element name, and the automatically calculated line length; the polygon element tables store the geometric fields of polygon type elements, the target identifier, the element name, and the automatically calculated area and perimeter; wherein, the target identifier is an auto-incrementing unique identifier generated by a database sequence object, the element list index mapping saves the index order through an association table containing the target identifier and the element table primary key, all geometric fields use binary geometric encoding defined by the GeoPackage specification, storage operations are batch committed through SQLite transactions, and spatial indexes can be optionally created for the geometric fields.

[0017] In one possible implementation, the reload based on target identifiers to reconstruct the project-level annotation task structure includes: the reload module reads all records in the target master table of GeoPackage to reconstruct the target queue, aggregates the corresponding element geometry based on the target identifiers in each geometric sub-table, and reassembles the element array according to the element name and type; reads the original layer footprints and coordinate system parameters associated with the project, re-imports the corresponding raster image and sets the view extent, and restores the task structure, measurement values ​​and symbolic rendering effects consistent with the previous save in the annotation panel.

[0018] In one possible implementation, the coordinate system configuration includes: directly identifying the coordinate system through the spatial reference system field in the image metadata or the EPSG code contained in the projection file; if the metadata does not contain an EPSG code, then matching the coordinate system by comparing a well-known text string with a preset coordinate series table, wherein the consistency of the ellipsoid and reference surface parameters is verified during the comparison; the affine transformation matrix of the image maps pixel coordinates to geographic coordinates and works in conjunction with the projection parameters of the coordinate system; the platform also generates measurement result tables in CSV, XLSX, or XLS formats, and a dynamic database in netCDF format as needed.

[0019] Beneficial effects compared to existing technologies:

[0020] 1. In this solution, by introducing pyramid pre-generation and viewport-driven adaptive tile size selection on the image side, an external .ovr is automatically constructed and the dynamic range is calculated when the overview layer is missing. Combined with the strategy of prioritizing the center of the visible area and loading only intersecting tiles, the amount of data read is greatly reduced when the ultra-large remote sensing image is opened for the first time and during continuous zooming and panning, and the screen refresh remains smooth, which takes into account the dual needs of fast panoramic browsing and fine observation of local details.

[0021] 2. In this solution, by establishing a target-level multi-element task table on the annotation side and adopting a unified GeoPackage structure combining the target table and geometric sub-table on the storage side, multiple geometric elements of the same geographic entity are assigned to a single target. During reload, the task structure is completely reconstructed according to the element index, realizing the recoverability, editability and traceability of project-level annotation results, effectively avoiding management chaos and information loss in the process of multi-element target annotation.

[0022] 3. In this solution, a layer-level generation counter is introduced into the tile loading channel. The generation is incremented with each viewport change and the old request queue is cleared. During the callback, only tile data matching the current generation is received. Combined with OpenGL texture caching and raster vector separate drawing, the old frame disorder and screen flicker caused by fast operation are suppressed. The interactive stability and visual recognition are significantly improved when continuously annotating complex dune boundaries and low-contrast areas. Attached Figure Description

[0023] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, the preferred embodiments of the present invention are described in detail below with reference to the accompanying drawings.

[0024] Figure 1 This is a schematic diagram illustrating the asynchronous loading and rendering effect of OpenGL texture caching and tiles in the platform of this invention;

[0025] Figure 2 This is a schematic diagram showing the statistical results of the global distribution of sand dunes on Mars according to this invention.

[0026] Figure 3 This is a schematic diagram illustrating the results of the investigation into the distribution and classification of sand dunes in the mid-to-low latitude regions of Mars by this invention.

[0027] Figure 4 This is a schematic diagram showing the results of extracting morphological parameters of different types of sand dunes on Mars using the platform of this invention.

[0028] Figure 5 This is a schematic diagram showing the results of the platform of the present invention in annotating the morphological parameters of the transverse sand ridges in potential landing areas on Mars and extracting the boundary vectorization.

[0029] Figure 6 This is a schematic diagram showing the results of the survey of wind streaks and lateral sand ridges in the potential landing area of ​​Chris Planitia on Mars by the platform of this invention. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of the present invention clearer, preferred embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be understood that the present invention can be implemented in many different forms and is not limited to the embodiments described herein; these embodiments are provided to make the disclosure thorough and complete, and to fully convey the scope of the invention to those skilled in the art. For the purpose of more clearly describing the present invention, well-known details or conventional processes not directly related to the present invention are omitted in the drawings and description.

[0031] This invention provides a planetary terrain intelligent interpretation and dynamic spatiotemporal analysis platform deployed in a MATLAB R2023b or later computing environment, requiring the Mapping Toolbox, Image Processing Toolbox, ParallelComputing Toolbox, and Database Toolbox. Alternatively, the same logic can be implemented using Python combined with open-source libraries such as NumPy, GDAL, and OpenGL. The core algorithm of this platform does not rely on MATLAB-specific functions. To further optimize raster data input and output, the GDAL library path can be configured in the operating system environment variables. Logically, the platform consists of an image processing and rendering module, an annotation task management module, and a data storage and reload module. These modules collaboratively execute the following steps:

[0032] Step 1: Image import, pyramid pre-generation, and coordinate system configuration

[0033] After a user selects a remote sensing image file to be analyzed via the toolbar or dialog box, the platform creates a RasterLayer instance for each image and adds it to the drawing stack maintained by the LayerManager. The LayerManager uniformly controls the visibility switching and drawing order of raster layers, vector layers, and annotation layers to support scene management requirements when overlaying multi-source data. When loading an image, the system synchronously reads the raster's affine transformation six-parameter set and coordinate reference system definition. If the image includes an embedded PRJ or external WKT file, the CRSManager module parses and verifies the coordinate system information, recording the valid CRS in the layer attributes; if the CRS cannot be read correctly, the CRSManager attempts to match it using a preset set of commonly used planetary coordinate series tables and issues a prompt to the user.

[0034] CRSManager supports two main types of coordinate systems: geographic coordinate systems and projected coordinate systems. Specific entries are as follows:

[0035] (1) Geographic coordinate system

[0036]

[0037] (2) Projected coordinate system

[0038] Projected coordinate system (Gauss-Kruger projection) using CGCS2000 as an example:

[0039]

[0040] Matching rules with image metadata

[0041] Image metadata (such as GeoTIFF files) must be matched with the coordinate system according to the following rules:

[0042] (1) EPSG code matching

[0043] The SRS field in the image metadata or the .prj file should contain a clear EPSG code (e.g., EPSG:4490). The system can directly identify the coordinate system through the code. If the metadata does not contain an EPSG code, it is necessary to compare it with the preset list through the WKT string (e.g., GEOGCS["CGCS2000",...]). When matching, attention should be paid to the consistency of parameters (e.g., ellipsoid, datum).

[0044] (2) Matching of affine transformation matrices

[0045] The affine transformation matrix of the image maps pixel coordinates to geographic coordinates and needs to work in conjunction with the projection parameters of the CRS (such as the central meridian and scale).

[0046] The rendering module then checks whether the image has an internal overview layer. If the detection result is no overview layer, the PyramidGenerator module calculates the total number of pyramid levels based on the image's width and height. This calculation uses 256×256 pixels as the base tile size, compares the long side of the original image with the tile side length, and downsamples layer by layer until the long side is smaller than the tile side length.

[0047] Among them, the total number of pyramid levels The calculation formula is as follows:

[0048]

[0049] in , These represent the width and height of the original image, respectively.

[0050] Downsampling in image pyramids:

[0051] Downsampling is performed at a fixed ratio of 2:1, meaning that for each higher layer, the image width and height are reduced to half of the next layer. The downsampling ratio sequence is a power of 2 (e.g., 1 / 2, 1 / 4, 1 / 8, ...), corresponding to the number of layers. The mathematical representation is as follows:

[0052] No. Layer images Generated by the following formula:

[0053]

[0054] in For the previous layer image, For the first The downsampled image of the layer at coordinates Pixel value at; , This represents the relative coordinate offset within the local neighborhood. For the previous layer image The actual pixel coordinates in the image.

[0055] The PyramidGenerator module calls the resampling function provided by the environment to generate downsampled images in batches by layer, and stores them as external .ovr files in the same directory as the original images. During the resampling phase, preprocessing progress messages are output to inform the user of the current status. When insufficient storage space or file system write permissions cause external pyramid generation to fail, the platform switches to on-demand read mode: in subsequent browsing interactions, for layers that have not been pre-generated, the corresponding area data is directly read from the original image and resampled in real time to ensure uninterrupted operation. Simultaneously, the platform continues to attempt to complete pyramid construction in a background thread, and upon successful construction, notifies the rendering module via a message to prioritize the use of the overview layer.

[0056] Once the pyramid is constructed, the system initializes the overview selector for the layer, records the resolution factor array for each level, and generates layer footprints on the view based on the geographic extent of the layer. If multiple raster layers exist in the current project, the system may reset the viewport extent to the geographic region corresponding to the union of each layer to provide a complete initial browsing view.

[0057] Step 2: Viewport-Driven Adaptive Tile Request and Dynamic Range Stretching

[0058] During the user's zooming and panning operations, the platform calculates the scaling factor between the source raster pixels and the screen display pixels in real time based on the current visible geographic range of the image canvas and the screen pixel size of the canvas controls. Scaling factor The proportional relationship between screen pixel size and actual geographic size is defined, and its specific expression is as follows: ,in The screen pixel side length refers to the width or height in pixels of the image display area (such as a Canvas) on the screen. The visible geographic extent refers to the width or height of the actual geographic area corresponding to the current image view, measured in meters (m). This factor represents the number of pixels occupied by each unit of geographic length (meter) on the current screen. When the user zooms in / out or pans the image, Changes occur, thus causing The dynamic changes.

[0059] Using this scaling factor, the system dynamically determines the tile pixel size used for this request.

[0060] Depend on Derive the method for calculating the pixel size of dynamic tiles:

[0061] In a tile imaging system, the final display size of a tile on the screen needs to be dynamically calculated based on the scaling ratio of the current view. The core principle is to combine image resolution... Perform the calculation.

[0062] (1) Determine the image resolution of the current layer.

[0063] Image resolution Defined as the geographical distance (in meters) represented by one pixel on the screen. In planetary projection (such as the Mercator projection on Mars) pyramid tile system, its calculation formula is:

[0064] in The equatorial circumference of the planet (meters); 256 represents the zoom level of the current image; 256 represents the pixel size (width or height) of a standard tile.

[0065] This formula shows that, with increasing hierarchy... Increase image resolution Halved, the image is displayed in greater detail.

[0066] (2) Calculate the pixel size of dynamic tiles

[0067] A single tile covers a fixed geographical area. In scaling factor The pixel size that the tile should display on the screen. for:

[0068]

[0069] in This represents the actual geographical side length (in meters) of a single tile. In a standard tile pyramid, Substituting into the above formula, we get... =256, meaning the tiles are displayed at their original size. Dynamic calculation scenario: When the screen display ratio is not 1:1 (i.e., there is overall scaling) or when it needs to adapt to non-standard DPI screens, a scaling factor needs to be introduced. Make corrections. At this point, the logical pixel size of the tile on the screen... It should be:

[0070] .

[0071] In actual rendering, we achieve this scaling equivalently by directly adjusting the transformation parameters between the image coordinate system and the screen coordinate system, rather than directly changing the image data of each tile.

[0072] At the same time, the overview selector is based on The relationship between the overview layer resolution factors and the pre-generated pyramid hierarchy is used to select the most matching overview layer factor.

[0073] The core threshold criteria for selecting overview layer factors are "selection criteria" and "selection limits". Its cost function can be expressed as a comprehensive optimization problem with the goals of information integrity, visual clarity and geographical typicality, aiming to minimize information loss and maximize the effectiveness of image expression.

[0074] (1) Threshold criteria: selection criteria and selection limits

[0075] In the overview layer (i.e., the selection stage of image generalization), the quantification threshold criteria for determining whether an element is retained mainly include the following two categories:

[0076] Selection criteria: The minimum size or measurement of features that must be retained on the image is a hard threshold that determines whether an element is "qualified" to be selected.

[0077] Length / Area Threshold: Rivers with a length of less than 1 cm or vegetation patches with an area of ​​less than 1 square millimeter on the map are not to be retained.

[0078] Importance threshold: Priority is set based on the administrative level and functional importance of land features. Secondary land features may be discarded even if they meet the size standard.

[0079] Selection limit: refers to the maximum number of ground features that can be represented per unit area or the percentage that needs to be retained, used to control the overall density and visual load of the image.

[0080] Maximum number: Within a 10cm x 10cm map area, a maximum of 15 settlements can be represented.

[0081] Differentiated zoning: Different quotas are set according to regional characteristics (such as river network density and settlement density) to avoid a "one-size-fits-all" approach. The core method is the regional index method, which first divides the mapping area into type zones (such as high, medium, and low density zones), and then sets a gradually changing range of selection indicators for each zone to maintain a natural transition in the number of elements at the zone boundaries.

[0082] (2) Cost function expression

[0083] The selection of overview layer factors can be viewed as an optimization problem, with the goal of finding an optimal subset of elements. To achieve this, a cost function can be constructed. This is used to measure the quality of the selection results. The function is typically designed to minimize the combined cost of information loss and maximize expressive utility.

[0084] The cost function can be expressed as:

[0085]

[0086] in This represents the set of image elements obtained after the selection operation. This is an information loss term that measures the loss of geographic information due to discarding features. It can be quantified based on the original importance weights or geometric characteristics (such as total length, total area) of the discarded features. This is a visual load cost term that measures the visual complexity and sharpness of an image. This cost increases when the feature density exceeds a certain visual comfort threshold (i.e., when the "selection limit" is violated). This is a geographical typicality award, which rewards the selection results that retain the typical features and important geographical features of the region; , , , where is the weighting coefficient, used to balance the relative importance of information loss, visual load, and geographic typicality. Its value depends on the image's intended use (e.g., educational images emphasize typicality and sharpness, while scientific reference images prioritize information completeness). The optimization objective is to find the cost function that minimizes ... Minimized subset of elements :

[0087] The optimization process must simultaneously satisfy the "selection criteria" (hard constraints) and approximate the "selection limit" (soft constraints or penalty terms).

[0088] Therefore, the complete decision-making process for selecting overview layer factors is as follows: clarify the purpose and scale of the image → analyze the characteristics of the image region and divide it into zones → set differentiated selection criteria and limits (threshold criteria) for each zone → construct or evaluate and optimize the selection scheme based on the cost function → output the final set of selected image elements.

[0089] For example, when This means that when zooming out to a coarser resolution, a higher overview layer is selected; when zooming in to near the original resolution, the lowest layer or the original image is selected. The visible area is divided into a regular grid, and only tiles corresponding to grids intersecting the visible area are included in the request queue, thus avoiding blind reading of the entire image. The request queue is also sorted in ascending order of distance from the tile center to the current viewport center, prioritizing the loading of tiles in the user's area of ​​interest, further reducing first-screen display latency.

[0090] In the data channel that runs parallel to the tile request, the rendering module samples the pixel values ​​within the currently visible area, calculates the 2% and 98% quantiles, and forms a statistical signature representing the dynamic range distribution of the area.

[0091] The platform compares the newly obtained statistical signature with the statistical signature currently used for display: if the signatures match, the current stretch mapping parameters remain unchanged; if the signatures do not match, the existing tile cache is cleared, the grayscale or color stretch lookup table is updated according to the latest 2%-98% quantile value, and a redraw is triggered. This adaptive dynamic range adjustment method improves the visual recognition of low-contrast scenes such as dunes and base, wind streaks and surrounding plains, ensuring that the soft-boundary wind-blown landforms maintain a clear display effect throughout the interaction.

[0092] Step 3: Generational Isolation Asynchronous Tile Loading and OpenGL Texture Buffer Rendering

[0093] The TileLoader module handles the actual reading and decoding of tiles. To reduce main thread blocking, TileLoader utilizes the parfeval mechanism provided by Parallel Computing Toolbox to submit the reading of the 256×256 pixel data block and the decoding of the one-dimensional byte stream corresponding to each tile to a background worker thread. The Future object returned by parfeval is registered by the afterEach callback: when the background task completes, the callback function passes the generated tile image data, the corresponding tile row and column indices, and the generation identifier to the main thread.

[0094] To address the issue of older tile requests overwriting new views in scenarios with continuous, rapid zooming and panning, the platform introduces a layer-level generation counter, `generation`. Each time viewport parameters change—specifically, the zoom level or pan center changes—the `generation` value increments, and the queue of currently pending older generation tile requests is cleared. Before writing tile data to the texture cache, the callback function first checks if the generation identifier carried by the tile is equal to the current layer's `generation` value; only if they match is the tile data accepted and updated in the tile cache; otherwise, it is discarded. This generation filtering method effectively suppresses image distortion and texture flickering caused by old frame data.

[0095] The tile cache is maintained within each RasterLayer, storing RGB or grayscale texture data using the tile row and column indices as keys. In the MapCanvas drawing loop, the raster rendering pipeline traverses the tiles hit within the current viewport, extracts the corresponding texture from the cache, and maps it to quadrilateral primitives; vector and annotation data are overlaid and drawn in subsequent draw passes. The drawing of all primitives relies on OpenGL texture handles; by binding texture IDs and transferring geometric vertices, coordinate mapping accuracy is ensured while scaling and translation operations maintain a smooth frame rate. Figure 1 As shown, the rendering effect after applying the above texture caching and asynchronous loading mechanism is shown, in which the details of the sand dune texture are clearly presented and the interface interaction is smooth.

[0096] Step 4: Target-level multi-element annotation task creation and interactive data collection

[0097] The annotation module employs a target-element two-level organizational structure, logically grouping multiple geometric elements belonging to the same geographic entity under a single target. After a user initiates the annotation function, the platform displays a two-step dialog box. In the first dialog box, the user sets the number of elements in the current annotation task and assigns a name and geometric type to each element, including points, lines, and polygons. In the second dialog box, the user selects a display color for each element. Based on these settings, the platform dynamically generates attribute columns corresponding to the number of elements in the right-hand panel of the interface. Each column constrains the geometric type of the element and has a preset storage location.

[0098] The global task status table is indexed by target_id and maintains the current completion status of each target and the measurement results of each element.

[0099] Once the interactive annotation phase begins, the platform uses a mouse behavior discrimination mechanism to distinguish between dragging and translating the view and adding vertices through point sampling. When the user presses and moves the mouse, the platform accumulates the displacement in pixels; if the accumulated displacement exceeds a preset pixel distance threshold before releasing the mouse, it is determined to be a drag-and-translate operation, and the view is translated accordingly without adding vertices to the current annotation element.

[0100] Threshold per pixel The constant is subtracted from the mean or Gaussian weighted mean of its neighboring pixels. Decide:

[0101] Adaptive thresholding calculates a local threshold for each pixel in an image to address uneven illumination. Its general calculation formula is:

[0102]

[0103] in For pixels Local threshold; In pixels It is the statistical value of all pixels within the neighborhood window centered on it. This is a constant subtracted from the mean or weighted mean, used to fine-tune the sensitivity of the threshold.

[0104] If the cumulative displacement does not exceed the threshold and is judged as a click operation, the platform appends the ground point corresponding to the image coordinates to the coordinate sequence of the current element and draws connecting lines or temporary point markers on the canvas in real time. For line elements and surface elements, when the closure or double-click termination condition is met, the platform calls the geometry construction interface to generate a Shapely geometry object; point elements directly generate a point geometry object after a single click.

[0105] After the acquisition of an element is completed, the task status table updates the measurement results of that element, including geometric parameters such as length and area. When all elements of a target have been acquired, the save button becomes available. After the user triggers save, the platform persists the geometry of all elements of the current target along with their corresponding target_id; then it generates a new target_id and resets the acquisition panel to proceed with the annotation process for the next target. This target-level linkage control avoids conflicts between browsing and point acquisition operations, and improves the spatial consistency of elements within the target during continuous annotation work.

[0106] Step 5: Unified storage of annotation results in separate tables and project reload reconstruction.

[0107] The platform utilizes the GeoPackage format for unified storage of annotation data. GeoPackage uses an SQLite database as a container, internally establishing the targets, ann_points, ann_lines, and ann_polygons tables. The targets table uses target_id as the primary key and records the target creation time, element list index mapping, and task remarks fields.

[0108] (1) Generation rules for target_id: Sequence generation — the database generates it through independent sequence objects in Oracle.<table_name> _<column_name> The system uses `_SEQUENCE` to generate an auto-incrementing, unique ID. When an insertion operation is performed, the system automatically retrieves the next value from the sequence as the `target_id`.

[0109] (2) Storage method for the index mapping of the element list: Foreign key association table - Create an independent association table, which contains at least two foreign key fields, pointing to the primary keys of the main table and the element table respectively. Additional fields can also be added to store metadata such as index order and association time.

[0110] The many-to-many mapping between users and tags can be stored in the UserTag table.

[0111] CREATE TABLE UserTag (

[0112] user_id BIGINT NOT NULL,

[0113] tag_id BIGINT NOT NULL,

[0114] `sort_index` (INT) -- Used to store the index or order of elements in the list.

[0115] FOREIGN KEY (user_id) REFERENCES User(id),

[0116] FOREIGN KEY (tag_id) REFERENCES Tag(id),

[0117] PRIMARY KEY (user_id, tag_id) );

[0119] The `ann_points` table stores the geometry fields, corresponding `target_id`, and element name of point-type elements; the `ann_lines` table stores the geometry fields, `target_id`, element name, and automatically calculated line length of line-type elements; and the `ann_polygons` table stores the geometry fields, `target_id`, element name, and automatically calculated area and perimeter of polygon-type elements. All geometry fields use binary geometry encoding defined by the GeoPackage specification. Storage operations are committed in batches via SQLite transactions, and spatial indexes can be optionally created for geometry fields to accelerate spatial queries.

[0120] When it is necessary to restore historical annotation projects, the reload module first reads all records in the `targets` table of `GeoPackage` and rebuilds the target queue. Then, it aggregates the corresponding element geometry based on the `target_id` in each geometry sub-table and reassembles the element array according to the element name and type. The platform reads the original layer footprints and coordinate system parameters associated with the project, re-imports the corresponding raster image and sets the view extent, finally restoring the task structure, measurement values, and symbolic rendering effects consistent with the previous save in the annotation panel.

[0121] In addition to the main GeoPackage file, the platform outputs measurement result tables in CSV, XLSX, or XLS formats as needed. These tables are arranged with the target as the row and the elements as the column, making it convenient for external tools to perform statistics and charts.

[0122] When using the platform constructed through the above steps to analyze Martian aeolian landforms, such as... Figure 2 As shown, based on the platform's statistical analysis of global Martian dune distribution, the total area of ​​Martian sand dunes is approximately 10... 6 km², sand dunes are concentrated in the Arctic lowlands and are scattered. For example... Figure 3 As shown, after conducting a survey on the distribution and classification of sand dunes in mid- and low-latitude regions using the platform, it was found that sand dunes in these regions are mainly located in the Southern Hemisphere plateaus, and a total of 18 major sand dune landform types were identified. The platform also extracted morphological parameters of different types of sand dunes globally on Mars, such as... Figure 4 As shown, the morphological parameters of dunes on Mars are highly consistent with those on Earth and other terrestrial planets in the solar system, confirming the similarity in dune development mechanisms. Figure 6 As shown, the platform conducted a distribution survey and morphological parameter measurement of wind streaks and lateral sand ridges in the potential landing area of ​​Chris Planitia on Mars, obtaining the spatial distribution and geometric characteristics of wind streaks and lateral sand ridges. Based on the morphological parameters and vector boundaries exported by the platform, combined with the local climate prediction and evaluation model of the landing site, a dynamic database for studying the occurrence and development mechanism of dust storms can be formed. The data is uniformly stored in netCDF format and supports subsequent numerical simulation calls.

[0123] Finally, it should be noted that the above embodiments are merely examples for clearly illustrating the present invention and are not intended to limit the implementation. Those skilled in the art will recognize that other variations or modifications can be made based on the above description. It is neither necessary nor possible to exhaustively list all possible implementations. However, obvious variations or modifications derived therefrom are still within the scope of protection of this invention.

Claims

1. A platform for intelligent interpretation and dynamic spatiotemporal analysis of planetary terrain, characterized in that, The platform includes an image processing and rendering module, an annotation task management module, and a data storage and reload module; The image processing and rendering module is configured to: perform pyramid pre-generation and coordinate system configuration on the imported planetary remote sensing images; perform adaptive tile requests based on the viewport range and load intersecting tiles according to the priority of the visible area center; perform quantile statistics on the current visible area pixel values ​​to perform dynamic range stretching; and perform image rendering through an intergenerational isolated asynchronous tile loading and texture caching rendering mechanism. The annotation task management module is configured to: establish a target-element two-level organizational structure, collect multi-element geometric data under the same geographic entity in response to user interaction, and maintain a global task status indexed by the target identifier; The data storage and reload module is configured to: use GeoPackage format to store the annotation results in separate tables, and aggregate and reload them according to the target identifier to reconstruct the project-level annotation task structure.

2. The intelligent interpretation and dynamic spatiotemporal analysis platform for planetary terrain as described in claim 1, characterized in that, The pyramid pre-generation includes: detecting whether the image has an internal overview layer; if there is no overview layer, calculating the total number of pyramid levels based on the image width and height using a preset tile size and downsampling layer by layer to generate an external .ovr file stored in the same directory as the original image, wherein downsampling is performed in batches by level using a resampling function; if the external .ovr file generation fails, switching to on-demand reading mode, directly reading the corresponding area data from the original image and performing real-time resampling, while continuing to attempt to complete the pyramid construction in a background thread, and prioritizing the use of the overview layer after successful construction.

3. The intelligent interpretation and dynamic spatiotemporal analysis platform for planetary terrain as described in claim 1, characterized in that, The adaptive tile request based on viewport range includes: determining a scaling factor based on the ratio of the current viewport resolution to the original image resolution; calculating the dynamic tile pixel size based on the scaling factor and the standard tile size; selecting a matching overview layer factor from a pre-generated pyramid hierarchy based on the relationship between the dynamic tile pixel size and the resolution factors of each overview layer; dividing the visible range into a regular grid; including only the tiles corresponding to the grids intersecting with the visible range in the request queue; and arranging them in ascending order according to the distance from the tile center to the current viewport center to prioritize loading tiles in the user's area of ​​interest.

4. The intelligent interpretation and dynamic spatiotemporal analysis platform for planetary terrain as described in claim 1, characterized in that, The step of performing quantile statistics on the currently visible area cell values ​​to execute dynamic range stretching includes: sampling the cell values ​​within the currently visible area, calculating the 2% quantile and 98% quantile to form a statistical signature representing the dynamic range distribution of the area; comparing the newly obtained statistical signature with the statistical signature currently used for display; if the signatures do not match, clearing the existing tile cache, updating the grayscale or color stretching lookup table based on the latest 2%-98% quantile values, and triggering a redraw.

5. The intelligent interpretation and dynamic spatiotemporal analysis platform for planetary terrain as described in claim 1, characterized in that, The image rendering mechanism using asynchronous tile loading and texture caching with generational isolation includes: introducing a layer-level generational counter in the tile loading channel, incrementing the generational identifier and clearing the old request queue each time the viewport changes; submitting the reading and decoding operations of the pixel data blocks corresponding to the tile to a background worker thread for execution, and passing the generated tile image data, its row and column indices, and its generational identifier to the main thread during callback; the main thread determines whether the generational identifier is consistent with the current layer generation, and if they are consistent, sending it to the OpenGL texture cache and triggering a redraw, otherwise discarding it directly; wherein, the image rendering adopts a raster-vector separation rendering method.

6. The intelligent interpretation and dynamic spatiotemporal analysis platform for planetary terrain as described in claim 1, characterized in that, The establishment of the target-element two-level organizational structure includes: receiving the number of elements, the name and geometric type of each element, and the display color of each element in the current annotation task through a two-step dialog box, wherein the geometric type includes points, lines, and surfaces; dynamically generating attribute columns corresponding to the number of elements in the interface panel according to the settings, with each column constraining the geometric type of the element and preset storage location; maintaining a global task status table with the target identifier as an index, recording the current completion status of each target and the length and area geometric parameters of each element.

7. The intelligent interpretation and dynamic spatiotemporal analysis platform for planetary terrain as described in claim 1, characterized in that, The response to user interaction in collecting multi-element geometric data under the same geographic entity includes: distinguishing between dragging and panning the view and adding vertices by mouse behavior discrimination mechanism, specifically by accumulating the displacement pixel distance from mouse press to release. If the cumulative displacement exceeds a preset pixel distance threshold before release, it is determined to be a dragging and panning operation; otherwise, it is determined to be a click operation and the ground point corresponding to the image coordinates is added to the coordinate sequence of the current element. For line elements and polygon elements, the geometry construction interface is called to generate Shapely geometry objects when the closure condition is met or the double-click ends. For point elements, a point geometry object is directly generated after a single click. After the collection of an element is completed, the geometric parameters of the element in the global task status table are updated, and the save operation is enabled when all elements of the same target have been collected.

8. The intelligent interpretation and dynamic spatiotemporal analysis platform for planetary terrain as described in claim 1, characterized in that, The method of uniformly storing annotation results using the GeoPackage format includes: establishing a target master table, point element tables, line element tables, and polygon element tables in an SQLite database container; the target master table uses the target identifier as the primary key and records the target creation time, element list index mapping, and task remarks field; the point element tables store the geometric fields of point type elements, the corresponding target identifier, and the element name; the line element tables store the geometric fields of line type elements, the target identifier, the element name, and the automatically calculated line length; the polygon element tables store the geometric fields of polygon type elements, the target identifier, the element name, and the automatically calculated area and perimeter; wherein, the target identifier is an auto-incrementing unique identifier generated by a database sequence object, the element list index mapping saves the index order through an association table containing the target identifier and the element table primary key, all geometric fields use binary geometric encoding defined by the GeoPackage specification, storage operations are batch committed through SQLite transactions, and spatial indexes can be optionally created for the geometric fields.

9. The intelligent interpretation and dynamic spatiotemporal analysis platform for planetary terrain as described in claim 1, characterized in that, The process of reloading based on target identifiers to reconstruct the project-level annotation task structure includes: the reload module reads all records in the target master table of GeoPackage to reconstruct the target queue, aggregates the corresponding element geometry based on the target identifiers in each geometric sub-table, and reassembles the element array according to the element name and type; reads the original layer footprints and coordinate system parameters associated with the project, re-imports the corresponding raster image and sets the view range, and restores the task structure, measurement values ​​and symbolic rendering effects consistent with the previous save in the annotation panel.

10. The intelligent interpretation and dynamic spatiotemporal analysis platform for planetary terrain as described in claim 1, characterized in that, The coordinate system configuration includes: directly identifying the coordinate system through the spatial reference system field in the image metadata or the EPSG code contained in the projection file; if the metadata does not contain an EPSG code, the coordinate system is matched by comparing a well-known text string with a preset coordinate series table, wherein the consistency of the ellipsoid and reference surface parameters is verified during the comparison; the affine transformation matrix of the image maps pixel coordinates to geographic coordinates and works in conjunction with the projection parameters of the coordinate system; the platform also generates measurement result tables in CSV, XLSX or XLS format, and a dynamic database in netCDF format as needed.