A method for generating an electronic chart incremental update file

Abstract

The present application relates to a kind of electronic chart incremental updating file generation method, belong to marine surveying and mapping technical field, by constructing "EN object record table" to store original data, "ER object record table" records change information, in combination with topological influence diffusion analysis, realize the cascade change identification of point, curve, combination geometry and associated elements.Especially, for complex curve editing, a geometric change detection algorithm based on "node sequence double-pointer matching and tolerance threshold judgment" is designed, which can accurately identify the insertion, deletion and coordinate update operation of nodes, and mark the change type in the ER record table.This method effectively improves the automation, accuracy and traceability of electronic chart updating, and ensures the timeliness of navigation data.

Description

Technical Field

[0001] This invention belongs to the field of marine surveying and mapping technology, and in particular to a method for generating incremental update files for electronic nautical charts. Background Technology

[0002] Electronic navigational charts (ENCs) are core geographic information data for ensuring safe navigation at sea, and their timeliness and accuracy are of paramount importance. The International Hydrographic Organization (IHO) has defined the data model and exchange format for international standard electronic charts, adopting an incremental update architecture of "base dataset (EN) + update set (ER)" to support efficient and secure dynamic maintenance of chart information.

[0003] For the production of electronic nautical chart data, accurately identifying changes and efficiently exporting incremental update files is a technical challenge, mainly facing the following problems: (1) Atomic-level changes need to be identified: For changes in features or spatial geometry, atomic-level changes (such as insertion, deletion, and movement) should be accurately identified. The affected features or geometric objects should not be exported completely to avoid excessively large ER file records.

[0004] (2) Need to quickly identify cascading changes: In addition to considering the objects currently created, edited or deleted, it is also necessary to automatically identify the indirect effects of the current changes (such as other objects with topological relationships) to avoid incomplete or incorrect updates.

[0005] (3) Backtracking and redoing need to be considered: Since editing operations may be backtracked or redone, it is necessary to establish a mapping relationship between the original data copy and the changed state to avoid exporting content without substantial changes to the ER file. Summary of the Invention

[0006] The purpose of this invention is to overcome the shortcomings of the prior art and propose a method for generating incremental update files for electronic nautical charts, which can solve the problems of low change recognition accuracy, slow recognition of cascading changes, and invalid incremental update content in existing incremental updates of electronic nautical charts.

[0007] The technical problem solved by this invention is achieved through the following technical solution: A method for generating incremental update files for electronic nautical charts, characterized in that: Step 1: Construct the basic nautical chart dataset (EN) object record table to store its complete attributes and geometric information, and at the same time construct the update set (ER) object record table to store subsequent change records; Step 2: Initiate the incremental update and editing operation of the electronic chart; trigger the incremental update and editing operation to ensure that subsequent steps execute the incremental operation logic; the objects of incremental update and editing include: geometry and affected features, where geometry includes points, multi-points, curves, composite curves and surfaces, and affected features are other geometric objects and feature objects related to geometry; Step 3: To store the updated geometry and related information of the affected elements after incremental updates, save the updated geometry data to the EN object record table and the ER object record table, and at the same time save the filtered affected elements and their original nautical chart object copies to the ER object record table. Step 4: Compare the updated geometry and its affected elements stored in Step 3 with the original nautical chart object copy to determine the change status of the updated geometry, affected geometry, affected elements, etc. According to the actual change type, mark them as: added, deleted, or updated, and save them to the incremental update data structure. The incremental update data structure fields are defined as follows: (1) The current base dataset version number is used to distinguish the change records of different base datasets.

[0008] (2) Current update set version number, used to distinguish change records of different update set versions under the same base dataset.

[0009] (3) The dataset name of the object being changed, used for quick indexing and querying of the object being changed.

[0010] (4) The unique ID of the object being changed, used for quick indexing and querying of the object being changed.

[0011] (5) The change type of the current object is used to identify and generate specific update record information of the object. If the change type is addition, the complete information of the object is directly inserted into the update set when generating the update set; if the change type is deletion, the record is marked as deleted when generating the update set; if the change type is update, the differences between the current object and the same object in the copy of the base dataset are compared and analyzed when generating the update set.

[0012] Step 5: Before generating and exporting the update file, it is necessary to construct the version number and other metadata of the ER update set, calculate the update set version, the current update object, the metadata of the update set, and the electronic chart incremental update file corresponding to the basic chart dataset, with a maximum of 999 updates. Step 6: Update Set Generation and Export. Extract the update set data from the incremental update data structure, organize it in order (meta-information, newly added status data, updated status data, deleted status data), generate the update set file, and export it to the specified location.

[0013] Moreover, the specific implementation method of step 1 is as follows: load the basic nautical chart dataset, construct the EN object record table, store the complete attributes and geometric information of each electronic nautical chart object with its RCID as the key, and initialize an empty ER object record table to store subsequent change records. The electronic nautical chart object includes geometry, features, information type and association relationship.

[0014] Furthermore, the specific implementation method of step 2 is as follows: before entering the incremental update editing operation of electronic nautical chart, check whether the current nautical chart dataset has been exported as an EN file (i.e., whether a basic nautical chart dataset has been formed). If the condition is not met, proceed to the normal editing operation (i.e., no basic nautical chart dataset has been formed). If the condition is met (i.e., a basic nautical chart dataset has been formed), proceed to the incremental update editing operation. The incremental update editing operation includes geometric editing operation, feature operation, feature attribute operation, etc. If the incremental update editing operation is a geometric editing operation, proceed to the next step. If the incremental update editing operation is a feature operation, feature attribute operation, feature and feature relationship operation, etc., directly record the update information to the ER object record table.

[0015] Furthermore, the specific implementation method of step 3 is as follows: Step 3.1: Save the updated geometric data and simultaneously save it to the EN object record table. Save the geometric unique identifier RCID to the ER object record table as a basis for subsequent comparison. Step 3.2: Based on topological relationships, filter other geometric objects and feature objects affected by this geometric update, including: features that directly reference the geometry, geometric objects that share nodes or boundaries, and related features whose positions have changed due to coordinate offset. Save the unique identifier (RCID) of all affected objects to the ER object record table. Step 3.3: Save copies of each original nautical chart object from Step 3.2 to the ER object record table.

[0016] Furthermore, the specific implementation method of step 4 is as follows: Step 4.1: Geometric change identification. Define coordinate tolerance thresholds, check whether point coordinates have changed, whether curve nodes have been added, deleted, or moved, and record the new coordinates. Step 4.2: Attribute change identification. Determine if the attribute name exists. If it does not exist, it is a newly added attribute. If it exists, compare the values. If they are inconsistent, mark it as an update. If the changed attribute is a multi-attribute object record, manage it by repeating the attribute with the same name and a certain value. Step 4.3: Element change identification. Take the current element RCID from the ER object record table and check if the RCID exists in the EN object record table. If it does not exist, mark the element as deleted. If it exists, continue with the subsequent judgment. Check if there is a copy record of the original nautical chart element object. If it exists, mark it as updated. If it does not exist, mark it as added.

[0017] During electronic chart editing, a curve object undergoes a series of geometric operations, such as moving a node, inserting a new node between two nodes, moving the newly inserted node again, or even deleting an existing node. After these operations are completed, the system needs to automatically determine what atomic changes have occurred in the final state relative to the original state, such as "node A coordinates updated" or "node D inserted between nodes B and C," so as to accurately record the change semantics in the ER record table.

[0018] To address the inaccurate change identification problem in existing electronic chart editing systems under complex geometric operations, this invention proposes a spatial curve geometric change detection method based on a combination of hash identifier matching and dual-pointer traversal. This method can accurately identify atomic-level operations performed by the user on curve nodes, such as "insertion," "deletion," and "coordinate update," and generate change records with clear semantics.

[0019] Algorithm input: The input to this algorithm mainly includes two sets of spatial geometric data: the original geometry Geo1 and the edited geometry Geo2. The original geometry Geo1 originates from the basic nautical chart data stored in the EN object record table, and contains an ordered sequence of nodes P = [p1, p2, ..., p...]. n Each node includes its spatial coordinates (x, y) and the ID of its parent object (such as the RCID of a curve object). The edited geometry Geo2 is the final state formed after the user completes a series of editing operations, containing another ordered sequence of nodes Q = [q1, q2, ..., q...]. m Each node also possesses coordinates and parent object ID information. Furthermore, the hash generation rule typically uses a combination of "parent object ID + spatial coordinates" to generate a unique hash value, ensuring that each node's identity can be uniquely identified.

[0020] Algorithm output: The algorithm outputs a structured list of changes, describing all node-level changes that occurred from Geo1 to Geo2. Each change record includes the change type (addition, deletion, update), coordinates before and after the change, corresponding hash value, position index in the original or new geometry, and specific location reference information for insertion or deletion.

[0021] Algorithm steps: (1) Initialization and preprocessing.

[0022] First, all nodes of the original curve P and the edited curve Q are standardized. ① All coordinates are projected to the same coordinate system and rounded to six decimal places to eliminate minor deviations caused by floating-point calculations. Then, a unique hash value is generated for each node using the formula: hash = hash(parent_id || x || y). ② Based on this, two hash mapping sets are constructed: H_P stores the correspondence between the hash value of the original node and its index in the sequence; H_Q stores the corresponding information of the edited node. This process achieves "identity binding" for each node, laying the foundation for subsequent precise matching.

[0023] (2) Initial identification of changes via dual-pointer traversal. ① A dual-pointer mechanism is used, pointing to the starting positions of the original sequence P and the edited sequence Q respectively, and traversing the two sequences synchronously from left to right. When the hash values ​​of the nodes pointed to by the two pointers are the same, they are considered to be the same node, and their coordinate differences are further compared: if the distance is less than the preset tolerance ε, it is marked as "unchanged"; otherwise, it is judged as "updated", and its coordinate change information is recorded. If the hash values ​​are different but the coordinates are close (still within the tolerance range), it is regarded as a slight adjustment caused by a slight drag, and is still classified as "updated". ② For cases where the hash value and coordinates do not match, the system further judges whether there is an insertion or deletion behavior: if the hash of the next node of the current node in the Q sequence is consistent with the hash of the current node in the P sequence, it indicates that there is an extra node in Q, which belongs to the "insertion" operation; conversely, if the hash of the next node in the P sequence is consistent with the hash of the current node in Q, it indicates that there is a redundant node in P, which should be marked as "deleted". Through this logic, the system can effectively identify local addition and deletion behaviors while maintaining the consistency of the order.

[0024] (3) Processing remaining nodes. After the main loop ends, there may still be some nodes in a sequence that have not been matched. If there are still nodes in the original sequence P that have not participated in the matching, it means that these nodes have been removed during the editing process, and the system marks them all as "deleted"; if there are still unmatched nodes in the edited sequence Q, it means that they are nodes added in this editing, and the system marks them all as "added". This step ensures that all changes are fully captured and avoids omissions.

[0025] (4) Insertion Point Location Restoration and Topological Consistency Analysis. For the identified "inserted" node, the system needs to further determine its relative position in the original geometry in order to generate change semantics with clear topological significance. Specifically, the system finds the adjacent nodes before and after the insertion point in the edited geometry and obtains their hash values ​​in the original geometry. By locating the positions of these neighbors in the original node sequence, it infers which two original nodes the insertion point should be located between. For example, if the new node is located between original nodes A and B, a semantic record of "inserted after node A" is generated. If a complete neighbor chain cannot be found, the insertion is determined to be at the end or the beginning based on the sequence order. This mechanism ensures that even after multiple edits, the system can still accurately restore the context in which the change occurred.

[0026] For example, in one editing operation, the original curve contained six nodes (hash1 to hash6). The user performed operations such as moving node 3, deleting node 4, inserting a new node ④ between nodes 3 and 5, and inserting node ⑦ after node 6. The system accurately identified the coordinate update of node 3, the deletion of node 4, and the insertion of nodes ④ and ⑦ through hash matching, and correctly restored their insertion positions by combining the adjacency relationship, which fully conformed to the logic of the diagram, proving the effectiveness and practicality of this method.

[0027] Furthermore, the specific implementation method of step 5 is as follows: ER update set file release and version and other metadata management. Before releasing the ER update set file, verify the metadata of the ER file, including: version, file suffix, dataset version, release time, producer, dataset summary. If the ER update set file is newly released, the version number is generated by adding 1 to the DSID.DSED field value in the EN dataset metadata, and the file suffix is ​​.001 to .999; if it is re-released, the version number remains unchanged.

[0028] Furthermore, the specific implementation method of step 6 is as follows: Step 6.1: Generate metadata data fragments based on the content of Step 5, and generate update set data fragments based on the content of Step 4. The update set data fragments are organized in the following order from top to bottom: new status data, updated status data, and deleted status data.

[0029] Step 6.2: Generate the complete update set in the order of "metadata first, update set data second" and export it as an ER update set file.

[0030] The advantages and positive effects of this invention are: This invention constructs an "EN object record table" to store raw data and an "ER object record table" to record change information. Combined with topological impact diffusion analysis, it enables the identification of cascading changes to points, curves, combined geometry, and related elements. Specifically, for complex curve editing, a geometric change detection algorithm based on "node sequence dual-pointer matching and tolerance threshold judgment" is designed. This algorithm can accurately identify node insertion, deletion, and coordinate update operations and mark the change type in the ER record table. This method effectively improves the automation, accuracy, and traceability of electronic chart updates, ensuring the safety and timeliness of nautical data. Attached Figure Description

[0031] Figure 1 This is a schematic diagram illustrating the principle of updating set generation in this invention; Figure 2 This is a flowchart illustrating the overall process of incremental updating of electronic nautical charts in this invention. Figure 3 This is a flowchart illustrating the editing operation change judgment process of this invention; Figure 4 This is a schematic diagram of the spatial curve geometric change detection method based on hash identifier matching and dual-pointer traversal of the present invention. Figure 5 This is a schematic diagram of the basic nautical chart dataset object of this invention; Figure 6 This is a schematic diagram of the object nodes and their numbers in the basic nautical chart dataset of this invention; Figure 7 This is a schematic diagram of the incremental update and editing object nodes and their numbers in this invention; Figure 8 This is a schematic diagram of the ER update set file of the present invention; Figure 9 This is a schematic diagram illustrating the export of the update set 001 file of this invention; Figure 10 This is a schematic diagram of the EN and ER files generated by this invention; Figure 11 This is a schematic diagram illustrating the use of third-party nautical chart software to verify EN files in this invention; Figure 12 This is a schematic diagram of the ER file exported using third-party nautical chart software in this invention. Detailed Implementation

[0032] A method for generating incremental update files for electronic nautical charts, characterized in that: Step 1: Construct the basic nautical chart dataset (EN) object record table to store its complete attributes and geometric information, and at the same time construct the update set (ER) object record table to store subsequent change records.

[0033] Load the basic nautical chart dataset, construct the EN object record table, store the complete attributes and geometric information of each electronic nautical chart object with its RCID as the key, and initialize an empty ER object record table to store subsequent change records. Electronic nautical chart objects include geometry, features, information types and relationships.

[0034] Step 2: Initiate the incremental update and editing operation of the electronic chart; trigger the incremental update and editing operation to ensure that subsequent steps execute the incremental operation logic; the objects of incremental update and editing include: geometry and affected features, where geometry includes points, multi-points, curves, composite curves and surfaces, and affected features are other geometric objects and feature objects related to geometry.

[0035] Before entering the incremental update editing operation of electronic nautical charts, it is verified whether the current nautical chart dataset has been exported as an EN file (i.e., whether a basic nautical chart dataset has been formed). If the condition is not met, the normal editing operation is entered (i.e., no basic nautical chart dataset has been formed). If the condition is met (i.e., a basic nautical chart dataset has been formed), the incremental update editing operation is entered. The incremental update editing operation includes geometric editing operation, feature operation, feature attribute operation, etc. If the incremental update editing operation is a geometric editing operation, the next step is taken. If the incremental update editing operation is a feature operation, feature attribute operation, feature and feature relationship operation, the update information is directly recorded to the ER object record table.

[0036] Step 3: To store the updated geometry and related information of the affected elements after incremental updates, save the updated geometry data to the EN object record table and the ER object record table, and at the same time save the filtered affected elements and their original nautical chart object copies to the ER object record table.

[0037] Step 3.1: Save the updated geometric data and simultaneously save it to the EN object record table. Save the geometric unique identifier RCID to the ER object record table as a basis for subsequent comparison. Step 3.2: Based on topological relationships, filter other geometric objects and feature objects affected by this geometric update, including: features that directly reference the geometry, geometric objects that share nodes or boundaries, and related features whose positions have changed due to coordinate offset. Save the unique identifier (RCID) of all affected objects to the ER object record table. Step 3.3: Save copies of each original nautical chart object from Step 3.2 to the ER object record table.

[0038] Step 4: Compare the updated geometry and its affected elements stored in Step 3 with the original nautical chart object copy to determine the change status of the updated geometry, affected geometry, affected elements, etc. Mark them as: added, deleted, or updated according to the actual change type, and save them to the incremental update data structure.

[0039] The incremental update data structure fields are defined as follows: (1) The current base dataset version number is used to distinguish the change records of different base datasets.

[0040] (2) Current update set version number, used to distinguish change records of different update set versions under the same base dataset.

[0041] (3) The dataset name of the object being changed, used for quick indexing and querying of the object being changed.

[0042] (4) The unique ID of the object being changed, used for quick indexing and querying of the object being changed.

[0043] (5) The change type of the current object is used to identify and generate specific update record information of the object. If the change type is addition, the complete information of the object is directly inserted into the update set when generating the update set; if the change type is deletion, the record is marked as deleted when generating the update set; if the change type is update, the differences between the current object and the same object in the copy of the base dataset are compared and analyzed when generating the update set.

[0044] This step includes the following steps: Step 4.1: Geometric change identification. Define coordinate tolerance thresholds, check whether point coordinates have changed, whether curve nodes have been added, deleted, or moved, and record the new coordinates. Step 4.2: Attribute change identification. Determine if the attribute name exists. If it does not exist, it is a newly added attribute. If it exists, compare the values. If they are inconsistent, mark it as an update. If the changed attribute is a multi-attribute object record, manage it by repeating the attribute with the same name and a certain value. Step 4.3: Element change identification. Take the current element RCID from the ER object record table and check if the RCID exists in the EN object record table. If it does not exist, mark the element as deleted. If it exists, continue with the subsequent judgment. Check if there is a copy record of the original nautical chart element object. If it exists, mark it as updated. If it does not exist, mark it as added.

[0045] During electronic chart editing, a curve object undergoes a series of geometric operations, such as moving a node, inserting a new node between two nodes, moving the newly inserted node again, or even deleting an existing node. After these operations are completed, the system needs to automatically determine what atomic changes have occurred in the final state relative to the original state, such as "node A coordinates updated" or "node D inserted between nodes B and C," so as to accurately record the change semantics in the ER record table.

[0046] To address the inaccurate change identification problem in existing electronic chart editing systems under complex geometric operations, this invention proposes a spatial curve geometric change detection method based on a combination of hash identifier matching and dual-pointer traversal. This method can accurately identify atomic-level operations performed by the user on curve nodes, such as "insertion," "deletion," and "coordinate update," and generate change records with clear semantics.

[0047] Algorithm input: The input to this algorithm mainly includes two sets of spatial geometric data: the original geometry Geo1 and the edited geometry Geo2. The original geometry Geo1 originates from the basic nautical chart data stored in the EN object record table, and contains an ordered sequence of nodes P = [p1, p2, ..., p...]. n Each node includes its spatial coordinates (x, y) and the ID of its parent object (such as the RCID of a curve object). The edited geometry Geo2 is the final state formed after the user completes a series of editing operations, containing another ordered sequence of nodes Q = [q1, q2, ..., q...]. m Each node also possesses coordinates and parent object ID information. Furthermore, the hash generation rule typically uses a combination of "parent object ID + spatial coordinates" to generate a unique hash value, ensuring that each node's identity can be uniquely identified.

[0048] Algorithm output: The algorithm outputs a structured list of changes, describing all node-level changes that occurred from Geo1 to Geo2. Each change record includes the change type (addition, deletion, update), coordinates before and after the change, corresponding hash value, position index in the original or new geometry, and specific location reference information for insertion or deletion.

[0049] Algorithm steps: (1) Initialization and preprocessing.

[0050] First, all nodes of the original curve P and the edited curve Q are standardized. ① All coordinates are projected to the same coordinate system and rounded to six decimal places to eliminate minor deviations caused by floating-point calculations. Then, a unique hash value is generated for each node using the formula: hash = hash(parent_id || x || y). ② Based on this, two hash mapping sets are constructed: H_P stores the correspondence between the hash value of the original node and its index in the sequence; H_Q stores the corresponding information of the edited node. This process achieves "identity binding" for each node, laying the foundation for subsequent precise matching.

[0051] (2) Initial identification of changes via dual-pointer traversal. ① A dual-pointer mechanism is used, pointing to the starting positions of the original sequence P and the edited sequence Q respectively, and traversing the two sequences synchronously from left to right. When the hash values ​​of the nodes pointed to by the two pointers are the same, they are considered to be the same node, and their coordinate differences are further compared: if the distance is less than the preset tolerance ε, it is marked as "unchanged"; otherwise, it is judged as "updated", and its coordinate change information is recorded. If the hash values ​​are different but the coordinates are close (still within the tolerance range), it is regarded as a slight adjustment caused by a slight drag, and is still classified as "updated". ② For cases where the hash value and coordinates do not match, the system further judges whether there is an insertion or deletion behavior: if the hash of the next node of the current node in the Q sequence is consistent with the hash of the current node in the P sequence, it indicates that there is an extra node in Q, which belongs to the "insertion" operation; conversely, if the hash of the next node in the P sequence is consistent with the hash of the current node in Q, it indicates that there is a redundant node in P, which should be marked as "deleted". Through this logic, the system can effectively identify local addition and deletion behaviors while maintaining the consistency of the order.

[0052] (3) Processing remaining nodes. After the main loop ends, there may still be some nodes in a sequence that have not been matched. If there are still nodes in the original sequence P that have not participated in the matching, it means that these nodes have been removed during the editing process, and the system marks them all as "deleted"; if there are still unmatched nodes in the edited sequence Q, it means that they are nodes added in this editing, and the system marks them all as "added". This step ensures that all changes are fully captured and avoids omissions.

[0053] (5) Insertion Point Location Restoration and Topological Consistency Analysis. For the identified "inserted" node, the system needs to further determine its relative position in the original geometry in order to generate change semantics with clear topological significance. Specifically, the system finds the adjacent nodes before and after the insertion point in the edited geometry and obtains their hash values ​​in the original geometry. By locating the positions of these neighbors in the original node sequence, it infers which two original nodes the insertion point should be located between. For example, if the new node is located between original nodes A and B, a semantic record of "inserted after node A" is generated. If a complete neighbor chain cannot be found, the insertion is determined to be at the end or the beginning based on the sequence order. This mechanism ensures that even after multiple edits, the system can still accurately restore the context in which the change occurred.

[0054] For example, in one editing operation, the original curve contained six nodes (hash1 to hash6). The user performed operations such as moving node 3, deleting node 4, inserting a new node ④ between nodes 3 and 5, and inserting node ⑦ after node 6. The system accurately identified the coordinate update of node 3, the deletion of node 4, and the insertion of nodes ④ and ⑦ through hash matching, and correctly restored their insertion positions by combining the adjacency relationship, which fully conformed to the logic of the diagram, proving the effectiveness and practicality of this method.

[0055] Step 5: Before generating and exporting the update file, it is necessary to construct the version number and other metadata of the ER update set, calculate the update set version, the current update object, the metadata of the update set, and the electronic chart incremental update file corresponding to the basic chart dataset, with a maximum of 999 updates.

[0056] The management of metadata such as the release and version of ER update set files involves verifying the metadata of the ER file before release, including: version, file extension, dataset version, release time, producer, and dataset summary. If the ER update set file is newly released, the version number is generated by adding 1 to the value of the DSID.DSED field in the EN dataset metadata, and the file extension is .001 to .999. If it is a re-release, the version number remains unchanged.

[0057] Step 6: Update Set Generation and Export. Extract the update set data from the incremental update data structure, organize it in order (meta-information, newly added status data, updated status data, deleted status data), generate the update set file, and export it to the specified location.

[0058] Step 6.1: Generate metadata data fragments based on the content of Step 5, and generate update set data fragments based on the content of Step 4. The update set data fragments are organized in the following order from top to bottom: new status data, updated status data, and deleted status data.

[0059] Step 6.2: Generate the complete update set in the order of "metadata first, update set data second" and export it as an ER update set file.

[0060] The effects of this invention will be illustrated by taking a road in a land area as an example.

[0061] A method for generating incremental update files for electronic nautical charts, such as Figures 1 to 4 As shown, the nodes of this road are modified, deleted, and inserted, and the updated set is exported. The specific steps are as follows: Step 1: Construct the incremental update data structure.

[0062] like Figure 5 As shown, the 101C100000000.000 basic dataset is loaded, an EN object record table is constructed, and an empty ER object record table is initialized. The unique identifier for road features is RCID=3, and the unique identifier for curves associated with features is RCID=4.

[0063] Step 2: Start the incremental update and editing operation of the electronic chart.

[0064] like Figure 6As shown, the original road element consists of 8 coordinate nodes, numbered 1 to 8 respectively. Now, move node 3 upwards, delete node 4, insert node 9 between nodes 3 and 5, and finally insert node 10 between nodes 6 and 7. The other numbered nodes remain unchanged.

[0065] like Figure 7 As shown, after editing begins, a unique ID is assigned to all nodes of the curve that constitute the current editing path in the original dataset copy and the working dataset. That is, nodes 1 to 8 correspond to unique ID values ​​hash1 to hash8 respectively. After moving node 3, its unique ID remains unchanged, only its coordinate value changes. After deleting node 4, hash4 is deleted simultaneously. Then, node 9 with the unique ID hash9 is inserted. Finally, node 10 with the unique ID hash10 is inserted between nodes 6 and 7.

[0066] Step 3: Save the updated geometry and filter the affected features.

[0067] In this example, the updated curve unique identifier remains unchanged at RCID=4, and the affected feature is the road feature with RCID=3. No other geometry is affected.

[0068] Step 4: Compare with the original electronic nautical chart object.

[0069] The modification, deletion, and insertion status of curve nodes are determined by comparing the unique IDs and coordinate values ​​of the nodes constituting the currently edited road curve in the ER object dataset with the original dataset copy. Whether the coordinate values ​​have changed is judged by setting a threshold. In this case, the nodes of the currently edited curve are traversed sequentially. By comparison, it is found that the unique IDs and coordinates of nodes 1 and 2 have not changed, the coordinate value of node 3 has changed, node 4 has been deleted, and the unique IDs and coordinates of node 5 have not changed. Therefore, it can be determined that node 3 has been modified, node 4 has been deleted, and a node with the unique ID hash9 has been added. Continuing to traverse and compare, it is found that nodes 6, 7, and 8 have not changed, but between nodes 6 and 7, there is an additional node with the unique ID hash10 compared to the original backup dataset.

[0070] In summary, the update set adds modification records for node 3, deletion records for node 4, and new records for nodes 9 and 10. The records include the node's offset index and coordinate values ​​(not required for deletion operations).

[0071] Step 5: Construct the version number and other metadata of the ER update set.

[0072] like Figure 8 As shown, in this example, a new version of the ER update set file is published with the suffix .001. The complete update set file name is 101C100000000.001.

[0073] Step 6: Update set generation and export.

[0074] ① Generate node 3 (update) structure: ② Generate the structure of node 4 (delete): ③ Generate node 9 (new addition) structure: ④ Generate the structure of node 10 (new addition): ⑤ For example Figures 9 to 12 As shown, export the update set file 101C100000000.001, which is used in combination with the base dataset file 101C100000000.000.

[0075] It should be emphasized that the embodiments described in this invention are illustrative rather than limiting. Therefore, this invention includes, but is not limited to, the embodiments described in the specific implementation. Any other implementations derived by those skilled in the art based on the technical solutions of this invention are also within the scope of protection of this invention.

Claims

1. A method for generating incremental update files for electronic nautical charts, characterized in that: Includes the following steps: Step 1: Construct the EN object record table of the basic nautical chart dataset to store its complete attributes and geometric information, and at the same time construct the ER object record table of the update set to store subsequent change records; Step 2: Initiate the incremental update and editing operation of the electronic nautical chart; Trigger the incremental update and edit operation to ensure that subsequent steps execute the incremental operation logic; The objects edited by incremental updates include geometry and affected features. Geometry includes points, multipoints, curves, composite curves, and surfaces. Affected features are other geometric objects and feature objects associated with the geometry. Step 3: To store the updated geometry and related information of the affected features after incremental updates, save the updated geometry data to the EN object record table and the ER object record table, and at the same time save the filtered affected features and their original nautical chart object copies to the ER object record table. Step 4: Compare the updated geometry and affected features stored in Step 3 with the original nautical chart object copy to determine the change status of the updated geometry, affected geometry, affected features, etc. According to the actual change type, mark them as: added, deleted, or updated, and save them to the incremental update data structure. Step 5: Before generating and exporting the update file, construct the version number and other metadata of the ER update set, calculate the update set version, the current update object, the metadata of the update set, and the electronic chart incremental update file corresponding to the basic chart dataset, with a maximum of 999 updates. Step 6: Extract update set data from the incremental update data structure and organize it in order, including metadata, newly added status data, updated status data and deleted status data, and generate an update set file, which is then exported to a specified location.

2. The method for generating incremental update files for electronic nautical charts according to claim 1, characterized in that: The specific implementation method of step 1 is as follows: load the basic nautical chart dataset, construct the EN object record table, store the complete attributes and geometric information of each electronic nautical chart object with its RCID as the key, and initialize an empty ER object record table to receive subsequent change records. The electronic nautical chart object includes geometry, features, information type and association relationship.

3. The method for generating incremental update files for electronic nautical charts according to claim 1, characterized in that: The specific implementation method of step 2 is as follows: Before entering the incremental update editing operation of the electronic nautical chart, check whether the current nautical chart dataset has been exported as an EN file. If the condition is not met, enter the normal editing operation. If the condition is met, enter the incremental update editing operation. The incremental update editing operation includes geometric editing operation, feature operation, feature attribute operation, etc. If the incremental update editing operation is a geometric editing operation, proceed to the next step. If the incremental update editing operation is a feature operation, feature attribute operation, feature and feature relationship operation, etc., directly record the update information to the ER object record table.

4. The method for generating incremental update files for electronic nautical charts according to claim 1, characterized in that: The specific implementation method of step 3 is as follows: Step 3.1: Save the updated geometric data and simultaneously save it to the EN object record table. Save the geometric unique identifier RCID to the ER object record table as a basis for subsequent comparison. Step 3.2: Based on topological relationships, filter other geometric objects and feature objects affected by this geometric update, including: features that directly reference the geometry, geometric objects that share nodes or boundaries, and related features whose positions have changed due to coordinate offset. Save the unique identifier (RCID) of all affected objects to the ER object record table. Step 3.3: Save copies of each original nautical chart object from Step 3.2 to the ER object record table.

5. The method for generating incremental update files for electronic nautical charts according to claim 1, characterized in that: The specific implementation method of step 4 is as follows: Step 4.1: Geometric change identification. Define coordinate tolerance thresholds, check whether point coordinates have changed, whether curve nodes have been added, deleted, or moved, and record the new coordinates. Step 4.2: Attribute change identification. Determine if the attribute name exists. If it does not exist, it is a newly added attribute. If it exists, compare the values. If they are inconsistent, mark it as an update. If the changed attribute is a multi-attribute object record, manage it by repeating the attribute with the same name and a certain value. Step 4.3: Element change identification. Take the current element RCID from the ER object record table and check if the RCID exists in the EN object record table. If it does not exist, mark the element as deleted. If it exists, continue with the subsequent judgment. Check if there is a copy record of the original nautical chart element object. If it exists, mark it as updated. If it does not exist, mark it as added.

6. The method for generating incremental update files for electronic nautical charts according to claim 1, characterized in that: The specific implementation method of step 5 is as follows: Before publishing the ER update set file, verify the metadata of the ER file, including: version, file suffix, dataset version, publication time, producer, and dataset summary. If the ER update set file is newly published, the version number is generated by adding 1 to the value of the DSID.DSED field in the EN dataset metadata, and the file suffix is ​​.001 to .999; if it is republished, the version number remains unchanged.

7. The method for generating incremental update files for electronic nautical charts according to claim 1, characterized in that: The specific implementation method of step 6 is as follows: Step 6.1: Generate metadata data fragments based on the content of Step 5, and generate update set data fragments based on the content of Step 4. The update set data fragments are organized in the following order from top to bottom: new status data, updated status data, and deleted status data. Step 6.2: Generate the complete update set in the order of "metadata first, update set data second" and export it as an ER update set file.

Images