Operator knowledge graph construction method and device for geospatial workflow orchestration

Abstract

The application discloses a kind of operator knowledge graph construction method and device for geospatial workflow arrangement, belong to the cross technical field of geographic information system and artificial intelligence.The method first collects geographic processing operator document and is standardized as the operator instance containing input slot, output slot and parameter slot;Further, the ability of operator is abstracted and slot contract is established, and the input and output product type matching and parameter binding rule are clarified;Then, the geospatial execution constraint is modeled as constraint type node, and the repair action node and repair link when constraint is not satisfied are constructed;Finally, the heterogeneous graph pattern containing operator, ability, slot, constraint, repair action and the relationship of node is designed, and the structured knowledge graph is output after node construction, relationship construction, consistency check.The application converts the dispersed operator document into computable, traversable and checkable graph structure knowledge, improves the correctness and reliability of geospatial analysis process automatic call.

Description

Technical Field

[0001] This invention belongs to the field of interdisciplinary technology of geographic information systems and artificial intelligence, and specifically relates to a method and apparatus for constructing operator knowledge graphs for geospatial workflow orchestration. Background Technology

[0002] The automated orchestration of geospatial analysis workflows requires the automatic selection of operators and the construction of executable processing chains based on the analysis objectives. This process relies not only on the functional specifications of individual operators but also on knowledge of the compatibility of input and output types and parameter requirements of preceding and subsequent operators. Therefore, the way operator knowledge is organized directly affects the reliability of operator retrieval, workflow connection, and execution invocation.

[0003] The existing operator organization methods can be broadly classified into three categories.

[0004] The first type is the operator organization method based on document indexing. This method typically organizes operator information hierarchically according to "software library—module directory—function or method—document page," providing functional descriptions, parameter explanations, return value descriptions, precautions, and sample code in the document page. This method is one of the most widely used operator organization forms, facilitating human learning, retrieval, and invocation. For large language models, natural language documents can provide clues such as operator functionality and parameter meanings; however, this information is usually scattered in unstructured text, lacking explicit expression of input / output, parameter dependencies, applicable conditions, and invocation constraints. Therefore, in automated orchestration scenarios, this method is difficult to directly support stable, traceable, and verifiable operator invocation.

[0005] The second category is the structured entry-based operator organization. This approach extracts the operator name, library, call signature, parameter list, return value, descriptive text, and some example patterns into structured entries to support function-level retrieval, semantic matching, or automated invocation. Compared to pure document indexing, this approach improves the machine readability of operator information and is easier to use in conjunction with retrieval enhancement generation methods or code generation models. However, the core organizational unit of this approach is usually still a single function or operator entry, which cannot depict the connections and dependencies between operators. For geospatial analysis workflows, automatic orchestration not only needs to identify whether a particular operator can be invoked, but also needs to determine whether multiple operators can be linked together to form a continuous and executable processing chain. Organizing operator knowledge solely with function entries and their parameter text will interpret operators as isolated calling units, making it difficult to support cross-operator input-output connections.

[0006] The third category is graph-based organization. This type of approach typically extracts processing steps, input / output data, operator call relationships, and step dependencies from existing geoprocessing scripts and modeling cases, organizing them into a graph structure or relational knowledge base. Compared to document indexing and function-level structured entries, this method focuses on the combination relationships between multiple operators or processing steps, supporting the retrieval of similar historical cases, the reuse of existing process fragments, and the generation of reference processing paths. However, historical process subgraphs essentially reflect the step combination relationships in specific cases. For open geospatial analysis tasks, changes in input types, field structures, coordinate references, and geometric states can all compromise the applicability of existing subgraphs, making it difficult to directly support reliable automatic operator invocation and workflow orchestration.

[0007] Document-based organization is primarily geared towards manual browsing. While this method includes information such as operator functionality, parameter descriptions, input / output requirements, and usage conditions, the documents often contain a large amount of explanatory and exemplary content, resulting in significant information redundancy. Furthermore, it lacks explicit modeling of functional relationships between operators, input / output connections, parameter dependencies, and invocation conditions. Therefore, this method is difficult to directly support the operator selection, process connection, and invocation verification required for automated orchestration.

[0008] Structured entry-based operator organization improves the machine readability of operator information, but its focus typically remains on the interface description of individual operators. This approach can organize operator names, libraries, input / output types, parameter lists, and descriptive text into structured entries, thus supporting function-level retrieval and single-operator calls. However, geospatial analysis workflows require the sequential execution of multiple operators, and whether the output of one operator satisfies the input conditions of the next is a critical issue in workflow orchestration. If the knowledge structure only stores inputs, outputs, and parameters as attributes of individual operators without further modeling the input-output connections between operators, different operators remain organized as isolated calling units. Therefore, while this approach improves the structured representation of single-operator information, its modeling of inter-operator connections remains insufficient.

[0009] While graph-based workflow organization begins to express relationships between processing steps, its graph structure is often derived from historical scripts, existing cases, or fixed workflows. The relationships expressed are typically instance-level combinations of steps. These relationships can illustrate that certain steps have appeared adjacently, been used together, or been executed in a specific order within existing processes, making them suitable for similar case retrieval and reuse of existing process segments. However, for new geospatial analysis tasks, input data types, field structures, and analysis objectives may all change, and the combination of steps in historical subgraphs may no longer meet the data conditions and execution requirements of the current task. This graph structure struggles to support operator selection and automatic connection relationships in open tasks. Summary of the Invention

[0010] To address the above technical problems, this invention proposes a method and apparatus for constructing an operator knowledge graph for geospatial workflow orchestration. This method uses official documentation, interface specifications, parameter definitions, and constraint rules of geoprocessing operators as its factual sources, and employs operator instance standardization, capability abstraction, slot contract modeling, spatial constraint modeling, repair action modeling, node generation, edge generation, and... Figure 1 Consistency verification is performed by constructing a heterogeneous knowledge graph for automatic orchestration of geospatial analysis workflows. This knowledge graph unifies the representation of operator capabilities, inputs and outputs, parameter slots, execution constraints, repair actions, and inter-operator connections, transforming operator knowledge from scattered document descriptions and historical workflow fragments into computable, traversable, and verifiable structured knowledge. This supports operator retrieval, workflow connection, parameter binding, and execution verification in natural language tasks. The specific technical solution is as follows:

[0011] A method for constructing operator knowledge graphs for geospatial workflow orchestration includes the following steps:

[0012] Collect official documentation and interface definition information of geoprocessing operators to form a set of raw operator records. Then, through standardized mapping, convert each raw operator record into a standardized operator instance containing operator identifier, platform, algorithm name, function description, input slot set, output slot set, parameter slot set, and tool service mapping information.

[0013] The standardized operator instances are abstracted to map specific operators to operator capability nodes that express processing intentions, and a slot contract is constructed for each operator instance. The slot contract includes input slots and their acceptable product types, output slots and their returned product types, parameter slots and their parameter types, default values, allowed values, field sources, and parameter dependencies.

[0014] The spatial correctness conditions that the operator must satisfy before the call are modeled as constraint type nodes, and the handling methods when the constraints are not satisfied are modeled as repair action nodes. A repair link is established from the constraint type node to the repair action node, and from the repair action node to the specific operator node that supports the repair action.

[0015] Design a heterogeneous knowledge graph pattern that includes a set of nodes and a set of edges. The set of nodes includes at least operator nodes, capability nodes, slot nodes, type nodes, constraint nodes, repair nodes, and service mapping nodes. The set of edges includes at least capability realization relationships, slot relationships, type relationships, constraint relationships, repair relationships, and service mapping relationships.

[0016] Based on the standardized operator instance, capability abstraction result, slot contract, constraint type node, repair action node, and graph pattern, node construction and relationship construction are executed sequentially. Figure 1 Consistency verification and graph output generate the operator knowledge graph; wherein, the node construction is based on the structured knowledge file to construct various types of nodes, and the relationship construction establishes various types of edges according to the structured knowledge file. Figure 1 The consistency check should at least verify the uniqueness of node identifiers, edge identifiers, suspended relationships, slot contract integrity, and constraint repair link integrity. After the check passes, a structured graph file will be output.

[0017] An operator-based knowledge graph construction device for geospatial workflow orchestration includes the following modules:

[0018] The conversion module collects official documentation and interface definition information of geoprocessing operators to form a set of raw operator records. It then converts each raw operator record into a standardized operator instance through standardized mapping, which includes operator identifier, platform, algorithm name, function description, input slot set, output slot set, parameter slot set, and tool service mapping information.

[0019] The mapping module abstracts the capabilities of the standardized operator instances, maps specific operators to operator capability nodes that express processing intentions, and constructs slot contracts for each operator instance. The slot contracts include input slots and their acceptable product types, output slots and their returned product types, parameter slots and their parameter types, default values, allowed values, field sources, and parameter dependencies.

[0020] The modeling module models the spatial correctness conditions that operators must satisfy before being called as constraint type nodes, and models the handling methods taken when constraints are not satisfied as repair action nodes, establishing repair links from constraint type nodes to repair action nodes, and from repair action nodes to specific operator nodes that support the repair action.

[0021] The design module designs a heterogeneous knowledge graph pattern that includes a set of nodes and a set of edges. The set of nodes includes at least operator nodes, capability nodes, slot nodes, type nodes, constraint nodes, repair nodes, and service mapping nodes. The set of edges includes at least capability realization relationships, slot relationships, type relationships, constraint relationships, repair relationships, and service mapping relationships.

[0022] The generation module, based on the standardized operator instance, capability abstraction result, slot contract, constraint type node, repair action node, and the graph pattern, sequentially performs node construction, relationship construction, and... Figure 1Consistency verification and graph output generate the operator knowledge graph; wherein, the node construction is based on the structured knowledge file to construct various types of nodes, and the relationship construction establishes various types of edges according to the structured knowledge file. Figure 1 The consistency check should at least verify the uniqueness of node identifiers, edge identifiers, suspended relationships, slot contract integrity, and constraint repair link integrity. After the check passes, a structured graph file will be output.

[0023] An electronic device includes: one or more processors; and a memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the method.

[0024] A computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, cause the processor to implement the method described thereon.

[0025] The beneficial effects of this invention are as follows:

[0026] By transforming operators that were originally scattered in document descriptions into unified graph structure knowledge, automated systems can select operators, connect processes, and determine execution conditions based on task requirements and data status, thereby improving the accuracy of the automatic invocation process of GIS operators. Attached Figure Description

[0027] Figure 1 This is a schematic diagram of the knowledge graph structure of the present invention;

[0028] Figure 2 A flowchart for constructing a geographical operator knowledge graph that takes spatial constraints into account. Detailed Implementation

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

[0030] Glossary

[0031] Slot: A slot is a unit used by an operator to receive input data, generate output results, or receive runtime parameters during automatic invocation. Slots are used to describe "what objects need to be bound when an operator is invoked, what type or conditions the object should meet, and how the object connects with other operators or data".

[0032] Input slots: These are the input data that need to be bound before an operator is executed. They describe the types of data objects that the operator can accept and their constraints, such as vector layers, raster layers, tabular data, geometric objects, etc.

[0033] Output slots: These refer to the output data generated after the operator is executed. They describe the type of data product returned by the operator and the result format that can be used by subsequent operators, such as output vectors, output rasters, statistical tables, or visualization results.

[0034] Parameter slots: These refer to the runtime parameters that need to be configured during operator execution, in addition to the input data objects. They are used to describe parameter types, default values, valid values, field sources, parameter dependencies, and binding rules, such as distance thresholds, field names, enumeration options, expressions, coordinate reference systems, or output paths.

[0035] This invention proposes a method for constructing an operator knowledge graph for geospatial workflow orchestration. This method uses the QGIS Processing operator system and its official documentation, parameter definitions, input / output descriptions, and execution constraint information as fact sources, and performs unified collection, parsing, and standardized organization of operators.

[0036] like Figure 1As shown, the method revolves around the operator selection, input-output connection, parameter binding, execution constraint judgment, and repair action insertion requirements in the automatic orchestration of geospatial analysis workflow. It unifies the objects such as specific operators, operator capabilities, input slots, output slots, parameter slots, product types, parameter types, constraint types, repair actions, and tool service mappings into a heterogeneous graph structure. The operator nodes are connected to operator capability nodes through capability implementation relationships, expressing the processing capabilities implemented by a specific operator; they are connected to input slot nodes through input slot relationships, and the input slot nodes are further connected to their acceptable product types, expressing the operator's input contract; they are connected to output slot nodes through output slot relationships, and the output slot nodes are further connected to their returned product types, expressing the operator's output contract; they are connected to parameter slot nodes through parameter slot relationships, and the parameter slot nodes are further connected to information such as parameter type, official default value, official allowed value, field source, and dependent parameters, expressing the basis for parameter binding; they are connected to constraint type nodes through constraint requirement relationships, and through constraint repair relationships and repair support relationships, they are connected to repair actions and their supporting operators, expressing execution constraints and their repairable paths; simultaneously, the operator nodes are also connected to the backend QGIS Processing call identifier through tool service nodes associated with tool service mapping relationships. This forms a heterogeneous operator knowledge graph that simultaneously supports function retrieval, slot matching, parameter binding, constraint verification, repair insertion, and execution invocation. Through the above method, operator knowledge, originally scattered across QGIS operator documents, parameter tables, and calling instructions, is organized into computable and verifiable graph-structured knowledge, thus providing a unified knowledge foundation for operator retrieval, process connection, parameter binding, constraint verification, and backend execution calling in natural language tasks. Specifically, this includes the following steps:

[0037] Step 1. Collection and standardization of operator instances

[0038] This invention first addresses the need for automated orchestration of geospatial analysis workflows by collecting operator-related records from official operator documentation, processing algorithm descriptions, parameter definitions, input / output descriptions, and API call descriptions of GIS software platforms or processing frameworks, forming a raw set of operator records:

[0039] ,

[0040] Wherein, any primitive operator record At a minimum, it should include information such as operator identifier, platform, official algorithm name, function description, input definition, output definition, parameter definition, default value, enumerated values, documentation source, and execution interface identifier. Represents the total number of records in the original operator, i=1,2,…, .

[0041] For any primitive operator record By standardizing the mapping function Convert it into an operator instance under a uniform input / output format. ,Right now:

[0042] ,

[0043] The standardized set of operator instances is represented as:

[0044] ,

[0045] Any operator instance It can be represented as:

[0046] ,

[0047] in, This represents a unique identifier for the operator. Indicates the platform to which the operator belongs. Indicates the official algorithm name or call identifier. This describes the function of the operator. Indicates the set of input slots. Indicates the set of output slots. Represents the set of parameter slots. This indicates the mapping information for the tool service.

[0048] During the standardization process, input parameters, output results, and ordinary parameters are no longer simply recorded as operator text fields. Instead, they are further broken down into slot structures that are bound to the operator at runtime. For any operator instance... Its slot set is defined as:

[0049] ,

[0050] ,

[0051] ,

[0052] in, This indicates the input slot, used to describe the data object that needs to be bound before the operator is executed; This indicates the output slot, used to describe the result object generated after the operator is executed; This indicates a parameter slot used to describe non-data input parameters and their binding rules. This indicates the number of slots to input. Indicates the number of output slots. Indicates the number of parameter slots.

[0053] Furthermore, the original data type descriptions in the input and output slots are standardized to reflect the product data type. For any given original product type description... Through product type mapping function Map it to a unified product type :

[0054] ,

[0055] in, It represents a set of standard product types, including at least vector data, raster data, tabular data, geometric objects, statistical results, array data, spatial weight objects, and visualization results.

[0056] Description of the original parameter type in any parameter slot Mapping functions through parameter types Map it to a uniform parameter type :

[0057] ,

[0058] in, It represents a set of standard parameter types, including numeric, string, boolean, enumeration, field selection, field list, distance unit, expression, coordinate reference system, and output path parameter types.

[0059] After the above processing, each operator instance forms a standardized structure consisting of "operator basic information - input slot - output slot - parameter slot - product type - parameter type - execution mapping". This structure transforms the information originally scattered in documentation, parameter tables, and calling interfaces into operator contract units that can be used for graph construction, providing a unified foundation for subsequent capability abstraction, parameter binding, constraint attachment, and backend execution calls.

[0060] Step 2. Capability Abstraction and Slot Contract Modeling

[0061] After standardizing and organizing operator instances, this invention further abstracts the capabilities of the operator instances, mapping specific executable operators to operator capability nodes in the knowledge graph of the space-oriented analysis process auto-orchestration. Let the set of standardized operator instances be:

[0062] ,

[0063] The set of capability nodes is:

[0064] ,

[0065] in, Indicates the number of capability nodes.

[0066] Construct capability mapping function:

[0067] ,

[0068] in, Representing operator instances Achieve capability nodes Multiple operator instances with similar functional semantics and processing objectives can be mapped to the same capability node. Furthermore, capability nodes can be grouped into capability sets. The corresponding grouping function is:

[0069] ,

[0070] This forms a hierarchical organizational structure of "capability grouping - operator capability - specific operator". Capability grouping is used to express higher-level GIS processing categories, operator capability is used to express fine-grained processing intentions for task planning, and specific operator is used to express executable implementation.

[0071] Building upon capability abstraction, this invention further constructs operator slot contracts. For any operator instance... Its slot contract is defined as follows:

[0072] ,

[0073] in, Indicates the set of input slots. Indicates the set of output slots. This represents the set of parameter slots.

[0074] For input slots The set of acceptable product types is defined as follows:

[0075] ,

[0076] in, This indicates that the input slot points to a set of relationships of acceptable types. This relationship describes what types of data artifacts a given input slot can be bound to at runtime.

[0077] For output slots Define its return product type set as:

[0078] ,

[0079] in, This indicates the set of relations that the output slot points to, representing the type of product returned. This relation describes the type of result produced after the operator is executed.

[0080] For parameter slots Define its parameter type as:

[0081] ,

[0082] in, This indicates the instance relationship between parameter slots and parameter types, and is used to specify which standard parameter type the parameter slot belongs to, such as numeric, string, boolean, enumeration, field selection, coordinate reference system, or output path.

[0083] Furthermore, the parameter slots are connected to the default value, the officially allowed value, the field source, the field list source, and the dependency parameters, which are represented as follows:

[0084] ,

[0085] ,

[0086] ,

[0087] ,

[0088] ,

[0089] in, This indicates the default value corresponding to the parameter slot; Indicates the allowed values ​​for the parameter slot; Indicates the input slot referenced by a field-type or field-list-type parameter; This indicates other parameter slots that have a dependency on the current parameter slot; This indicates the default value given for this parameter slot in the official documentation or interface definition; This indicates the officially allowed values, enumeration items, value range, or validity requirements for this parameter slot; and This indicates which data field corresponding to the input slot should be selected from for field-type parameters and field list-type parameters, respectively. This indicates the dependency relationship between this parameter slot and other parameter slots.

[0090] Through the slot contract modeling described above, operators are represented as bindable units composed of input slots, output slots, parameter slots and their types, default values, officially allowed values, field sources, and parameter dependencies. These bindable units support automated orchestration processes by enabling conditional checks on whether input data is bindable, whether output results are continuous, whether parameters have default or optional values, whether field-type parameters can be determined from the input data, and whether parameter values ​​conform to the officially defined structured criteria.

[0091] Step 3. Geospatial Execution Constraints and Repair Action Modeling

[0092] After completing the modeling of operator capabilities and slot contracts, this invention further models the conditions that geospatial operators need to meet before invocation as constraint type nodes. The constraint type is used to describe the geospatial correctness conditions that the operator should meet under specific input data and analysis processes, so as to ensure that the operator invocation process and its output results conform to the spatial analysis logic.

[0093] The constraints include, but are not limited to, a defined coordinate reference system, consistency of coordinate references for multiple input data, requirements for projected coordinate systems, validity of vector geometry, matching of input geometry types, consistency of raster resolution, raster grid alignment, overlapping of spatial ranges, processing of NoData data, existence of fields, and compatibility of field types.

[0094] For any constraint type node, at least the constraint identifier, constraint name, constraint description, applicable objects, triggering scope, triggering conditions, and typical failure signals must be recorded. Operator nodes or parameter slot nodes can be connected to constraint type nodes through constraint requirement relationships, which are used to represent the spatial conditions that the operator or parameter slot needs to meet before execution.

[0095] When constraints are not met, this invention further models the possible processing methods as repair action nodes. These repair actions include, but are not limited to, vector reprojection, raster reprojection, coordinate reference system assignment, geometric repair, raster resampling, raster grid alignment, field mapping, field creation, field type conversion, missing parameter supplementation, spatial range checking, and NoData processing. Constraint type nodes are connected to repair action nodes through constraint repair relationships, representing the processing actions that can be taken when a constraint is not met. Repair action nodes are connected to specific operator nodes that support the repair action through repair support relationships, and to repair method nodes through repair method relationships, indicating that the repair action is operator-based.

[0096] Therefore, the repair path when the constraint is not satisfied can be represented as:

[0097] ,

[0098] in, Represents a constraint type node. This indicates the need to repair the action node. This indicates the specific operator node that supports the repair action. Through this link, geospatial execution constraints are no longer just notes in the documentation, but are organized into a traversable, verifiable, and repairable graph structure.

[0099] Step 4. Graph Pattern Design

[0100] The geospatial operator knowledge graph adopts a unified node-edge representation mechanism, which can be represented as:

[0101] ,

[0102] in, Represents a set of nodes. This represents a set of edges. Nodes represent different categories of operator knowledge objects, while edges represent the functional affiliation, slot contracts, parameter bindings, execution constraints, repair links, and backend call mappings between knowledge objects.

[0103] The node set includes at least operator nodes, capability nodes, input slot nodes, output slot nodes, parameter slot nodes, product type nodes, parameter type nodes, constraint type nodes, repair action nodes, repair method nodes, and tool service nodes. Specifically, operator nodes represent executable QGIS Processing operators; capability nodes express the functional semantics of the operators; input slots, output slots, and parameter slots express the calling contract of the operators; product type and parameter type unify the type expression of input / output objects and parameters; constraint type, repair action, and repair method express spatial correctness constraints and their repair paths; and tool service nodes are used to associate with the backend QGIS Processing calling identifier.

[0104] The edge set includes at least the following relationships: capability realization relationship, input slot relationship, output slot relationship, parameter slot relationship, input acceptance relationship, output return relationship, parameter type relationship, default value relationship, legal value relationship, field selection relationship, field list selection relationship, parameter dependency relationship, constraint requirement relationship, constraint repair relationship, repair support relationship, repair method relationship, and tool service mapping relationship.

[0105] Through the combination of the above nodes and edges, the knowledge graph forms core graph paths such as "operator-capability", "operator-input slot-product type", "operator-output slot-product type", "operator-parameter slot-parameter type / default value / legal value / field source", "operator or parameter slot-constraint type-repair action-supported operator", and "operator-tool service mapping", thereby providing structured support for operator retrieval, slot matching, parameter binding, constraint verification, repair insertion, and execution invocation.

[0106] Step 5. Graph Instantiation Construction and Consistency Verification

[0107] After completing operator instance standardization, capacity and slot contract modeling, geospatial execution constraints and repair action modeling, and graph pattern design, the structured knowledge file generated in the aforementioned processes is used as input, and then constructed according to node construction, relationship construction, and... Figure 1The process of generating a geospatial operator knowledge graph involves four stages: consistency verification, graph output, and more. The specific workflow is as follows: Figure 2 As shown.

[0108] The structured knowledge file includes an operator registry, a standardized operator instance table, an input slot table, an output slot table, a parameter slot table, a product type table, a parameter type table, a capability catalog table, an operator capability mapping table, a constraint type table, a constraint repair link table, and a tool service mapping table. The operator registry, standardized operator instance table, and various slot tables are formed through the process of collecting and standardizing operator instances; the capability catalog table and operator capability mapping table are formed through a capability abstraction process; and the constraint type table and constraint repair link table are formed through the geospatial execution constraint and repair action modeling process.

[0109] First, the structured knowledge file is read and validated. Validation includes verifying file existence, field integrity, identifier consistency, non-empty nature of necessary fields, and consistency of cross-file references. After successful validation, the node construction phase begins.

[0110] Phase 1: Node building phase.

[0111] Based on the structured knowledge file, construct operator nodes, capability nodes, input slot nodes, output slot nodes, parameter slot nodes, product type nodes, parameter type nodes, constraint type nodes, repair action nodes, and tool service nodes respectively.

[0112] Specifically, based on the operator registry and standardized operator instance table, operator nodes are constructed using the operator identifier as the unique key, and the official operator identifier, tool name, function description, documentation source, and execution interface identifier are recorded; capability nodes are constructed based on the capability directory table; input slot nodes, output slot nodes, and parameter slot nodes are constructed based on the input slot table, output slot table, and parameter slot table, respectively; product type nodes and parameter type nodes are constructed based on the product type table and parameter type table; constraint type nodes are constructed based on the constraint type table; repair action nodes are constructed based on the constraint repair link table; and tool service nodes are constructed based on the tool service mapping table.

[0113] Phase Two: Relationship Building Phase.

[0114] Based on the existing nodes, establish capability realization relationships, input slot relationships, output slot relationships, input acceptance relationships, parameter slot relationships, output return relationships, constraint requirement relationships, constraint repair relationships, and tool service mapping relationships according to the structured knowledge file.

[0115] Specifically, the following steps are taken: First, the capability implementation relationship between operator nodes and capability nodes is established based on the operator capability mapping table. Second, the slot relationships between operator nodes and input slot nodes, output slot nodes, and parameter slot nodes are established based on the input slot table, output slot table, and parameter slot table, respectively. Third, the product type identifiers in the input and output slots are associated with the constructed product type nodes, and the input acceptance relationship between input slots and product type nodes, and the output return relationship between output slots and product type nodes are established. Fourth, the parameter type relationship, default value relationship, legal value relationship, field selection relationship, field list selection relationship, and parameter dependency relationship are established based on the parameter type, default value, allowed values, field source, and parameter dependency information in the parameter slots. Fifth, the constraint requirement relationship between operator nodes or parameter slot nodes and constraint type nodes is established based on the constraint type table. Sixth, the constraint repair relationship between constraint type nodes and repair action nodes, and the repair support relationship between repair action nodes and supporting operator nodes are established based on the constraint repair link table. Finally, the tool service mapping relationship between operator nodes and tool service nodes is established based on the tool service mapping table.

[0116] Phase Three: Figure 1 Consistency check.

[0117] The verification content includes at least the uniqueness of node identifiers, the uniqueness of edge identifiers, the legality of node types, the legality of edge types, dangling relationship checks, the integrity of operator capability mapping, the integrity of slot contracts, the integrity of product type attachments, the integrity of parameter type attachments, the integrity of parameter binding relationships, the integrity of constraint attachments, the integrity of constraint repair links, and the integrity of tool service mapping.

[0118] For nodes or edges that fail the consistency check, record the anomaly type, anomaly location, and corresponding knowledge source for correction; re-execute after correction. Figure 1 Consistency checks are performed until the preset consistency requirements are met.

[0119] Phase 4: Atlas output.

[0120] The system outputs the node and edge sets as a structured graph file, and simultaneously outputs a build manifest and a verification report. The build manifest records the build timestamp, input knowledge source path, number of knowledge source rows, knowledge source hash value, number of nodes, number of edges, statistics for each type, output path, and verification results to support the traceability and reproducibility of the graph construction process.

[0121] In addition to being applied to the QGIS Processing platform, the map construction method of the present invention can also be applied to other GIS platforms or processing frameworks.

[0122] In summary, the above are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for constructing an operator knowledge graph for geospatial workflow orchestration, characterized in that, Includes the following steps: Collect official documentation and interface definition information of geoprocessing operators to form a set of raw operator records. Then, through standardized mapping, convert each raw operator record into a standardized operator instance containing operator identifier, platform, algorithm name, function description, input slot set, output slot set, parameter slot set, and tool service mapping information. The standardized operator instances are abstracted to map specific operators to operator capability nodes that express processing intentions, and a slot contract is constructed for each operator instance. The slot contract includes input slots and their acceptable product types, output slots and their returned product types, parameter slots and their parameter types, default values, allowed values, field sources, and parameter dependencies. The spatial correctness conditions that the operator must satisfy before the call are modeled as constraint type nodes, and the handling methods when the constraints are not satisfied are modeled as repair action nodes. A repair link is established from the constraint type node to the repair action node, and from the repair action node to the specific operator node that supports the repair action. Design a heterogeneous knowledge graph pattern that includes a set of nodes and a set of edges. The set of nodes includes at least operator nodes, capability nodes, slot nodes, type nodes, constraint nodes, repair nodes, and service mapping nodes. The set of edges includes at least capability realization relationships, slot relationships, type relationships, constraint relationships, repair relationships, and service mapping relationships. Based on the standardized operator instance, capability abstraction result, slot contract, constraint type node, repair action node, and graph pattern, node construction, relationship construction, graph consistency verification, and graph output are executed sequentially to generate the operator knowledge graph. Specifically, node construction builds various types of nodes based on a structured knowledge file; relationship construction establishes various types of edges based on the structured knowledge file; and graph consistency verification checks at least the uniqueness of node identifiers, edge identifiers, dangling relationships, slot contract integrity, and constraint repair link integrity. After successful verification, a structured graph file is output.

2. The method according to claim 1, characterized in that, The node set specifically includes operator nodes, capability nodes, input slot nodes, output slot nodes, parameter slot nodes, product type nodes, parameter type nodes, constraint type nodes, repair action nodes, repair method nodes, and tool service mapping nodes; the edge set specifically includes capability realization relationships, input slot relationships, output slot relationships, parameter slot relationships, input acceptance relationships, output return relationships, parameter type relationships, default value relationships, valid value relationships, field selection relationships, field list selection relationships, parameter dependency relationships, constraint requirement relationships, constraint repair relationships, repair support relationships, repair method relationships, and tool service mapping relationships.

3. The method according to claim 1, characterized in that, In the standardized mapping, the original input parameters, output results, and ordinary parameters are split into slot structures that are bound to the operator at runtime. The original product type description is mapped to a standard product type set through a product type mapping function, and the original parameter type description is mapped to a standard parameter type set through a parameter type mapping function. The standard product type set includes at least vector data, raster data, tabular data, geometric objects, statistical results, array data, spatial weight objects, and visualization results. The standard parameter type set includes at least numeric, string, boolean, enumeration, field selection, field list, distance unit, expression, coordinate reference system, and output path types. In the capability abstraction, multiple operator instances with similar functional semantics are mapped to the same capability node, and capability nodes are grouped into capability group sets, forming a hierarchical organizational structure from capability group to operator capability to specific operator; in the slot contract, the set of acceptable product types for input slots is used to describe the type matching conditions of runtime bound data products, the set of return product types for output slots is used to describe the type basis for subsequent operators to follow the operator execution results, and the field selection relationship and field list selection relationship for parameter slots are used to describe that field-type parameters and field list-type parameters should be selected from the corresponding data fields of the specified input slots, respectively.

4. The method according to claim 1, characterized in that, The constraint type node records at least the constraint identifier, constraint name, constraint description, applicable object, trigger range, trigger condition, and typical failure signal; the repair action node includes at least vector reprojection, raster reprojection, coordinate reference system assignment, geometric repair, raster resampling, raster mesh alignment, field mapping, field creation, field type conversion, missing parameter supplementation, spatial range check, and NoData processing; the repair link is represented as constraint type node to repair action node to specific operator node supporting the repair action; the repair action node is also connected to repair method node through repair method relationship to indicate that the repair action belongs to operator-based repair.

5. The method according to claim 1, characterized in that, The structured knowledge file includes an operator registry, a standardized operator instance table, an input slot table, an output slot table, a parameter slot table, a product type table, a parameter type table, a capability directory table, an operator capability mapping table, a constraint type table, a constraint repair link table, and a tool service mapping table. In the node construction phase, operator nodes are constructed based on the operator registry and the standardized operator instance table; capability nodes are constructed based on the capability directory table; input slot nodes, output slot nodes, and parameter slot nodes are constructed based on each slot table; product type nodes and parameter type nodes are constructed based on the product type table and the parameter type table; constraint type nodes are constructed based on the constraint type table; repair action nodes are constructed based on the constraint repair link table; and tool service nodes are constructed based on the tool service mapping table.

6. The method according to claim 1, characterized in that, In the relationship construction, capability realization relationships from operator nodes to capability nodes are established based on the operator capability mapping table. Slot relationships from operator nodes to input slot nodes, output slot nodes, and parameter slot nodes are established based on each slot table. Input acceptance relationships and output return relationships are established based on the product type identifiers in the input and output slots. Parameter type relationships, default value relationships, legal value relationships, field selection relationships, field list selection relationships, and parameter dependency relationships are established based on the parameter type, default value, allowed values, field source, and parameter dependency information in the parameter slots. Constraint requirement relationships between operator nodes or parameter slot nodes and constraint type nodes, as well as repair method relationships between repair action nodes and repair method nodes, are established based on the constraint type table. Constraint repair relationships between constraint type nodes and repair action nodes, as well as repair support relationships between repair action nodes and supporting operator nodes, are established based on the constraint repair link table. Tool service mapping relationships between operator nodes and tool service nodes are established based on the tool service mapping table.

7. The method according to claim 1, characterized in that, The graph consistency check also checks the validity of node types, edge types, operator capability mapping, product type attachment, parameter type attachment, parameter binding relationship, constraint attachment, and tool service mapping. For nodes or edges that fail the check, the exception type, exception location, and corresponding knowledge source are recorded and corrected. After correction, the graph consistency check is re-executed until the preset consistency requirements are met. The graph output synchronously outputs a construction list and a verification report. The construction list includes at least the construction timestamp, input knowledge source path, number of nodes, number of edges, statistics of each type, output path, and verification results.

8. An operator knowledge graph construction device for geospatial workflow orchestration, characterized in that, Includes the following modules: The conversion module collects official documentation and interface definition information of geoprocessing operators to form a set of raw operator records. It then converts each raw operator record into a standardized operator instance through standardized mapping, which includes operator identifier, platform, algorithm name, function description, input slot set, output slot set, parameter slot set, and tool service mapping information. The mapping module abstracts the capabilities of the standardized operator instances, maps specific operators to operator capability nodes that express processing intentions, and constructs slot contracts for each operator instance. The slot contracts include input slots and their acceptable product types, output slots and their returned product types, parameter slots and their parameter types, default values, allowed values, field sources, and parameter dependencies. The modeling module models the spatial correctness conditions that operators must satisfy before being called as constraint type nodes, and models the handling methods taken when constraints are not satisfied as repair action nodes, establishing repair links from constraint type nodes to repair action nodes, and from repair action nodes to specific operator nodes that support the repair action. The design module designs a heterogeneous knowledge graph pattern that includes a set of nodes and a set of edges. The set of nodes includes at least operator nodes, capability nodes, slot nodes, type nodes, constraint nodes, repair nodes, and service mapping nodes. The set of edges includes at least capability realization relationships, slot relationships, type relationships, constraint relationships, repair relationships, and service mapping relationships. The generation module, based on the standardized operator instance, capability abstraction result, slot contract, constraint type node, repair action node, and graph pattern, sequentially performs node construction, relationship construction, graph consistency verification, and graph output to generate the operator knowledge graph. Specifically, node construction builds various types of nodes based on a structured knowledge file; relationship construction establishes various types of edges based on the structured knowledge file; and graph consistency verification checks at least the uniqueness of node identifiers, edge identifiers, dangling relationships, slot contract integrity, and constraint repair link integrity. Upon successful verification, a structured graph file is output.

9. An electronic device, characterized in that, include: One or more processors; A memory for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores executable instructions that, when executed by a processor, cause the processor to perform the method described in any one of claims 1 to 7.

Images