A two-dimensional map annotation collaborative editing method based on geometric perception

Abstract

The application provides a two-dimensional map label collaborative editing method based on geometric perception, and a time and space information fusion architecture of the map label is constructed by introducing a geometric vector clock and a minimum bounding rectangle. The method improves the merging efficiency of the visual node operation in a large-scale node scene by means of an operation merging and layering mechanism, reduces the semantic loss of the translation operation by topological anomaly detection and spatio-temporal joint operation merging, realizes automatic error correction of most topological errors, and improves the accuracy of two-dimensional map collaborative editing.

Description

Technical Field

[0001] This invention belongs to the field of collaborative editing algorithm technology, specifically relating to a collaborative editing method for two-dimensional map annotation based on geometric perception. Background Technology

[0002] In the field of distributed geographic information collaborative editing, scenarios such as disaster emergency response and crowdsourced maps place extremely high demands on the real-time collaborative capabilities of map annotation. However, current collaborative editing methods for 2D map annotation generally suffer from weak collaborative capabilities, especially when dealing with editing conflicts in distributed environments, which present significant challenges.

[0003] Traditional collaborative editing algorithms based on Conflict-Free Copy Data Type (CRDT) are primarily geared towards text editing. Their design logic aligns with text insertion and deletion operations, but fails to deeply integrate with the geometric features of map elements. While CRDT-based collaborative algorithms like RGA and YATA can achieve eventual consistency when directly applied to geographic information collaborative editing, these algorithms only consider the temporal information of the operation sequence, lacking utilization of spatial information such as geometric semantics (e.g., point coordinates) in map annotations. This results in an inability to accurately perceive geometric semantic differences when processing operations like map element translation and vertex movement, easily leading to semantic loss such as translation operations being overwritten. Furthermore, the lack of spatial information also prevents the use of node visibility to differentiate node update priorities during updates, thus causing performance bottlenecks. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention proposes a geometrically perceptive-based collaborative editing method for two-dimensional map annotations, thereby solving the problem of weak collaborative capabilities in two-dimensional map annotation collaborative editing methods.

[0005] The present invention achieves the above-mentioned technical objectives through the following technical means.

[0006] A geometry-aware collaborative editing method for 2D map annotation:

[0007] Map annotation objects are divided into point nodes and line nodes. Point nodes represent point elements in the map, non-closed line nodes represent line elements in the map, and closed line nodes represent polygon elements in the map.

[0008] During the merge operation, the following geometric topology check is performed: For closed line nodes, check whether the polygon enclosed by their vertices is a simple polygon. If yes, the corresponding operation is a valid operation; otherwise, the corresponding operation is an illegal operation.

[0009] Furthermore,

[0010] Each node maintains a V-Clock, which includes a device ID and a counter. The device ID is taken from the device ID of the terminal that created the node. The counter starts from an initial value after the node is created and increments by 1 after each operation.

[0011] For operations other than creation, V-Clock is maintained, where: the device ID is the device ID of the terminal that issued the operation; and the counter value is the target node's counter value + 1.

[0012] Furthermore, for the vertex insertion operation of the line node, the operations are sorted according to their V-Clock size, and the operations with smaller V-Clocks are merged first.

[0013] Furthermore, for operations merged based on V-Clock size sorting, if the geometric topology check finds it invalid, the following geometric topology correction is performed:

[0014] S1, using the geoHash value of each vertex, and based on the prefix matching characteristic of geoHash, calculate the spatial matching degree S between each successor vertex and the target vertex;

[0015] S2, sort according to the size of spatial matching degree S, and merge operations with larger spatial matching degree S first.

[0016] Furthermore, the spatial matching degree S is the length of the common geoHash prefix of both the successor vertex and the target vertex.

[0017] Furthermore, based on whether the MBR involved in the operation intersects with the MBR of the terminal window, it is determined whether the operation is visible, where intersection indicates visibility;

[0018] The MBR involved in the operation is the MBR before and after the operation on the target node. The MBR of the window is defined according to the map area displayed in the window. The MBR is the smallest rectangle that can cover the node or the map area.

[0019] For visual operations, merge them first.

[0020] Furthermore,

[0021] The length and width of the MBR are parallel to the map coordinate axes;

[0022] The MBR of a point node is its own coordinate range;

[0023] The MBR of a line node is the extreme range of all vertex coordinates.

[0024] Furthermore, for translation operations of vertices in point nodes or line nodes, the operation instruction records the coordinate offset of the point, and translates the target point node or vertex according to the coordinate offset.

[0025] Furthermore, the method for determining the simple polygon is as follows:

[0026] Check if any two sides intersect, for any two line segments AB and CD:

[0027] Take the MBR of line segment AB and line segment CD respectively, and determine whether the MBR values ​​of the two overlap in the range of the map x-axis and y-axis. If not, the two line segments do not intersect.

[0028] Calculate the cross product of vectors AB and AC (cross1), AB and AD (cross2), CD and CA (cross3), and CD and CB (cross4), and determine whether the line segments intersect based on the geometric meaning of the vector cross product.

[0029] If no two sides intersect, it is a simple polygon.

[0030] Furthermore, the geometric topology check also includes a vertex count check. If the number of vertices in a line node is greater than or equal to 2, the corresponding operation is a valid operation; otherwise, it is an invalid operation.

[0031] Furthermore, line nodes found to have engaged in illegal operations are marked.

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

[0033] (1) This invention provides a two-dimensional map annotation collaborative editing method based on geometric perception. Through the topological anomaly detection and spatiotemporal joint operation merging mechanism, it achieves automatic repair of 70.8% of node topological errors.

[0034] (2) For translation operations, the present invention records the coordinate offset of the point in the operation instruction. Compared with directly recording the coordinate position after translation, the present invention can retain all client operations by means of geometric vector merging rules, which greatly reduces the loss of operation semantics.

[0035] (3) The present invention optimizes the collaborative efficiency of large-scale nodes based on the MBR-based merging operation hierarchical mechanism. When the node scale is 10,000, the update latency of visible nodes is 315ms, which is 45% lower than YATA, and the latency of non-visual nodes is 287ms, which is only 16% higher, which can effectively improve the user experience. Attached Figure Description

[0036] Figure 1 This is the UML class diagram for this invention;

[0037] Figure 2 This is a flowchart illustrating the collaborative editing method for two-dimensional map annotations of the present invention.

[0038] Figure 3This is a schematic diagram of the visible window and visible node in this invention;

[0039] Figure 4 This is a diagram illustrating the legality of line node operations;

[0040] Figure 5 This is a schematic diagram showing the intersection of edges in a line node;

[0041] Figure 6 This is a schematic diagram of geometric topology error correction during vertex insertion operation merging in this invention;

[0042] Figure 7 The test case shows the merged delay curve for visual node operations;

[0043] Figure 8 The test case shows the combined delay curve for non-visual node operations. Detailed Implementation

[0044] The embodiments of the present invention are described in detail below. Examples of the embodiments are shown in the accompanying drawings. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, but should not be construed as limiting the present invention.

[0045] This embodiment proposes a conflict-free collaborative editing method that integrates Geometric Vector Clock (GVC) and Minimum Bounding Rectangle (MBR), including:

[0046] I. Geometric Semantic Modeling

[0047] Reference Figure 1 The UML (Unified Modeling Language) diagram shown illustrates how this invention abstracts map annotation objects into two categories: "point nodes" and "line nodes." Both inherit information data from the geographic node class, where:

[0048] 1. A geographic node is a point on a map. Its information data records include: a unique identifier (UUID), a geometric vector clock (GVC), a minimum bounding rectangle (MBR), and operation information for that geographic node, such as whether the node has a topology error, whether the node should be deleted, and the operation list for that node.

[0049] 1) Geometric Vector Clock (GVC): Includes Virtual Clock (V-Clock) and GeoHash:

[0050] 1.1) V-Clock is a Lamport clock, which consists of the device ID and counter of the terminal (i.e., a user terminal or client in the distributed map annotation collaborative editing system); the device ID is a unique identification code assigned when the terminal comes online; the counter starts counting from 0.

[0051] Two V-Clocks can be compared in the following way: First, compare the counter values ​​of the two, and the V-Clock with the larger local counter is larger; if the local counters are equal, then compare the device IDs of the two, and the V-Clock with the larger device ID is larger.

[0052] This invention maintains a V-Clock value for each node and each operation (i.e., map annotation operation).

[0053] 1.2) GeoHash is a geocoding proposed by Gustavo Niemeyer, which uses related algorithms to transform the geographical coordinates of a point into a string of hash values.

[0054] 2) MBR: The smallest rectangle that can cover a labeled object or a certain area in the map, and the length and width of the rectangle are parallel to the coordinate axes.

[0055] MBR can be denoted as (x1,y1)×(x2,y2); where (x1,y1) and (x2,y2) are the two diagonal coordinates of MBR, that is, in a typical plane coordinate system (x-axis increases to the right, y-axis increases upward), (x1,y1) is the coordinate of the lower left corner of MBR, and (x2,y2) is the coordinate of the upper right corner of MBR.

[0056] 2. Point Node: Represents a point on the map, recording the coordinates (x, y) of that point;

[0057] 1) The MBR of a point node is its own coordinate range (x,y)×(x,y).

[0058] 2) In the V-Clock of the point node:

[0059] 2.1) Device ID, which is the device ID of the terminal that created this node;

[0060] 2.2) Counter: The initial value of the node is 0 after it is created, and it is incremented by 1 after each operation.

[0061] 3. LineNode: Stores a list of vertices and information on whether the vertex is closed (corresponding to the isPath field in the graph).

[0062] 1) The vertex list stores information about all vertices that make up the line segment, as well as the target vertex information of each vertex (corresponding to the origin field in the diagram). In this embodiment, the target vertex information is the unique identifier (UUID) of the geographic node. For example, if vertex B is inserted after vertex A, then vertex A is the target vertex of vertex B, vertex B is the successor vertex of vertex A, and the origin field of vertex B records the UUID of vertex A.

[0063] 2) The isPath field records a Boolean value to distinguish whether the line segment (of the line node) is closed or not; where a Boolean value of "true" represents a closed line node, which represents a face in the map, and a Boolean value of "false" represents an open line node, which represents a line in the map.

[0064] 3) The MBR of a line node is the extreme range of all vertex coordinates (x... min ,y min )×(x max ,y max ), where x min and x max x n Minimum and maximum values, y min and y max y n The minimum and maximum values, (x) n ,y n ) represents the coordinates of the nth vertex in the line node.

[0065] 4) The V-Clock value of a line node is the same as that of a point node, where:

[0066] 4.1) Device ID, which is the device ID of the terminal that created this line node;

[0067] 4.2) Counter: The initial value of the line node is 0 after it is created, and it is incremented by 1 after each operation.

[0068] 4. Atomic operations

[0069] This embodiment abstracts map annotation operations (i.e., editing operations on the aforementioned point or line nodes) into atomic operations (corresponding to Operations in the diagram). The basic model structure of atomic operations includes:

[0070] 1) Target node ID: For operations such as "translation", this field records the UUID of the target geographic node; for operations such as creating classes, this field is empty.

[0071] 2) V-Clock, where the device id is the device id of the device that issued the operation command; the counter value is the target node's counter value + 1, and for creation operations without a target node, the counter value is 0.

[0072] 3) Operation type, which can be further divided into: ① creating a point node, ② deleting a point node, ③ translating a point node, ④ creating a line node, ⑤ deleting a line node, ⑥ deleting a vertex, ⑦ translating a vertex, and ⑧ inserting a vertex.

[0073] 4) Operation payload, which records the meta-information of the corresponding operation, where:

[0074] ① The operation payload for creating a point node is the coordinate of the created point;

[0075] ② The operation payload for deleting a point node is empty;

[0076] ③ The operation payload for translating a point node is the coordinate offset of the translated point;

[0077] ④ The operation payload for creating a line node is the vertex list and the isPath field of the created line node;

[0078] ⑤ The operation payload for deleting a line node is empty;

[0079] ⑥ The operation payload for deleting a vertex is the identification code of the deleted vertex;

[0080] ⑦ The operation payload for translating a vertex is the identification code of the translated vertex and the coordinate offset;

[0081] ⑧ The operation payload for inserting a vertex is the identification code of the target vertex and the identification code of the newly inserted vertex.

[0082] Exemplarily:

[0083] At time t1,

[0084] Terminal A makes operation 1, and the content of operation 1 is to create a node a (point node or line node), then the V-Clock of operation 1 can be recorded as (id_A, count 0);

[0085] Node a is created based on operation 1, and the initial V-Clock of node a is recorded as (id_A, count 0).

[0086] At time t2,

[0087] Terminal B and terminal C make operations (translation, deletion, insertion, etc.) on node a at the same time, and the counter value of the operation is the counter value of the target node + 1, then the V-Clocks of the two operations are recorded as (id_B, count 1) and (id_C, count 1);

[0088] After node a executes the above 2 operations, the counter is incremented by 2, so the V-Clock is updated to (id_A, count 2);

[0089] At time t3,

[0090] Terminal B operates on node a again, and the V-Clock of the corresponding operation is recorded as (id B, count 3);

[0091] After node a executes the above operation once, the V-Clock is updated to (id A, count 3).

[0092] II. Collaboration method

[0093] 1. Hierarchical synchronization

[0094] As Figure 2 shown, assume that the distributed map annotation collaborative editing system has two terminals, namely annotation client 1 and annotation client 2, and the two terminals are respectively operated by user 1 and user 2 for map annotation. The figure shows an example of synchronizing the operation of user 1 to user 2.

[0095] After receiving the map annotation operation sent by other terminals, first judge whether the operation is visible. If it is visible, execute the operation immediately; otherwise, cache this operation into the local operation queue and process it according to the priority of each operation.

[0096] Refer to Figure 3 shown, to judge whether a certain operation is visible, it is judged by whether the MBR involved in this operation intersects with the MBR of the window (visible window) of this terminal, where:

[0097] 1) The MBR of the window is defined according to the map area displayed in the window;

[0098] 2) The MBR involved in the operation includes the MBR of the map annotation object (point node or line node) before and after the operation.

[0099] 2. Geometric topology check

[0100] Map annotation operations will change the geometric topology structure of nodes and sometimes cause topological structure errors. The present invention verifies the legality of user operations through the following geometric topology checks:

[0101] (1) Vertex number check

[0102] For operations on line nodes, check whether the number of vertices of the line node after the operation is greater than or equal to 2. If so, the corresponding operation is a legal operation; otherwise, the corresponding operation is an illegal operation.

[0103] (2) Simple polygon check

[0104] For closed line nodes, check whether the polygon formed by its vertices is a simple polygon. If so, the corresponding operation is a legal operation; otherwise, the corresponding operation is an illegal operation.

[0105] Refer to Figure 4 As shown, the simple polygon is one in which no two sides intersect.

[0106] For example, such as Figure 5 As shown, for any two line segments AB and CD on the map, let the coordinates of point A be (x1, y1), the coordinates of point B be (x2, y2), the coordinates of point B be (x3, y3), and the coordinates of point C be (x4, y4). This embodiment provides the following specific determination method:

[0107] 1) Take the MBR of line segment AB and line segment CD respectively, and determine whether the MBR values ​​of the two overlap in the x-axis and y-axis ranges of the map. If not, the two line segments do not intersect. If they do, continue with the following judgment steps.

[0108] 2) Calculate the cross product cross1 of vectors AB and AC, the cross product cross2 of vectors AB and AD, the cross product cross3 of vectors CD and CA, and the cross product cross4 of vectors CD and CB:

[0109] cross1=(x2-x1)(y3-y1)-(y2-y1)(x3-x1)

[0110] cross2=(x2-x1)(y4-y1)-(y2-y1)(x4-x1)

[0111] cross3=(x4-x3)(y1-y3)-(y4-y3)(x1-x3)

[0112] cross4=(x4-x3)(y2-y3)-(y4-y3)(x2-x3)

[0113] 3) Determine whether line segments intersect based on the geometric meaning of the cross product of vectors:

[0114] If cross1*cross2<0 and cross3*cross4<0, then point C and point D are on opposite sides of line segment AB, and point A and point B are also on opposite sides of line segment CD, meaning there is an intersection between the two line segments.

[0115] If cross1 = cross2 = cross3 = cross4 = 0, then line segment AB and line segment CD are collinear; in this case, if the two line segments overlap in the range of values ​​on both the x-axis and y-axis, then there is an overlap between the two line segments (a special type of intersection);

[0116] If there exists a cross product of 0, such as cross1 = 0, and the x-axis and y-axis coordinates of point C are between points A and B, it means that point C is on line segment AB, and there is an intersection of the endpoints of the two line segments (another special intersection).

[0117] If none of the above conditions apply, then the two line segments do not intersect.

[0118] 3. Spatiotemporal joint operation merging

[0119] After a terminal issues an operation command, it is distributed to other terminals for synchronization via a distributed map annotation and collaborative editing system. Consequently, a terminal may receive multiple operation commands simultaneously, and some of these operations may target the same node. To address this, this invention provides the following spatiotemporal joint operation merging method to complete node state synchronization.

[0120] (1) Merging point node creation operations

[0121] Different creation operations create different points and will not cause merge conflicts, so they can be merged directly.

[0122] (2) Merge the deletion of point nodes

[0123] Deleting a node always results in the node disappearing, so it inherently possesses consistency and can be directly merged. However, to prevent error issues arising from other terminals simultaneously performing operations such as translation on this node, this invention does not directly delete all the data of the node, but instead marks the node's operation information as "deleted," i.e. Figure 1 Set the isDeleted field in the value to true.

[0124] (3) Merging translation point node operations

[0125] The position of the point node is translated based on the coordinate offset in the operation load. According to the commutative and associative properties of geometric vector addition, the consistency of the translation result can be guaranteed no matter which operation is merged first. Therefore, the operations can be merged directly.

[0126] (4) Merge line node creation operations

[0127] When creating point nodes, they can be directly merged.

[0128] For each created line node, the validity of the operation is checked through geometric topology. If the operation is found to be illegal, it is ignored.

[0129] (5) Merge the deletion line node operation

[0130] Similar to deleting a node, you can directly merge them.

[0131] (6) Vertex deletion operation merge

[0132] Similar to deleting a node, you can directly merge it.

[0133] For line nodes after deleting a vertex, the legality of the operation is checked through geometric topology. If the check finds the operation to be illegal, the operation information for this line node is marked as "topology error". Figure 1 Set the topoError field to true.

[0134] (7) Merging Vertex Translation Operations

[0135] Nodes that are the same as the translation point nodes can be directly merged.

[0136] For line nodes after translating a vertex, the legality of the operation is checked through geometric topology. If the operation is found to be illegal, the operation information for this line node is marked as "topology error". Figure 1 Set the topoError field to true.

[0137] (8) Merging of Vertex Insertion Operations

[0138] If multiple operations all use the same vertex as the target vertex to insert into the successor vertex, then the operations are merged according to the following method:

[0139] Step 1.1: Sort the operations according to their V-Clock size, and merge the operations with smaller V-Clocks first;

[0140] Step 1.2: Perform a geometric topology check on the legality of the merged operation in Step 1.1. If it is legal, the merged operation in Step 1.1 is used; otherwise, Step 2 is executed.

[0141] Step 2, refer to Figure 6 As shown, geometric topology correction is performed using the geohash of the vertices:

[0142] Step 2.1: Based on the prefix matching property of geoHash (the longer the same prefix, the closer the spatial positions of the two coordinate points), calculate the spatial matching degree S between each successor vertex and the target vertex:

[0143] S = Length of the common prefix of the geohash of the successor vertex and the target vertex.

[0144] The larger the spatial matching degree S, the closer the successor vertex is to the target vertex;

[0145] Step 2.2: Sort according to the size of the spatial matching degree S, and merge the operations with the larger spatial matching degree S first;

[0146] Step 2.3 involves a geometric topology check to verify the validity of the merged operation from Step 2.2. If valid, the merged operation from Step 2.2 is performed; otherwise, the operation information for this line node is marked as "topology error". Figure 1 Set the topoError field to true.

[0147] III. Test

[0148] 1. Hardware and software

[0149] Hardware specifications: AMD 5600 processor, 16GB RAM, solid-state drive;

[0150] Software: Node.js, Playwright;

[0151] Lateral comparison algorithms: Yet Another Transformation Approach (YATA algorithm); ReplicateGrowable Array (RGA algorithm);

[0152] 2. Translation operation merge test

[0153] The test simulated 10 terminals and randomly generated 100 discrete points (uniformly distributed over a 10km × 10km area). Two terminals and one node were randomly selected, and the two terminals simultaneously performed a random translation on the node (the translation range on both the x and y axes was within 1km). This was repeated 200 times. The experiment calculated the error rate and average deviation distance by comparing the actual and theoretical positions of the final points, and also statistically analyzed the average synchronization time for a single operation. Specific data are shown in Table 1 below.

[0154] Table 1: Results of Combined Tests for Translation Operations

[0155] algorithm Error rate Average deviation distance (m) Time taken (ms / time) YATA 98.4％ 470 95 RGA 97.9％ 530 120 This invention 0％ 0 102

[0156] Test results show that, when merging point translation operations, this invention, compared with traditional algorithms, can effectively retain all client movement operation information within approximately the same time consumption and CPU utilization by utilizing the characteristics of vector space merging, thus greatly improving the accuracy of annotation.

[0157] 3. Geometric topology error correction test

[0158] The test simulation created 10 terminals and a surface with 10 vertices (simulating the outline of a lake), with the distance between vertices approximately 10 km. Fifty vertices were randomly inserted after vertices 3, 5, and 7. To ensure that the inserted vertices had a probability of disrupting the topology, the distance between the inserted vertices and the target vertices was set to approximately 20 km. The results are shown in Table 2 below.

[0159] Table 2: Geometric Topology Error Correction Test Results

[0160]

[0161] Experiments show that the geometric topology detection strategy of this invention can effectively identify topological errors within a time frame similar to that of traditional algorithms, and correct 70.8% of the nodes using spatial information, while marking those that fail to correct errors, thereby improving the reliability of map annotation of geometric topology.

[0162] 4. Computing resource performance testing

[0163] The test simulated creating 500 terminals and several nodes, randomly performing 100 operations of each type, with an equal number of operations targeting visible and non-visual nodes. The number of nodes was gradually increased from 2000 to 10000, while maintaining a 30% proportion of visible nodes. The average time taken for operation synchronization between visible and non-visual nodes was statistically analyzed, with specific data as follows: Figure 7 and Figure 8 As shown.

[0164] Figure 7 Delay for merging operations on visible nodes Figure 8 The experiment shows that in small-scale annotation scenarios, the operation merging time for visible nodes is about 10% faster than YATA, which is not a significant advantage. At the same time, there is a certain lag in the synchronization time of non-visual nodes.

[0165] However, as the node scale increases, the advantage of this invention in merging visible node operations compared to traditional algorithms becomes increasingly apparent. When the node scale reaches 10,000, the algorithm reduces the time spent merging visible node operations by 45% compared to the YATA algorithm. Meanwhile, the time spent merging non-visual node operations deteriorates steadily, with only 16% more time spent compared to the YATA algorithm when the node scale reaches 10,000.

[0166] In summary, this invention introduces geometric perception capabilities into collaborative algorithms, demonstrating multi-dimensional advantages in distributed 2D map annotation and collaborative editing. During translation operations, the geometric vector merging rules preserve all client operations, significantly reducing semantic loss. For geometric topology error correction, topology errors are identified through vertex number constraints and simple polygon constraints, and a spatiotemporal joint operation merging mechanism achieves automatic correction of 70.8% of node topology errors. In terms of performance, the MBR-based hierarchical merging operation mechanism optimizes collaborative efficiency for large-scale nodes. With 10,000 nodes, the update latency for visible nodes is 315ms, a 45% reduction compared to YATA, while the latency for non-visible nodes is 287ms, only 16% higher, effectively improving user experience.

[0167] This invention is not limited to the above-described embodiments. Any obvious improvements, substitutions, or modifications that can be made by those skilled in the art without departing from the essence of this invention are within the scope of protection of this invention.

Claims

1. A collaborative editing method for two-dimensional map annotation based on geometry perception, characterized in that: Map annotation objects are divided into point nodes and line nodes. Point nodes represent point elements in the map, non-closed line nodes represent line elements in the map, and closed line nodes represent polygon elements in the map. Each node maintains a V-Clock, which includes a device ID and a counter. The device ID is the device ID of the terminal that created the node. The counter increments by 1 after each operation, starting from the initial value after node creation. For operations other than creation, a V-Clock is maintained, where the device ID is the device ID of the terminal that issued the operation, and the counter value is the target node's counter value + 1. During the merge operation, the following geometric topology check is performed: For closed line nodes, check whether the polygon enclosed by their vertices is a simple polygon. If yes, the corresponding operation is a valid operation; otherwise, the corresponding operation is an illegal operation. For the vertex insertion operation of line nodes, the operations are sorted according to their V-Clock size. Operations with smaller V-Clock values ​​are merged first. If the geometric topology check finds it to be illegal, the following geometric topology correction is performed: S1, using the geoHash value of each vertex, and based on the prefix matching characteristic of geoHash, calculate the spatial matching degree S between each successor vertex and the target vertex; S2, sort according to the size of spatial matching degree S, and merge operations with larger spatial matching degree S first.

2. The geometric perception-based collaborative editing method for two-dimensional map annotation according to claim 1, characterized in that: The spatial matching degree S is the length of the common geoHash prefix of both the successor vertex and the target vertex.

3. The geometric perception-based collaborative editing method for two-dimensional map annotation according to claim 1, characterized in that: Whether an operation is visible is determined by whether the MBR involved in the operation intersects with the MBR of the terminal window; if they intersect, the operation is visible. The MBR involved in the operation is the MBR before and after the operation on the target node. The MBR of the window is defined according to the map area displayed in the window. The MBR is the smallest rectangle that can cover the node or the map area. For visual operations, merge them first.

4. The geometric perception-based collaborative editing method for two-dimensional map annotation according to claim 3, characterized in that: The length and width of the MBR are parallel to the map coordinate axes; The MBR of a point node is its own coordinate range; The MBR of a line node is the extreme range of all vertex coordinates.

5. The two-dimensional map annotation collaborative editing method based on geometry perception according to claim 1, characterized in that: For translation operations of vertices in point nodes or line nodes, the operation instruction records the coordinate offset of the point, and translates the target point node or vertex according to the coordinate offset.

6. The geometric-aware two-dimensional map annotation collaborative editing method according to claim 4, characterized in that: The method for determining the simple polygon is as follows: Check if any two sides intersect, for any two line segments AB and CD: Take the MBR of line segment AB and line segment CD respectively, and determine whether the MBR values ​​of the two overlap in the x-axis and y-axis ranges of the map. If not, the two line segments do not intersect. Calculate the cross product of vectors AB and AC. The cross product of vectors AB and AD The cross product of vectors CD and CA The cross product of vectors CD and CB And based on the geometric meaning of the cross product of vectors, determine whether the line segments intersect; If no two sides intersect, it is a simple polygon.

7. The geometric perception-based collaborative editing method for two-dimensional map annotation according to claim 1, characterized in that: The geometric topology check also includes a vertex count check. If the number of vertices in a line node is greater than or equal to 2, the corresponding operation is a valid operation; otherwise, it is an invalid operation. Mark the line nodes that are found to have engaged in illegal operations.

Images