Geospatial data governance method and system based on quality control and blood tracing

Abstract

The application discloses a geospatial data management method and system based on quality control and bloodline tracing. The method comprises the following steps: constructing a unified metadata warehouse, storing model and field metadata, and establishing a model version sequence for different time snapshots; calculating stable identifiers for each version of spatial features through business primary keys or spatial fingerprints generated based on standardized geometry, pairing cross-version features, identifying and recording feature-level spatio-temporal bloodline evolution relationship; then calculating spatial feature cross-time geometry change metrics, combining with the acquisition or inference of legal change reasons, implementing spatio-temporal consistency quality judgment and outputting graded quality inspection results; finally, according to the graded quality inspection results, quality access judgment is performed, a differentiated access control decision is generated, and a quality report is output in association with the feature-level spatio-temporal bloodline. The application realizes automatic bloodline tracing and consistency quality inspection of geospatial data in the version evolution process, and improves the reliability and auditability of data management.

Description

Technical Field

[0001] This application relates to the field of geospatial data governance technology, and in particular to geospatial data governance methods and systems based on quality control and lineage tracing. Background Technology

[0002] With the increasing informatization and digitalization of industries such as natural resources, land spatial planning, forestry, ecological environment, and real estate, geospatial data exhibits the following characteristics in practical applications: First, the data forms are diverse, including not only point, line, and polygon vector elements and their geometric attributes, but also a large amount of attribute table data associated with spatial objects; second, the data is frequently updated, with multiple time versions formed by year, quarter, project batch, etc.; third, the data processing chain is complex, including multiple processing processes such as extraction, fusion, spatial overlay analysis, and index calculation, and the downstream often relies on the continuous updating and iteration of upstream data.

[0003] Existing data governance platforms or quality management tools typically provide attribute rule validation (such as NOT NULL, range, and format) and some spatial geometry checks (such as geometric validity and topological relationship checks), and may also provide table-level or field-level lineage tracing. However, the following problems still commonly exist in geospatial data governance:

[0004] (1) Lack of spatiotemporal consistency quality control for multi-version data. Existing quality inspection mainly focuses on "single snapshot" inspection, which makes it difficult to judge whether the deformation, area change, position offset, etc. of the same spatial object are reasonable between different time versions, and cannot distinguish between "legitimate changes" and "abnormal changes".

[0005] (2) Insufficient granularity of lineage tracing or lack of spatiotemporal evolution semantics. Only table-level or field-level lineage is insufficient to answer key questions such as "from which historical elements did a certain element in a certain version evolve?" and "how to trace the object evolution chain caused by merging / splitting", which leads to the problem location relying on manual experience.

[0006] (3) Quality issues are separated from lineage information, making it difficult to form a closed loop. After quality issues are discovered, there is a lack of mechanisms for root cause localization, scope of impact deduction, and priority ranking of repairs based on lineage, resulting in low repair efficiency and high rectification costs.

[0007] (4) The specific constraints of geospatial data have not been modeled and solidified. Spatial characteristics such as coordinate system, geometric type, Z / M value, topological constraints, and version axis are often scattered in scripts, configurations or manual conventions if they are not uniformly defined at the model level. This makes them difficult to reuse and results in a lack of unified basis for rule execution and lineage modeling. Summary of the Invention

[0008] Based on this, the purpose of this invention is to address the above-mentioned technical problems by providing a geospatial data governance method and system based on quality control and lineage tracing, which can link model definition, spatiotemporal lineage, cross-time consistency quality inspection, strong and weak rule classification and report output to achieve a traceable, interpretable and closed-loop geospatial data governance process.

[0009] To achieve the aforementioned objectives, the first aspect of this application provides a geospatial data governance method based on quality control and lineage tracing, comprising: For the vector space data and its attribute table data to be governed, a unified metadata repository is constructed to store model definitions that include at least model metadata and field metadata. Based on the model definitions, a model version sequence is established for different time snapshots of the vector space data. For spatial features in each model version, calculate feature stability identifiers based on business primary keys or spatial fingerprints generated from standardized geometry. Based on the element stability identifier, spatial elements in cross versions are paired, and the evolution relationship of elements in cross versions is determined according to the pairing results. The evolution relationship is recorded as element-level spatiotemporal lineage. For spatial elements with evolutionary relationships, the cross-temporal geometric change measure of the spatial elements is calculated, and the legitimate reasons for the changes of the spatial elements are obtained or inferred based on the spatiotemporal lineage of the elements. The spatiotemporal consistency quality of the spatial elements is judged by combining the cross-temporal geometric change measure and the legitimate reasons for the changes, and the graded quality inspection results are output. Based on the graded quality inspection results, a quality access control judgment is made on the current model version, a differentiated access control decision is generated, and the element-level spatiotemporal lineage output quality report is associated.

[0010] Preferably, the model metadata includes at least a spatial reference identifier, geometric type, set of topological constraints, version identifier field, and feature stability identifier generation strategy; the field metadata includes at least field constraints and semantic tags for automatic rule assembly and lineage semantic annotation.

[0011] Preferably, the stability identifier of the computational element specifically includes: The element stability identifier is generated in the following manner: The original geometry is subjected to mesh adsorption tolerance processing and ring order normalization processing to obtain a standardized geometry. The standardized geometry is encoded using WKB and its hash value is calculated to obtain a spatial fingerprint; The hash value is calculated by concatenating the business primary key with the spatial fingerprint, or the spatial fingerprint is used directly as the element stability identifier when the business primary key is missing. The spatial overlap ratio is calculated as a supplementary pairing criterion. For opposite features, the calculation is based on the intersection area. For line features and point features, the spatial overlap ratio is obtained by generating a strip surface or circular region through buffering and then calculating the intersection area. Alternatively, linear difference measurement or displacement distance can be used as a supplementary pairing criterion. When the stable identifier of the feature cannot be generated or cannot be accurately matched, pairing is performed according to the supplementary pairing criterion.

[0012] Preferably, the evolutionary relationship is determined according to the following logic: When there is a unique element pairing across versions, and the spatial overlap ratio is greater than or equal to the first threshold, it is determined to be a relationship that is maintained. When there is a unique element pairing across versions, and the spatial overlap ratio is less than the first threshold, it is determined to be an update relationship; When multiple elements in the old version are paired with one element in the new version, it is determined to be a merge relationship; When an element in the old version is paired with multiple elements in the new version, it is determined to be a split relationship; When an element only appears in a new version, it is considered a newly added relationship; When an element only appears in the old version, it is determined to be a deletion relationship.

[0013] Preferably, the geometric change measure includes: Calculate the area change rate and symmetry difference rate for opposite elements; Calculate the rate of change of length and measure the difference in line shape for line features; Calculate the displacement distance for point features; The formula for calculating the area change rate is: in, and These represent the areas of the spatial elements in two adjacent versions; The formula for calculating the symmetry difference rate is:

[0014] in, and These represent the feature geometry of the spatial feature in two adjacent versions, respectively. This represents the symmetric difference operation; The formula for calculating the rate of change of length is:

[0015] in, and These represent the line feature lengths of the spatial feature in two adjacent versions; The formula for calculating the linear difference measure is as follows:

[0016] in, or These represent the generation of a strip surface with a radius of r through buffering. The formula for calculating the displacement distance is:

[0017] in, and These represent the coordinate positions of the spatial element in two adjacent versions.

[0018] Preferably, the legitimate reason for the change is obtained through at least one of the following methods: Extract the approval type field from the attribute table or related business table of the spatial elements and map it to a standardized approval change reason; From the metadata of the data processing job that generated the model version, the operator types that caused the geometric changes are parsed out and mapped to standardized job change reasons.

[0019] Preferably, the spatiotemporal consistency quality determination specifically includes: When the cross-time geometric change metric exceeds the corresponding threshold and no valid legal reason for the change is obtained, it is determined to be a strong rule violation; When the cross-time geometric change metric exceeds the corresponding threshold but a valid and legitimate reason for the change is obtained, it is determined to be a weak rule violation; Using the legitimate change reason as the context parameter, the spatial topology rules or attribute consistency rules triggered by the elements that match the legitimate change reason are executed in a weak constraint mode, and only warnings are recorded; Rules triggered by elements for which no legitimate reason for change has been obtained are executed in a strong constraint mode, directly determining quality anomalies.

[0020] To achieve the purpose of the invention, a second aspect of this application provides a geospatial data governance system based on quality control and lineage tracing, applying the geospatial data governance method based on quality control and lineage tracing described above. The system includes: The metadata management module builds a unified metadata repository for the vector space data to be governed and its attribute table data, which is used to store and manage model metadata and field metadata. The version and identifier management module is used to generate and manage the model version sequence based on the metadata management module, and to generate stable identifiers for spatial elements in each version. The spatiotemporal lineage construction module is used to perform cross-version element pairing based on the element stability identifier and determine the evolution relationship to form element-level spatiotemporal lineage. The spatiotemporal consistency verification module is used to calculate the cross-temporal geometric change measure of spatial elements with evolutionary relationships, obtain or infer the legitimate reasons for the changes of the spatial elements based on the spatiotemporal lineage of the elements, and combine the cross-temporal geometric change measure and the legitimate reasons for the changes to determine the spatiotemporal consistency quality of the spatial elements and output the graded quality inspection results. The quality access control judgment and output module is used to make quality access control judgments on the current model version based on the graded quality inspection results, generate differentiated access control decisions, and associate the element-level spatiotemporal lineage output quality report.

[0021] Preferably, the spatiotemporal consistency verification module is specifically used for: Calculate the area change rate and symmetry difference ratio of the opposite elements; Calculate the rate of change of length for line features and measure the line shape difference based on the buffer symmetry difference ratio; Calculate the displacement distance for point features; When the cross-time geometric change metric exceeds the corresponding threshold and no valid legal reason for the change is obtained, it is determined to be a strong rule violation; When the cross-time geometric change metric exceeds the corresponding threshold but a valid and legitimate reason for the change is obtained, it is determined to be a weak rule violation.

[0022] Preferably, using the legitimate change reason as a context parameter, the spatial topology rules or attribute consistency rules triggered by the elements that match the legitimate change reason are executed in a weak constraint mode, and only warnings are recorded; Rules triggered by elements for which no legitimate reason for change has been obtained are executed in a strong constraint mode, directly determining quality anomalies.

[0023] Compared with the prior art, the beneficial effects of this invention are: This invention defines spatial constraints and versions uniformly through model metadata, providing a consistent basis for cross-time comparisons; it constructs element-level spatiotemporal lineage based on element stability identifiers, accurately tracing the evolutionary relationships of spatial objects across versions, including maintenance, updates, merging, and splitting; it introduces geometric change measurements and legitimate change reasons into spatiotemporal consistency verification, generating tiered quality inspection results to effectively distinguish between legitimate adjustments and abnormal changes; and it links the quality inspection results with lineage information, generating differentiated access decisions for model versions through a quality gate mechanism, achieving a closed-loop governance system from model definition, lineage construction, quality judgment to data access, significantly improving the accuracy of multi-version geospatial data consistency verification, the precision of problem tracing, and the automation level of process control, realizing a traceable, explainable, and closed-loop geospatial data governance process. Attached Figure Description

[0024] Figure 1This is a flowchart illustrating a geospatial data governance method based on quality control and lineage tracing in an embodiment of the present invention. Figure 2 This is a schematic diagram of the process for geospatial data governance and outputting quality reports in an embodiment of the present invention; Figure 3 This is a schematic diagram of a geospatial data governance system based on quality control and lineage tracing in an embodiment of the present invention. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of the invention. The following embodiments are used to illustrate the invention but are not intended to limit its scope.

[0026] Example 1 Embodiment 1 of this application provides a geospatial data governance method based on quality control and lineage tracing, such as... Figure 1 As shown, it includes: S1. For the vector space data and its attribute table data to be governed, construct a unified metadata repository to store model definitions that include at least model metadata and field metadata. Based on the model definitions, establish a model version sequence for snapshots at different times. S2. For spatial features in each model version, calculate the feature stability identifier based on the business primary key or the spatial fingerprint generated based on standardized geometry. S3. Based on the element stability identifier, pair spatial elements across versions, determine the evolution relationship of elements across versions based on the pairing results, and record the evolution relationship as element-level spatiotemporal lineage. S4. For spatial elements with evolutionary relationships, calculate the cross-temporal geometric change measure of the spatial elements, and obtain or infer the legitimate reasons for the changes of the spatial elements based on the spatiotemporal lineage of the elements. Combine the cross-temporal geometric change measure and the legitimate reasons for the changes to determine the spatiotemporal consistency quality of the spatial elements and output the graded quality inspection results. S5. Based on the graded quality inspection results, perform quality access control judgment on the current model version, generate differentiated access control decisions, and associate them with the element-level spatiotemporal lineage output quality report.

[0027] The specific contents of steps S1-S5 above are as follows: This invention centers on a unified metadata repository and establishes a closed-loop governance process around "model definition—version axis—stability identifier—spatiotemporal lineage—cross-time consistency verification—quality gate control—reporting and traceability." The geospatial data governance objects of this invention are limited to: vector spatial data (points / lines / polygons) and their attribute table data.

[0028] (I) Defining the overall data structure First, define the following data object: Model: The basic unit of platform governance, which can be an entity table or a space-attribute unified model.

[0029] Model Version: A snapshot of the same model taken at different points in time, denoted as (V_{t}).

[0030] Feature ID: A unique identifier for cross-version identification and pairing of the same spatial object, which can be generated from the business primary key and spatial fingerprint.

[0031] Evolution: Describes the type of state change of an element between adjacent versions, including maintain, update, merge, split, add, and delete.

[0032] Quality rules: A set of rules used to verify data quality, categorized into strong and weak rules based on their severity.

[0033] QualityGate: A mechanism that determines the access status of data versions based on the results of rule execution. The status includes pass, pass with warning, and block.

[0034] Building a metadata repository structure (one of the input / output structures: model and field metadata): The platform establishes a unified metadata repository to store model definitions and field metadata. Its key table structures may include, but are not limited to: 1) Model Metadata Table Used to record model-level spatial constraints and version axis definitions: model_id: A unique identifier for the model.

[0035] model_name: Model name.

[0036] srid: Spatial reference identifier.

[0037] geom_type: Geometry type (POINT / LINESTRING / POLYGON, etc.).

[0038] has_z and has_m: Z / M value identifiers.

[0039] topo_rule_set: Identifier of the set of topological constraints (such as the set of rules for validity, self-intersection, overlap, gaps, etc.).

[0040] version_field: Version identifier field name (e.g., version_id).

[0041] time_field: The field name for the collection / effective time (e.g., collect_time / valid_from).

[0042] featureid_policy: FeatureID policy (business primary key / spatial fingerprint / combination).

[0043] security_level, tags: security level and tags ().

[0044] 2) Field Metadata Table It should include at least: English field name, Chinese field name, field type, field length, primary key, foreign key, cannot be null, unit, default value, whether it is a key value, field security level, data dictionary, field data type, field data level, field data format, field description, knowledge graph display, field label, etc.

[0045] The role of field metadata includes: providing a basis for the automatic assembly of attribute quality inspection rules (such as not being nullable, dictionary constraints, format constraints); providing a basis for the semantic annotation of field nodes in the lineage graph (such as whether it is a key value, data type, level, label); and providing dimensions (model / field / label / security level) for the grouping and summarization of quality reports.

[0046] Constructing a pedigree and quality data structure (Input / Output Structure 2: Pedigree and Quality Inspection Result Table): 1) JobMeta Record basic information for each extraction or spatial computation task: job_id: Job identifier.

[0047] operator_type: Operator type (extract / merge / prune / intersection / field calculation, etc.).

[0048] params_hash: Parameter summary (used for auditing and reproduction).

[0049] src_models, tgt_models: Input / output model collections.

[0050] run_time and status: execution time and status.

[0051] 2) Model-level lineage table (ModelLineage) Purpose: To record the dependencies between model versions caused by job processing, in order to answer "which upstream model versions were processed from a certain model version".

[0052] src_model_id: Unique identifier of the upstream model (source model ID).

[0053] src_version: Upstream model version identifier (source version number / snapshot number / timestamp).

[0054] tgt_model_id: Unique identifier for the downstream model (target model ID).

[0055] tgt_version: Downstream model version identifier (target version number / snapshot number / timestamp).

[0056] job_id: The job identifier that generated this lineage (corresponding to the job ID in the job metadata table).

[0057] operator_type: Operator type / job type (such as extract, merge, trim, intersection, field calculation, etc.).

[0058] lineage_time: The time when lineage relationships are generated (usually the time when the job is completed or the time when the lineage is registered).

[0059] 3) Field-level lineage table (FieldLineage) Purpose: To record the one-to-many mapping relationship between the target field and the source fields, as well as the field transformation logic, in order to answer "which source fields are used to calculate / map a certain field".

[0060] src_model_id: Unique identifier of the source model (from the source table / the model ID to which the layer belongs).

[0061] src_field: The English name of the source field (source field name).

[0062] tgt_model_id: Unique identifier of the target model (the model ID to which the target table / layer belongs).

[0063] tgt_field: The English name of the target field (target field name).

[0064] transform_expr: Field transformation expression / mapping rule (e.g., colB = f2 * 100, or tgt_field = func(src_field)).

[0065] job_id: The job identifier that generated the lineage of this field (corresponding to the job ID that performed the calculation / mapping of this field).

[0066] 4) Feature-level spatiotemporal lineage table Purpose: To record the evolution of spatial elements across versions or processes, and to answer questions such as "from which historical elements did a certain element in a certain version evolve?" and "Did a merger / splitting occur?"

[0067] src_feature_id: Source feature stable identifier (upstream feature ID, which can be generated from business primary key / spatial fingerprint).

[0068] src_version: The version identifier of the source element (source version number / snapshot number / timestamp).

[0069] tgt_feature_id: Target feature stability identifier (downstream feature ID).

[0070] tgt_version: The version identifier of the target element (target version number / snapshot number / timestamp).

[0071] evolve_type: Evolution type.

[0072] KEEP: Maintain (changes below a threshold are considered as continuation of the same object).

[0073] UPDATE: Update (one-to-one but with significant deformation or attribute change).

[0074] MERGE: Merge (many-to-one).

[0075] SPLIT: Split (one-to-many).

[0076] NEW: Added (only appears in new versions).

[0077] DELETE: Delete (only exists in older versions).

[0078] job_id: The job identifier (corresponding job ID) that generated this evolution relationship.

[0079] operator_type: Operator type / job type (used to explain the origin of evolution, such as merging, trimming, and blending).

[0080] params_hash: Summary / hash of job parameters (used for auditing and reproducing the calculation conditions of this evolution relationship).

[0081] evolve_time: The time when the evolution relationship was generated (usually the time when the job was completed or the time when the lineage was established).

[0082] Note: For many-to-many relationships to be merged / splittered, multiple records can be used to express them; for example, when merging, multiple src_feature_ids can create multiple mapping records for the same tgt_feature_id; when splitting, the same src_feature_id can create multiple mapping records for multiple tgt_feature_ids.

[0083] 5) Quality Rule Table Purpose: To uniformly store the metadata and execution expressions of quality inspection rules, and support scheduling and report aggregation according to rule type and strength level.

[0084] rule_id: A unique identifier for a rule.

[0085] rule_name: Rule name (for easy interface display and report reference).

[0086] rule_type: Rule type.

[0087] ATTR: Attribute rules (not empty, dictionary, range, format, etc.).

[0088] SPATIAL: Spatial rules (geometric validity, topological relationships, etc.).

[0089] TEMPORAL: Spatiotemporal / cross-time rules (cross-version consistency, change thresholds, etc.).

[0090] severity: level of severity.

[0091] STRONG: Strong rule (not allowed to occur; if it occurs, it will be blocked).

[0092] WEAK: Weak rule (allowed to occur but requires warning).

[0093] apply_scope: Scope of application (binding rules based on dimensions such as model / field / tag).

[0094] model: Bound to a specific model or collection of models.

[0095] field: Binds to a specific field or collection of fields.

[0096] tag: Binds to a model / field that has a certain tag (for easy batch rule assembly).

[0097] rule_expr: A rule expression or script reference (SQL fragment, spatial expression, script path / identifier, etc.).

[0098] threshold_set: Threshold set identifier (referencing threshold configuration, used to differentiate thresholds under different models / scales for the same rule).

[0099] 6) Quality Inspection Result Detail Sheet (QualityIssue) Purpose: To record the details of violations generated each time a rule is executed, and to locate specific problem records / elements and their evidence.

[0100] rule_id: The identifier of the matched rule.

[0101] severity: The severity level of the rule being hit (STRONG / WEAK).

[0102] rule_type: The type of rule that was hit (ATTR / SPATIAL / TEMPORAL).

[0103] model_id: The identifier of the model where the problem occurred.

[0104] version: The data version identifier where the problem occurred (used for cross-time management and backtracking).

[0105] record_id / feature_id: Identifier of the object that violated the rules.

[0106] record_id: The primary key of a table record (used for pure table / attribute records).

[0107] feature_id: Spatial feature stable identifier FeatureID (used for spatial features).

[0108] evidence: evidence / explanatory information.

[0109] It can include: change measures (such as ΔA, D), hit fields, comparison versions, associated job_id, associated feature pairs, etc.

[0110] check_time: Quality inspection execution time (rule execution time or result storage time).

[0111] 7) Quality Inspection Summary Table (RuleViolationSummary) Purpose: Used for reporting and summarizing data on access control decisions, aggregating the number of violations by rule and version.

[0112] rule_id: Rule identifier.

[0113] severity: The severity level of the rule (STRONG / WEAK).

[0114] model_id: Model identifier.

[0115] version: Version identifier.

[0116] violation_count: Number of violations (the number of times this rule has been hit on this model version).

[0117] check_time: The time when the summary is generated (usually the same as the time of the batch in this round of quality inspection).

[0118] Constructing a quality access control state machine: To achieve a closed-loop governance mechanism of "strong rule blocking and weak rule early warning," this invention constructs a QualityGate state machine. This machine maps rule execution results to the admission status of model versions, determining whether data for a given version is allowed to enter downstream stages such as publishing, service provision, or topic computation. Unlike existing solutions that only output quality inspection results, this invention's access control mechanism links "rule configuration—execution—judgment—output" into a closed loop. The definition and grading strategies for strong and weak rules are configured by the user on the platform, which provides default grading templates but does not mandate their fix.

[0119] Definition of strong and weak rules (configurable) In this invention, "strong rules" and "weak rules" represent the severity levels of quality rules. Users can explicitly set these levels for each rule through the rule management interface or REST API, or through batch inheritance from rule templates. Users can determine the severity level based on factors such as business tolerance, data usage, confidentiality level, and service release requirements.

[0120] (1) Configuring granularity Strong and weak rules support user-defined granularities at least as follows: Rule-level hierarchical classification: Set severity=STRONG / WEAK for each rule; Rule set / template level hierarchy: Set a default severity level for a certain type of rule set (such as "topology validity rule set" or "attribute dictionary rule set"); Model-level coverage: The same rule can be applied to different models with different severity levels (e.g., STRONG for the "core library model" and WEAK for the "data lake model"). Field-level overriding (optional): The same rule can be differentiated across different fields (e.g., STRONG for non-null primary key fields and WEAK for non-null memo fields). Tag / Security Level Driven Grading (Optional): Automatically maps the default severity level based on model or field tags and data security level.

[0121] Note: The priority of the above coverage relationships is set as follows: field-level coverage > model-level coverage > rule-level settings > rule set / template default values.

[0122] (2) Configure entry and storage structure The platform stores rules and their severity level field (severity) in the QualityRule table and allows users to maintain them in the following ways: Graphical interface: Select "Strong rule / Weak rule" on the rule editing page; API: Includes severity when submitting rule metadata; Template import: Batch import from rule templates and inherit the default severity level.

[0123] In addition to severity, the rule can also configure the following access control related parameters (user optional): gate_action: Access control action after a hit (block / warn / log only); allow_condition: Allowed conditions (e.g., downgraded processing when there is a legitimate reason for the change); threshold_set: Threshold set (allows for differentiating thresholds by model or scale).

[0124] Common hierarchical strategies for strong and weak rules (default suggestions, adjustable): To reduce user configuration costs, default suggestions (templates) are provided, but the final settings will be based on the user's configuration. For example: Rules that are typically recommended to be STRONG include: invalid geometry, empty geometry, null primary key, key dictionary field out of range, abnormal mutation across time without a valid reason, etc. Rules typically recommended to be WEAK include: empty non-critical description fields, minor geometric deformations that do not exceed thresholds, and acceptable missing fields (as permitted by business requirements). Users can set strategies based on different governance levels. For example: Data Lake Layer: leans towards "data entry first, governance later," with some rules set to WEAK to indicate risks; Core Layer / Release Layer: leans towards "usability and controllability," with critical rules set to STRONG to ensure the quality of downstream services.

[0125] Downgrade / exception handling after rule hit (user configurable): To avoid "reasonable changes being misjudged as blocking," the access control logic supports user-defined rule degradation strategies: When a rule with severity=STRONG is hit, if the allow_condition is met (e.g., there is a legitimate reason for the change, approval is granted, it belongs to a specified operator type, or it is within a whitelist time period / area), the hit can be downgraded from STRONG to WEAK, or it can be recorded without blocking. For cross-time consistency rules (TEMPORAL type), the "legitimate reason for the change" field or judgment conditions can be configured as an important evidence chain for access control judgment.

[0126] Quality access control state machine and decision logic: Access control status is used to give an admission decision for "model version", and includes at least the following three statuses: PASS: No STRONG or WEAK was hit; WARN: No STRONG was hit, but WEAK was hit; FAIL: At least one STRONG was hit (or the number of STRONG hits exceeded the threshold).

[0127] An example of its decision logic is as follows:

[0128]

[0129] Table 1. Parameter Definition Table for Example of Decision Logic of Quality Access Control State Machine Table 1 shows the parameter definitions for an example of the decision logic of the quality access control state machine, where StrongCount(V t ) and WeakCount(V t The statistics are derived from aggregated statistics of QualityIssue or RuleViolationSummary; the aggregated dimensions must include at least model_id and version. When a degradation strategy is enabled, the statistics should be based on the "final severity level after degradation".

[0130] Access control actions and downstream linkage: Once the access control status is generated, the system executes the corresponding action (configurable): FAIL: Blocks the model version from entering downstream release / service / topic calculations; a repair list and work order can be automatically generated simultaneously; WARN: Allows entry downstream, but writes warning rules and typical issues into the report and returns a quality prompt on the data service side; PASS: Allows normal flow and records batch pass information. The above access control results are linked with rule hit details and lineage (model / field / feature lineage) to support subsequent "root cause tracing, impact analysis, and repair priority ranking," thereby achieving a closed-loop governance system.

[0131] (II) Specific implementation steps based on the above data structure, such as Figure 2As shown, it includes: Step 1: Model Definition and Version Axis Construction: Create model definitions via a graphical interface or API, and write them to ModelMeta and FieldMeta. Organize different snapshots of the same model into a version sequence (V{t_1}, V{t_2}, ..., V{t_n}) based on the version_field and time_field. Versions can be organized by natural time (day / month / year) or by batch number.

[0132] Step 2: FeatureID generation and cross-version pairing: Generate FeatureIDs for spatial features in each version: (1) Geometric normalization:

[0133] In the geometric normalization formula, Represents the original geometric object (point / line / surface and its coordinate sequence) input; This indicates the mesh snapping tolerance (quantizing / rounding coordinates to a given precision, merging similar coordinates into the same mesh to eliminate floating-point jitter and minor noise). Indicates to All vertex coordinates are executed with Gridded adsorption processing for high resolution; Normalize the order of the rings (outer and inner rings) representing opposite elements and their vertices (e.g., unify the direction of the outer ring and the direction of the inner ring, and select the starting vertex according to the stability rule to eliminate the representation difference of "same shape but different order"). This means combining the adsorption geometry with the ring order canonical results to output a standardized geometry that satisfies both coordinate accuracy and topological representation consistency. This is used for subsequent spatial fingerprint / hash pairing with cross-version elements.

[0134] (2) Spatial fingerprint:

[0135] In spatial fingerprint formula middle, This represents a geometrically standardized object (which has undergone normalization processes such as mesh snapping and ring order / direction unification to eliminate the effects of homogeneous but different orders and floating-point errors). This means encoding geometric objects into stable binary byte sequences according to the Well-Known Binary standard to achieve a consistent geometric representation across different systems / storage engines; This indicates that a hash digest calculation (such as MD5, SHA-256 or other configurable hash algorithms) is performed on the binary byte sequence, and a fixed-length digest value is output as a spatial fingerprint; Spatial fingerprint values ​​are used as stable geometric identifiers in cross-version pairing, deduplication, fast comparison, and lineage association.

[0136] (3) FeatureID:

[0137] In the feature stable identifier formula (FeatureID=Hash(biz_id\Vert fp)) or (FeatureID=fp), (FeatureID) represents a unique stable identifier for features used for cross-version pairing and spatiotemporal lineage tracing; (biz_id) represents a unique object code assigned by the business primary key or external system (e.g., a plot / parcel / object ID that does not change with version), used to provide stability in business semantics; (fp) represents the stable identifier derived from standardized geometry. The generated spatial fingerprint summary is used to provide geometric stability; symbols This indicates string / byte sequence concatenation (usually using a fixed delimiter or length prefix to avoid ambiguity), that is, combining (biz_id) and (fp) to form a joint feature; This is a hash digest algorithm used to map joint features to a fixed-length unique identifier. In practice, MD5, SHA-256, or MurmurHash can be used (configurable). SHA-256 is preferred for scenarios with high security and collision resistance requirements, while MurmurHash can be used for high-performance, large-scale deduplication and pairing scenarios. When data lacks a reliable business primary key or only needs to be driven by geometric shape for pairing, it can be directly set... Spatial fingerprints are used as element identifiers, but at this time, version axis and necessary auxiliary conditions (such as attribute key values ​​and spatial adjacency relationships) need to be combined to reduce the risk of mismatch caused by hash collisions or homogeneous objects.

[0138] Cross-version matching prioritizes exact matching using the business primary key or FeatureID; if these are missing, spatial overlap ratio matching is used.

[0139] The spatial overlap ratio is calculated as a supplementary pairing criterion. For face-to-face features, the overlap ratio is calculated based on the intersection area. For line and point features, the overlap ratio is obtained by buffering to generate a strip or circular region before calculating the intersection area. Alternatively, linear difference metrics or displacement distance can be used as supplementary pairing criteria. Pairing is performed based on these supplementary criteria when feature stability identifiers cannot be generated or cannot be accurately matched. Line / point features can be buffered into a surface with radius r before calculating R, where r is configured by the acquisition accuracy or value set. During cross-version pairing, the platform compares adjacent versions V... t With V t+1 The elements are first matched using a deterministic exact matching strategy: if a stable business primary key biz_id or a generated stable element identifier FeatureID exists, a one-to-one candidate correspondence is directly established based on "equal primary key / equal FeatureID"; when the above keys are missing, of unreliable quality, or when multiple elements appear with one key, the process switches to candidate matching based on spatial similarity, calculating the spatial overlap ratio. As a matching metric, among which and These represent the same model in different versions. and Candidate feature geometry (usually using standardized geometry) To eliminate the effects of minute coordinate jitter. This represents the intersection region of two geometric shapes. Denotes the region of union of two geometries. This represents an area measurement operation; this index is essentially equivalent to the Jaccard similarity coefficient (IoU, Intersection over Union), and its value ranges from 0 to 1. 1. When The closer the value is to 1, the more consistent the spatial morphology. The platform can set a threshold θR (configurable by the user and can be graded by model type / scale). When R≥θR, the pair of elements is judged as a candidate pair of the same object. When multiple candidates meet the threshold, the "maximum RRR" optimization strategy can be further adopted. If necessary, auxiliary constraints (such as the same administrative region code, consistent adjacency relationship, attribute key value, etc.) can be superimposed to reduce mismatches and provide candidate set input for subsequent "merging / splitting" evolution identification.

[0140] Step 3: Construct element-level spatiotemporal lineage: For adjacent version pairs ((V) t V t+1 Based on pairing relationships and spatial similarity (where spatial similarity refers to the spatial overlap ratio defined above), (Based on the Jaccard similarity coefficient of Intersection / Union, the corresponding threshold is θR) Determine the evolution type: One-to-one and change below the threshold: KEEP. One-to-one and change exceeding the threshold: UPDATE. Many-to-one: MERGE. One-to-many: SPLIT. Only exists in the new version: NEW. Only exists in the old version: DELETE. The mapping is then written to FeatureLineage, and simultaneously to JobMeta, ModelLineage, and FieldLineage to form an audit chain.

[0141] Step 4: Cross-time consistency check (TEMPORAL rule): For adjacent version pairs ((V) t V t+1 For features that have completed cross-version pairing, the system performs cross-time consistency checks based on feature-level spatiotemporal lineage. To adapt to the different geometric characteristics of vector data points / lines / polygons, this step adopts an adaptive strategy based on geometric type for cross-time change measurement: area and region difference measures are used for polygon features; length and line shape difference measures are used for line features; and position displacement measures are used for point features. These measures are then compared with corresponding thresholds to identify abrupt changes and reasonable alterations.

[0142] Calculate the measure of change over time for paired elements: (1) Measurement of geometrical change over time for surface features: Area change rate:

[0143] In determining the evolution of adjacent version elements, an area change rate index is introduced. Used to quantify the same paired element in version V t With V t+1 The degree of geometric scale variation between the two periods. This indicator uses the feature area of ​​version t as a normalization benchmark to calculate the relative change ratio of the area between the two periods, thereby eliminating the impact of absolute area differences on features at different scales. Algorithmically, it first uses the business primary key, FeatureID, or spatial overlap ratio. Establish a cross-version one-to-one pairing relationship, and then calculate the geometric area A of the paired elements at times t and t+1 respectively. t With A t+1 And based on this, the area change rate is obtained. .when When the value is ≤θA (area change threshold), it can be determined that the shape is stable or slightly adjusted; when... When the value is greater than θA, it is considered a significant geometric change, typically associated with evolution types such as boundary correction, clipping expansion, or planning adjustments. This indicator is related to the spatial overlap ratio. Used together, it is used to distinguish between two types of situations: "high overlap but significant area change" and "structural change caused by low overlap".

[0144] Symmetrical difference rate:

[0145] In the process of determining cross-version element evolution, to further characterize the "spatial offset and reconstruction degree" of geometric shape changes, this invention constructs a symmetry difference rate based on the area change rate and spatial overlap ratio. This metric calculates the geometry of adjacent version features. and The symmetric difference area is calculated and normalized using the area of ​​the baseline feature version to quantify the proportion of "non-overlapping parts" in the original features. The symmetric difference operation can simultaneously capture both added and removed geometric regions, avoiding the insensitivity to local changes when relying solely on intersection-union comparisons. When the value is small and below the user-defined threshold θD, it can be considered a minor geometric adjustment (such as boundary fine-tuning or coordinate correction); when... When the value increases significantly and exceeds a threshold, it indicates that the feature has undergone substantial morphological reconstruction, serving as one of the important criteria for evolution types such as UPDATE, SPLIT, or MERGE. This algorithm is applicable to isal features, implemented based on standard GIS topology operators, and the calculation process can be efficiently completed within database spatial functions or GIS engines.

[0146] (2) Measurement of geometrical change over time for line features: For line elements, the system uses the line element length L of version t. t Using this as a baseline, calculate the rate of change over time ( This is used to depict the increase or decrease in length of linear objects such as roads, rivers, and pipelines between adjacent versions. ≤ When () the change in line length is deemed acceptable; when () When (G) is considered a significant change, to further characterize linear offset or geometric reconstruction (i.e., similar lengths but large changes in direction), the system can use the "buffered symmetry difference ratio" as a measure of linear difference: for (G) t ) and (G t+1 ) Generate strip surfaces by buffering with radius r respectively. Then calculate the proportion of the symmetrical difference area ( The buffer radius (r) can be determined by the data acquisition accuracy, scale, or model threshold set configuration, and is used to convert linear differences into measurable area differences. This mechanism is applicable to determining the consistency of line features across time under conditions such as edge translation, bending correction, and discontinuity adjustment.

[0147]

[0148]

[0149] (iii) Measurement of cross-time geometrical change for point features: For point features, the system calculates the displacement distance between adjacent versions. ) as a measure of consistency across time, where (P t ) and (P t+1 ) represent the coordinates of the same paired point at version (t) and (t+1), respectively. Distance calculation can use planar distance or ellipsoidal geodesic distance (determined by the model SRID and metric requirements). When ( ≤ When () the positional change is deemed acceptable; when () > When a change is identified as a significant displacement, it proceeds to subsequent rule classification and explanation of legitimate causes. This mechanism is applicable to the identification of abnormal migrations of objects such as POIs, monitoring points, and cadastral boundary points during cross-version updates.

[0150]

[0151] The introduction and explanatory determination of the legitimate change reason: After measuring the geometric changes of adjacent version features (G_t) and (G_{t+1}), the system compares the measurement results with a threshold and outputs the TEMPORAL rule hit result. It also introduces a legitimate change reason identifier, change_reason, as a correction factor for time consistency determination. change_reason is not manually assigned a value but is automatically introduced through the following two methods: (1) Approval / Business Field Mapping: Extract the approval type field (such as "adjustment type", "approval item", "change basis" etc.) that is bound to the element from the element attribute table or related business table, and map it to a standardized change reason code; (2) JobMeta metadata parsing: From the JobMeta metadata generated in the data production or governance process, the operator links that the current element has experienced (such as “boundary correction”, “clipping”, “buffering”, “topology repair”, “version replacement”, etc.) are parsed, and the geometric change properties are inferred according to the operator type rules.

[0152] When the extracted change_reason is in the allowed list, even if the change measure corresponding to the surface / line / point ( If the threshold is exceeded, the change can be marked as an interpretable change and allowed or downgraded at the time consistency level. If a legitimate reason cannot be extracted, or the reason is not within the allowed range, it will still be strictly judged as a significant change based on the threshold result, and the evidence (change measure, comparison version, feature equivalent) will be written into QualityIssue to provide input for subsequent spatial and attribute rules.

[0153] Step 5: Execution of Spatial and Attribute Rules (SPATIAL / ATTR Rules): Based on the TEMPORAL rule output (with polygons / lines / points corresponding to their time-varying change metrics and threshold determination results respectively), the system further combines spatial topology rules and attribute consistency rules to refine the determination of changing elements. Spatial rules focus on verifying whether geometric changes cause topological conflicts (such as self-intersection, gaps, overlaps, boundary crossings, etc.) and whether they meet the spatial constraints of the target layer; attribute rules are used to verify the logical consistency of key attributes (such as ownership codes, usage types, source identifiers, etc.) before and after changes.

[0154] In this stage, `change_reason` is used as a context parameter in the rule execution process: if it originates from an approval field or JobMeta operator inference and belongs to a type in the allowed list, some spatial or attribute rules can be executed in a weak constraint mode (WEAK), such as only recording a warning without directly blocking; otherwise, a strong constraint mode (STRONG) is used, and elements that do not conform to the rules are directly judged as quality anomalies. Through this mechanism, "rule strength is dynamically adjusted according to change semantics," avoiding one-size-fits-all misjudgments.

[0155] Step 6: Quality Access Control Judgment and Report Output: After integrating the results of TEMPORAL, SPATIAL, and ATTR rules, the system enters the quality access control judgment stage. This stage makes decisions based on two dimensions: "rule trigger result + legality of change reason": (1) When the geometric change index exceeds the threshold and the change_reason does not exist or is not in the allowed list, it is judged as STRONG abnormal, directly blocking data entry or version release; (2) When the geometric change index exceeds the threshold, but the change_reason is legal and explainable, it is judged as WEAK abnormal, allowing entry but requiring a record in the quality inspection report; (3) When the geometric change index does not exceed the threshold, it is judged as pass regardless of whether the change_reason exists. Finally, the system automatically generates a structured quality inspection report, clearly recording the element identifier, change index value, trigger rule, change_reason source (approval field or JobMeta operator), judgment level (STRONG / WEAK / PASS) and processing suggestions. The change index value is output according to the geometric type: polygon elements output ΔA, D (and R if necessary); line elements output ΔL, Output point element Δd. Achieve full-process traceability, auditability, and verifiability in quality access control.

[0156] Example 2 Embodiment 2 of this application, based on Embodiment 1, provides a geospatial data governance system based on quality control and lineage tracing, such as... Figure 3 As shown, it includes: The metadata management module 101 is used to build a unified metadata repository for the vector space data to be governed and its attribute table data, and to store and manage model metadata and field metadata. Version and identifier management module 201 is used to generate and manage model version sequence based on the metadata management module, and generate stable identifiers for spatial elements in each version; The spatiotemporal lineage construction module 301 is used to perform cross-version element pairing based on the element stability identifier and determine the evolution relationship to form an element-level spatiotemporal lineage. The spatiotemporal consistency verification module 401 is used to calculate the cross-time geometric change measure of spatial elements with evolutionary relationships, obtain or infer the legitimate change reasons of the spatial elements based on the spatiotemporal lineage of the elements, combine the cross-time geometric change measure and the legitimate change reasons to determine the spatiotemporal consistency quality of the spatial elements, and output the graded quality inspection results. The quality access control judgment and output module 501 is used to make quality access control judgments on the current model version based on the graded quality inspection results, generate differentiated access control decisions, and associate the element-level spatiotemporal lineage output quality report.

[0157] The spatiotemporal consistency verification module 401 is specifically used for: calculating the area change rate and symmetry difference ratio of face features; calculating the length change rate and linear difference measurement based on the buffer symmetry difference ratio of line features; calculating the displacement distance of point features; when the cross-time geometric change measurement exceeds the corresponding threshold and no valid legal change reason is obtained, it is determined as a strong rule violation; when the cross-time geometric change measurement exceeds the corresponding threshold but a valid legal change reason is obtained, it is determined as a weak rule violation; using the legal change reason as the context parameter, the spatial topology rules or attribute consistency rules triggered by features that hit the legal change reason are executed in a weak constraint mode, and only warnings are recorded; the rules triggered by features that do not obtain a valid change reason are executed in a strong constraint mode, and quality anomalies are directly determined.

[0158] Example 3 This embodiment 3, based on embodiment 1, takes the governance of county-level administrative division boundary data under the unified management of a provincial natural resources authority as an example to further illustrate the method of the present invention, as follows: The administrative division boundary data is stored in the form of area features and is generated in multiple versions annually for use in land spatial planning, land use control, statistical analysis, and downstream thematic applications. Due to administrative division adjustments, boundary demarcation corrections, and improvements in data accuracy, there may be minor adjustments to the boundaries, mergers or splits of administrative units between different annual versions.

[0159] This type of data has the following typical characteristics: a large number of polygon features, continuous spatial range, and sensitivity to topological relationships; most features have stable business primary keys (such as administrative division codes), but there are missing or changed instances in historical data; merging, splitting, and boundary adjustments often originate from formal approval documents, but the approval information and spatial data are not always strongly correlated; downstream systems have high requirements for the temporal consistency and accuracy of boundary data. Therefore, the method described in this invention is suitable for cross-time consistency verification and lineage tracing.

[0160] (1) Model and version axis construction: Define an "Administrative Division Boundary" model in the GIS platform, and record the following key information in the corresponding ModelMeta table: geom_type = POLYGON: Feature geometry type, indicating that the data managed by this model is isometric spatial features.

[0161] srid = CGCS2000: Spatial reference identifier, indicating that the coordinate reference system used by this model is the 2000 National Geodetic Coordinate System (CGCS2000).

[0162] topo_rule_set={geometric validity, no self-intersection, no gaps, no overlap}: A set of topological rules used to constrain the spatial topological relationships of surface features, including: valid geometry, no self-intersection of single features, no gaps between adjacent features, and no overlap between features on the same layer.

[0163] version_field=version_id: Version identifier field, used to distinguish data versions of the same model at different times or in different batches.

[0164] time_field=effective_date: The time attribute field is used to describe the effective time or point in time of the data version or feature, serving as the basis for time series analysis and cross-time consistency verification.

[0165] featureid_policy=biz_id+spatial fingerprint: a unique identifier generation strategy for features. It generates stable feature identifiers by combining business primary key identifiers with spatial geometric fingerprints, which are used for cross-version feature matching and lineage tracing.

[0166] The data from 2022 and 2023 were used as model versions (V{2022}) and (V{2023}) respectively, forming adjacent version pairs for subsequent comparison.

[0167] (2) FeatureID generation and cross-version pairing: For all surface features in (V{2022}) and (V{2023}), the system first performs geometric normalization, including coordinate mesh snapping and ring order normalization, to obtain normalized geometry (G_{norm}), and generates spatial fingerprint fp based on its WKB representation.

[0168] Subsequently, a stable identifier, FeatureID, is generated according to the following strategy: For elements with stable administrative division codes, adopt ; For elements with missing or untrusted business primary keys, adopt .

[0169] During the cross-version matching phase, the system prioritizes performing exact matching based on FeatureID; for features that fail to match, the spatial overlap ratio (R) is calculated, and when (R ≥ 0.05R), a candidate pairing relationship is established, and in the case of multiple candidates, the matching pair with the largest overlap ratio is selected.

[0170] (3) Element-level spatiotemporal lineage construction: Based on cross-version pairing results, the system constructs feature-level spatiotemporal lineage relationships for adjacent version pairs ((V{2022}, V{2023})): features with one-to-one matching and high spatial similarity are identified as KEEP or UPDATE; multiple (V{2022}) features corresponding to one (V{2023}) feature are identified as MERGE; one (V{2022}) feature corresponding to multiple (V{2023}) features are identified as SPLIT; features appearing only in new versions are marked as NEW; and features existing only in old versions are marked as DELETE. All evolution relationships are written to the FeatureLineage table and associated with the corresponding job_id and operator_type to form an auditable evolution chain.

[0171] (4) Cross-time consistency verification and legal change identification: For elements with one-to-one evolutionary relationships, the system calculates the rate of change of area ( ) and symmetry difference rate ( The system quantifies the degree of boundary changes. When the change index exceeds the configured threshold, the system further introduces the legitimate change reason (change_reason) for interpretive judgment. Specifically, the system reads fields such as "adjustment type" and "approval document number" from the administrative division attribute table and maps them to standardized change reason codes; at the same time, it parses the operator types recorded in JobMeta, such as "administrative division merger", "boundary correction", and "historical data replacement", and infers the source of the change accordingly; if the extracted change_reason belongs to the allowed list (such as "approval of administrative division adjustment" and "update of boundary survey results"), the change is deemed to have business rationality.

[0172] (5) Joint determination of spatial and attribute rules: Based on the TEMPORAL rule results, the system continues to execute spatial topology rules and attribute consistency rules: for geometric changes caused by legitimate alterations, the spatial rules adopt the WEAK mode and only record warnings; for significant changes without legitimate reasons, both the spatial rules and attribute rules adopt the STRONG mode; for cases where key attributes such as administrative division codes and names are inconsistent and there is no approval basis, they are directly judged as quality anomalies.

[0173] (6) Quality access control judgment and result output: The system summarizes all rule execution results and performs quality access control judgment on version (V{2023}): If the STRONG rule is hit, the access control status is FAIL, blocking the version from entering the release stage; if only the WEAK rule is hit, the access control status is WARN, allowing release but generating a warning report; if no rule is hit, the access control status is PASS.

[0174] At the same time, the system outputs a quality and lineage report containing the following: Element-level evolution types (KEEP / UPDATE / MERGE / SPLIT, etc.); time-varying change indicators (( ), ( ), ( Triggering rules and their severity levels; the source and explanation path of the legitimate change reasons; related historical version elements and downstream impact scope.

[0175] As can be seen from the above embodiments, the present invention can realize cross-time consistency verification, interpretable evolution determination and quality access control of administrative division boundary data in real land spatial data scenarios, effectively improving the accuracy, traceability and automation level of multi-version spatial data governance.

Claims

1. A geospatial data governance method based on quality control and lineage tracing, characterized in that, include: For the vector space data and its attribute table data to be governed, a unified metadata repository is constructed to store model definitions that include at least model metadata and field metadata. Based on the model definitions, a model version sequence is established for snapshots at different times. For spatial features in each model version, calculate feature stability identifiers based on business primary keys or spatial fingerprints generated from standardized geometry. Based on the element stability identifier, spatial elements in cross versions are paired, and the evolution relationship of elements in cross versions is determined according to the pairing results. The evolution relationship is recorded as element-level spatiotemporal lineage. For spatial elements with evolutionary relationships, the cross-temporal geometric change measure of the spatial elements is calculated, and the legitimate reasons for the changes of the spatial elements are obtained or inferred based on the spatiotemporal lineage of the elements. The spatiotemporal consistency quality of the spatial elements is judged by combining the cross-temporal geometric change measure and the legitimate reasons for the changes, and the graded quality inspection results are output. Based on the graded quality inspection results, a quality access control judgment is made on the current model version, a differentiated access control decision is generated, and the element-level spatiotemporal lineage is associated to output a quality report.

2. The method according to claim 1, characterized in that, The model metadata includes at least spatial reference identifiers, geometric types, topological constraint sets, version identifier fields, and feature stability identifier generation strategies; the field metadata includes at least field constraint conditions and semantic tags, which are used for automatic rule assembly and lineage semantic annotation.

3. The method according to claim 1, characterized in that, The stability identifier of the computational element specifically includes: The element stability identifier is generated in the following manner: The original geometry is subjected to mesh adsorption tolerance processing and ring order normalization processing to obtain a standardized geometry; The standardized geometry is encoded using WKB and its hash value is calculated to obtain a spatial fingerprint; The hash value is calculated by concatenating the business primary key with the spatial fingerprint, or the spatial fingerprint is used directly as the element stability identifier when the business primary key is missing. The spatial overlap ratio is calculated as a supplementary pairing criterion. For opposite features, the calculation is based on the intersection area. For line features and point features, the spatial overlap ratio is obtained by generating a strip surface or circular region through buffering and then calculating the intersection area. Alternatively, linear difference measurement or displacement distance can be used as a supplementary pairing criterion. When the stable identifier of the feature cannot be generated or cannot be accurately matched, pairing is performed according to the supplementary pairing criterion.

4. The method according to claim 3, characterized in that, The evolutionary relationship is determined according to the following logic: When there is a unique element pairing across versions, and the spatial overlap ratio is greater than or equal to the first threshold, it is determined to be a relationship that is maintained. When there is a unique element pairing across versions, and the spatial overlap ratio is less than the first threshold, it is determined to be an update relationship; When multiple elements in the old version are paired with one element in the new version, it is determined to be a merge relationship; When an element in the old version is paired with multiple elements in the new version, it is determined to be a split relationship; When an element only appears in a new version, it is considered a newly added relationship; When an element only appears in the old version, it is determined to be a deletion relationship.

5. The method according to claim 3, characterized in that, The geometric change measure includes: Calculate the area change rate and symmetry difference rate for opposite elements; Calculate the rate of change of length and measure the difference in line shape for line features; Calculate the displacement distance for point features; The formula for calculating the area change rate is: in, and These represent the areas of the spatial elements in two adjacent versions; The formula for calculating the symmetry difference rate is: in, and These represent the feature geometry of the spatial feature in two adjacent versions, respectively. This represents the symmetric difference operation; The formula for calculating the rate of change of length is: in, and These represent the line feature lengths of the spatial feature in two adjacent versions; The formula for calculating the linear difference measure is as follows: in, and These represent the generation of a strip surface with a radius of r through buffering; The formula for calculating the displacement distance is: in, and These represent the coordinate positions of the spatial element in two adjacent versions.

6. The method according to claim 1, characterized in that, The legitimate reason for the change is obtained through at least one of the following methods: Extract the approval type field from the attribute table or related business table of the spatial elements and map it to a standardized approval change reason; From the metadata of the data processing job that generated the model version, the operator types that caused the geometric changes are parsed out and mapped to standardized job change reasons.

7. The method according to claim 1, characterized in that, The spatiotemporal consistency quality determination specifically includes: When the cross-time geometric change metric exceeds the corresponding threshold and no valid legal reason for the change is obtained, it is determined to be a strong rule violation; When the cross-time geometric change metric exceeds the corresponding threshold but a valid and legitimate reason for the change is obtained, it is determined to be a weak rule violation; Using the legitimate change reason as the context parameter, the spatial topology rules or attribute consistency rules triggered by the elements that match the legitimate change reason are executed in a weak constraint mode, and only warnings are recorded; Rules triggered by elements for which no legitimate reason for change has been obtained are executed in a strong constraint mode, directly determining quality anomalies.

8. A geospatial data governance system based on quality control and lineage tracing, characterized in that, include: The metadata management module builds a unified metadata repository for the vector space data to be governed and its attribute table data, which is used to store and manage model metadata and field metadata. The version and identifier management module is used to generate and manage the model version sequence based on the metadata management module, and to generate stable identifiers for spatial elements in each version. The spatiotemporal lineage construction module is used to perform cross-version element pairing based on the element stability identifier and determine the evolution relationship to form element-level spatiotemporal lineage. The spatiotemporal consistency verification module is used to calculate the cross-temporal geometric change measure of spatial elements with evolutionary relationships, obtain or infer the legitimate reasons for the changes of the spatial elements based on the spatiotemporal lineage of the elements, and combine the cross-temporal geometric change measure and the legitimate reasons for the changes to determine the spatiotemporal consistency quality of the spatial elements and output the graded quality inspection results. The quality access control judgment and output module is used to make quality access control judgments on the current model version based on the graded quality inspection results, generate differentiated access control decisions, and associate the element-level spatiotemporal lineage output quality report.

9. The system according to claim 8, characterized in that, The spatiotemporal consistency verification module is specifically used for: Calculate the area change rate and symmetry difference ratio of the opposite elements; Calculate the rate of change of length for line features and measure the line shape difference based on the buffer symmetry difference ratio; Calculate the displacement distance for point features; When the cross-time geometric change metric exceeds the corresponding threshold and no valid legal reason for the change is obtained, it is determined to be a strong rule violation; When the cross-time geometric change metric exceeds the corresponding threshold but a valid and legitimate reason for the change is obtained, it is determined to be a weak rule violation.

10. The system according to claim 8, characterized in that, The spatiotemporal consistency verification module is also used for: Using the legitimate change reason as the context parameter, the spatial topology rules or attribute consistency rules triggered by the elements that match the legitimate change reason are executed in a weak constraint mode, and only warnings are recorded; Rules triggered by elements for which no legitimate reason for change has been obtained are executed in a strong constraint mode, directly determining quality anomalies.

Images