A district-level city digital base data fusion method based on a knowledge graph

Abstract

The application discloses a kind of district-level city digital base data fusion methods based on knowledge graph, it is related to wisdom city data management technical field, including: access data and standardization is as city data record;According to coordinate landing point forms jurisdiction level node, city entity node and jurisdiction chain edge;Based on administrative jurisdiction chain gate CompGCN forms jurisdiction closed representation;Mark broken chain jurisdiction edge and divide entity group;According to source constraint relationship, execute core attribute aggregation;Check state and write into real-time perception state;Output fusion data and fusion check result.The application can improve city entity fusion accuracy, grid attribution reliability and data traceability.

Description

Technical Field

[0001] This invention relates to the field of smart city data governance technology, and in particular to a method for data fusion of a district-level city digital infrastructure based on knowledge graphs. Background Technology

[0002] In the field of smart city data governance technology, existing technologies typically first standardize the format and transform the coordinates of data from different sources, and then perform entity matching based on object codes, object names, or spatial locations, incorporating the matched city objects into a unified management framework. Some existing solutions also introduce knowledge graphs to express the semantic relationships between city objects, improving data query and correlation analysis capabilities.

[0003] Current data fusion methods focus more on whether fields are identical, coordinates are close, or names are similar, but they lack sufficient verification of hierarchical affiliation between administrative districts, streets, communities, grids, and city objects. When intermediate levels are missing or incorrectly affixed, data may still be merged, resulting in city objects being attached to incorrect grids or being repeatedly merged.

[0004] Data from different sources often have inconsistent recording standards for the same object attribute. Existing methods struggle to determine which data sources are suitable for participating in key attribute fusion, easily leading to conflicts in object encoding, names, and coordinate results. For real-time sensing data, existing methods often employ direct updates, lacking verification between the data and existing business states. This allows abnormal states to enter the digital foundation, reducing the accuracy and traceability of the fused data.

[0005] Therefore, how to provide a data fusion method for a district-level city digital infrastructure based on knowledge graphs is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0006] One objective of this invention is to propose a data fusion method for district-level city digital infrastructure based on knowledge graphs. This invention utilizes the administrative jurisdiction chain gating CompGCN to perform jurisdictional closure, source constraints, and status inheritance verification on city entities, which has the advantages of high fusion accuracy, clear attribution relationships, and traceable verification.

[0007] A data fusion method for a district-level city digital infrastructure based on a knowledge graph, according to an embodiment of the present invention, includes the following steps: Access the district-level city digital infrastructure data, perform standardized preprocessing, and obtain city data records; Match jurisdictional level nodes and city entity nodes according to coordinate landing points, incorporate them into the district-level city knowledge graph and connect them to form a jurisdictional chain edge; In the administrative jurisdiction chain gating CompGCN, the jurisdiction chain routing order is set, and the jurisdiction chain edges are combined in the following order: administrative region to street, street to community, community to grid, grid to city entity. When the previous level jurisdiction chain edge is not completed, the subsequent level jurisdiction chain edge is blocked from propagating to the city entity node, thus forming a closed representation of jurisdiction. Based on the jurisdiction closure representation, the broken jurisdiction edge is marked. City entity nodes associated with the broken jurisdiction edge are included in the unmerged entity group, and city entity nodes not associated with the broken jurisdiction edge are included in the entity group to be merged. The data source is converted into a source constraint relationship. In the administrative jurisdiction chain gating CompGCN, the city entity nodes participating in the core attribute aggregation are selected based on the source constraint relationship and the chain break mark. The core attribute aggregation is then performed on the selected city entity nodes. Read the previous state of the city entity nodes in the entity group to be merged, form a state succession relationship based on the current business state, verify the state succession relationship according to the previous state, and write the real-time perception state into the city entity node after the verification is passed. City entity nodes that fail the verification are transferred to the unmerged entity group. The entity groups to be merged that have completed jurisdiction closure, source constraints, and status acceptance will be released as district-level city digital foundation fusion data, and the unmerged entity groups will be organized into fusion verification results.

[0008] Optionally, the standardization preprocessing includes the following steps: Map the object name, object code, spatial coordinates, data source, current business status, and real-time perception status in the access data to a unified field; Transform the spatial coordinates to a unified district-level spatial benchmark and extract the coordinate points of the city data records; The current business status and real-time perception status are written to the same city data record according to the collection time, and the correspondence between the data source and the city data record is preserved.

[0009] Optionally, the formation of the city entity nodes and the jurisdiction chain edges includes the following steps: A district-level spatial index is constructed based on the coordinate points recorded in the city data to locate the administrative districts corresponding to the coordinate points; Within the administrative region, street boundaries, community boundaries, and grid boundaries are matched sequentially to obtain the street, community, and grid corresponding to the coordinate landing point, and the administrative region, street, community, and grid are determined as the jurisdictional level nodes; Based on urban data records, urban entity nodes are established, and jurisdictional level nodes and urban entity nodes are incorporated into the district-level urban knowledge graph, forming jurisdictional chain edges by connecting them according to hierarchical affiliation.

[0010] Optionally, the setting of the jurisdiction link includes the following steps in sequence: Based on the two ends of the jurisdiction chain connection, the administrative region to street, street to community, community to grid, and grid to city entity node are arranged into a four-level routing order; The administrative jurisdiction chain gating CompGCN follows a four-level routing order, first performing combination on the jurisdiction chain edges from administrative district to street, and then sequentially performing combination on the jurisdiction chain edges from street to community, community to grid, and grid to urban entity node; The combined results of the management chain edges at each level are transmitted to the city entity nodes along the four-level routing sequence.

[0011] Optionally, the formation of the jurisdictional closure representation includes the following steps: The CompGCN administrative jurisdiction chain gating system determines the previous level jurisdiction chain edge of the current jurisdiction chain edge to be combined based on the four-level routing order. When the previous level of the jurisdiction chain edge is combined, the propagation gating of the current jurisdiction chain edge to be combined is activated, and vector combination is performed on the two ends of the current jurisdiction chain edge to be combined. When the previous level of jurisdiction chain edge has not been combined, close the propagation gate of the current jurisdiction chain edge to be combined, and block the propagation of the current jurisdiction chain edge to be combined and the next level of jurisdiction chain edge to the city entity node; The combined result that has been completed step by step and has not been blocked by the propagation gating is output as a jurisdictional closure representation.

[0012] Optionally, marking the broken chain jurisdiction edge includes the following steps: Based on the incomplete combination states in the jurisdiction closure representation, determine the current jurisdiction chain edge corresponding to the closure of the propagation gating; Mark the current jurisdiction chain edge and the jurisdiction chain edge following the current jurisdiction chain edge as broken jurisdiction edges, and determine the city entity nodes associated with the broken jurisdiction edges; City entity nodes with disconnected jurisdictional edges are classified into the unmerged entity group, and city entity nodes without disconnected jurisdictional edges are classified into the entity group to be merged.

[0013] Optionally, converting the data source into a source constraint relationship includes the following steps: Extract data source, object code, object name, and coordinate location from city data records, and determine the object code, object name, and coordinate location as core attributes; Based on the core attributes of urban entity nodes, establish the correspondence between data sources and core attributes; The correspondence between data sources and core attributes is encoded as source constraint relationships, which include the corresponding content of data sources, core attributes, and city entity nodes; The source constraint relationship is converted into a relation vector in the administrative jurisdiction chain gating CompGCN, which serves as the relation constraint before the core attribute aggregation.

[0014] Optionally, the core attribute aggregation includes the following steps: Based on the broken chain marker, the city entity nodes in the unmerged entity group are hidden, while the city entity nodes in the entity group to be merged are retained; The administrative jurisdiction chain gating CompGCN matches the retained city entity nodes with the source constraint relationship to determine the city entity nodes participating in the aggregation of each core attribute; When the data source corresponding to a city entity node satisfies the source constraint relationship of the core attribute, the city entity node is retained to participate in the core attribute aggregation. When the data source corresponding to a city entity node does not meet the source constraint relationship of the core attribute, the city entity node is blocked from participating in the core attribute aggregation. For city entity nodes participating in core attribute aggregation, perform object code aggregation, object name aggregation, and coordinate landing point aggregation respectively, and determine the aggregated object code, object name, and coordinate landing point as the core attributes of the city entity node.

[0015] Optionally, the verification of the state succession relationship includes the following steps: Identify city entity nodes in the entity group to be merged and obtain the previous state corresponding to the city entity node. Based on the state succession rules corresponding to the current business state, determine the previous state that can be succeeded and establish the state succession relationship between the current business state and the previous state that can be succeeded. Compare the previous state corresponding to the city entity node with the previous states that are allowed to be inherited in the state inheritance relationship; When the comparison is consistent, the state inheritance relationship is determined to have passed the verification. The real-time perceived state is used as the state content of the urban entity node, and the state inheritance verification is retained. If the comparison is inconsistent, it is determined that the status inheritance relationship has failed the verification. The reason for the failure of the status inheritance verification is retained, and the corresponding city entity node is transferred to the unmerged entity group.

[0016] Optionally, the formation of the district-level city digital infrastructure fusion data and fusion verification results includes the following steps: For city entity nodes in the fused entity group, verify the closed representation of jurisdiction, the aggregation results of core attributes corresponding to source constraint relationships, and the status acceptance verification pass mark; When the jurisdiction closure indicates that the core attributes corresponding to the existence and source constraint relationship have been aggregated and the state acceptance verification has passed, the corresponding city entity node will be identified as the district-level city digital foundation fusion data. For city entity nodes in unintegrated entity groups, sort out the reasons for broken chain jurisdiction edges, unmet source constraints, and failed state inheritance verification; The city entity nodes, broken chain jurisdiction edges, unmet source constraints, and reasons for failing the state acceptance verification in the unintegrated entity group are determined as the fusion verification results.

[0017] The beneficial effects of this invention are: (1) This invention combines administrative districts, streets, communities, grids and urban entity nodes in order of jurisdiction chain, and blocks subsequent propagation when the previous level of jurisdiction chain is not completed. This can prevent the missing or incorrect jurisdiction level from entering the fusion process, thereby improving the accuracy of urban entity attribution judgment and reducing cross-grid attachment and entity attribution offset.

[0018] (2) This invention converts the data source into a source constraint relationship and combines the broken chain mark to screen the city entity nodes participating in the core attribute aggregation. When there are multiple source differences in object code, object name and coordinate landing point, entities whose source does not meet the constraints can be excluded from the aggregation, thereby improving the consistency and reliability of the core attribute fusion results.

[0019] (3) Before releasing the fused data, the present invention introduces a status acceptance verification. The current business status is verified based on the previous status of the city entity node. Only after the verification is passed is the real-time perception status written. If the verification fails, it is transferred to the non-fused entity group, which avoids abnormal status directly covering the city entity and improves the traceability and business credibility of the district-level city digital base fused data. Attached Figure Description

[0020] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is an overall flowchart of a knowledge graph-based data fusion method for district-level urban digital infrastructure proposed in this invention. Figure 2 This is a schematic diagram of the CompGCN, the administrative jurisdiction chain gate, in this invention. Figure 3 This is a schematic diagram of the process of core attribute aggregation under source constraints in this invention. Detailed Implementation

[0021] The present invention will now be described in further detail with reference to the accompanying drawings. These drawings are simplified schematic diagrams, illustrating only the basic structure of the invention, and therefore only show the components relevant to the invention.

[0022] refer to Figures 1-3 A data fusion method for district-level city digital infrastructure based on knowledge graphs includes the following steps: Access the district-level city digital infrastructure data, perform standardized preprocessing, and obtain city data records; Match jurisdictional level nodes and city entity nodes according to coordinate landing points, incorporate them into the district-level city knowledge graph and connect them to form a jurisdictional chain edge; In the administrative jurisdiction chain gating CompGCN, the jurisdiction chain routing order is set, and the jurisdiction chain edges are combined in the following order: administrative region to street, street to community, community to grid, grid to city entity. When the previous level jurisdiction chain edge is not completed, the subsequent level jurisdiction chain edge is blocked from propagating to the city entity node, thus forming a closed representation of jurisdiction. Based on the jurisdiction closure representation, the broken jurisdiction edge is marked. City entity nodes associated with the broken jurisdiction edge are included in the unmerged entity group, and city entity nodes not associated with the broken jurisdiction edge are included in the entity group to be merged. The data source is converted into a source constraint relationship. In the administrative jurisdiction chain gating CompGCN, the city entity nodes participating in the core attribute aggregation are selected based on the source constraint relationship and the chain break mark. The core attribute aggregation is then performed on the selected city entity nodes. Read the previous state of the city entity nodes in the entity group to be merged, form a state succession relationship based on the current business state, verify the state succession relationship according to the previous state, and write the real-time perception state into the city entity node after the verification is passed. City entity nodes that fail the verification are transferred to the unmerged entity group. The entity groups to be merged that have completed jurisdiction closure, source constraints, and status acceptance will be released as district-level city digital foundation fusion data, and the unmerged entity groups will be organized into fusion verification results.

[0023] In this embodiment, the standardization preprocessing includes the following steps: Map the object name, object code, spatial coordinates, data source, current business status, and real-time perception status in the access data to a unified field; Transform the spatial coordinates to a unified district-level spatial benchmark and extract the coordinate points of the city data records; After the spatial benchmark is unified for urban data recording, the geometric shape of the objects is read first. For point objects, the coordinate point is used as the coordinate landing point; for line objects, the midpoint is calculated along the line length, and if the endpoint of the line segment carries a management endpoint identifier, the management endpoint is used as the coordinate landing point; for area objects, representative points are calculated within the area, and if the representative point falls outside the area, the point farthest from the boundary within the area is used instead. When the coordinate landing point is located in the overlapping area of ​​administrative district, street, community, and grid boundary, the spatial coverage area and management affiliation record are read, and the matching object with the largest coverage area is preferred; if the coverage areas are the same, the management affiliation record is used to determine the unique matching object.

[0024] The current business status and real-time perception status are written to the same city data record according to the collection time, and the correspondence between the data source and the city data record is preserved.

[0025] Before writing city data records to their status, the current business status and real-time sensing status are first arranged according to the collection time. If the current business status is earlier than the real-time sensing status, the current business status is used as the basis for forming the status succession relationship, and the real-time sensing status is used as the status content written to the city entity node. If the real-time sensing status is earlier than the current business status, the collection time of the real-time sensing status is retained, and it is not included in the status succession relationship. After writing is completed, the status time, status source, and status order are retained in the same city data record for use in status succession verification.

[0026] In this embodiment, the formation of the city entity node and the jurisdiction chain edge includes the following steps: A district-level spatial index is constructed based on the coordinate points recorded in the city data to locate the administrative districts corresponding to the coordinate points; The district-level spatial index is retrieved based on the coordinate points to determine the administrative region boundaries containing those coordinate points. If only one administrative region boundary is found, the administrative region corresponding to that boundary is used; if two or more administrative region boundaries are found, the administrative affiliation record from the city data is obtained, and the administrative region corresponding to that record is used.

[0027] Within the administrative region, street boundaries, community boundaries, and grid boundaries are matched sequentially to obtain the street, community, and grid corresponding to the coordinate landing point, and the administrative region, street, community, and grid are determined as the jurisdictional level nodes; Using the administrative regions obtained in the previous step as the search scope, we search for street boundaries containing coordinate points within the administrative regions; using the street boundaries as the next search scope, we search for community boundaries containing coordinate points; using the community boundaries as the next search scope, we search for grid boundaries containing coordinate points. After the search is completed, the administrative regions, streets, communities, and grids are identified as jurisdictional level nodes, and the hierarchical relationship between each jurisdictional level node is preserved.

[0028] Based on urban data records, urban entity nodes are established, and jurisdictional level nodes and urban entity nodes are incorporated into the district-level urban knowledge graph, forming jurisdictional chain edges by connecting them according to hierarchical affiliation.

[0029] Node identifiers for urban entity nodes are established using object codes from urban data records. When object codes are missing, node identifiers are formed using data source, object name, and coordinate location. Object name, coordinate location, data source, current business status, and real-time sensing status are used as node attributes for urban entity nodes. Jurisdiction-level nodes and urban entity nodes are incorporated into the district-level urban knowledge graph, connected in the direction of administrative district to street, street to community, community to grid, and grid to urban entity node, forming jurisdictional chain edges. Corresponding jurisdictional relationship types are configured for each jurisdictional chain edge.

[0030] In this embodiment, the setting of the jurisdiction link includes the following steps in sequence: Based on the two ends of the jurisdiction chain connection, the administrative region to street, street to community, community to grid, and grid to city entity node are arranged into a four-level routing order; Label each jurisdiction chain with its superior and subordinate objects. When the superior object is an administrative region and the subordinate object is a street, it is classified as Level 1; when the superior object is a street and the subordinate object is a community, it is classified as Level 2; when the superior object is a community and the subordinate object is a grid, it is classified as Level 3; and when the superior object is a grid and the subordinate object is a city entity node, it is classified as Level 4. After classification, determine the four-level routing order according to Level 1 to Level 4.

[0031] The administrative jurisdiction chain gating CompGCN follows a four-level routing order, first performing combination on the jurisdiction chain edges from administrative district to street, and then sequentially performing combination on the jurisdiction chain edges from street to community, community to grid, and grid to urban entity node; In each level of routing, vector combinations are performed using the vectors of the parent object node, the current jurisdictional chain edge relationship vector, and the lower-level object node vector. During vector combination, the parent object node vector is first multiplied bitwise with the current jurisdictional chain edge relationship vector, and then linearly transformed to obtain the parent relationship combination vector. Next, the parent relationship combination vector is concatenated with the lower-level object node vector, and the result is obtained by applying an activation function. The linear transformation is performed using the trainable weight matrix in the CompGCN administrative jurisdictional chain gating system, and the activation function is the ReLU function. After the first level is completed, the second level is initiated, followed by the third level, and so on, until the fourth level is reached.

[0032] The combined results of the management chain edges at each level are transmitted to the city entity nodes along the four-level routing sequence.

[0033] The first-level combination result serves as the input constraint for the second-level vector combination, the second-level combination result serves as the input constraint for the third-level vector combination, and the third-level combination result serves as the input constraint for the fourth-level vector combination. After the fourth level is completed, the city entity node obtains the combination result passed down level by level along the administrative district, street, community, and grid.

[0034] In this embodiment, the formation of the jurisdictional closure representation includes the following steps: The CompGCN administrative jurisdiction chain gating system determines the previous level jurisdiction chain edge of the current jurisdiction chain edge to be combined based on the four-level routing order. The preceding level of the administrative chain edge is determined according to the four-level routing order. The preceding level from street to community is from administrative district to street; the preceding level from community to grid is from street to community; and the preceding level from grid to city entity node is from community to grid. The first-level administrative chain edge does not have a preceding level administrative chain edge; vector combination is performed directly.

[0035] When the previous level of the jurisdiction chain edge is combined, the propagation gating of the current jurisdiction chain edge to be combined is activated, and vector combination is performed on the two ends of the current jurisdiction chain edge to be combined. When the previous level combination result is completed, and the lower-level object in the previous level combination result is consistent with the upper-level object of the current managed chain edge, the propagation gate is activated. After the propagation gate is activated, the upper-level object node vector, the current managed chain edge relationship vector, and the lower-level object node vector are used as inputs to obtain the current level combination result according to the aforementioned vector combination method. After obtaining the current level combination result, the current managed chain edge is marked as having completed the combination.

[0036] When the previous level of jurisdiction chain edge has not been combined, close the propagation gate of the current jurisdiction chain edge to be combined, and block the propagation of the current jurisdiction chain edge to be combined and the next level of jurisdiction chain edge to the city entity node; If the previous level combination result is incomplete, or if the lower-level object in the previous level combination result is inconsistent with the upper-level object of the current governing chain edge, the propagation gating is closed. After the propagation gating is closed, the current governing chain edge stops vector combination, and the governing chain edges located after the current governing chain edge stop transmitting combination results to the city entity nodes, and are marked as incomplete combination state.

[0037] The combined result that has been completed step by step and has not been blocked by the propagation gating is output as a jurisdictional closure representation.

[0038] When vector combinations are completed at the administrative district to street, street to community, community to grid, and grid to city entity node levels, and the propagation gating is not closed, the fourth-level combination result is used as the jurisdictional closure representation of the city entity node. When any level of propagation gating is closed, the output of the jurisdictional closure representation stops, and the incomplete combination state is retained.

[0039] In this embodiment, the step of marking the broken chain jurisdiction edge includes the following steps: Based on the incomplete combination states in the jurisdiction closure representation, determine the current jurisdiction chain edge corresponding to the closure of the propagation gating; Check incomplete combination states according to the fourth-level routing order. When an incomplete combination state corresponds to a propagation gating closed position, determine the governing chain edge being processed at the propagation gating closed position as the current governing chain edge, and record the parent and child objects of the current governing chain edge.

[0040] Mark the current jurisdiction chain edge and the jurisdiction chain edge following the current jurisdiction chain edge as broken jurisdiction edges, and determine the city entity nodes associated with the broken jurisdiction edges; Using the current jurisdictional chain edge as the starting point of the chain break, determine the jurisdictional chain edges from the starting point of the chain break to the city entity node along the four-level routing sequence, and mark them as the broken jurisdictional edges. When the lower-level objects of the current jurisdictional chain edge are streets, communities, or grids, continue to determine subsequent jurisdictional chain edges along the lower-level objects until the city entity node is determined; when the current jurisdictional chain edge is from a grid to a city entity node, determine the city entity node corresponding to the lower-level object of the jurisdictional chain edge. The determined city entity node is the city entity node associated with the broken jurisdictional edge.

[0041] City entity nodes with disconnected jurisdictional edges are classified into the unmerged entity group, and city entity nodes without disconnected jurisdictional edges are classified into the entity group to be merged.

[0042] When a city entity node is associated with a broken jurisdictional boundary, it is classified into the unmerged entity group. When a city entity node is not associated with a broken jurisdictional boundary, and the administrative district to street, street to community, community to grid, and grid to city entity node are all combined, it is classified into the entity group to be merged.

[0043] In this embodiment, converting the data source into a source constraint relationship includes the following steps: Extract data source, object code, object name, and coordinate location from city data records, and determine the object code, object name, and coordinate location as core attributes; The object code, object name, and coordinate location are retrieved from the city data records. The object code is used to distinguish the identity of city entity nodes, the object name is used for name consistency checks, and the coordinate location is used for grid affiliation determination. These three items are then used as core attributes and processed in the source constraint relationship handling.

[0044] Based on the core attributes of urban entity nodes, establish the correspondence between data sources and core attributes; Core attributes are organized by city entity nodes. Each core attribute records the data source that provides the core attribute; when there are more than two data sources for the same core attribute, the correspondence between the data sources and the core attributes is retained separately, and the core attributes are not merged at this stage.

[0045] The correspondence between data sources and core attributes is encoded as source constraint relationships, which include the corresponding content of data sources, core attributes, and city entity nodes; The system consists of three corresponding elements: city entity nodes, core attributes, and data sources. City entity nodes define the constraint objects, core attributes define the constraint fields, and data sources define the attribute sources. After coding, a relationship identifier is configured for each source constraint relationship.

[0046] The source constraint relationship is converted into a relation vector in the administrative jurisdiction chain gating CompGCN, which serves as the relation constraint before the core attribute aggregation.

[0047] The relation vector is indexed by the relation identifier based on the source constraint relationship. After the relation vector is associated with the corresponding city entity node, it enters the core attribute aggregation pre-stage of the administrative jurisdiction chain gating CompGCN, which is used to limit the city entity nodes participating in the core attribute aggregation.

[0048] In this embodiment, the core attribute aggregation includes the following steps: Based on the broken chain marker, the city entity nodes in the unmerged entity group are hidden, while the city entity nodes in the entity group to be merged are retained; The filtering entry points are the entity groups to be merged and the entity groups not yet merged. City entity nodes belonging to the unmerged entity group are not included in the source constraint matching; city entity nodes belonging to the entity groups to be merged are included in the source constraint matching. After filtering, only city entity nodes from the entity groups to be merged are retained for subsequent core attribute aggregation judgment.

[0049] The administrative jurisdiction chain gating CompGCN matches the retained city entity nodes with the source constraint relationship to determine the city entity nodes participating in the aggregation of each core attribute; Using city entity nodes as the matching unit, the data source of each city entity node is compared with the source constraints corresponding to the core attributes. After the comparison is completed, the city entity nodes corresponding to the object code, object name, and coordinate landing point that participate in the core attribute aggregation are determined respectively.

[0050] When the data source corresponding to a city entity node satisfies the source constraint relationship of the core attribute, the city entity node is retained to participate in the core attribute aggregation. Using the current core attribute as the judgment object, obtain the data source corresponding to the core attribute in the city entity node and compare it with the data source corresponding to the core attribute recorded in the source constraint relationship. If the two are consistent and the city entity node belongs to the entity group to be merged, retain the city entity node as the aggregation object of the current core attribute.

[0051] When the data source corresponding to a city entity node does not meet the source constraint relationship of the core attribute, the city entity node is blocked from participating in the core attribute aggregation. If the data source corresponding to the current core attribute is inconsistent with the data source recorded in the source constraint relationship, the city entity node will be removed from the aggregation object of the current core attribute. Removal only applies to the current core attribute and does not change the affiliation of the city entity node in the entity group to be merged; other core attributes of the same city entity node will continue to be judged according to their respective source constraint relationships.

[0052] For city entity nodes participating in core attribute aggregation, perform object code aggregation, object name aggregation, and coordinate landing point aggregation respectively, and determine the aggregated object code, object name, and coordinate landing point as the core attributes of the city entity node.

[0053] Aggregation is performed on the identified core attributes. If object codes are consistent, the consistent code is retained; if object codes are inconsistent, the object code with consistent source constraints is retained. If object names are consistent, the consistent name is retained; if object names are inconsistent, the object name with consistent source constraints is retained. If coordinate points belong to the same grid, coordinate points that have completed jurisdictional closure are retained; if coordinate points do not belong to the same grid, coordinate point aggregation is stopped. After aggregation, the core attributes of the city entity nodes are obtained.

[0054] In this embodiment, the verification of the state succession relationship includes the following steps: Identify city entity nodes in the entity group to be merged and obtain the previous state corresponding to the city entity node. The states that have passed the state succession verification are arranged in chronological order according to the state status of the city entity node. The state that is most recent and preceding the current business state is the previous state. If there is no state that has passed the state succession verification, the city entity node is transferred to the unmerged entity group, and the missing previous state is recorded.

[0055] Based on the state succession rules corresponding to the current business state, determine the previous state that can be succeeded and establish the state succession relationship between the current business state and the previous state that can be succeeded. State succession rules are determined based on the object type of the city entity node. These rules record the correspondence between object type, current business state, allowed previous state, and state code. The current business state of the city entity node is matched against the state succession rules to obtain the allowed previous state and its corresponding state code, thus forming a state succession relationship.

[0056] Compare the previous state corresponding to the city entity node with the previous states that are allowed to be inherited in the state inheritance relationship; The previous state corresponding to the city entity node is converted into a state code, and the previous state that is allowed to be inherited is also converted into a state code. When the two state codes are consistent, the real-time perception state writing step is initiated; when the two state codes are inconsistent, the unfused entity group transition step is initiated.

[0057] When the comparison is consistent, the state inheritance relationship is determined to have passed the verification. The real-time perceived state is used as the state content of the urban entity node, and the state inheritance verification is retained. When the status codes are consistent, the real-time perceived status is used as the status content of the city entity node. The previous status, current business status, real-time perceived status, and status succession verification pass flag are retained.

[0058] If the comparison is inconsistent, it is determined that the status inheritance relationship has failed the verification. The reason for the failure of the status inheritance verification is retained, and the corresponding city entity node is transferred to the unmerged entity group.

[0059] When status codes are inconsistent, the previous status, current business status, and allowed previous status for the city entity node are retained. The inconsistent status codes are used as the reason for the status acceptance verification failure, and the city entity node is then transferred to the unmerged entity group.

[0060] In this embodiment, the formation of the district-level city digital infrastructure fusion data and fusion verification results includes the following steps: For city entity nodes in the fused entity group, verify the closed representation of jurisdiction, the aggregation results of core attributes corresponding to source constraint relationships, and the status acceptance verification pass mark; First, verify whether the city entity node has a closed-loop jurisdiction representation. If a closed-loop jurisdiction representation exists, verify whether the object code, object name, and coordinate location have all completed core attribute aggregation. If the aggregation results of the three core attributes are all associated with the same city entity node, then verify the status and mark the verification as passed. If any verification fails, it is uncertain whether it is district-level city digital foundation fusion data, and the city entity node is retained in the unfused entity group.

[0061] When the jurisdiction closure indicates that the core attributes corresponding to the existence and source constraint relationship have been aggregated and the state acceptance verification has passed, the corresponding city entity node will be identified as the district-level city digital foundation fusion data. After all three verifications are passed, the city entity nodes, jurisdictional closure representations, aggregated object codes, object names, coordinate locations, real-time sensing status, and status acceptance verification pass marks are compiled to obtain the district-level city digital foundation fusion data.

[0062] For city entity nodes in unintegrated entity groups, sort out the reasons for broken chain jurisdiction edges, unmet source constraints, and failed state inheritance verification; The city entity nodes in the unintegrated entity group are used as the unit of organization. When there is a broken chain jurisdiction edge, the broken chain jurisdiction edge and the corresponding incomplete combination state are retained; when there is an unmet source constraint relationship, the unmet core attribute, the corresponding data source and the source constraint relationship are retained; when there is a state acceptance verification failure, the previous state, the current business state, the allowed previous state, and the reason for the state acceptance verification failure are retained.

[0063] The city entity nodes, broken chain jurisdiction edges, unmet source constraints, and reasons for failing the state acceptance verification in the unintegrated entity group are determined as the fusion verification results.

[0064] Associate each city entity node in each unmerged entity group with a broken chain jurisdiction edge, an unmet source constraint relationship, and the reason for the failed state succession verification. If the same city entity node has two or more of the above, retain the corresponding content to form the merging verification result.

[0065] Example 1: To verify the feasibility of this invention in practice, it was applied to a data fusion scenario of a district-level city's digital infrastructure. In this scenario, the city's digital infrastructure needs to access data from business registration, spatial infrastructure, grid governance, and sensor collection. Data objects include buildings, road facilities, public components, grid events, and urban entities within the management area. Data from different sources differ in object coding, object names, spatial coordinates, and status records. Some objects have incomplete hierarchical affiliations between administrative districts, streets, communities, and grids, and some sensor statuses are not compatible with existing business statuses. If fusion is performed directly based on similar object names, close coordinates, or identical codes, it is easy to result in the same urban entity being repeatedly merged, different grid objects being incorrectly attached, and abnormal statuses directly overwriting existing statuses, affecting the data accuracy of the district-level city's digital infrastructure.

[0066] In practical applications, the object name, object code, spatial coordinates, data source, current business status, and real-time perception status in the accessed data are first organized into unified fields, and the spatial coordinates are converted to a district-level unified spatial benchmark. For point objects, the coordinate landing point is directly extracted; for line objects, the coordinate landing point is determined based on the midpoint of the line segment or the management endpoint; for area objects, a representative point located inside the area is used as the coordinate landing point. After the coordinate landing point is determined, administrative districts, streets, communities, and grids are matched sequentially in the district-level spatial index. The matched jurisdictional level nodes and city entity nodes are incorporated into the district-level city knowledge graph and connected according to hierarchical affiliation to form jurisdictional chain edges.

[0067] After establishing the jurisdictional chain edge, it is input into the Administrative Jurisdiction Chain Gating System (CompGCN). The CompGCN processes these edges according to a four-level routing sequence: administrative district to street, street to community, community to grid, and grid to city entity node. The current-level jurisdictional chain edge only enters vector combination after the previous-level jurisdictional chain edge has completed its combination. If the previous-level jurisdictional chain edge has not completed its combination, or if the lower-level object in the previous-level combination result is inconsistent with the upper-level object of the current jurisdictional chain edge, the propagation gating is closed, and subsequent jurisdictional chain edges will no longer transmit combination results to city entity nodes. City entity nodes with incomplete jurisdictional levels are identified and grouped into the unmerged entity group to prevent incomplete jurisdictional chains from continuing to participate in merging.

[0068] For city entity nodes entering the entity group to be merged, the data source is further converted into source constraints. Taking city entity nodes as units, the data source corresponding to the object code, object name, and coordinate landing point is recorded separately, forming a source constraint relationship between the data source, core attributes, and city entity nodes. Before core attribute aggregation, the administrative jurisdiction chain gating CompGCN first uses chain break markers to shield city entity nodes in the unmerged entity group, and then uses the source constraints to determine whether city entity nodes in the entity group to be merged can participate in the corresponding core attribute aggregation. When the data source satisfies the source constraints of the current core attribute, the city entity node is retained to participate in the aggregation; when the data source does not satisfy the constraints, the city entity node is simply removed from the aggregation object of the current core attribute, without affecting the continued judgment of other core attributes. When there are differences between multiple data sources, data from unsuitable sources is prevented from being directly mixed into the aggregation process of object code, object name, and coordinate landing point.

[0069] Regarding state handling, when a city entity node within a group of entities to be merged obtains its previous state, the allowed previous state is determined based on the state inheritance rules corresponding to the current business state. If the previous state of the city entity node is consistent with the allowed previous state, the real-time perceived state is used as the state content of the city entity node, and the state inheritance verification pass mark is retained. If the two are inconsistent, the inconsistencies between the previous state, the current business state, and the allowed previous state are recorded, and the city entity node is transferred to the unmerged entity group. This avoids the perceived data directly overwriting the original business state, ensuring that the merged city entities have both spatial ownership consistency, source constraint consistency, and state inheritance rationality.

[0070] After the above processing is completed, the city entity nodes in the entity group to be merged enter the digital foundation fusion data update stage, while the city entity nodes in the non-merged entity group retain the reasons for broken link jurisdiction edges, unmet source constraints, or failed status inheritance verification. Administrators can view the specific problems of each non-merged city entity based on the fusion verification results, eliminating the need to repeatedly check for differences between object codes, spatial affiliations, and status records in the original data. This reduces manual verification workload and improves the targeted nature of subsequent corrective processing.

[0071] During the verification process, city data records from the same batch were selected for comparison. Conventional field matching and fusion methods primarily use object encoding, object name, and coordinate similarity as the fusion criteria; the method of this invention adds jurisdictional closure verification, source constraint filtering, and status continuity verification to the same data. The comparison results are shown in Table 1.

[0072] Table 1. Comparison of Data Fusion Effects of District-Level Urban Digital Infrastructure

[0073] As can be seen from Table 1, the method of the present invention improves the entity matching accuracy from 90.8% to 97.6% of the conventional field matching fusion method. This indicates that the present invention no longer relies solely on object encoding, object name, or coordinate proximity for fusion, but combines jurisdictional hierarchy, data source constraints, and status acceptance verification to jointly determine whether city entities can be fused. Therefore, it can reduce false matching caused by objects with the same name, neighboring objects, and cross-grid objects.

[0074] Regarding grid attribution error rate and erroneous merging rate, the method of this invention reduces these to 1.5% and 1.2% respectively, showing improvement compared to conventional field matching fusion methods. This indicates that by judging the hierarchical jurisdiction relationship from administrative district, street, community, grid to city entity node, city entities with incomplete attribution chains or abnormal attribution can be identified before fusion, avoiding the incorrect attachment of objects under different grids to the same entity and reducing the situation of different objects being mistakenly merged.

[0075] The method of this invention reduces the object field conflict rate and state update error rate to 2.4% and 0.9%, respectively, indicating that the source constraint relationship can filter more reliable attribute sources when there are differences in object encoding, object name, and coordinate landing points, preventing data that does not meet the source constraints from directly participating in core attribute aggregation. Simultaneously, the state continuity verification can determine whether the continuity relationship between the previous state and the current business state is met before real-time state perception is written, reducing the possibility of abnormal states overwriting existing city entity states. Overall, this invention can improve the accuracy, consistency, and usability of district-level city digital infrastructure fusion data.

[0076] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A data fusion method for a district-level urban digital infrastructure based on knowledge graphs, characterized in that, Includes the following steps: Access the district-level city digital infrastructure data, perform standardized preprocessing, and obtain city data records; Match jurisdictional level nodes and city entity nodes according to coordinate landing points, incorporate them into the district-level city knowledge graph and connect them to form a jurisdictional chain edge; In the administrative jurisdiction chain gating CompGCN, the jurisdiction chain routing order is set, and the jurisdiction chain edges are combined in the following order: administrative region to street, street to community, community to grid, grid to city entity. When the previous level jurisdiction chain edge is not completed, the subsequent level jurisdiction chain edge is blocked from propagating to the city entity node, thus forming a closed representation of jurisdiction. Based on the jurisdiction closure representation, the broken jurisdiction edge is marked. City entity nodes associated with the broken jurisdiction edge are included in the unmerged entity group, and city entity nodes not associated with the broken jurisdiction edge are included in the entity group to be merged. The data source is converted into a source constraint relationship. In the administrative jurisdiction chain gating CompGCN, the city entity nodes participating in the core attribute aggregation are selected based on the source constraint relationship and the chain break mark. The core attribute aggregation is then performed on the selected city entity nodes. Read the previous state of the city entity nodes in the entity group to be merged, form a state succession relationship based on the current business state, verify the state succession relationship according to the previous state, and write the real-time perception state into the city entity node after the verification is passed. City entity nodes that fail the verification are transferred to the unmerged entity group. The entity groups to be merged that have completed jurisdiction closure, source constraints, and status acceptance will be released as district-level city digital foundation fusion data, and the unmerged entity groups will be organized into fusion verification results.

2. The method for data fusion of a district-level city digital infrastructure based on knowledge graphs according to claim 1, characterized in that, The standardization preprocessing includes the following steps: Map the object name, object code, spatial coordinates, data source, current business status, and real-time perception status in the access data to a unified field; Transform the spatial coordinates to a unified district-level spatial benchmark and extract the coordinate points of the city data records; The current business status and real-time perception status are written to the same city data record according to the collection time, and the correspondence between the data source and the city data record is preserved.

3. The method for data fusion of a district-level city digital infrastructure based on knowledge graphs according to claim 1, characterized in that, The formation of the city entity nodes and the jurisdiction chain edges includes the following steps: A district-level spatial index is constructed based on the coordinate points recorded in the city data to locate the administrative districts corresponding to the coordinate points; Within the administrative region, street boundaries, community boundaries, and grid boundaries are matched sequentially to obtain the street, community, and grid corresponding to the coordinate landing point, and the administrative region, street, community, and grid are determined as the jurisdictional level nodes; Based on urban data records, urban entity nodes are established, and jurisdictional level nodes and urban entity nodes are incorporated into the district-level urban knowledge graph, forming jurisdictional chain edges by connecting them according to hierarchical affiliation.

4. The method for data fusion of a district-level city digital infrastructure based on knowledge graphs according to claim 1, characterized in that, The establishment of the jurisdiction link includes the following steps in sequence: Based on the two ends of the jurisdiction chain connection, the administrative region to street, street to community, community to grid, and grid to city entity node are arranged into a four-level routing order; The administrative jurisdiction chain gating CompGCN follows a four-level routing order, first performing combination on the jurisdiction chain edges from administrative district to street, and then sequentially performing combination on the jurisdiction chain edges from street to community, community to grid, and grid to urban entity node; The combined results of the management chain edges at each level are transmitted to the city entity nodes along the four-level routing sequence.

5. The method for data fusion of a district-level city digital infrastructure based on knowledge graphs according to claim 4, characterized in that, The formation of the jurisdictional closure representation includes the following steps: The CompGCN administrative jurisdiction chain gating system determines the previous level jurisdiction chain edge of the current jurisdiction chain edge to be combined based on the four-level routing order. When the previous level of the jurisdiction chain edge is combined, the propagation gating of the current jurisdiction chain edge to be combined is activated, and vector combination is performed on the two ends of the current jurisdiction chain edge to be combined. When the previous level of jurisdiction chain edge has not been combined, close the propagation gate of the current jurisdiction chain edge to be combined, and block the propagation of the current jurisdiction chain edge to be combined and the next level of jurisdiction chain edge to the city entity node; The combined result that has been completed step by step and has not been blocked by the propagation gating is output as a jurisdictional closure representation.

6. The method for data fusion of a district-level city digital infrastructure based on knowledge graphs according to claim 1, characterized in that, The process of marking the broken chain jurisdiction edge includes the following steps: Based on the incomplete combination states in the jurisdiction closure representation, determine the current jurisdiction chain edge corresponding to the closure of the propagation gating; Mark the current jurisdiction chain edge and the jurisdiction chain edge following the current jurisdiction chain edge as broken jurisdiction edges, and determine the city entity nodes associated with the broken jurisdiction edges; City entity nodes with disconnected jurisdictional edges are classified into the unmerged entity group, and city entity nodes without disconnected jurisdictional edges are classified into the entity group to be merged.

7. The method for data fusion of a district-level city digital infrastructure based on knowledge graphs according to claim 1, characterized in that, The conversion of data sources into source constraint relationships includes the following steps: Extract data source, object code, object name, and coordinate location from city data records, and determine the object code, object name, and coordinate location as core attributes; Based on the core attributes of urban entity nodes, establish the correspondence between data sources and core attributes; The correspondence between data sources and core attributes is encoded as source constraint relationships, which include the corresponding content of data sources, core attributes, and city entity nodes; The source constraint relationship is converted into a relation vector in the administrative jurisdiction chain gating CompGCN, which serves as the relation constraint before the core attribute aggregation.

8. The method for data fusion of a district-level urban digital infrastructure based on knowledge graphs according to claim 7, characterized in that, The core attribute aggregation includes the following steps: Based on the broken chain marker, the city entity nodes in the unmerged entity group are hidden, while the city entity nodes in the entity group to be merged are retained; The administrative jurisdiction chain gating CompGCN matches the retained city entity nodes with the source constraint relationship to determine the city entity nodes participating in the aggregation of each core attribute; When the data source corresponding to a city entity node satisfies the source constraint relationship of the core attribute, the city entity node is retained to participate in the core attribute aggregation. When the data source corresponding to a city entity node does not meet the source constraint relationship of the core attribute, the city entity node is blocked from participating in the core attribute aggregation. For city entity nodes participating in core attribute aggregation, perform object code aggregation, object name aggregation, and coordinate landing point aggregation respectively, and determine the aggregated object code, object name, and coordinate landing point as the core attributes of the city entity node.

9. A data fusion method for a district-level city digital infrastructure based on knowledge graphs according to claim 1, characterized in that, The verification of the state succession relationship includes the following steps: Identify city entity nodes in the entity group to be merged and obtain the previous state corresponding to the city entity node. Based on the state succession rules corresponding to the current business state, determine the previous state that can be succeeded and establish the state succession relationship between the current business state and the previous state that can be succeeded. Compare the previous state corresponding to the city entity node with the previous states that are allowed to be inherited in the state inheritance relationship; When the comparison is consistent, the state inheritance relationship is determined to have passed the verification. The real-time perceived state is used as the state content of the urban entity node, and the state inheritance verification is retained. If the comparison is inconsistent, it is determined that the status inheritance relationship has failed the verification. The reason for the failure of the status inheritance verification is retained, and the corresponding city entity node is transferred to the unmerged entity group.

10. A data fusion method for a district-level city digital infrastructure based on knowledge graphs according to claim 1, characterized in that, The formation of the district-level city digital infrastructure fusion data and fusion verification results includes the following steps: For city entity nodes in the fused entity group, verify the closed representation of jurisdiction, the aggregation results of core attributes corresponding to source constraint relationships, and the status acceptance verification pass mark; When the jurisdiction closure indicates that the core attributes corresponding to the existence and source constraint relationship have been aggregated and the state acceptance verification has passed, the corresponding city entity node will be identified as the district-level city digital foundation fusion data. For city entity nodes in unintegrated entity groups, sort out the reasons for broken chain jurisdiction edges, unmet source constraints, and failed state inheritance verification; The city entity nodes, broken chain jurisdiction edges, unmet source constraints, and reasons for failing the state acceptance verification in the unintegrated entity group are determined as the fusion verification results.

Images