Multi-sheet virtual database map data management system and method

Abstract

The application provides a multi-sheet virtual database map data management system and method. The system comprises: a plurality of physical sheet databases for storing spatial element data and attribute data; a metadata index library for returning a hit sheet set in response to a sheet retrieval request for a target spatial range; a virtual database for providing a unified data access interface to an upper-layer application, and comprising: a dynamic data scheduling engine for determining the hit sheet set and a corresponding physical sheet database set; a result aggregation unit for performing merging and deduplication on sub-request results; an editing and edge processing engine for decomposing an editing request into sub-editing operations respectively facing each sheet database when the sheet set comprises multiple sheets; and a transaction coordination unit for starting a transaction for each of the multiple physical sheet databases corresponding to the sub-editing operations and performing the sub-editing operations. The application can improve cross-sheet operation efficiency and reduce heterogeneous data integration and maintenance costs.

Description

Technical Field

[0001] This application relates to the field of map data production and management technology, and in particular to a multi-map virtual database map data management system and method. Background Technology

[0002] In the field of map data production and geospatial data management, when processing large areas in traditional map drawing systems, engineering data is usually stored and databased separately according to standard map sheets or geographic blocks, forming multiple independent map sheet databases. At the same time, the sources of project data are complex, and may come from file-type data formed by different surveying and mapping units, lightweight database data formed by field collection, or historical geographic database data. Different data sources have differences in data models, coordinate references, attribute structures, and storage methods.

[0003] Current map drawing and management methods mostly use single-map sheet projects as the basic work unit. Users need to open different data sources for different map sheets one by one for processing, making it difficult to form a continuous and consistent geospatial view. When the work scope spans multiple map sheets, cross-map sheet queries, statistics, analysis, and drawing often rely on manually switching data sources and stitching and summarizing the results. This operation is cumbersome and prone to omissions, duplications, or inconsistent boundaries. For heterogeneous data sources, traditional methods usually require format conversion, structure alignment, and data migration before the job to achieve unified management. This is not only labor-intensive and costly to maintain, but may also introduce conversion errors or damage the original field semantics, metadata, and storage organization, making it difficult to meet the needs of efficient and consistent operations for large-scale, multi-source, and multi-map sheet map data. Summary of the Invention

[0004] In view of this, embodiments of this application provide a multi-map sheet virtual database map data management system and method to solve the problems of existing technologies, such as the difficulty in uniformly loading scattered multi-map sheet data, the need for manual splicing for cross-map sheet query and editing, and the high cost of heterogeneous data access and integration.

[0005] The first aspect of this application provides a multi-map sheet virtual database map data management system, including: multiple physical map sheet databases, each corresponding to a different map sheet or geographic block, used to store spatial feature data and attribute data; a metadata index library, used to store map sheet identifiers, map sheet spatial ranges, database types, access paths, connection parameters, and spatial adjacency relationships between map sheets corresponding to each physical map sheet database, and used to respond to map sheet retrieval requests for a target spatial range to return a set of hit map sheets; a virtual database, used to provide a unified data access interface for upper-layer applications, and including: a dynamic data scheduling engine, used to receive data requests submitted by upper-layer applications, parse the data requests to obtain the target spatial range and target data object identifier, call the metadata index library based on the target spatial range to determine the set of hit map sheets and the corresponding set of physical map sheet databases, and establish a connection between the virtual database and the physical map sheet database. The system comprises the following components: a physical map sheet database set access connection and the issuance of sub-requests; a result aggregation unit, which receives the sub-request results returned by each physical map sheet database, merges and deduplicates the sub-request results based on the data object identifier, and outputs a unified result to the upper-layer application; an editing and edge-joining processing engine, which, upon receiving an editing request, determines the map sheet set traversed by the editing request based on the metadata index, and decomposes the editing request into sub-editing operations targeting each map sheet database when the map sheet set contains multiple map sheets; and a transaction coordination unit, which opens transactions for each physical map sheet database corresponding to the sub-editing operation and executes the sub-editing operation. If a sub-editing operation fails, it triggers a compensation operation for the successfully executed sub-editing operations and records the transaction log. When all sub-editing operations are successfully executed, it commits the transactions of each physical map sheet database and returns the execution result to the upper-layer application.

[0006] The second aspect of this application provides a method for managing multi-map sheet virtual database map data based on the system of the first aspect, comprising: receiving a data request submitted by an upper-layer application and parsing the data request to obtain a target spatial range and a target data object identifier; querying a metadata index based on the target spatial range to determine the set of hit map sheets and the set of physical map sheet databases associated with the set of hit map sheets; establishing an access connection based on the set of physical map sheet databases and generating a sub-request carrying the target spatial range and the target data object identifier, and sending the sub-request to each physical map sheet database to obtain the sub-request result or sub-operation execution status; when the data request is a query request, receiving the data from each physical map sheet database... Based on the sub-request results returned by the database, the sub-request results are merged and deduplicated according to the data object identifier to form a unified result, which is then returned to the upper-layer application. When the data request is an edit request, the map sheet set traversed by the edit request is determined based on the metadata index. If the map sheet set contains multiple map sheets, the edit request is decomposed into sub-edit operations targeting each map sheet database. Transactions are opened and sub-edit operations are executed on the corresponding multiple physical map sheet databases. If a sub-edit operation fails, a compensation operation is triggered for the successfully executed sub-edit operations and the transaction log is recorded. When all sub-edit operations are successfully executed, the transactions of each physical map sheet database are committed, and the execution results are returned to the upper-layer application.

[0007] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: Multiple physical map sheet databases, each corresponding to different map sheets or geographic blocks, are used to store spatial feature data and attribute data. A metadata index is used to store the map sheet identifier, spatial extent, database type, access path, connection parameters, and spatial adjacency relationships between map sheets corresponding to each physical map sheet database. It is also used to respond to map sheet retrieval requests for a target spatial extent and return the matching set of map sheets. A virtual database provides a unified data access interface for upper-layer applications and includes a dynamic data scheduling engine. This engine receives data requests submitted by upper-layer applications, parses the data requests to obtain the target spatial extent and target data object identifier, calls the metadata index based on the target spatial extent to determine the matching set of map sheets and the corresponding set of physical map sheet databases, establishes access connections to the physical map sheet database sets, and downloads the corresponding data. The system comprises the following components: a sub-request unit; a result aggregation unit, which receives the sub-request results from each physical map sheet database, merges and deduplicates the results based on data object identifiers, and outputs a unified result to the upper-layer application; an editing and edge-joining engine, which, upon receiving an editing request, determines the set of map sheets traversed by the editing request based on the metadata index, and decomposes the editing request into sub-editing operations targeting each map sheet database when the map sheet set contains multiple map sheets; and a transaction coordination unit, which initiates transactions for each of the multiple physical map sheet databases corresponding to the sub-editing operation and executes the sub-editing operation. If any sub-editing operation fails, it triggers compensation operations for successfully executed sub-editing operations and records the transaction log. When all sub-editing operations are successfully executed, it commits the transactions for each physical map sheet database and returns the execution results to the upper-layer application. This application enables unified presentation of multi-map sheet data, improves the efficiency of cross-map sheet operations, and reduces the cost of heterogeneous data integration and maintenance. Attached Figure Description

[0008] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 This is a schematic diagram of the overall architecture of the multi-map virtual database map data management system provided in this application embodiment in a real-world scenario; Figure 2 This is a schematic diagram of the overall process of data editing and updating provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structural composition of the multi-map virtual database map data management system provided in the embodiments of this application; Figure 4This is a flowchart illustrating the multi-map virtual database map data management method provided in this application embodiment. Detailed Implementation

[0010] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0011] Traditional map-making systems typically face the following problems when dealing with large areas: (1) Data fragmentation: Data from different map sheets are stored in different project files or databases. Users can only open and process them one by one, and cannot form a continuous and holistic geospatial view.

[0012] (2) Cumbersome cross-map operation: To perform cross-map query, analysis or drawing, users need to manually switch data sources and stitch the results together, which is extremely cumbersome and prone to errors.

[0013] (3) Data heterogeneity problem: Project data usually comes from diverse sources, including Shapefiles from different surveying units, SQLite / SpatiaLite databases collected in the field, legacy File Geodatabases, and even MapInfo TAB formats. These data models, coordinate systems, and attribute table structures vary, forming "data silos." Traditional methods require tedious and data-intensive format conversions and structural unifications before integration, which is labor-intensive and damages the original value of the data.

[0014] In view of the problems existing in the prior art, this application provides a map data management system and method for unified loading, visualization, querying and analysis of multiple independent map sheet databases. This application belongs to the field of map data production, specifically a system and method for spatial data management of multi-map sheet operations in large-scale map drawing processes.

[0015] The core idea of ​​this application's technical solution is to logically integrate multiple physically distributed and heterogeneous databases through a virtual database, presenting them as a single, continuous virtual data source to upper-layer applications. The following detailed description, in conjunction with the accompanying drawings and embodiments, illustrates the specific composition, functions, and implementation methods of this application's multi-map virtual database map data management system. Figure 1 This is a schematic diagram of the overall architecture of the multi-map virtual database map data management system provided in this application embodiment in a real-world scenario, as shown below. Figure 1 As shown, the system may specifically include the following: 1. Multiple physical map sheet databases: serving as the underlying data storage units. Each database corresponds to a standard map sheet or a geographic block, and can be a SpatiaLite, Shapefile set, or even a File Geodatabase. They can be stored in different local directories.

[0016] 2. Metadata Index Repository: This is a lightweight configuration file library (such as XML, JSON, or a small index database). It mainly records: (1) The unique identifier and geospatial extent of each map sheet.

[0017] (2) The type of physical database, access path and necessary connection parameters corresponding to each map sheet.

[0018] (3) Spatial adjacency between map sheets.

[0019] 3. Virtual Database: The core component of this patent application, acting as an intelligent agent to handle all data requests. Main responsibilities include: (1) Load the global map sheet index at startup.

[0020] (2) Receive user operation instructions (such as query).

[0021] (3) Based on the current spatial range of the operation, query the global map sheet index in real time and intelligently locate the relevant physical map sheet database.

[0022] (4) Schedule and load specific data.

[0023] (5) Seamlessly aggregate query results from multiple databases in memory and finally present a unified result to the user.

[0024] In practice, the metadata index can be a lightweight index file (such as JSON, XML, or a small SQLite database) whose structure includes: map sheet number, map sheet range, database path, database type, and included layers.

[0025] This system supports seamless cross-map sheet query and visualization. When a user needs to query an area that spans multiple map sheets, the engine operates according to the following workflow: S1. The application submits a cross-map query request; S2, The virtual database accepts the request; S3. Query metadata index to locate the relevant physical database based on spatial range; S4. Connect to and query all relevant physical databases; S5. The virtual database merges and deduplicates the query results; S6. Return the unified result to the application.

[0026] This system also supports data editing and updating. Figure 2 This is a schematic diagram of the overall process of data editing and updating provided in the embodiments of this application, such as... Figure 2 As shown, the specific implementation process is as follows: (1) Single map sheet editing: When the editing operation is entirely within a single map sheet, the process is simple and direct, and the engine performs intelligent routing.

[0027] (2) Cross-map editing: When the editing operation spans multiple map sheets, the process is as follows: a. Operation decomposition: The engine decomposes editing operations into corresponding sub-operations for different map sizes.

[0028] b. Determine whether all map sheets in the edit data are connected and editable.

[0029] b. Distributed transactions: The engine attempts to perform updates on multiple databases separately.

[0030] c. Consistency guarantee: If all operations succeed, commit; if any one fails, attempt to roll back other operations (compensation transaction) and log the process to ensure data logical consistency.

[0031] The specific structure and functions of the multi-map virtual database map data management system provided in this application will be described in detail below with reference to the accompanying drawings and specific embodiments. Figure 3 This is a schematic diagram of the structural composition of the multi-map virtual database map data management system provided in this application embodiment, as shown below. Figure 3 As shown, the system may specifically include the following: Multiple physical map sheet databases 301, each corresponding to a different map sheet or geographic block, are used to store spatial feature data and attribute data; Metadata index 302 is used to store map sheet identifiers, map sheet spatial ranges, database types, access paths, connection parameters, and spatial adjacency relationships between map sheets corresponding to each physical map sheet database, and is used to respond to map sheet retrieval requests for target spatial ranges to return the set of hit map sheets; Virtual database 303 is used to provide a unified data access interface for upper-layer applications and includes: The dynamic data scheduling engine 304 is used to receive data requests submitted by upper-layer applications, parse the data requests to obtain the target spatial range and the target data object identifier, call the metadata index library based on the target spatial range to determine the hit map sheet set and the corresponding physical map sheet database set, establish access connections to the physical map sheet database set and send out sub-requests respectively. The result aggregation unit 305 is used to receive the sub-request results returned by each physical map sheet database, perform merging and deduplication on the sub-request results based on the data object identifier, and output a unified result to the upper layer application. The editing and edge-joining processing engine 306 is used to determine the set of map sheets that the editing request will traverse based on the metadata index when an editing request is received, and to decompose the editing request into sub-editing operations that target each map sheet database when the set of map sheets contains multiple map sheets; The transaction coordination unit 307 is used to start transactions and execute sub-editing operations for multiple physical map sheet databases corresponding to sub-editing operations. When a sub-editing operation fails, it triggers a compensation operation and records the transaction log for the successfully executed sub-editing operations. When all sub-editing operations are successfully executed, it commits the transactions of each physical map sheet database and returns the execution results to the upper layer application.

[0032] In some embodiments, the metadata index library includes a map sheet index table, which is used to associate and store map sheet identifiers, map sheet spatial ranges, physical map sheet database types, physical map sheet database access paths, connection parameters, and the set of layer identifiers contained in the physical map sheet database. When determining the set of map sheets to be matched, the dynamic data scheduling engine filters based on the spatial intersection relationship between the target spatial range and the map sheet spatial range, and performs secondary filtering on the physical map sheet database set based on the set of layer identifiers.

[0033] Specifically, the fields used for associated storage in the map sheet index table include map sheet identifier, map sheet spatial range, physical map sheet database type, physical map sheet database access path, connection parameters, and the set of layer identifiers contained in the physical map sheet database. Among these, the map sheet identifier uniquely identifies a standard map sheet or geographic block; the map sheet spatial range describes the spatial envelope of the map sheet under a unified coordinate reference, typically expressed using the minimum bounding rectangle to support fast intersection determination; the physical map sheet database type indicates the storage medium type of the map sheet data, allowing the dynamic data scheduling engine to select a matching data access adapter; the physical map sheet database access path and connection parameters are used to locate the actual storage location of the physical map sheet database and establish an access connection; and the set of layer identifiers describes the set of published or accessible layers within the physical map sheet database, enabling further filtering of irrelevant data sources after a map sheet is matched, avoiding establishing connections or issuing sub-requests to databases that do not contain the target layer.

[0034] In some examples, spatial intersection filtering employs a "range hit priority" strategy. Upon receiving the target spatial range, the dynamic data scheduling engine normalizes it to a range expression consistent with the map sheet spatial range and retrieves map sheet records from the memory index structure that have spatial intersection relationships with the target spatial range. These spatial intersection relationships include at least one of the following: overlap, tangency, or containment relationship between the target spatial range and the map sheet spatial range. For boundary tangency, the system considers tangency as a hit to ensure that features crossing map sheet boundaries are not missed due to boundary landing points. After completing the spatial intersection filtering, the dynamic data scheduling engine obtains the set of hit map sheets and extracts the database type, access path, and connection parameters from the corresponding records to form a candidate physical map sheet database set.

[0035] In some examples, secondary filtering of layer identifier sets is used to reduce invalid access when heterogeneous data sources are connected. When parsing a data request, the dynamic data scheduling engine obtains not only the target spatial range but also the target layer identifier or target layer identifier set. Once the set of hit map sheets is determined, the dynamic data scheduling engine reads the layer identifier set corresponding to each hit map sheet one by one, determining whether the set contains the target layer identifier. If it does not contain it, the physical map sheet database corresponding to that map sheet is removed from the candidate physical map sheet database set; if it does contain it, the physical map sheet database is retained as a valid data source and proceeds to the subsequent connection establishment and sub-request issuance process. For data requests containing multiple target layer identifiers, this embodiment supports determining and outputting a physical map sheet database set that can cover at least one target layer based on the layer identifier set, while simultaneously carrying the actual hit target layer identifier set in subsequent sub-requests to limit the retrieval objects on the physical map sheet database side.

[0036] This embodiment uses a map sheet index table to jointly constrain the spatial range of the map sheet and the set of layer identifiers. The dynamic data scheduling engine can quickly locate the target map sheet and eliminate irrelevant data sources in scenarios with multiple map sheets and heterogeneous data sources. This reduces unnecessary connection establishment and sub-request issuance, improves the processing efficiency of cross-map sheet retrieval and scheduling, and reduces the invalid access and maintenance costs caused by heterogeneous data sources and differences in layer distribution.

[0037] In some embodiments, the dynamic data scheduling engine is used for: Receive data requests submitted by upper-layer applications. The data requests carry spatial range parameters to limit the scope of querying or editing, and data object parameters to indicate the target data object. The system identifies the request type of data requests, determines whether they are query or edit requests, and calls the corresponding parsing template based on the request type. Based on the parsing template, the target spatial range is extracted from the spatial range parameters, and the target spatial range is standardized into a preset spatial range expression. Based on the parsing template, the target data object identifier is extracted from the data object parameter, and a set of target data object identifiers is generated when the data object parameter contains multiple data objects; The target spatial range and the target data object identifier or the set of target data object identifiers are output as the parsing result of the data request.

[0038] Specifically, the data request submitted by the upper-layer application must include at least spatial extent parameters and data object parameters. The spatial extent parameter defines the geographic spatial range involved in the query or edit, while the data object parameter indicates the target data object, which can be a single spatial feature or a collection of multiple spatial features. To adapt to multi-map sheet operations, the upper-layer application does not need to explicitly specify a specific map sheet or physical map sheet database; it only needs to provide the spatial extent parameters and data object parameters in the request. The dynamic data scheduling engine can then complete the subsequent cross-map sheet positioning and distribution.

[0039] In some examples, when the upper-layer application requests full-range data, the spatial extent parameter corresponds to the range of the current viewport or selected area, and the data object parameter can be empty or indicate all features under the target layer. After the dynamic data scheduling engine completes parsing, it initiates a map sheet retrieval from the metadata index and issues a sub-request. When the upper-layer application submits a move or edit request, the spatial extent parameter corresponds to the edit envelope range or the edit trajectory coverage range, and the data object parameter carries the identifier of the manipulated feature, such as 0edc or a4d4 in the example.

[0040] Furthermore, upon receiving a data request, the dynamic data scheduling engine first performs request type identification to determine whether the data request is a query request or an edit request. Request type identification can be based on the operation category field, interface call entry point, or preset instruction identifier carried in the data request. For example, when a data request carries search conditions, layer identifiers, and spatial range parameters, it can be identified as a query request; when a data request carries an edit operation type, target data object identifier, and edit spatial range, it can be identified as an edit request. This request type identification result is used to select different parsing templates to ensure that the parameter extraction rules for query and edit requests are consistent and reusable, and to connect with the processing chain of subsequent modules. Specifically, the parsing template for query requests focuses on extracting the target spatial range, target layer identifier, and optional target data object identifier; the parsing template for edit requests focuses on extracting the target spatial range, target data object identifier, optional edit operation type, and post-edit geometric information.

[0041] In some examples, the dynamic data scheduling engine extracts the target spatial range from the spatial range parameters based on the parsing template and performs normalization processing on the target spatial range. Normalization processing refers to converting the different spatial range expressions that upper-layer applications may use into a unified preset spatial range expression, so as to facilitate subsequent determination of map sheet spatial range intersection and limitation of sub-request ranges.

[0042] The preset spatial range can be expressed as the range of the minimum bounding rectangle, including four boundary values: minimum longitude, minimum latitude, maximum longitude, and maximum latitude; or it can be expressed as the vertex sequence of a polygon range and the envelope range can be generated simultaneously.

[0043] For view ranges, selection box ranges, or trajectory coverage ranges from upper-layer applications, the dynamic data scheduling engine converts them into a unified preset spatial range expression and supplements them with necessary boundary closure information and coordinate reference identifiers to ensure consistent input for subsequent filtering of spatial intersection relationships of map sheet spatial ranges in the metadata index.

[0044] In some examples, the dynamic data scheduling engine extracts target data object identifiers from data object parameters based on parsing templates, and generates a set of target data object identifiers when the data object parameters contain multiple data objects. The target data object identifier is used to uniquely indicate the spatial feature being queried or edited in cross-map scenarios. The target data object identifier can be formed by the spatial feature's primary key identifier, a globally unique identifier, or a combination of layer identifiers and feature identifiers. For query requests, data object parameters can be used to specify a set of feature identifiers or a target set filtered by attributes; for edit requests, data object parameters typically directly carry the identifier of the feature being edited. For example, when performing intra-map-sheet movement editing on 0edc, the data object parameter carries 0edc; when performing cross-map-sheet editing on the cross-map-sheet line data a4d4, the data object parameter carries a4d4. After extracting the target data object identifiers, the dynamic data scheduling engine further determines whether the data object parameters contain multiple data objects. If so, it generates a set of target data object identifiers and uses this set as a limiting condition in subsequent sub-requests to support querying or batch editing multiple features in a single request.

[0045] The dynamic data scheduling engine outputs the target spatial range and the target data object identifier or set of target data object identifiers as the parsing result of the data request, and provides this parsing result to subsequent modules. Specifically, when the request type is a query request, the target spatial range in the parsing result is used to trigger the map sheet retrieval of the metadata index and to limit the sub-request retrieval range of each physical map sheet database. The target data object identifier or set of target data object identifiers in the parsing result is used to limit the target features of the sub-request or as the deduplication grouping key for the result aggregation unit. When the request type is an edit request, the target spatial range in the parsing result is used to determine the set of map sheets traversed by the edit request, and the target data object identifiers in the parsing result are used for the operation decomposition between the editing and edge processing engines and the cross-database transaction association of the transaction coordination unit.

[0046] The following example illustrates this parsing process. Assume an upper-layer application initiates a query request spanning DN105000513 and DN105000514. The spatial range parameter corresponds to the selected area envelope, and the data object parameter indicates the target layer as "roads" without specifying concrete feature identifiers. The dynamic data scheduling engine recognizes this request as a query, calls the query parsing template, extracts and normalizes the target spatial range, and simultaneously parses the data object parameter into target layer identifiers, generating an empty set of target data object identifiers. The parsing results are then output for the metadata index to retrieve the matched map sheet and issue a sub-request.

[0047] For example, an upper-layer application submits a request to move and edit within the map sheet for a target data object (0edc). The spatial range parameter corresponds to the geometric envelope before and after the move, and the data object parameter carries the target data object identifier (0edc). The dynamic data scheduling engine recognizes this request as an edit request, calls the edit parsing template, extracts and normalizes the target spatial range, extracts the target data object identifier (0edc), and outputs the parsing result. This enables subsequent modules to locate the target map sheet and execute single-map sheet transaction updates accordingly.

[0048] For example, an upper-layer application submits a cross-map sheet editing request for the cross-map sheet line data a4d4. The spatial range parameter covers the boundary area between the two map sheets, and the data object parameter carries the target data object identifier a4d4. The dynamic data scheduling engine recognizes this as an editing request and outputs the target spatial range and a4d4. The subsequent editing and edge-joining processing engine uses this to determine that the map sheet sets traversed are DN105000513 and DN105000514, and decomposes the editing operation into sub-editing operations targeting the two map sheet databases respectively. The transaction coordination unit then initiates and executes transactions for each sub-operation.

[0049] Through the above implementation, the dynamic data scheduling engine in this embodiment completes unified access to upper-layer application requests, request type identification, spatial range standardization, and target data object identification extraction within the virtual database. This enables cross-map sheet queries and cross-map sheet editing to trigger map sheet hit location, sub-request distribution, and multi-database collaborative processing under a consistent parameter system. This reduces the upper-layer application's awareness of the details of multiple map sheets and heterogeneous databases, improves the availability and processing efficiency of multi-map sheet workflows, and reduces routing deviations and repetitive processing costs caused by inconsistent parameter expressions.

[0050] In some embodiments, the dynamic data scheduling engine is also used for: Submit a map sheet retrieval request carrying the target spatial range to the metadata index, so that the metadata index can filter the map sheet set that is hit based on the spatial intersection relationship between the target spatial range and the spatial range of each map sheet, and return the database type, access path and connection parameters associated with the hit map sheet set respectively; Based on the database type of physical map sheet database collection, select the corresponding data access adapter, and the data access adapter establishes an access connection according to the access path and connection parameters; The sub-requests are generated according to the set of hit map sheets and correspond to each physical map sheet database. The sub-requests carry the target spatial range and the target data object identifier or the target data object identifier set, and are used to limit the search range or update object in the corresponding physical map sheet database. Sub-requests are sent to the physical map databases with established access connections to obtain the sub-request results or sub-operation execution status.

[0051] Specifically, the dynamic data scheduling engine first submits a map sheet retrieval request carrying the target spatial range to the metadata index. This map sheet retrieval request includes at least the target spatial range and optional target layer identifiers or operation type information, which assists the metadata index in returning a more business-relevant set of hits. The metadata index filters based on the spatial intersection relationship between the target spatial range and each map sheet spatial range, obtaining the set of hit map sheets, and returning the database type, access path, and connection parameters associated with each set of hit map sheets. This spatial intersection relationship filtering works in conjunction with the map sheet spatial ranges recorded in the map sheet index table, using a fast range intersection determination method to ensure that when the target spatial range crosses map sheet boundaries, map sheets with tangent or partially overlapping boundaries can be hit, thereby avoiding the omission of cross-map sheet features at the boundaries. For requests that are only within a single map sheet, the set of hit map sheets is a single-element set.

[0052] In some examples, once the target map sheet set is determined, the dynamic data scheduling engine selects the corresponding data access adapter for each physical map sheet database set. A data access adapter is an access component used to mask the differences between different physical map sheet database types. Its inputs are the access path and connection parameters, and its output is a unified data access connection and standardized query or update interface. Different database types correspond to different data access adapters, such as data access adapters for file-based spatial data, lightweight databases, and geographic databases.

[0053] The dynamic data scheduling engine selects a data access adapter that matches the database type for each hit map sheet, and the data access adapter establishes an access connection according to the access path and connection parameters. During the connection establishment process, the data access adapter can further perform connection parameter verification, data source reachability verification, and connection handle caching to support repeated access to the same map sheet database and reuse connection resources.

[0054] In some examples, the dynamic data scheduling engine generates sub-requests corresponding to each physical map sheet database based on the matched map sheet set. Sub-requests are used within the virtual database to split a single upper-level data request into multiple sub-tasks targeting different map sheet databases. Each sub-request carries at least the target spatial extent and the target data object identifier or set of target data object identifiers, and is used to limit the retrieval scope or update objects in the corresponding physical map sheet database.

[0055] Furthermore, for query requests, sub-requests can carry target layer identifiers, attribute filtering conditions, or spatial relationship constraints, ensuring that the physical map sheet database returns only spatial feature records within the target spatial range that meet the conditions. For edit requests, sub-requests carry target data object identifiers and editing operation-related parameters, enabling the physical map sheet database to perform update, delete, or write operations within its local map sheet transaction. When the dynamic data scheduling engine generates a corresponding sub-request for each hit map sheet, it binds the hit map sheet identifier to the sub-request, so that subsequent result aggregation units can supplement the sub-request results with the map sheet identifier, or facilitate the transaction coordination unit to start local map sheet transactions based on the map sheet identifier.

[0056] In some examples, the dynamic data scheduling engine distributes sub-requests to the respective physical map sheet databases with established access connections to obtain sub-request results or sub-operation execution status. For query requests, the returned content is the sub-request result, containing spatial feature records and their data object identifiers, for the result aggregation unit to perform merging and deduplication. For edit requests, the returned content is the sub-operation execution status, including whether the sub-edit operation was successful, the reason for failure, and optional pre-operation status summary information, for the transaction coordination unit to perform commit, rollback, or compensation.

[0057] For example, the dynamic data scheduling engine sends query sub-requests to the physical map sheet databases corresponding to DN105000513 and DN105000514 respectively and obtains the sub-request results. DN105000513 returns a4d4 and 0edc, while DN105000514 returns a4d4. Considering the timing of migrating 0edc across map sheets, the dynamic data scheduling engine establishes connections to both map sheets after matching them. Then, it generates corresponding sub-requests based on the sub-editing operations decomposed by the editing and edge-joining processing engines. One sub-request is used to delete 0edc in DN105000513, and the other is used to write 0edc into DN105000514. Both sub-requests are then sent to obtain their respective execution statuses. Considering the timing of editing a4d4 across map sheets, the dynamic data scheduling engine sends update sub-requests to both map sheets to obtain their execution statuses, thereby supporting the transaction coordination unit in uniformly committing or rolling back sub-operations across multiple databases.

[0058] The operability of this scheduling process is further illustrated below with a specific example. Assume the upper-layer application initiates a query request for a range spanning DN105000513 and DN105000514, where the target spatial range covers the boundary area between the two map sheets, the target data object identifier is empty, and the target layer identifier is "roads". The dynamic data scheduling engine submits a map sheet retrieval request to the metadata index, returning DN105000513 and DN105000514 as the matched map sheets, along with their database types, access paths, and connection parameters. The dynamic data scheduling engine selects a lightweight geodatabase access adapter for each map sheet, establishing access connections to data / DN105000513.sqlite and data / DN105000514.sqlite respectively. Subsequently, the dynamic data scheduling engine generates two query sub-requests based on the matched map sheet sets, each carrying the target spatial range and target layer identifier, and sends them to the two physical map sheet databases.

[0059] After the two physical map sheet databases return their respective sub-request results, the dynamic data scheduling engine outputs the sub-request results to the result aggregation unit. The result aggregation unit performs deduplication on a4d4 and forms a unified result to return to the upper-layer application, enabling the upper-layer application to obtain a continuous and consistent query view. For example, the upper-layer application initiates an edit request to move 0edc from DN105000513 to DN105000514, with the target spatial range covering the movement trajectory and landing area, and the target data object identified as 0edc. After the dynamic data scheduling engine matches the two map sheets and establishes a connection, it generates delete and write sub-requests based on the operation decomposition results and sends them out separately. It obtains the sub-operation execution status of the two physical map sheet databases, allowing the transaction coordination unit to execute a commit if both databases succeed, and to perform a rollback and compensation if either fails.

[0060] Through the above implementation, the dynamic data scheduling engine in this embodiment can complete map sheet retrieval and positioning based on the target spatial range, and realize unified connection and access to heterogeneous physical map sheet databases through a database type-driven data access adapter. Then, by generating and issuing sub-requests according to the hit map sheet, it realizes the distribution and scheduling of cross-map sheet queries and cross-map sheet editing, thereby reducing the overhead of accessing irrelevant data sources and repeated connections, improving the scheduling efficiency and processing stability of multi-map sheet data requests, and providing consistent input and clear processing boundaries for subsequent result aggregation and cross-database transaction coordination.

[0061] In some embodiments, the result aggregation unit is used for: Receive the sub-request results returned by each physical map sheet database in response to the sub-request. The sub-request results include spatial feature records and their corresponding data object identifiers. Spatial feature records contain geometric data and attribute data. The results of sub-requests are normalized to convert spatial feature records from different database types into records to be aggregated with a pre-defined unified structure, and to add map sheet identifiers to the records to be aggregated. Grouping is performed on the records to be aggregated based on the data object identifier, and records to be aggregated with the same data object identifier are determined to be cross-map sheet duplicate records of the same target spatial feature; For duplicate records across map sheets, generate a unique aggregated record and retain the map sheet identifier set or physical map sheet database identifier set corresponding to the unique aggregated record; The unique aggregated record is merged with the non-duplicate records to be aggregated to form a unified result, and the unified result is returned to the upper-layer application through a unified data access interface.

[0062] Specifically, the sub-request results returned by each physical map sheet database for a sub-request include spatial feature records and their corresponding data object identifiers. Spatial feature records contain at least geometric data and attribute data, whereby the geometric data describes the shape and location of the spatial feature, and the attribute data describes the business attributes of the spatial feature.

[0063] To adapt to scenarios with coexisting heterogeneous database types, spatial feature records returned by different physical map sheet databases may differ in field naming, geometric representation, attribute type representation, and default fields. For example, the attribute field types returned for the same type of road feature in a file-based data source may differ from those returned in a lightweight database, and geometric data may also use different internal representations. To ensure that subsequent aggregation and deduplication can be performed on a unified data structure, the result aggregation unit first performs result normalization processing after receiving the sub-request results.

[0064] In some examples, result normalization involves converting spatial feature records from different database types into records to be aggregated with a pre-defined unified structure, and supplementing the records with their respective map sheet identifiers. The pre-defined unified structure includes at least a data object identifier field, a geometric data field, an attribute data field, and a map sheet identifier field. The data object identifier field is used for subsequent grouping and deduplication; the geometric and attribute data fields are used to form feature representations that can be directly used by upper-level applications; and the map sheet identifier field identifies which map sheet database the record to be aggregated originates from, allowing for data source tracing when needed or providing a basis for subsequent editing and decomposition. When performing normalization, the result aggregation unit can write the map sheet identifier into the map sheet identifier field of the record to be aggregated based on the hit map sheet identifier bound by the dynamic data scheduling engine when issuing sub-requests, thereby avoiding ambiguity caused by relying solely on data source connection information to infer the source.

[0065] In some examples, the result aggregation unit groups the records to be aggregated based on data object identifiers and identifies records with the same data object identifier as cross-map sheet duplicate records of the same target spatial feature. Here, the data object identifier is a globally consistent feature identifier or a composite identifier formed by combining layer identifiers and feature identifiers, ensuring consistency of identity for the same feature across map sheets. For cross-map sheet features, represented as a4d4 in this example, this feature exists in the physical map sheet databases corresponding to map sheet DN105000513 and map sheet DN105000514. Therefore, in queries covering two map sheets, both physical map sheet databases will return spatial feature records with the data object identifier a4d4. The result aggregation unit can identify these duplicate records as cross-map sheet duplicate records by grouping them based on data object identifiers. For features that exist only in a single map sheet, such as 0edc in the example, only the corresponding record will be returned in DN105000513, and naturally, no cross-database duplicate group will be formed after grouping.

[0066] In some examples, for duplicate records across map sheets, the result aggregation unit generates a unique aggregated record and retains the map sheet identifier set or physical map sheet database identifier set corresponding to the unique aggregated record. A unique aggregated record means that only one record representing the target spatial feature is presented on the upper-level application side, rather than presenting duplicate records from different map sheet databases separately.

[0067] When generating a unique aggregated record, the aggregation unit can employ a record selection strategy based on preset priorities. This could include selecting a record as the master record based on the order of the hit map sheet sets, sorting by map sheet identifiers, or determining record integrity. Simultaneously, the map sheet identifiers corresponding to the source records of the data object in other map sheets are added to the map sheet identifier set, thus forming a "unique aggregated record—source map sheet set" association. This association information can be used by upper-layer applications to query the source of elements when needed, and it can also be provided to the editing and edge-joining processing engine to determine the update scope of cross-map sheet elements when subsequent editing requests occur, ensuring that editing of cross-map sheet elements covers their corresponding records in multiple map sheet databases.

[0068] In some examples, the result aggregation unit merges unique aggregated records with non-duplicate records to be aggregated to form a unified result, and returns the unified result to the upper-layer application through a unified data access interface. The unified result is organized with a preset unified structure, enabling the upper-layer application to render, select, and further query the unified result as a single virtual data source, without being aware that the data comes from multiple physical map sheet databases.

[0069] For example, when an upper-layer application requests to cover the full range of data for DN105000513 and DN105000514, DN105000513 returns a4d4 and 0edc, while DN105000514 returns a4d4. The result aggregation unit determines that the two a4d4 records are duplicate records across map sheets, generates a unique aggregated record, and retains the map sheet identifier set {DN105000513, DN105000514}. Simultaneously, 0edc is retained as a non-duplicate record, ultimately forming a unified result containing both a4d4 and 0edc, which is returned to the upper-layer application. Because the unified result contains only one a4d4 record, the upper-layer application will not encounter the problem of duplicate overlay or selection of the same cross-map sheet feature when displaying and querying.

[0070] The following is a supplementary explanation of the output behavior of the unified result in conjunction with the rule of "loading only a portion of the map sheet". When only map sheet DN105000514 is loaded, when the upper-level application initiates a query request, it only hits DN105000514 and returns a4d4. The unified result output by the result aggregation unit includes a4d4, and its map sheet identifier set only includes DN105000514. Since DN105000513 is missing, the system will impose a read-only restriction on a4d4 in subsequent editing stages to avoid disrupting the consistency across map sheet objects.

[0071] When only map sheet DN105000513 is loaded, the upper-layer application, upon initiating a query request, hits DN105000513 and returns a4d4 and 0edc. The unified result output by the result aggregation unit includes a4d4 and 0edc. The map sheet identifier set of a4d4 only contains DN105000513, while 0edc is a single map sheet element, which can be edited within the map sheet in subsequent editing stages. Therefore, the map sheet identifier set retained by the result aggregation unit in the unified result is not only used for source marking after deduplication but also provides a data foundation for subsequent editing permission control and operation decomposition.

[0072] Through the above implementation, the result aggregation unit in this embodiment can perform structure normalization, group deduplication based on data object identifier, and retention of source map sheet sets on the sub-request results from multiple physical map sheet databases, and return them to the upper-layer application in the form of unified results through a unified data access interface. This avoids repeated presentation and selection of cross-map sheet elements in the query and visualization process, improves the consistency and usability of multi-map sheet range query results, and provides reliable data source association information for the determination of the range and consistency maintenance of subsequent cross-map sheet editing.

[0073] In some embodiments, the editing and edge-joining processing engine is used for: Parse the edit request to obtain the edit space range, the target data object identifier, and the edit operation type; Submitting a map sheet retrieval request to the metadata index based on the editing space range enables the metadata index to return the set of map sheets traversed by the editing request based on the spatial intersection relationship between the editing space range and the spatial ranges of each map sheet; When the set of map sheets traversed by the editing request contains multiple map sheets, a sub-editing operation set is generated based on the editing operation type. The sub-editing operation set includes: Perform the first sub-edit operation of deletion or update in the physical map sheet database corresponding to the target data object identifier; Perform a second sub-edit operation—writing or updating—on the target data object identifier in the physical map sheet database corresponding to the target map sheet.

[0074] Specifically, after receiving an edit request from the upper-layer application, the editing and edge-joining processing engine first parses the edit request to obtain the edit space range, the target data object identifier, and the edit operation type. The edit space range describes the spatial envelope range involved in this edit operation. It is usually determined by the union envelope range of the geometry before and after the edit, or by the coverage range of the edit trajectory, to ensure that when a feature moves across the map sheet boundary, the map sheet it traverses can be completely identified.

[0075] The target data object identifier is used to uniquely identify the spatial feature being edited, such as 0edc and a4d4 in the example. The edit operation type is used to indicate the category of the edit action, which includes at least one of move, geometric modification, attribute modification, and deletion; among them, move operations are usually accompanied by changes in the geometric position of the feature, which may cause the feature to migrate from the source map sheet to the target map sheet, or cause the records of cross-map sheet features in multiple map sheet databases to need to be updated synchronously.

[0076] In some examples, the editing and edge-joining processing engine submits map sheet retrieval requests to the metadata index based on the editing spatial range. This allows the metadata index to return the set of map sheets traversed by the editing request, based on the spatial intersection relationship between the editing spatial range and the spatial ranges of each map sheet. Here, "the set of map sheets traversed" refers to the set of all map sheets that have a spatial intersection relationship with the editing spatial range, including the map sheet where the editing operation starts, the map sheet where the editing operation ends, and the map sheets through which the editing trajectory passes.

[0077] To ensure that editing across map sheet boundaries does not miss adjacent map sheets, this embodiment treats tangent boundaries as intersecting boundaries. Therefore, when the editing space crosses a map sheet boundary line, both map sheets on both sides of the boundary will be returned. In a practical scenario, when 0edc moves and edits within map sheet DN105000513, the editing space intersects with the map sheet space of DN105000513 but not with DN105000514. Therefore, the set of map sheets traversed only includes DN105000513. When 0edc moves from DN105000513 to DN105000514, the editing space covers both the starting and ending points of the movement and crosses the map sheet boundary. Therefore, the set of map sheets traversed includes both DN105000513 and DN105000514. When cross-map sheet editing is performed on the cross-map sheet line data a4d4, the editing space covers the area where the cross-map sheet object is located, and both map sheets will be hit.

[0078] In some examples, when the set of map sheets traversed by the edit request contains multiple map sheets, the editing and edge-joining processing engine generates a set of sub-editing operations based on the edit operation type, including at least a first sub-editing operation and a second sub-editing operation. To ensure the determinism of subsequent transaction execution, this embodiment summarizes the rules for determining the source map sheet and the target map sheet as follows: the source map sheet is the map sheet to which the spatial feature record corresponding to the target data object belonged before editing, and the target map sheet is the map sheet to which the spatial feature record should belong after editing.

[0079] The source map sheet can be determined by the set of map sheet identifiers retained by the result aggregation unit, the map sheet where the geometric point was located before editing, or the current attribution information carried in the editing request; the target map sheet can be determined by the map sheet where the geometric point was located after editing or the target attribution range specified in the editing request.

[0080] When the map sheet set being traversed contains multiple map sheets and the editing operation type is a move operation, the editing and edge-joining processing engine prioritizes determining the source map sheet by its affiliation before editing and determining the target map sheet by its landing point after editing, thereby providing a clear object for subsequent deletion, writing, or update sub-operations.

[0081] In some examples, the first sub-edit operation in the sub-edit operation set is used to perform a deletion or update on the target data object identifier in the physical map sheet database corresponding to the source map sheet, and the second sub-edit operation is used to perform a write or update on the target data object identifier in the physical map sheet database corresponding to the target map sheet.

[0082] The combined strategies for "delete, write, update" for different editing operation types are as follows: When the editing operation type is cross-map sheet migration and there is no record corresponding to the target data object identifier in the target map sheet database, the first sub-editing operation is deletion and the second sub-editing operation is write; when the editing operation type is cross-map sheet migration and there is already a record corresponding to the target data object identifier in the target map sheet database, the first sub-editing operation is deletion and the second sub-editing operation is update; when the editing operation type is cross-map sheet object consistent update, both the first and second sub-editing operations are updates, and the same or related geometric and attribute updates are performed on the corresponding records in each hit map sheet database.

[0083] The following example illustrates the breakdown of the above operations. Taking "moving 0edc from DN105000513 to DN105000514" as an example, the upper-layer application submits an edit request. The target data object is identified as 0edc, the edit space covers the start and end points of the move, and the edit operation type is "move". The editing and edge-joining processing engine calls the metadata index to determine the map sheet set to be crossed as DN105000513 and DN105000514. Based on the pre-edit attribution, the source map sheet is determined to be DN105000513, and based on the post-edit landing point, the target map sheet is determined to be DN105000514. Subsequently, a set of sub-edit operations is generated. The first sub-edit operation is to delete 0edc in the physical map sheet database corresponding to DN105000513, and the second sub-edit operation is to write 0edc in the physical map sheet database corresponding to DN105000514. This set of sub-edit operations is then output to the transaction coordination unit to execute a multi-database transaction.

[0084] Taking "cross-map sheet editing a4d4" as an example, the target data object is identified as a4d4, the editing space covers the boundary area of ​​two map sheets, and the editing operation type is geometric modification or attribute modification. The editing and edge processing engine determines that the map sheet sets crossed are DN105000513 and DN105000514, and generates two update sub-operations to update a4d4 in the two physical map sheet databases respectively, so as to maintain the consistency of the cross-map sheet object records in multiple map sheet databases.

[0085] Taking "moving a4d4 to DN105000514" as an example, if the editing and edge processing engine determines that a4d4 already exists in the target map sheet database, it generates the first sub-editing operation to delete a4d4 in DN105000513 and the second sub-editing operation to update a4d4 in DN105000514, thereby realizing cross-map sheet migration and ownership adjustment.

[0086] Through the above implementation, the editing and edge-joining processing engine in this embodiment can accurately identify the set of map sheets that the editing request traverses based on the editing space range, and in cross-map sheet scenarios, decompose an editing request into sub-editing operations targeting different map sheet databases based on the editing operation type, forming a set of sub-operations that can be directly executed by the transaction coordination unit. This enables cross-map sheet migration and cross-map sheet consistent updates to have clear database paths and operation boundaries, reducing the complexity of manual switching and manual splitting, and improving the data consistency and operational stability of the multi-map sheet editing process.

[0087] In some embodiments, the transaction coordination unit is used for: The set of physical map sheet databases participating in the editing is determined based on the set of sub-editing operations, and access connections to each physical map sheet database are established respectively; Local map sheet transactions are started on each physical map sheet database, and associated transaction identifiers are generated for the same editing request to be used for cross-database record association; According to the set of sub-edit operations, execute write, update or delete sub-edit operations in the corresponding physical map sheet database, and obtain the execution status of each sub-edit operation.

[0088] Specifically, the transaction coordination unit first determines the set of physical map sheet databases participating in the editing based on the set of sub-editing operations, and then establishes access connections to each physical map sheet database. Each sub-editing operation in the set of sub-editing operations is bound to a map sheet identifier or a physical map sheet database identifier, and the transaction coordination unit summarizes the set of physical map sheet databases participating in the editing based on this.

[0089] The process of establishing access connections can reuse the data access adapter mechanism of the dynamic data scheduling engine. This involves selecting a matching data access adapter for each physical map sheet database type and establishing an access connection based on the access path and connection parameters. When a connection has already been established and is valid in a previous scheduling link, the transaction coordination unit can directly reuse the existing connection handle to reduce the overhead of repeated connections during cross-map sheet editing. For editing requests involving only a single map sheet, where the set of physical map sheet databases involved in the editing is a single-element set, the transaction coordination unit can also use the same connection establishment process to ensure consistency in the processing links.

[0090] In some examples, the transaction coordination unit initiates local map sheet transactions on each physical map sheet database and generates associated transaction identifiers for the same edit request to associate records across databases. A local map sheet transaction refers to a transaction boundary established within a single physical map sheet database, used to ensure that write, update, or delete operations within that database are committed or rolled back atomically.

[0091] The transaction coordination unit generates a unique transaction identifier for the same editing request and associates this transaction identifier with information such as the identifiers of each map sheet involved in the editing, the type of each sub-editing operation, and the identifier of the target data object. This allows for subsequent tracking of the cross-database execution process, summarizing the execution status, and locating the cause of failure based on the same transaction identifier. This transaction identifier can be formed by combining a system-generated sequence number, a timestamp, and a request sequence number, or it can be generated by mapping the request identifier from the upper-layer application. However, in this embodiment, the specific generation method is not limited; it is only required that it can uniquely identify the cross-database execution process of a cross-map sheet editing request within the virtual database.

[0092] Furthermore, the transaction coordination unit executes write, update, or delete sub-edit operations in the corresponding physical map sheet database according to the sub-edit operation set, and obtains the execution status of each sub-edit operation. Each sub-edit operation in the sub-edit operation set includes a target data object identifier, an operation type, and operation parameters matching the operation type. Specifically, a write operation includes at least the geometric data and attribute data of the written feature, an update operation includes at least the target data object identifier of the updated feature and the updated geometric data or attribute data, and a delete operation includes at least the target data object identifier of the deleted feature.

[0093] After initiating local map sheet transactions in each physical map sheet database, the transaction coordination unit executes sub-editing operations sequentially or in parallel, recording the execution status of each sub-editing operation upon completion. The execution status includes at least a success or failure flag, and in the event of a failure, the reason for the failure and the map sheet identifier of the failure are further recorded, so as to trigger rollback or compensation and return locatable problem information to the upper-layer application.

[0094] The above process is illustrated below with a specific example. Taking "moving 0edc from DN105000513 to DN105000514" as an example, the set of sub-edit operations generated by the editing and edge-joining processing engine includes: a sub-edit operation to delete 0edc in the physical map sheet database corresponding to DN105000513, and a sub-edit operation to write 0edc in the physical map sheet database corresponding to DN105000514. Based on this, the transaction coordination unit determines that the set of physical map sheet databases participating in the editing is the two databases corresponding to DN105000513 and DN105000514, and establishes access connections to them respectively; then, local map sheet transactions are started on both databases, and a transaction identifier is generated for the editing request to associate records; then, the sub-edit operations to delete 0edc and write 0edc are executed respectively, and the execution status of the two sub-edit operations is obtained. When both execution statuses are successful, the cross-database execution status corresponding to the transaction identifier is marked as a committable status for use in the subsequent commit phase.

[0095] Taking "editing a4d4 across map sheets" as an example, the set of sub-edit operations includes updating a4d4 in both databases DN105000513 and DN105000514. The transaction coordination unit also starts transactions in both databases and executes the update operations, obtaining their respective execution statuses to support consistent updates of cross-map sheet objects across multiple databases. Taking "moving a4d4 to DN105000514" as another example, the set of sub-edit operations includes deleting a4d4 in DN105000513 and updating a4d4 in DN105000514. The transaction coordination unit executes these operations and records their execution statuses, providing a basis for subsequent commit or failure handling.

[0096] Through the above implementation, the transaction coordination unit in this embodiment can determine the set of physical map sheet databases participating in the editing based on the sub-editing operation set, establish access connections and start local map sheet transactions on each database, and then perform write, update or delete operations according to the sub-editing operation set and summarize the execution status. This provides a unified cross-database execution boundary and traceable transaction association records for cross-map sheet editing, reduces execution uncertainty in the cross-database editing process, and improves the controllability and problem localization capability of multi-map sheet editing requests.

[0097] In some embodiments, the transaction coordination unit is further configured to: When any sub-editing operation returns to a failure state, a rollback instruction is sent to the physical map sheet database that has returned to a success state to roll back the local map sheet transaction, and the failed map sheet identifier, the type of failed sub-editing operation, and the reason for failure are recorded in the transaction log associated with the transaction identifier. When all sub-edit operations return a success status, a commit command is sent to each physical map sheet database to commit the local map sheet transaction, and the commit result is returned to the upper layer application as the execution result of the editing request.

[0098] Specifically, after executing each sub-editing operation, the transaction coordination unit summarizes and determines the execution status, forming a cross-database execution status set associated with the transaction identifier. The execution status of each sub-editing operation includes at least an execution result flag, a corresponding map sheet identifier, and the sub-editing operation type, where the execution result flag indicates success or failure. When the transaction coordination unit detects that any sub-editing operation returns to a failure status, it immediately enters the failure rollback path.

[0099] In the failure rollback path, the transaction coordination unit sends a rollback instruction to the physical map sheet database that has returned a success status, so as to roll back the local map sheet transactions that have been started on the corresponding database, thereby undoing the successfully executed write, update or delete operations, and returning the cross-database editing to the state before editing.

[0100] To ensure the traceability of rollback execution and subsequent compensation processing, the transaction coordination unit synchronously records the failed map sheet identifier, the type of failed sub-editing operation, and the reason for failure in the transaction log associated with the transaction identifier. It can also further record information such as the target data object identifier associated with the failure, the set of target map sheets to be rolled back, and the time when the rollback instruction was issued, so as to form a consistent audit record for cross-database editing.

[0101] In some examples, when the transaction coordination unit determines that all sub-edit operations have returned a successful status, it enters the unified commit path. In the unified commit path, the transaction coordination unit issues commit commands to each physical map sheet database to commit the local map sheet transactions, thus making the previously executed write, update, or delete operations in each database permanent in their respective databases. The commit command can be issued by the data access adapter based on an established access connection and is associated with a transaction identifier so that the set of map sheets successfully committed and the commit time are recorded in the log.

[0102] After receiving the submission confirmations from each physical map sheet database, the transaction coordination unit summarizes the submission results into the execution results of the editing requests and returns them to the upper-layer application. The submission results include at least the transaction identifier, the set of participating map sheets, the final status of each sub-editing operation, and optional failure information placeholder fields, enabling the upper-layer application to consistently present cross-map sheet editing results or further trigger interface refreshes.

[0103] The following example illustrates the specific triggering process of failure rollback and unified commit. Taking "moving 0edc from DN105000513 to DN105000514" as an example, after the transaction coordination unit executes the deletion and writing of 0edc in the two databases respectively, assuming that both sub-editing operations return a successful status, the transaction coordination unit issues commit commands to DN105000513 and DN105000514 respectively, committing the local map sheet transactions in the two databases, and returning the commit results to the upper-layer application. The upper-layer application refreshes the display accordingly, showing the state of 0edc located in map sheet DN105000514. If an anomaly occurs in this example, such as DN105000514 failing to write to 0edc while DN105000513 successfully deletes 0edc, the transaction coordination unit detects the failure and enters the failure rollback path. It issues a rollback command to DN105000513 to undo the executed deletion operation. At the same time, it records the failure map identifier as DN105000514, the failure sub-edit operation type as write, and the failure reason information in the transaction log. The failure result is then returned to the upper-layer application, enabling the upper-layer application to display the anomaly and maintain consistency between the display and the data.

[0104] Taking "cross-map sheet editing of a4d4" as an example, if the updates to a4d4 are successful in both map sheet libraries, the transaction coordination unit commits the transactions for both libraries. If the update in one library fails, the transaction coordination unit rolls back the update in the other library and records the failure information to prevent a4d4 from having inconsistent attributes or geometry in the two map sheet libraries. Taking "moving a4d4 to DN105000514" as another example, the transaction coordination unit deletes a4d4 in DN105000513 and updates a4d4 in DN105000514, and commits the transaction after both are successful. If the update in DN105000514 fails, the deletion in DN105000513 is rolled back, thus preventing a4d4 from being lost or its ownership unclear.

[0105] Through the above implementation, the transaction coordination unit in this embodiment can choose to commit uniformly or roll back if it fails based on the execution status of each sub-editing operation in the cross-map editing scenario. It also records the failed map, the type of failed operation and the reason for failure through the transaction log associated with the transaction identifier. This reduces the risk of data fragmentation caused by partial success in cross-database editing, improves the data consistency control capability and anomaly traceability in the cross-map editing process, and enables the upper-layer application to obtain clear editing result feedback to support interface refresh and problem localization.

[0106] In some embodiments, when the transaction coordination unit performs compensation operations on sub-editing operations, it records the target map area identifier, target data object identifier, operation type, and pre-operation status information of each sub-editing operation based on the transaction log. When it is determined that there are sub-editing operations that have failed to execute, it performs reverse update or reverse write on the sub-editing operations that have been successfully executed based on the pre-operation status information to complete the compensation.

[0107] Specifically, before initiating compensation, the transaction coordination unit establishes transaction log entries based on transaction identifiers and writes the key audit fields of each sub-editing operation into the transaction log. The transaction log records at least the target map sheet identifier, the target data object identifier, the operation type, and the pre-operation status information. Among them, the target map sheet identifier is used to locate the specific physical map sheet database that needs compensation, the target data object identifier is used to locate the spatial feature record that needs to be restored, the operation type is used to indicate whether the atomic editing action belongs to write, update, or delete, and the pre-operation status information is used to describe the baseline status of the corresponding spatial feature record before the execution of the sub-editing operation.

[0108] In some examples, the pre-operation state information includes at least: whether the spatial feature exists in the corresponding physical map sheet database before execution, the geometric data before execution, the attribute data before execution, and optional version markers or update timestamps. The transaction coordination unit reads and caches the above pre-operation state information before or during the execution of the sub-edit operation, and persists it to the transaction log after the sub-edit operation starts or succeeds, so as to ensure that usable recovery basis can be obtained during compensation.

[0109] Furthermore, when the transaction coordination unit determines that there are sub-edit operations that have failed, it locates the set of successfully executed sub-edit operations based on the transaction log, and generates compensation sub-operations according to the pre-operation state information corresponding to these sub-edit operations. Then, it performs reverse update or reverse write on the successfully executed sub-edit operations. Reverse update refers to restoring the geometric and attribute data of the spatial feature records to the baseline values ​​recorded in the pre-operation state information when the atomic edit operation is an update. Reverse write refers to performing data recovery in the opposite direction to the baseline content based on the "existence" recorded in the pre-operation state information when the atomic edit operation is a write or delete.

[0110] For example, if an atomic edit operation is a write operation and the pre-operation state information indicates that the element did not exist before execution, then the compensation sub-operation is to delete the element record; if an atomic edit operation is a delete operation and the pre-operation state information indicates that the element existed before execution, then the compensation sub-operation is to write the element record in reverse according to the pre-operation state information; if an atomic edit operation is an update operation and the pre-operation state information indicates that the element existed before execution, then the compensation sub-operation is to update and restore geometry and attributes in reverse; if an atomic edit operation is an update operation but the pre-operation state information indicates that the element did not exist before execution, then the compensation sub-operation can be to delete the element record or write an empty baseline record, depending on the system's recovery strategy for abnormal states, but all are based on the pre-operation state information in the transaction log.

[0111] In some examples, the execution flow of the compensation operation is consistent with that of the regular sub-editing operation. Specifically, the transaction coordination unit establishes an access connection to the corresponding physical map sheet database for the target map sheet identifier requiring compensation, initiates a local map sheet transaction on the corresponding database, executes the compensation sub-operation, and obtains the compensation execution status. Subsequently, based on the compensation execution status, it submits or records compensation failure information. To avoid conflicts caused by concurrent compensation and normal editing, in this embodiment, the transaction coordination unit marks transaction identifiers with mutual exclusion during the compensation period, ensuring that editing requests associated with the same transaction identifier do not trigger new sub-editing operations before compensation is completed. Simultaneously, the transaction coordination unit writes the execution results of the compensation sub-operation to the transaction log, forming a complete link record of "original execution status—compensation execution status" to support subsequent auditing and anomaly tracking.

[0112] Through the above implementation, in this embodiment, the transaction coordination unit can generate compensation sub-operations based on the target map sheet identifier, target data object identifier, operation type, and pre-operation state information recorded in the transaction log in the case of cross-map sheet editing failure. It can also perform reverse update or reverse write to the successfully executed sub-editing operations to complete the compensation. Thus, it still has the ability to restore the consistent state of the object of attention under complex conditions such as rollback unreachability, weak network, or partial commit, improves the final consistency guarantee level of the cross-map sheet editing process, and enhances the traceability of data recovery and problem localization capabilities in abnormal scenarios.

[0113] The above embodiments have described in detail the specific composition and functions of the multi-map virtual database map data management system of this application. The implementation process of the multi-map virtual database map data management method of this application will be described in detail below with reference to specific embodiments. Figure 4 This is a flowchart illustrating the multi-map virtual database map data management method provided in this application embodiment, as shown below. Figure 4 As shown, the method may specifically include the following steps: S401, Receive data request submitted by upper layer application, and parse data request to obtain target space range and target data object identifier; S402, based on the target spatial range, query the metadata index library to determine the set of hit map sheets and the set of physical map sheet databases associated with the set of hit map sheets respectively; S403: Establish an access connection based on the physical map sheet database set, generate a sub-request carrying the target spatial range and the target data object identifier, and send the sub-request to each physical map sheet database to obtain the sub-request result or sub-operation execution status. S404: When the data request is a query request, it receives the sub-request results returned by each physical map sheet database, performs merging and deduplication on the sub-request results based on the data object identifier, forms a unified result, and returns the unified result to the upper layer application. S405: When the data request is an edit request, the set of map sheets that the edit request traverses is determined based on the metadata index. If the set of map sheets contains multiple map sheets, the edit request is decomposed into sub-edit operations targeting each map sheet database. Transactions are started and sub-edit operations are executed on the corresponding multiple physical map sheet databases. If a sub-edit operation fails, a compensation operation is triggered for the successfully executed sub-edit operations and the transaction log is recorded. When all sub-edit operations are executed successfully, the transactions of each physical map sheet database are committed and the execution results are returned to the upper layer application.

[0114] It should be understood that the sequence number of each step in the above method embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0115] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although the technical solutions of this application have been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A multi-map virtual database map data management system, characterized in that, include: Multiple physical map sheet databases, each corresponding to a different map sheet or geographic block, are used to store spatial feature data and attribute data; The metadata index is used to store the map sheet identifier, map sheet spatial range, database type, access path, connection parameters, and spatial adjacency relationship between map sheets corresponding to each physical map sheet database, and is used to respond to map sheet retrieval requests for a target spatial range to return the set of hit map sheets; A virtual database is used to provide a unified data access interface for upper-layer applications and includes: The dynamic data scheduling engine is used to receive data requests submitted by upper-layer applications, parse the data requests to obtain the target spatial range and the target data object identifier, call the metadata index library based on the target spatial range to determine the hit map sheet set and the corresponding physical map sheet database set, establish an access connection to the physical map sheet database set and send out sub-requests respectively. The result aggregation unit is used to receive the sub-request results returned by each of the physical map sheet databases, perform merging and deduplication on the sub-request results based on the data object identifier, and output a unified result to the upper layer application. The editing and edge-joining processing engine is used to determine the set of map sheets that the editing request traverses based on the metadata index when an editing request is received, and to decompose the editing request into sub-editing operations targeting each map sheet database when the set of map sheets contains multiple map sheets; The transaction coordination unit is used to open transactions for multiple physical map sheet databases corresponding to the sub-editing operation and execute the sub-editing operation. When the sub-editing operation fails, it triggers a compensation operation for the successfully executed sub-editing operation and records the transaction log. When all the sub-editing operations are successfully executed, it commits the transactions of each physical map sheet database and returns the execution results to the upper layer application.

2. The system according to claim 1, characterized in that, The metadata index library includes a map sheet index table, which is used to associate and store map sheet identifiers, map sheet spatial ranges, physical map sheet database types, physical map sheet database access paths, connection parameters, and the set of layer identifiers contained in the physical map sheet database. When determining the set of hit map sheets, the dynamic data scheduling engine filters based on the spatial intersection relationship between the target spatial range and the map sheet spatial range, and performs secondary filtering on the physical map sheet database set based on the set of layer identifiers.

3. The system according to claim 1, characterized in that, The dynamic data scheduling engine is used for: Receive data requests submitted by upper-layer applications, the data requests carrying spatial range parameters for limiting the scope of querying or editing and data object parameters for indicating the target data object; The data request is identified by request type to determine whether it is a query request or an edit request, and the corresponding parsing template is invoked based on the request type. Based on the parsing template, the target spatial range is extracted from the spatial range parameters, and the target spatial range is standardized into a preset spatial range expression; Based on the parsing template, the target data object identifier is extracted from the data object parameter, and a target data object identifier set is generated when the data object parameter contains multiple data objects; The target spatial range and the target data object identifier or the set of target data object identifiers are output as the parsing result of the data request.

4. The system according to claim 1, characterized in that, The dynamic data scheduling engine is also used for: Submit a map sheet retrieval request carrying the target spatial range to the metadata index library, so that the metadata index library can filter the set of hit map sheets based on the spatial intersection relationship between the target spatial range and each map sheet spatial range, and return the database type, access path and connection parameters respectively associated with the set of hit map sheets; Based on the database type, the corresponding data access adapter is selected for each physical map sheet database set, and the data access adapter establishes an access connection according to the access path and connection parameters. According to the hit map sheet set, a sub-request corresponding to each physical map sheet database is generated. The sub-request carries the target spatial range and the target data object identifier or target data object identifier set, and is used to limit the search range or update object in the corresponding physical map sheet database. The sub-requests are sent to the physical map databases with established access connections to obtain the sub-request results or sub-operation execution status.

5. The system according to claim 1, characterized in that, The result aggregation unit is used for: Receive the sub-request results returned by each of the physical map sheet databases in response to the sub-request. The sub-request results include spatial feature records and their corresponding data object identifiers. The spatial feature records contain geometric data and attribute data. The results of the sub-requests are normalized to convert spatial feature records from different database types into records to be aggregated with a preset unified structure, and map sheet identifiers are added to the records to be aggregated. Based on the data object identifier, the records to be aggregated are grouped, and the records to be aggregated with the same data object identifier are determined to be cross-map sheet duplicate records of the same target spatial feature; For the repeated records across map sheets, a unique aggregate record is generated and the map sheet identifier set or physical map sheet database identifier set corresponding to the unique aggregate record is retained; The unique aggregated record is merged with the non-duplicate records to be aggregated to form a unified result, and the unified result is returned to the upper-layer application through the unified data access interface.

6. The system according to claim 1, characterized in that, The editing and edge-joining processing engine is used for: The edit request is parsed to obtain the edit space range, the target data object identifier, and the edit operation type; Based on the editing space range, a map sheet retrieval request is submitted to the metadata index, so that the metadata index returns the set of map sheets traversed by the editing request based on the spatial intersection relationship between the editing space range and each map sheet space range; When the set of map sheets traversed by the edit request contains multiple map sheets, a sub-edit operation set is generated based on the edit operation type, and the sub-edit operation set includes: In the physical map sheet database corresponding to the source map sheet, perform a first sub-edit operation to delete or update the target data object identifier; In the physical map sheet database corresponding to the target map sheet, perform a second sub-edit operation to write or update the target data object identifier.

7. The system according to claim 1, characterized in that, The transaction coordination unit is used for: Based on the set of sub-editing operations, determine the set of physical map sheet databases to participate in the editing, and establish access connections to each of the physical map sheet databases respectively; Local map sheet transactions are initiated on each of the aforementioned physical map sheet databases, and associated transaction identifiers are generated for the same editing request to be used for cross-database record association; According to the set of sub-edit operations, write, update or delete sub-edit operations are executed in the corresponding physical map sheet database, and the execution status of each sub-edit operation is obtained.

8. The system according to claim 7, characterized in that, The transaction coordination unit is also used for: When any sub-editing operation returns to a failure state, a rollback instruction is sent to the physical map sheet database that has returned to a success state to roll back the local map sheet transaction, and the failed map sheet identifier, the type of failed sub-editing operation, and the reason for failure are recorded in the transaction log associated with the transaction identifier. When all the sub-editing operations return a success status, a submission instruction is sent to each of the physical map sheet databases to submit the local map sheet transaction, and the submission result is returned to the upper-layer application as the execution result of the editing request.

9. The system according to claim 8, characterized in that, When performing compensation operations on the sub-editing operations, the transaction coordination unit records the target map area identifier, target data object identifier, operation type, and pre-operation status information of each sub-editing operation based on the transaction log. When it is determined that there are sub-editing operations that have failed to execute, it performs reverse update or reverse write on the sub-editing operations that have been successfully executed based on the pre-operation status information to complete the compensation.

10. A method for managing multi-map sheet virtual database map data based on the system described in any one of claims 1 to 9, characterized in that, include: Receive data requests submitted by upper-layer applications and parse the data requests to obtain the target spatial range and the target data object identifier; Based on the target spatial range, query the metadata index library to determine the set of hit map sheets and the set of physical map sheet databases associated with the set of hit map sheets respectively; An access connection is established based on the physical map sheet database set, and a sub-request carrying the target spatial range and the target data object identifier is generated. The sub-request is then sent to each physical map sheet database to obtain the sub-request result or sub-operation execution status. When the data request is a query request, the system receives the sub-request results returned by each physical map sheet database, merges and deduplicates the sub-request results based on the data object identifier to form a unified result, and returns the unified result to the upper-layer application. When the data request is an edit request, the set of map sheets traversed by the edit request is determined based on the metadata index. If the set of map sheets contains multiple map sheets, the edit request is decomposed into sub-edit operations targeting each map sheet database. Transactions are opened on the corresponding multiple physical map sheet databases and the sub-edit operations are executed. If any sub-edit operation fails, a compensation operation is triggered for the successfully executed sub-edit operations and a transaction log is recorded. When all sub-edit operations are successfully executed, the transactions of each physical map sheet database are committed, and the execution results are returned to the upper-layer application.

Images