A spatio-temporal information system and processing method based on multi-source remote sensing data

Abstract

This application discloses a spatiotemporal information system and processing method based on multi-source remote sensing data, relating to the field of remote sensing data processing and information service technology. The system includes a backend, which comprises multiple adapter plugins, a data streaming pipeline based on an event-driven architecture, and a retrieval service unit. The adapter plugins process the acquired remote sensing data into structured key metadata. The data streaming pipeline encapsulates the structured key metadata and corresponding processing requirements into standardized event messages and publishes them to preset topics, while asynchronously subscribing to, consuming, and parsing the standardized event messages. The retrieval service unit updates the spatial index and inverted index based on the hybrid index architecture and the parsed standardized event messages; generates query requests; performs retrieval based on the spatial index and inverted index; and generates query results to be fed back to the user. This application can improve the overall efficiency of integrating, retrieving, and serving multi-source heterogeneous remote sensing data.

Description

Technical Field

[0001] This application relates to the field of remote sensing data processing and information service technology, and in particular to a spatiotemporal information system and processing method based on multi-source remote sensing data. Background Technology

[0002] With the rapid development of remote sensing technology and the growth of data volume, the application potential of remote sensing data is becoming increasingly prominent, but it also faces many challenges. For example, the continuous emergence of high-resolution satellites has led to an explosive growth in remote sensing data. Traditional storage architectures often encounter performance bottlenecks when faced with such large-scale, high-frequency data read and write operations, making it difficult to guarantee efficient data storage and rapid retrieval. At the same time, traditional data retrieval methods, such as queries based on simple keyword matching or fixed metadata, can no longer meet the diverse and refined data needs of today. Traditional methods are inefficient and struggle to quickly match suitable subsets of data, severely restricting the application effectiveness of remote sensing data.

[0003] At the system architecture level, existing remote sensing data management and service systems are relatively outdated, mostly adopting centralized or simple distributed architectures. This architecture lacks sufficient scalability and flexibility, making it difficult to withstand the increasing query pressure. Especially when facing sudden emergency events (such as natural disaster monitoring and rescue), a large number of concurrent query requests can easily lead to slow system response or even crashes, failing to meet the needs of application scenarios with extremely high real-time requirements. Summary of the Invention

[0004] The purpose of this application is to provide a spatiotemporal information system and processing method based on multi-source remote sensing data, which can improve the system's processing speed for multi-source heterogeneous data, improve data retrieval speed, and achieve high-precision and reliable understanding of professional remote sensing query intentions.

[0005] To achieve the above objectives, this application provides the following solution: In a first aspect, this application provides a spatiotemporal information system based on multi-source remote sensing data, comprising: a backend; the backend includes multiple adapter plugins, a data streaming pipeline based on an event-driven architecture, and a retrieval service unit; wherein all the adapter plugins follow a unified preset interface standard, and each adapter plugin can only be bound to one data source interface one-to-one.

[0006] The adapter plugin is used to obtain remote sensing data from the corresponding data source interface and process the remote sensing data to obtain structured key metadata.

[0007] The data streaming pipeline includes a data access unit, a message publishing unit, and a downstream processing unit. The data access unit acquires structured key metadata output by the adapter plugin corresponding to the data source interface and encapsulates the structured key metadata and corresponding processing requirements into standardized event messages. The message publishing unit publishes the standardized event messages to a preset topic. The downstream processing unit asynchronously and in parallel retrieves standardized event messages from the preset topic and parses the retrieved standardized event messages.

[0008] The retrieval service unit is used for...

[0009] Based on the hybrid index architecture and the parsed standardized event messages, the spatial index and inverted index are updated; the hybrid index architecture is an index structure that combines the spatial index and the inverted index.

[0010] The system acquires natural language query information sent by the user and generates a query request based on the natural language query information and a cascaded semantic parsing framework. The cascaded semantic parsing framework includes an information extraction model trained on a remote sensing domain knowledge graph and a multi-dimensional intent recognition model.

[0011] Based on the spatial index, the inverted index, and the query request, query results are generated and then fed back to the user.

[0012] Secondly, this application provides a spatiotemporal information processing method based on multi-source remote sensing data, including: The adapter plugin obtains remote sensing data from the corresponding data source interface and processes the remote sensing data to obtain structured key metadata; wherein, all the adapter plugins follow a unified preset interface standard, and each adapter plugin can only be bound to one data source interface one-to-one.

[0013] The data access unit obtains the structured key metadata output by the adapter plugin corresponding to the data source interface, and encapsulates the structured key metadata and the corresponding processing requirements into standardized event messages.

[0014] The message publishing unit publishes the standardized event message to a preset topic.

[0015] Downstream processing units asynchronously and in parallel retrieve standardized event messages from a preset topic and parse the retrieved standardized event messages.

[0016] The retrieval service unit updates the spatial index and inverted index based on the hybrid index architecture and the parsed standardized event messages; the hybrid index architecture is an index structure that combines the spatial index and the inverted index.

[0017] The retrieval service unit obtains natural language query information sent by the user terminal, and generates a query request based on the natural language query information and the cascaded semantic parsing framework; the cascaded semantic parsing framework includes an information extraction model trained based on a remote sensing domain knowledge graph and a multi-dimensional intent recognition model.

[0018] The retrieval service unit generates query results based on the spatial index, the inverted index, and the query request, and then sends the query results back to the user.

[0019] According to the specific embodiments provided in this application, this application has the following technical effects: This application provides a spatiotemporal information system and processing method based on multi-source remote sensing data, including a backend. The backend includes multiple adapter plugins, a data stream processing pipeline based on an event-driven architecture, and a retrieval service unit. The data stream processing pipeline includes a data access unit, a message publishing unit, and a downstream processing unit. Remote sensing data is obtained from the corresponding data source interface through the adapter plugins, and the remote sensing data is processed to obtain structured key metadata. Since all adapter plugins follow a unified preset interface standard, the data obtained from different data sources has a unified data standard format, improving the system's processing speed for multi-source heterogeneous data and facilitating subsequent data processing. The structured key metadata output by the adapter plugin corresponding to the data source interface is obtained through the data access unit, and the structured key metadata and corresponding processing requirements are encapsulated into standardized event messages. The message publishing unit publishes the standardized event messages to a preset topic; then, the downstream processing unit asynchronously and in parallel pulls the standardized event messages within the preset topic and parses them. Since the backend adopts a data stream processing pipeline based on an event-driven architecture, it can treat data access as an event-driven process and data arrival as an event to be published, triggering the downstream processing unit to process tasks in parallel, thus improving the real-time response of the system. The retrieval service unit updates the spatial index and inverted index based on the hybrid index architecture and the parsed standardized event messages. Through collaborative queries using multiple index architectures, the data retrieval speed is improved. Furthermore, a cascaded semantic parsing framework parses the natural language query information sent by the user and generates query requests, achieving high-precision and reliable understanding of professional remote sensing query intentions, lowering the system's usage threshold, and enhancing the level of interactive intelligence. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a schematic diagram of the structure of a spatiotemporal information system based on multi-source remote sensing data in one embodiment of this application; Figure 2 This is a flowchart illustrating a spatiotemporal information processing method based on multi-source remote sensing data, provided as an embodiment of this application. Detailed Implementation

[0022] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0024] Existing remote sensing data platforms often face inconsistent data quality when integrating multi-source data. This is due to significant differences in metadata formats, field definitions, coordinate systems, and quality descriptions among different data sources. Specifically, this manifests as missing fields, inconsistent naming conventions, inconsistent units, and inaccurate or missing quality control information (such as cloud cover). This leads to difficulties in data integration, compromising the accuracy and completeness of the data, thus affecting the reliability of subsequent retrieval and analysis, and ultimately diminishing the data's application value.

[0025] This application addresses the issue of inconsistent data quality (format, standards): By implementing the `parse()` and `extractMetadata()` methods within each adapter plugin for specific data sources, raw metadata from diverse sources is forcibly converted into structured key metadata with unified field names, data types, and units of measurement within the system, achieving standardization from the outset. Regarding data accuracy and completeness: The `validate()` method of the adapter plugin validates the input parameters and the acquired data; simultaneously, an event-driven pipeline state tracking mechanism ensures that the entire data processing chain is traceable and auditable, thereby guaranteeing the accuracy and completeness of the data entering the database.

[0026] In one exemplary embodiment, such as Figure 1 The diagram shown is a schematic representation of a spatiotemporal information system based on multi-source remote sensing data in one embodiment of this application. The system includes a backend; the backend includes multiple adapter plugins, a data streaming pipeline based on an event-driven architecture, and a retrieval service unit; wherein all the adapter plugins follow a unified preset interface standard, and each adapter plugin can only be bound to one data source interface one-to-one.

[0027] The adapter plugin is used to obtain remote sensing data from the corresponding data source interface, and to parse and standardize the remote sensing data to obtain structured key metadata.

[0028] For example, a data source interface.

[0029] (1) USGS (United States Geological Survey) official website.

[0030] For example, consider a Landsat-8 dataset with the identifier LC08_L2SP_123032_20230415_20230420_02_T1. Download its metadata file LC08_L2SP_123032_20230415_20230420_02_T1_MTL.txt.

[0031] (2) Utilize the Sichuan Center Platform for Land and Resources Satellite Application to receive data and metadata files from public satellites (Gaofen series, Resource series, etc.) of the Ministry of Natural Resources Land and Resources Satellite Remote Sensing Application Center.

[0032] To unify access to multi-source heterogeneous remote sensing data, this invention designs a standardized adapter plugin system. Each plugin encapsulates protocol adaptation, parsing rules, and quality verification logic for a specific data source. Specifically, it includes: Match adapter plugins for each data source (including Landsat, Sentinel, GF, ZY, UAV, etc.).

[0033] All adapter plugins adhere to a unified interface standard. This standard interface specifies the functionalities each adapter must implement and the data parameters it must respond to, ensuring that upper-layer applications can consistently invoke different data sources. Key parameters of the unified interface include: Data types: Optical, radar, drones, etc.

[0034] Data source identifier: sensor name, number of standardized bands, etc.

[0035] Query criteria: spatial range (latitude and longitude bounding box or geometry), time range, and a set of expandable filtering criteria (such as cloud cover percentage, spatial resolution, image quality level, polarization mode of radar data, etc.).

[0036] Operation commands include querying image metadata that meets the criteria, downloading image data, and assigning preprocessing tasks (such as atmospheric correction and radiometric calibration).

[0037] Target parameters: local storage path for data download, desired preprocessing type, etc.

[0038] To address the characteristics of different remote sensing data sources, the `parse()`, `extractMetadata()`, and `validate()` methods are implemented differently, focusing on adapting to differences in the number of bands, resolution, filtering criteria, and interface protocols. Different remote sensing data sources exhibit significant differences in data format, metadata structure, access protocols, and product characteristics. To achieve a unified interface, each adapter needs to implement differentiated methods in the following core methods, with specific functional descriptions as follows: (1) The specific function of the parse(input_data) method.

[0039] 1) Function Definition: This method is responsible for parsing the raw files of the data source and converting them into a unified, structured data model within the system. It parses the content into key-value pair memory objects, including extracting information such as data ID, data source name, data time, sensor ID, sensor name, band details, longitude, latitude, cloud cover, orbital number, and data level.

[0040] 2) Examples of data extraction.

[0041] For Landsat data, the parse() method parses the JSON response or MTL.txt metadata file, extracts information such as scene ID, acquisition time, file paths for each band, cloud cover, and solar altitude angle, and maps them to a unified field.

[0042] For Sentinel data, the parse() method parses the Manifest.safe file or the XML / JSON response from the OpenSearch API, processing information such as dataset identifier, track number, tile number, and cloud cover. For UAV data (custom text, image EXIF, or simple JSON), the parse() method extracts the flight path number, latitude and longitude, altitude, camera parameters, etc., from the image EXIF ​​information or project configuration file.

[0043] 3) Core Adaptability: Handling different data formats (JSON / XML / text), interface protocols (REST API / OData / FTP), and information organization structures.

[0044] (2) The specific function of the extractMetadata(parsed_data) method: 1) Function definition: The extractMetadata() method refines and reorganizes the results parsed by parse() to generate "structured key metadata". This data is a JSON object that conforms to the system's internal standards (the main difference from the parse() method is that it forms a standard JSON object, and it will also focus on filtering the key information that needs to be recorded). The structured key metadata includes information such as data number, data source name, data time, sensor number, sensor name, band details, longitude, latitude, cloud cover, orbital number, data level, spatial resolution, polygon type and inflection point coordinates, storage path, etc.

[0045] 2) Example of data extraction: For the GF-6 satellite's wide-swath camera (16-meter multispectral) and high-resolution camera (2-meter panchromatic / 8-meter multispectral), this method accurately extracts and identifies the number of bands (e.g., 4 bands) and their respective spatial resolutions (e.g., 16m, 2m) corresponding to different payloads. For optical data (e.g., Landsat, Sentinel-2), this method extracts cloud cover information. For radar data (e.g., Sentinel-1), it extracts the polarization mode (VV, VH, etc.). For high-resolution data such as ZY-3, it extracts the image level (Product Level: L1A, L2A, etc.).

[0046] 3) Core adaptation point: Map metadata field names unique to different data sources (such as Landsat's CLOUD_COVER vs. Sentinel-2's Cloud cover percentage) to a unified field and handle the conversion of their units and dimensions.

[0047] (3) The specific function of the validate(query_parameters) method.

[0048] 1) Function definition: Before initiating a request, verify whether the query parameters entered by the user are valid, effective and complete for the current data source.

[0049] 2) The verification content includes: Spatial extent verification: Verify that the bounding box coordinates are within the global coverage of the data source (such as a specific orbit or region).

[0050] Time range verification: Check whether the query time is within the operational lifespan of the satellite sensor.

[0051] Parameter validity verification: For the Sentinel-1 adapter, it checks whether the "polarization mode" entered by the user is a mode supported by the sensor (e.g., IW mode supports VV+VH); for UAV data, it verifies whether the "resolution" parameter matches the camera model.

[0052] Required parameter check: Ensure that the download path parameter is provided and valid when performing the "download" operation.

[0053] 3) Core adaptation points: Implement different verification rules based on the data policies, sensor constraints, and product specifications of different data sources.

[0054] The data streaming pipeline includes a data access unit, a message publishing unit, and a downstream processing unit; wherein, the data access unit is used to obtain structured key metadata output by the adapter plugin corresponding to the data source interface, and encapsulate the structured key metadata and the corresponding processing requirements into standardized event messages.

[0055] The message publishing unit is used to publish the standardized event message to a preset topic.

[0056] The downstream processing unit is used to asynchronously and in parallel retrieve standardized event messages within a preset topic and parse the retrieved standardized event messages.

[0057] To achieve efficient collaboration and traceability across the entire data access, processing, and updating process, a remote sensing data streaming pipeline based on an event-driven architecture was constructed. Apache Kafka was used as the message middleware, and after data access, it was published to the message queue as a "data arrival event." Structured key metadata and processing requirements were encapsulated into standardized event messages and published to a specified topic in Kafka, thus decoupling data production and consumption.

[0058] (1) Event encapsulation and publication.

[0059] When the data access unit obtains new structured key metadata, the data streaming pipeline (hereinafter referred to as the pipeline) is triggered.

[0060] 1) Event Encapsulation: The event encapsulator is activated to package the newly arrived structured key metadata and its processing requirements into a standardized event message that conforms to the internal protocol. The message body includes the event ID, unique data identifier, metadata body, event type, timestamp, and target processing requirement identifier.

[0061] 2) Message Publishing: The event wrapper publishes the generated standardized event message as a "data arrival event" record to the predefined raw-metadata-events topic in Apache Kafka. This topic serves as a unified data entry point, enabling data persistence and centralized management.

[0062] The above uses an event wrapper to handle the functions of the data access unit and the message publishing unit.

[0063] (2) Message broadcasting and subscription As a message broker, the Kafka cluster is responsible for the persistence and distribution of events. 1) Topic broadcast: Messages published to the raw-metadata-events topic are persisted and retained for a specified duration for retrospection.

[0064] 2) Consumer Subscription: Different downstream processing units act as independent consumer groups, asynchronously subscribing to the raw-metadata-events topic. Kafka's mechanism ensures that the same message can be consumed in parallel by multiple consumer groups, achieving one-to-many broadcasting.

[0065] The retrieval service unit is used for: Based on the hybrid index architecture and the parsed standardized event messages, the spatial index and inverted index are updated; the hybrid index architecture is an index structure that combines the spatial index and the inverted index.

[0066] The system acquires natural language query information sent by the user and generates a query request based on the natural language query information and a cascaded semantic parsing framework. The cascaded semantic parsing framework includes an information extraction model trained on a remote sensing domain knowledge graph and a multi-dimensional intent recognition model.

[0067] Based on the spatial index, the inverted index, and the query request, query results are generated and then fed back to the user.

[0068] This application ensures that all adapter plugins adhere to a unified preset interface standard, guaranteeing that data from different data sources possesses a consistent data standard format. This facilitates subsequent data processing. The backend employs an event-driven architecture-based data stream processing pipeline, treating data access as an event and publishing data arrival as an event to trigger downstream processing units to process tasks in parallel. This improves the system's processing speed for multi-source heterogeneous data and enhances the system's real-time response. The retrieval service unit updates the spatial index and inverted index based on a hybrid index architecture and parsed standardized event messages. This enables efficient collaborative query strategies that prioritize spatial positioning filtering and precise attribute condition selection, improving data retrieval speed. Furthermore, a cascaded semantic parsing framework parses natural language query information sent by the user to generate query requests, achieving high-precision and reliable understanding of professional remote sensing query intentions.

[0069] In an exemplary embodiment, the parsed normalized event message is an incremental document; the incremental document includes incremental structured key metadata; and the retrieval service unit is configured to: update the spatial index and inverted index based on the hybrid index architecture and the parsed normalized event message; The incremental structured key metadata is processed to obtain core fields; the core fields include spatial location fields and attribute fields.

[0070] The retrieval service unit includes a metadata intelligent perception and extraction engine, which is used to extract core fields.

[0071] For standard format files such as GeoTIFF, the built-in structured metadata is directly parsed based on the GDAL and OGR libraries to obtain core fields such as geographic range, coordinate system, and band information. For semi-structured / unstructured metadata, JSON rule templates (covering keyword matching and regular expressions) are used to locate and extract key information to obtain core fields.

[0072] The difference between structured key metadata and core fields.

[0073] Structured key metadata: A complete descriptive profile containing all business information (such as band details and storage paths).

[0074] Core fields: "Labels" or "filter dimensions" selected from structured key metadata for indexing and retrieval. Suffixes (such as _keyword, _date) indicate the field type in the index. Examples include dataSource_keyword, sensor_keyword, and acquisitionTime_date.

[0075] The core fields are a subset specifically designed for index building and efficient querying. The system extracts key-value pairs from the JSON rule template as core fields, including information such as data number, data source name, data time, sensor name, cloud cover, spatial resolution, polygon type and inflection point coordinates, and data level.

[0076] Table 1 Examples of core fields

[0077] In some embodiments, index optimization strategies are also applied, including: Enable doc_values ​​caching: Enable doc_values ​​for keyword, float, and date type fields to cache field values ​​to disk, improving the efficiency of sorting and aggregation queries.

[0078] Disable unnecessary word segmentation: All attribute fields should use keyword or numeric types to avoid query ambiguity caused by word segmentation.

[0079] Field compression: Enable ES field compression mechanism for frequently repeated fields to reduce index storage usage.

[0080] The spatial location field is converted into a geometric object, and the geometric object is mapped to a geospatial geo_shape field type. When the geometric object is mapped to a geospatial geo_shape field type, a spatial index is automatically created. The automatically created spatial index is then merged with the previous spatial index in the retrieval service unit to obtain the current spatial index.

[0081] Each attribute field is indexed to generate a corresponding inverted triplet; the attribute field is a keyword type field or a numeric type field; the inverted triplet includes the keyword type field name, term, and record ID of the incremental structured key metadata where the keyword type field is located, or the inverted triplet includes the numeric type field name, value range, and record ID of the incremental structured key metadata where the numeric type field is located.

[0082] Each record ID in the inverted triplet is appended to the inverted list corresponding to the term or value range to form the current inverted list. The current inverted list is then merged with the previous inverted index in the retrieval service unit to obtain the current inverted index.

[0083] The retrieval service unit also includes a multi-dimensional cross-retrieval service module, which constructs a hybrid index structure that integrates spatial indexes and inverted indexes to achieve efficient collaborative querying of remote sensing data through "spatial positioning + attribute filtering".

[0084] (1) Spatial index construction For spatial location fields (such as administrative boundaries and custom polygons) in the core fields, the system uses the Geometry library to convert them into geometric objects conforming to the GeoJSON specification and maps them to the geo_shape field type in Elasticsearch. Elasticsearch automatically builds efficient spatial indexes such as R-trees for these geospatial fields, thereby supporting fast spatial relationship queries.

[0085] (2) Inverted index construction and core field mapping The inverted index is built using structured key metadata as the data source. When indexing metadata into Elasticsearch, the core fields are first extracted from each complete structured key metadata record, and then an inverted index is built for these core fields. The mapping process is as follows: 1) Field extraction: Filter out the core fields and their values ​​for indexing from the structured key metadata records.

[0086] 2) Indexing: Elasticsearch indexes the values ​​of each core field based on its type. For keyword fields, the value is treated as a complete term; for numeric fields, the value is included in a numeric range tree.

[0087] 3) Inverted list generation: The system maintains an inverted list for each unique index term (such as the sensor name Sentinel-2A), which records the IDs of all metadata records containing that term.

[0088] 4) Formation of mapping relationship: Thus, a mapping relationship is formed from "specific attribute value (keyword)" to "the set of all metadata record IDs containing the attribute value", that is, keyword-core field mapping information.

[0089] The internal logic of the inverted index: For the core field in the example above, Elasticsearch will construct the following mapping: dataSource_keyword field: “Landsat-8”->[Metadata record ID_of_LC08_..._T1, Metadata record ID_of_another_Landsat, ...].

[0090] sensor_keyword field: “OLI_TIRS” -> [Metadata record ID_of_LC08_..._T1, ...]. cloudCover_float field (numeric range index): [0.0 To 10.0]->[Metadata record ID_of_LC08_..._T1, Metadata record ID_of_another low cloud image,...].

[0091] The specific process of creating a hybrid index: The system sends the core fields in JSON format to Elasticsearch for indexing.

[0092] Elasticsearch automatically creates a spatial index for geometry_shape based on the field mapping.

[0093] At the same time, create inverted indexes for text / enumeration fields such as dataSource_keyword and sensor_keyword (establish the above term-metadata record ID list).

[0094] Create indexes for cloudCover_float, spatialResolution_int, and acquisitionTime_date suitable for range queries.

[0095] This embodiment uses a distributed search engine for data retrieval.

[0096] All structured key metadata is indexed into Elasticsearch. Leveraging its powerful DSL and aggregation capabilities, multi-dimensional query conditions (time range, spatial range, cloud cover requirements, data type, sensor type, resolution requirements, etc.) are combined into a complex query request and sent to the Elasticsearch cluster for execution.

[0097] The multi-dimensional cross-search service module indexes a set of core fields as Elasticsearch documents.

[0098] The process of index lookup includes: (1) Query request generation: The conditions set by the user on the front end (such as "Landsat-8 data of cloud cover in the Yangtze River Delta region in April 2023 when it was less than 10%) or the parsing results of natural language query information will be converted into structured filtering conditions (query requests) for the core fields.

[0099] (2) Execute queries using hybrid indexes 1) Spatial filtering: First, use spatial indexing to quickly find the set of image document IDs Set_A that intersects with the boundary of the "Yangtze River Delta".

[0100] 2) Attribute filtering: Then, based on Set_A, perform an AND operation using the inverted index: Find the list of metadata record IDs Set_B in the dataSource_keyword mapping with the value "Landsat-8".

[0101] Find the list of metadata record IDs Set_C in the processingLevel_keyword mapping with the value "L2SP".

[0102] Find the list of metadata record IDs Set_D in the cloudCover_float range index with values ​​<10.0.

[0103] 3) Result merging: Calculate the intersection: Result_IDs = Set_A ∩ Set_B ∩ Set_C ∩ Set_D. This process utilizes the "keyword-core field mapping information" for efficient location.

[0104] (3) Result return: The system retrieves the complete structured key metadata from Elasticsearch based on Result_IDs and returns it to the user to complete the query.

[0105] The above process can also employ query optimization strategies: automatically adjusting the query order based on the selectivity of the query conditions. Prioritizing spatial range filtering to quickly narrow down the dataset, followed by filtering based on other attributes, improves query efficiency.

[0106] Optionally, the retrieval service unit also includes an event-driven distribution engine and a built-in rule engine such as Drools. Administrators can configure rules, such as: IF event type = "earthquake" AND magnitude > 5.0 THEN automatically subscribe to all satellite data within 100 kilometers of the epicenter of the Tingri earthquake in Tibet, with cloud cover < 20% in the last 3 days.

[0107] Once the rule is triggered, a data retrieval task is automatically generated, and the results are pushed to the specified user or user group. The data retrieval task and its triggered execution operations are as follows: (1) Task instantiation: The rule engine generates a specific task instance based on the template of the THEN clause, which includes the above complete query conditions, target users, push methods and other information, and saves it to the task database.

[0108] (2) Generate a structured query request: The task scheduler converts the "query conditions" part of the task into a structured query request (JSON format) that is fully compatible with the API of the multi-dimensional cross-retrieval service module in the above embodiment. For example, "100-kilometer buffer zone around the epicenter" is converted into a GeoJSON geometric object.

[0109] (3) Call the search service: The system asynchronously calls the query interface provided by the multi-dimensional cross-search service module and submits the structured query request generated in the previous step. This process is consistent with the path of a regular user initiating a search on the front end.

[0110] (4) Processing search results: After executing the query, the multi-dimensional cross-search service module returns a list of data metadata that meets the criteria. The distribution engine receives this list.

[0111] (5) Results push: Based on the “target user group” and “push method” defined in the task, the search results (data list, overview, access link) are encapsulated into a notification message and sent to the corresponding user through the message service.

[0112] (6) Task status management: The task enters the "completed" status, or is set to be executed periodically according to the "task validity period" (e.g., executed once a day to obtain the latest data).

[0113] To address the challenge of efficiently retrieving massive amounts of remote sensing metadata, this invention designs a hybrid index architecture that integrates spatial indexes and inverted indexes. By mapping the spatial range and timestamps of standardized metadata to Elasticsearch's geospatial index, and simultaneously constructing inverted indexes from attribute fields such as sensor and cloud cover, an efficient collaborative query strategy of "spatial location-based filtering and attribute-based precise selection" is achieved. Combined with an Elasticsearch distributed cluster, this enables more comprehensive, faster, and more accurate complex combined queries.

[0114] In an exemplary embodiment, regarding the generation of a query request based on the natural language query information and the cascaded semantic parsing framework, the retrieval service unit is configured to: The information extraction model identifies entity information in the natural language query information; the entity information is an entity in a remote sensing domain knowledge graph; the information extraction model is a trained NER model; the trained NER model is a model obtained by training the NER model with the constructed remote sensing domain knowledge graph.

[0115] The entity information is parsed based on the multi-dimensional intent recognition model to obtain multi-dimensional intent information, and a query request is generated based on the multi-dimensional intent information. The multi-dimensional intent recognition model is a trained LLM large language model. The trained LLM large language model is a model obtained by training the LLM large language model based on a fine-tuned dataset in the remote sensing domain and historical query requests. The fine-tuned dataset is a dataset constructed based on the structured key metadata and the remote sensing terminology dictionary.

[0116] The query request generation process may include: The user enters a natural language query: "Help me find Landsat 8 images of Beijing with cloud cover below 10% in the summer of 2023."

[0117] The retrieval service unit first identifies the time entity "Summer 2023", the spatial entity "Beijing", the attribute entity "cloud cover less than 10%" and the data source entity "Landsat8" through the information extraction model.

[0118] Subsequently, a multi-dimensional intent recognition model is used to convert time entities into time range conditions ["2023-06-01", "2023-08-31"], spatial entities into geographic boundary polygons, attribute entities into numerical conditions cloudCover<0.1, and data source entities into exact matching conditions dataSource = "Landsat-8". Finally, a structured query request is generated based on the above information.

[0119] In some embodiments, the retrieval service unit further includes an intelligent report generator, which supports multi-scenario adaptation and enables automated and standardized presentation of remote sensing data retrieval results. It incorporates multiple professional report templates covering core scenarios such as multi-source remote sensing data query result reports, remote sensing domain knowledge Q&A reports, and data statistical analysis reports. Based on the Jinja2 template engine, it deeply integrates retrieved remote sensing images, multi-dimensional statistical charts, and structured data tables with professional text descriptions automatically generated through natural language generation technology, supporting one-click export of standardized PDF reports.

[0120] To address the pain point of traditional remote sensing platforms' inability to understand users' professional intent, this invention proposes a cascaded semantic parsing framework of "knowledge graph + NER + domain LLM". First, a NER model trained using a remote sensing domain knowledge graph accurately extracts entity information from the query. Then, an LLM large-scale language model trained using a fine-tuned dataset in the remote sensing domain completes multi-dimensional intent recognition. Finally, the trained LLM large-scale language model is guided to generate unambiguous structured query instructions. This achieves high-precision and reliable understanding of professional remote sensing query intent.

[0121] After data is accessed, the "data arrival" event is published to the message middleware through an event-driven architecture, triggering downstream processing units to process it. Downstream processing units, such as data statistical analysis and index update functions, act as message consumers, asynchronously subscribe to the corresponding topics, pull tasks on demand and process them in parallel, thereby completing a fully automated and real-time integration pipeline from the data source to the available service.

[0122] In an exemplary embodiment, the downstream processing unit is an index update consumer, which is used for: The system asynchronously and in parallel retrieves standardized event messages from a preset topic, parses the retrieved standardized event messages to obtain incremental structured key metadata, and sends the incremental structured key metadata to the retrieval service unit.

[0123] Input: Pull event messages from the raw-metadata-events topic.

[0124] Processing: Parse the message and extract the structured key metadata (incremental structured key metadata). Then, directly call the Elasticsearch client API to index or update the corresponding hybrid index as an incremental document using this metadata.

[0125] Output: Generates or updates the corresponding index records in Elasticsearch.

[0126] In one exemplary embodiment, the downstream processing unit is a statistical analysis consumer, which is used for: Asynchronously and in parallel, standardized event messages within a preset topic are retrieved and parsed to obtain incremental structured key metadata.

[0127] The incremental structured key metadata is aggregated and analyzed according to one or more preset statistical dimensions to obtain the statistical analysis results of the incremental structured key metadata, and the statistical analysis results are sent to the retrieval service unit; the statistical analysis results include the statistical quantity of the incremental structured key metadata under each statistical dimension.

[0128] Input: Pull event messages from the raw-metadata-events topic.

[0129] Processing: Parse metadata and perform real-time aggregation analysis according to one or more statistical dimensions (such as aggregation by sensor type, region, and time dimension).

[0130] Statistical dimensions, for example: Statistics by sensor type: Using the sensor field in the incremental structured key metadata as the grouping key, the number of new data scenes added for each sensor type within a specific time window is counted.

[0131] Statistics by geographic region: Based on the spatial range field in the metadata, data is aggregated to a preset geographic administrative region, such as province, city, or county-level administrative divisions.

[0132] Statistics are based on natural regions, such as watersheds and ecological functional zones.

[0133] Statistics can be calculated using a custom grid, such as a latitude and longitude grid of 0.1° × 0.1°.

[0134] Statistics by time dimension: Data is aggregated at multiple granularities based on the data collection time, for example: Real-time statistics: the amount of new data in the last hour and 24 hours; Daily / monthly / yearly statistics: aggregated by natural day, month, and year.

[0135] Statistics by data attribute: Aggregation based on core business fields: Cloud cover distribution: Statistics on the amount of data with cloud cover percentages in the ranges of [0-10%], [10-30%], [30-50%], and [50-100%]; Product level: Statistics on the amount of data at different processing levels such as L1, L2, and L3; Resolution distribution: Statistics on the amount of data at different spatial resolutions (e.g., 10m and 30m).

[0136] Output: Send the statistical results to the retrieval service unit.

[0137] In an exemplary embodiment, the parsed standardized event message is an incremental document; the incremental document includes incremental structured key metadata; the retrieval service unit is further configured to: The system obtains the statistical analysis results of the incremental structured key metadata and updates the time-series database and / or business database based on the statistical analysis results. The time-series database and / or business database are used to store the statistical analysis results of all structured key metadata for querying and access by the system's data visualization module (display device) or other data consumption services.

[0138] The retrieval service unit provides a data access interface to the application layer through the statistical query API service. The display device is deployed at the application presentation layer and interacts with the statistical query API service through HTTP / RESTful API to obtain statistical analysis results stored in the time series database and / or business database, which are used to visualize the statistical analysis results of all structured key metadata.

[0139] In an exemplary embodiment, the downstream processing unit is a task-triggered consumer, which is used for: Asynchronously and in parallel, standardized event messages within a preset topic are retrieved and parsed to obtain incremental structured key metadata.

[0140] Data distribution and subscription task instructions are generated based on pre-configured business rules and the incremental structured key metadata, and then published to a task topic. The task topic is a preset topic within the message middleware, a separate topic consumed by task execution services. The task topic is subscribed to and consumed by downstream corresponding task execution services (such as task schedulers and workflow engines) to complete the specific operations defined by the task instructions.

[0141] The process of generating a data distribution and subscription task instruction based on pre-configured business rules and the incremental structured key metadata refers to matching the incremental structured key metadata with the pre-configured business rules. If the match is successful, a data distribution and subscription task instruction is automatically generated.

[0142] In some embodiments, the method further includes generating image processing task instructions based on pre-configured business rules and the incremental structured key metadata, and publishing the image processing task instructions to a task topic.

[0143] Input: Pull event messages from the raw-metadata-events topic.

[0144] Processing: The message content of incremental structured key metadata (such as data source, region, etc.) is matched with pre-configured business rules (rule base) to determine whether specific conditions are met. If met, a data distribution subscription task or an image processing task message is automatically generated.

[0145] If the rule is defined as: "dataSource" equals "Landsat-8" and "region" contains "Beijing", a data distribution subscription task will be generated.

[0146] When the incremental structured key metadata meets the above conditions, a data distribution subscription task instruction is generated. The task instruction includes: Task type: such as "data_distribution" or "image_processing"; Task ID: a globally unique task identifier; Source data identifier: the ID of the metadata record that triggered the task; Target information: for distribution tasks, specify the recipient or target system; for processing tasks, specify the processing requirements and parameters; Priority: the priority of task execution; Timestamp: the time the task was generated.

[0147] The generation process for image processing tasks is similar to that of data distribution and subscription tasks, and will not be elaborated upon here. Parameter extraction for image processing tasks includes extracting the necessary parameters from incremental structured key metadata, such as: data path: the storage location of the original image; processing level: atmospheric correction from L1C to L2A; output format: GeoTIFF; processing region: the region of interest in the image; output: generating new task instructions and publishing them to a Kafka task topic or writing them to a task queue.

[0148] The downstream processing unit provides state persistence and confirmation functions.

[0149] Processing Status Tracking: After key processing steps (such as successful indexing or statistical completion) are completed, consumers can send status event messages to a dedicated `processing-status` topic to achieve end-to-end traceability of the processing. The `processing-status` topic is customizable and primarily broadcasts and records the success, failure, and progress status of core data processing stages.

[0150] Consumer offset commit: After processing a message, the consumer commits the consumption offset to Kafka to ensure at least one reliable delivery of the message and prevent data loss or duplicate processing.

[0151] In an exemplary embodiment, the parsed standardized event message is an incremental document; the incremental document includes incremental structured key metadata; the retrieval service unit is further configured to: Based on the user's historical query keywords, historical application records, industry sector selected during registration, and interest extraction model, a user interest vector is generated.

[0152] By analyzing users' historical query keywords, historical data application records, and industry sectors selected during user registration, the BERTopic model is used to extract user interest topics and generate user interest vectors (including user interest tags and their weights).

[0153] 1) Determine user interest tags (referred to as tags), including primary tags and secondary tags.

[0154] Primary tags: Core requirement tags (including data type, geographic region, resolution level, etc.).

[0155] Secondary tags: Interest value tags (values ​​corresponding to core need tags).

[0156] First, based on knowledge in the field of remote sensing and combined with statistical analysis of the frequency of various query condition fields in behavioral data such as user historical query logs and data application records, the primary labels are determined based on the statistical analysis results. Second, specific secondary label values ​​are determined for each primary label through value range enumeration, numerical discretization, and topic clustering (such as BERTopic).

[0157] 2) Determine the behavioral weights of user interest tags, and use the TF-IDF weighting method combined with behavioral weights to quantify the importance of user interest tags.

[0158] TF-IDF = TF × IDF.

[0159] TF (Term Frequency) = Number of times a tag appears in the current user's text ÷ Total number of times all tags appear in the current user's text.

[0160] IDF (Inverse Document Frequency) = log((Total number of users + 1) ÷ (Number of users containing this tag + 1)) + 1.

[0161] Behavioral weights: Data request behavior weight (weight=3) > Query click weight (weight=2) > Normal query weight (weight=1).

[0162] Time decay: Within the last 3 months, the behavior weight is multiplied by 1.0; within 3-6 months, the behavior weight is multiplied by 0.7; within 6-12 months, the behavior weight is multiplied by 0.3; and within 1 year or more, the behavior weight is multiplied by 0.1.

[0163] Final label weight = behavior weight × TF-IDF value × time decay factor.

[0164] 3) Interest Vector Generation: Sort all user interest tags according to a preset dictionary, and use the weight of the final user interest tag as the vector dimension value to generate a fixed-length user interest vector.

[0165] Based on the user interest vector and the incremental structured key metadata, a push instruction is generated, and push data is generated based on the incremental structured key metadata. The push data is then fed back to the user.

[0166] In an exemplary embodiment, the retrieval service unit is configured to: generate push instructions based on the user interest vector and the incremental structured key metadata, and generate push data based on the incremental structured key metadata. S1, Based on the core requirement tags, extract core features from the incremental structured key metadata, and determine the feature vector of the incremental structured key metadata based on all core features; the core features correspond one-to-one with the core requirement tags; The feature vector generation method is as follows: When a new structured key metadata record is generated, it is precisely matched to a global standardized tag system consisting of all core requirement tags and their values ​​based on its core field content; then, a weight value is assigned to each tag using a preset weight calculation rule: if the content of the incremental structured key metadata completely matches the feature described by the tag, the weight is set to 1.0, otherwise it is set to 0; finally, all tags are arranged in a fixed global order, and their weight values ​​form a fixed-length floating-point array, i.e., the feature vector.

[0167] For example, take the aforementioned Landsat-8 data as an example.

[0168] 1) Tagging.

[0169] For example, based on the core fields of Landsat-8: dataSource: "Landsat-8", sensor: "OLI_TIRS", processingLevel: "L2SP", spatialResolution: 30, cloudCover: 5.2, a tag set can be generated for it: ["Landsat-8", "Optical", "Multispectral", "L2 Level Product", "30-meter Resolution", "Cloud Cover [0-10%]"].

[0170] 2) Weight calculation.

[0171] We use user interest tags to calculate the weight of each tag.

[0172] "Landsat-8": 0.85; "Optics": 0.75; "30-meter resolution": 0.60; "Cloud cover [0-10%]": 0.90; "Level 2 product": 0.55; (Other unseen tags have a weight of 0).

[0173] 3) Vector generation Arrange all tags in a preset global order (a dictionary containing 50 standard tags), fill in the corresponding weight values ​​in the corresponding positions, fill in 0 for missing tags, and form a fixed-length array.

[0174] “feature_vector”: [0.85, 0.75, 0.0, 0.55, 0.60, 0.90, 0.0, 0.0, ...] / / A float array with a fixed length of 50.

[0175] S2, calculate the cosine similarity between the user interest vector and the feature vector.

[0176] S3, when the cosine similarity is greater than a preset threshold, a push instruction is generated, and push data is generated based on the incremental structured key metadata; the push data includes the name, type, summary and application link of the incremental structured key metadata.

[0177] Cosine similarity calculation and threshold determination.

[0178] Similarity calculation: The similarity between the feature vector of incremental structured key metadata and the user interest vector is calculated using the cosine similarity formula (the value ranges from 0 to 1, and the closer it is to 1, the higher the interest matching degree).

[0179] Cosine similarity formula: .

[0180] in, User interest vector, This is the feature vector for incrementally structured key metadata. The numerator is the dot product of the two vectors, and the denominator is the product of the L2 norms of the two vectors. The calculated result ranges from [0,1], with values ​​closer to 1 indicating a higher degree of interest matching.

[0181] Threshold setting: Set dynamic thresholds based on business scenarios. The default threshold is 0.7, which can be adjusted according to user activity: 0.65 for high-frequency users and 0.75 for low-frequency users.

[0182] Triggering condition: Personalized push notifications are triggered when the similarity is greater than or equal to the set threshold.

[0183] The push content includes core information such as the name, type, metadata summary, and application link of incremental structured key metadata.

[0184] Push Channel Manager.

[0185] Push channel: Push notifications via platform in-site notifications.

[0186] In one exemplary embodiment, a spatiotemporal information processing method based on multi-source remote sensing data is provided, such as... Figure 2 The diagram shown is a flowchart illustrating a spatiotemporal information processing method based on multi-source remote sensing data.

[0187] This spatiotemporal information processing method based on multi-source remote sensing data includes: S201, the adapter plugin obtains remote sensing data from the corresponding data source interface and processes the remote sensing data to obtain structured key metadata; wherein, all the adapter plugins follow a unified preset interface standard, and each adapter plugin can only be bound to one data source interface one-to-one.

[0188] S202, the data access unit obtains the structured key metadata output by the adapter plug-in corresponding to the data source interface, and encapsulates the structured key metadata and the corresponding processing requirements into a standardized event message.

[0189] S203, the message publishing unit publishes the standardized event message to the preset topic of the message middleware.

[0190] S204, the downstream processing unit asynchronously and in parallel pulls standardized event messages within a preset topic and parses the pulled standardized event messages.

[0191] S205, the retrieval service unit updates the spatial index and inverted index according to the hybrid index architecture and the parsed standardized event messages; the hybrid index architecture is an index structure that combines the spatial index and the inverted index.

[0192] S206, the retrieval service unit obtains the natural language query information sent by the user terminal, and generates a structured query request based on the natural language query information and the cascaded semantic parsing framework; the cascaded semantic parsing framework includes an information extraction model trained based on a remote sensing domain knowledge graph and a multi-dimensional intent recognition model fine-tuned based on the remote sensing domain.

[0193] S207, the retrieval service unit generates query results based on the spatial index, the inverted index, and the query request, and feeds the query results back to the user terminal.

[0194] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Moreover, the collection, use and processing of the relevant data are carried out in compliance with the relevant data protection laws and policies of the country where the location is located, and with the authorization granted by the owner of the corresponding device.

[0195] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0196] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0197] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0198] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A spatiotemporal information system based on multi-source remote sensing data, characterized in that, The spatiotemporal information system based on multi-source remote sensing data includes: a backend; the backend includes multiple adapter plugins, a data streaming pipeline based on an event-driven architecture, and a retrieval service unit; wherein, all the adapter plugins follow a unified preset interface standard, and each adapter plugin can only be bound to one data source interface one-to-one; The adapter plugin is used to obtain remote sensing data from the corresponding data source interface and process the remote sensing data to obtain structured key metadata. The data streaming pipeline includes a data access unit, a message publishing unit, and a downstream processing unit. The data access unit acquires structured key metadata output by the adapter plugin corresponding to the data source interface and encapsulates the structured key metadata and corresponding processing requirements into standardized event messages. The message publishing unit publishes the standardized event messages to a preset topic. The downstream processing unit asynchronously and in parallel retrieves standardized event messages from the preset topic and parses the retrieved standardized event messages. The retrieval service unit is used for: Based on the hybrid index architecture and the parsed standardized event messages, the spatial index and inverted index are updated; the hybrid index architecture is an index structure that combines the spatial index and the inverted index. The system acquires natural language query information sent by the user and generates a query request based on the natural language query information and the cascaded semantic parsing framework. The cascaded semantic parsing framework includes an information extraction model trained on a remote sensing domain knowledge graph and a multi-dimensional intent recognition model. Based on the spatial index, the inverted index, and the query request, query results are generated and then fed back to the user.

2. The spatiotemporal information system based on multi-source remote sensing data according to claim 1, characterized in that, The parsed standardized event message is an incremental document; the incremental document includes incremental structured key metadata; in updating the spatial index and inverted index according to the hybrid index architecture and the parsed standardized event message, the retrieval service unit is used for: The incremental structured key metadata is processed to obtain core fields; the core fields include spatial location fields and attribute fields; The spatial location field is converted into a geometric object, and the geometric object is mapped to a geospatial geo_shape field type. When the geometric object is mapped to a geospatial geo_shape field type, a spatial index is automatically created. The automatically created spatial index is then merged with the previous spatial index in the retrieval service unit to obtain the current spatial index. Each attribute field is indexed to generate a corresponding inverted triplet; the attribute field is a keyword type field or a numeric type field; the inverted triplet includes the keyword type field name, term, and record ID of the incremental structured key metadata where the keyword type field is located, or the inverted triplet includes the numeric type field name, value range, and record ID of the incremental structured key metadata where the numeric type field is located. Each record ID in the inverted triplet is appended to the inverted list corresponding to the term or value range to form the current inverted list. The current inverted list is then merged with the previous inverted index in the retrieval service unit to obtain the current inverted index.

3. The spatiotemporal information system based on multi-source remote sensing data according to claim 1, characterized in that, In generating query requests based on the natural language query information and the cascaded semantic parsing framework, the retrieval service unit is configured to: The information extraction model identifies entity information in the natural language query; the entity information is an entity in a remote sensing domain knowledge graph; the information extraction model is a trained NER model; the trained NER model is a model obtained by training the NER model with the constructed remote sensing domain knowledge graph. The entity information is parsed based on the multi-dimensional intent recognition model to obtain multi-dimensional intent information, and a query request is generated based on the multi-dimensional intent information. The multi-dimensional intent recognition model is a trained LLM large language model; the trained LLM large language model is a model obtained by training the LLM large language model based on a fine-tuned dataset in the remote sensing domain and historical query requests; the fine-tuned dataset is a dataset constructed based on the structured key metadata and the remote sensing terminology dictionary.

4. The spatiotemporal information system based on multi-source remote sensing data according to claim 1, characterized in that, The downstream processing unit is an index update consumer, which is used for: The system asynchronously and in parallel retrieves standardized event messages from a preset topic, parses the retrieved standardized event messages to obtain incremental structured key metadata, and sends the incremental structured key metadata to the retrieval service unit.

5. The spatiotemporal information system based on multi-source remote sensing data according to claim 1, characterized in that, The downstream processing unit is a statistical analysis consumer, which is used for: Asynchronously and in parallel, standardized event messages within a preset topic are retrieved, and the retrieved standardized event messages are parsed to obtain incremental structured key metadata; The incremental structured key metadata is aggregated and analyzed according to one or more preset statistical dimensions to obtain the statistical analysis results of the incremental structured key metadata, and the statistical analysis results are sent to the retrieval service unit; the statistical analysis results include the statistical quantity of the incremental structured key metadata under each statistical dimension.

6. The spatiotemporal information system based on multi-source remote sensing data according to claim 1, characterized in that, The parsed standardized event message is an incremental document; the incremental document includes incremental structured key metadata; the retrieval service unit is also used for: Obtain the statistical analysis results of the incremental structured key metadata, and update the time-series database and / or business database based on the statistical analysis results; the time-series database and / or business database are used to store the statistical analysis results of all structured key metadata.

7. The spatiotemporal information system based on multi-source remote sensing data according to claim 1, characterized in that, The downstream processing unit is a task-triggered consumer, which is used for: Asynchronously and in parallel, standardized event messages within a preset topic are retrieved, and the retrieved standardized event messages are parsed to obtain incremental structured key metadata; Data distribution and subscription task instructions are generated based on pre-configured business rules and the incremental structured key metadata, and the data distribution and subscription task instructions are published to the task topic; the task topic is a topic in the preset topics.

8. The spatiotemporal information system based on multi-source remote sensing data according to claim 1, characterized in that, The parsed standardized event message is an incremental document; the incremental document includes incremental structured key metadata; the retrieval service unit is also used for: Based on the user's historical query keywords, historical data application records, industry sector selected during registration, and interest extraction model, a user interest vector is generated. Based on the user interest vector and the incremental structured key metadata, a push instruction is generated, and push data is generated based on the incremental structured key metadata. The push data is then fed back to the user.

9. The spatiotemporal information system based on multi-source remote sensing data according to claim 8, characterized in that, The user interest vector includes core demand tags; in generating push instructions based on the user interest vector and the incremental structured key metadata, and generating push data based on the incremental structured key metadata, the retrieval service unit is used for: Based on the core requirement tags, core features are extracted from the incremental structured key metadata, and the feature vector of the incremental structured key metadata is determined based on all core features; The core features correspond one-to-one with the core requirement tags; Calculate the cosine similarity between the user interest vector and the feature vector; When the cosine similarity is greater than a preset threshold, a push instruction is generated, and push data is generated based on the incremental structured key metadata; the push data includes the name, type, summary, and application link of the incremental structured key metadata.

10. A spatiotemporal information processing method based on multi-source remote sensing data, characterized in that, The spatiotemporal information processing method based on multi-source remote sensing data includes: The adapter plugin obtains remote sensing data from the corresponding data source interface and processes the remote sensing data to obtain structured key metadata; wherein, all the adapter plugins follow a unified preset interface standard, and each adapter plugin can only be bound to one data source interface one-to-one; The data access unit obtains the structured key metadata output by the adapter plugin corresponding to the data source interface, and encapsulates the structured key metadata and the corresponding processing requirements into standardized event messages; The message publishing unit publishes the standardized event message to a preset topic; Downstream processing units asynchronously and in parallel retrieve standardized event messages from a preset topic and parse the retrieved standardized event messages; The retrieval service unit updates the spatial index and inverted index based on the hybrid index architecture and the parsed standardized event messages; the hybrid index architecture is an index structure that combines the spatial index and the inverted index. The retrieval service unit obtains natural language query information sent by the user terminal, and generates a query request based on the natural language query information and the cascaded semantic parsing framework; the cascaded semantic parsing framework includes an information extraction model trained based on a remote sensing domain knowledge graph and a multi-dimensional intent recognition model. The retrieval service unit generates query results based on the spatial index, the inverted index, and the query request, and then sends the query results back to the user.

Images