A floor plan mapping system and method

Abstract

The present application relates to remote sensing data processing technical field, specifically to a kind of one edition cartography system and method, wherein, one edition cartography system includes the storage component layer, service engine layer, Web interface layer and Web presentation layer connected in turn, service engine layer is configured to carry out the import and export of map patch data, the spatial merging of change map patch and present situation map patch, the spatial segmentation of map patch and image based on administrative division boundary, and map service release processing of map patch vector and image.The above scheme is realized by using layered microservice architecture and hybrid storage mechanism, the decoupling of data storage, service processing, interface calling and visual presentation in cartography production process is realized, and the system expansibility and modular degree are improved.

Description

Technical Field

[0001] This invention relates to the field of remote sensing data processing technology, and more specifically, to a single-map mapping system and method. Background Technology

[0002] In ecological remote sensing monitoring, it is necessary to identify and extract the range and type of ecological resource changes in each province on an annual basis. This involves generating change patch data through parallel processing of multiple sub-tasks. These change patches include attribute information such as vector range, previous image type, and subsequent image type. After multiple rounds of review and confirmation, the results of all sub-tasks enter the map production stage. This stage involves generating vector files for provincial-level change patches and current status patches, performing image mosaicking, and further segmenting the data according to county-level administrative divisions to generate county-level result files. Ultimately, this forms a two-tiered provincial-county mapping result system to support the visualization and delivery of results.

[0003] However, existing technical solutions lack a unified layered architecture design and automated process control mechanism. Key aspects such as multi-sub-task data integration, provincial and county-level output production, and collaborative processing of image and vector data rely on manual operation or decentralized tools, resulting in low data processing efficiency, difficulty in process collaboration, and chaotic storage management. Furthermore, they cannot achieve dynamic adaptation and seamless connection between production processes and map visualization, making it difficult to meet the technical requirements of large-scale ecological remote sensing monitoring operations for efficient, automated, and integrated mapping production systems. Summary of the Invention

[0004] The purpose of this invention is to provide a single-page drawing system and method to solve the above-mentioned technical problems.

[0005] In a first aspect, embodiments of the present invention provide a layout mapping system, comprising: a storage component layer, a service engine layer, a web interface layer, and a web rendering layer connected sequentially, wherein: The storage component layer is configured to adopt a hybrid storage architecture that combines a file system and a database system to manage vector files, image files and their metadata index information in a hierarchical manner. The service engine layer is configured to perform import and export of patch data, spatial merging of changed patches and existing patches, spatial segmentation of patches and images based on administrative boundaries, and map service publishing processing of patch vectors and images. The Web interface layer is configured to provide a map production interface, a map submission interface, and a map result query interface; wherein, the map production interface triggers the asynchronous execution of the provincial-level map patch merging and image mosaicking process, and the map submission interface triggers the asynchronous execution of the spatial segmentation and distribution process from the provincial-level results to the district / county-level results. The Web presentation layer is configured to dynamically switch visualization modes based on the map view scale, so as to call map services to publish results or query the database in real time to present map features at different scales.

[0006] Furthermore, the storage component layer includes a shared disk directory and a relational database, wherein: The shared disk directory is configured to establish a hierarchical storage structure based on year and administrative division level, for persistent storage of map feature vector files and image files; wherein, the map feature vector files include changed map feature vector files and current map feature vector files, and the image files are generated through image mosaicking processing; The relational database is configured to store map production records, file location indexes, vector patch attribute information, and spatial range index data.

[0007] Furthermore, the disk shared directory is configured to establish a two-level storage structure, consisting of a first-level directory named by a combination of year and province code under a specified root directory, and a second-level subdirectory named by province or district code. The first-level directory is named by a combination of year and province code, and is used to store the map results data for the corresponding year and province; The second-level subdirectories are named by province or county codes and are used to store vector files of changed features, vector files of current features, and image files within the corresponding administrative division units; The file name includes the year, administrative division code, and map patch type fields, which are configured as retrieval index fields when the map service is published.

[0008] Furthermore, the relational database stores a map production result record table, a map production document record table, a changed map patch storage table, a map result patch storage table, and a boundary point coordinate table, wherein: The map production results record table is used to store the unique identifier of the provincial-level production record, as well as the year, map type, and province code information. The map production file record table is used to store the production status and storage path of vector files and image files at the provincial and county levels. The change patch storage table is used to store the vector boundary of the subtask-level change patch and the previous time image code, previous time image year, subsequent time image code, and subsequent time image year information; The map result patch storage table is used to store the vector boundaries and previous time image code, previous time image year, subsequent time image code, and subsequent time image year information of the merged provincial-level result patches; The coordinate table of the four boundaries is used to store the bounding rectangular vector range of provincial-level results to support map view positioning.

[0009] Furthermore, the service engine layer includes: vector image import / export service, vector image merging service, vector file cutting service, image mosaicking and cutting service, vector publishing service, and image publishing service, wherein: The vector image import / export service is configured to perform bidirectional conversion of image data between the relational database and the vector file; The vector map patch merging service is configured to spatially overlay and merge the current period change patches with the historical period status patches to generate an updated status patch. The vector file cutting service is configured to spatially segment provincial-level map patch vector files based on administrative division boundary vector data to generate district / county-level map patch vector files. The image mosaicking and cutting service is configured to perform mosaicking and merging of multiple images and image spatial segmentation processing based on administrative division boundaries. The vector publishing service and the image publishing service are configured to publish the polygon vector files and image files as map services and generate service call identifiers.

[0010] Furthermore, the vector publishing service and image publishing service are configured to: automatically scan the vector and image files in the shared disk directory, and parse the year, administrative division code, and map type fields contained in the file names; store the fields as index information in the relational database, and establish a mapping relationship between the file storage path and the map service identifier; and, in response to the retrieval request of the Web interface layer, query and return the corresponding map service identifier based on the index information.

[0011] Furthermore, in response to the call to the layout production interface, the service engine layer executes the following asynchronous processing flow: After creating the provincial-level map production results record and initial file record in the relational database, the image mosaicking process is triggered to merge the image files of each sub-task under the current province to generate a provincial-level image file and store it in the disk shared directory, and update the image file storage path and production status in the map production file record table. According to the type of map patch specified in the map production results record, if the map patch type is a changed map patch, then the changed map patch production process is triggered; wherein, the changed map patch production process includes: extracting valid changed map patches from the changed map patch storage table to generate a provincial-level changed map patch vector file and storing it in the disk shared directory; after calculating the outer rectangle coordinates of the vector file and storing it in the relational database, importing the changed map patch into the map production results map patch storage table; If the type of map patch is a current status map patch, then the current status map patch production process is triggered; wherein, the current status map patch production process includes: retrieving the vector file of the current status map patch of the previous year, spatially merging it with the current year's change map patch to generate the current year's current status map patch vector file and storing it in the disk shared directory, and at the same time importing the merged current status map patch into a map result map patch storage table. After completing the above processing steps, update the production status information in the production results record table of the first layout.

[0012] Furthermore, in response to the call to the map submission interface, the service engine layer executes the following asynchronous processing flow: Based on the production results record of the first map, determine whether the vector plots have been modified or changed. If they have been modified or changed, re-export the vector plot files from the first map result plot storage table to overwrite the original provincial-level files. Trigger vector file splitting process, based on administrative division boundary vector data, to split the provincial-level map patch vector file into district / county-level map patch vector files, and store them in the corresponding district / county subdirectories of the disk shared directory; Trigger image file segmentation processing, and divide the provincial-level image file into district / county-level image files based on administrative division boundary vector data, and store them in the corresponding district / county subdirectories of the disk shared directory; Create file records for each district and county in the production file record table of the map, and update their vector file storage path, image file storage path and production status information.

[0013] Furthermore, the Web presentation layer is configured to dynamically switch the map patch visualization mode in response to a request to view the mapping results, based on a comparison between the current map view scale and a preset threshold. When the map view scale is smaller than a preset threshold, the vector publishing service is invoked to obtain the map service identifier, and the provincial or county-level vector vector patches are loaded and aggregated for presentation through the map service interface. When the map view scale is not less than a preset threshold, the mapping result query interface is invoked to retrieve the details of vector patches within the current view range from the map result patch storage table in real time for refined presentation.

[0014] Secondly, embodiments of the present invention provide a method for creating a single-page drawing, comprising: In response to the map production interface call, create a provincial-level map production result record in the relational database, and create an initial file record in the corresponding production file record table; Trigger image mosaicking process, merge the image files of each subtask under the current province to generate a provincial-level image file and store it in the shared disk directory, and update the image file storage path and production status information in the production file record table at the same time; Perform the corresponding patch production processing according to the patch type specified in the production result record: If the type of map patch is a changed map patch, then the valid changed map patch data is extracted from the changed map patch storage table, a provincial-level changed map patch vector file is generated and stored in the disk shared directory, the outer rectangle coordinates of the vector file are calculated and stored in the relational database, and then the changed map patch data is imported into the map patch storage table of the first-level map results. If the type of map patch is a current status map patch, then retrieve the vector file of the current status map patch from the previous year, spatially merge it with the current year's change map patch to generate the vector file of the current year's current status map patch and store it in the shared disk directory. At the same time, import the merged current status map patch data into the map result map patch storage table of the first edition. After the above processing steps are completed, update the production status information in the production results record table of the first version.

[0015] The above solution employs a layered microservice architecture and a hybrid storage mechanism to decouple data storage, service processing, interface calls, and visual presentation in the mapping production process, thereby improving system scalability and modularity. Furthermore, through collaborative management of shared disk directories and relational databases, combined with standardized file naming rules and automated index mapping mechanisms, it achieves unified storage, rapid location, and efficient retrieval of vector files and image files at the province-county level. Additionally, it uses an asynchronous processing mechanism to execute image mosaicking, patch merging, and spatial segmentation tasks in parallel, dynamically switching between service publishing and database query modes based on the map view scale, thus optimizing patch visualization performance and user experience across multiple scales while ensuring production efficiency.

[0016] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing embodiments of the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments of the present invention will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of the architecture of a layout drawing system provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the storage directory structure design and naming rules provided in an embodiment of the present invention; Figure 3 A schematic diagram of the layout-related library table structure provided in an embodiment of the present invention; Figure 4 A schematic diagram of a layout production process provided in an embodiment of the present invention; Figure 5 A schematic diagram of a layout submission process provided in an embodiment of the present invention; Figure 6 A schematic diagram illustrating the process of viewing a single-page drawing result provided in an embodiment of the present invention; Figure 7 A schematic diagram of a layout drawing production and submission page provided in an embodiment of the present invention; Figure 8 A schematic diagram of the interface for presenting the drawing results provided in an embodiment of the present invention. Detailed Implementation

[0019] The embodiments of the technical solution of the present invention will be described in detail below with reference to the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solution of the present invention, and are therefore only examples, and should not be used to limit the scope of protection of the present invention. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and the foregoing description of the drawings are intended to cover non-exclusive inclusion. In the description of the embodiments of the present invention, technical terms such as "first," "second," etc., are only used to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly indicating the number, specific order, or primary or secondary relationship of the indicated technical features. In the description of the embodiments of the present invention, "a plurality of" means two or more, unless otherwise explicitly specified. The reference to "embodiment" herein means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the present invention. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0020] like Figure 1 As shown, an embodiment of the present invention provides a single-page drawing system, comprising: Storage component layer 110 is configured to use a hybrid storage architecture that combines a file system and a database system to manage polygon vector files, image files and their metadata index information in a hierarchical manner. Service Engine Layer 120 is configured to perform import and export of patch data, spatial merging of changed patches and existing patches, spatial segmentation of patches and images based on administrative boundaries, and map service publishing processing of patch vectors and images. Web interface layer 130 is configured to provide a map production interface, a map submission interface and a map result query interface; among them, the map production interface triggers the asynchronous execution of the provincial-level map patch merging and image mosaicking process, and the map submission interface triggers the asynchronous execution of the spatial segmentation and distribution process from the provincial-level results to the district and county-level results. The Web presentation layer 140 is configured to dynamically switch visualization modes based on the map view scale, so as to call map services to publish results or query the database in real time to present map features at different scales.

[0021] The aforementioned "one-map" refers to an authoritative mapping result generated in ecological remote sensing monitoring operations. This result is formed by integrating and standardizing the ecological resource change map data from various sub-tasks within the same province after multiple rounds of review and confirmation. Specifically, this result involves spatially merging the vector data of change maps extracted from all sub-tasks across the province to generate a provincial-level change map vector file; simultaneously, it overlays and merges the current year's change maps with the previous year's status maps to generate a current year's provincial-level status map vector file; and concurrently, it mosaics the images from all sub-tasks across the province to generate a provincial-level image file consistent with the spatiotemporal reference of the vector results. Building upon this, the "one-map" further segments the provincial-level vector file and image file into corresponding district / county-level result units based on administrative boundaries, forming a final delivery system with full spatial coverage at both the provincial and district / county levels, complete attribute information, and a unified data structure. This system supports the mapping presentation, result archiving, and operational decision-making for ecological resource change monitoring.

[0022] The aforementioned storage component layer 110, serving as the system's underlying data support, is configured with a hybrid storage architecture combining a file system and a database system to achieve hierarchical and categorized management of massive remote sensing mapping data. Storage component layer 110 primarily handles the high-capacity, high-throughput persistent storage of map feature vector files and image files through the file system. Simultaneously, it utilizes a relational database system for structured storage and efficient retrieval management of mapping production records, file location indexes, vector feature attribute information, and spatial extent index data, thereby establishing a decoupled abstract data access layer between the upper-layer service engine and the underlying physical storage. Storage component layer 110 is mainly responsible for the logical organization and physical isolation of map feature vector files and image files at all levels according to year and administrative division, ensuring the independence and traceability of provincial and county-level results. Simultaneously, it maintains file metadata and spatial index information through the database system, providing rapid data location and query capabilities for map feature import / export, spatial merging, regional segmentation, and map service publishing in the upper-layer service engine layer. It also provides necessary spatial extent index support for multi-scale visualization in the Web presentation layer, achieving high availability, scalability, and manageability of mapping data at the storage level.

[0023] Optionally, the aforementioned storage component layer 110 includes a disk shared directory and a relational database, wherein: The shared disk directory is configured to establish a hierarchical storage structure based on year and administrative division level, used for persistent storage of map feature vector files and image files; among them, the map feature vector files include changed map feature vector files and current map feature vector files, and the image files are generated through image mosaicking processing; The relational database is configured to store map production records, file location indexes, vector patch attribute information, and spatial range index data.

[0024] The aforementioned shared disk directory serves as a persistent storage medium for map data. Its function is to provide high-throughput, large-capacity file-level storage capabilities, and to organize and manage massive amounts of map patch vector files and image files in a hierarchical structure. This ensures logical isolation and fast read / write access in physical storage for provincial and county-level change map patch vector files, current map patch vector files, and image files generated through mosaic processing. As a result, it provides a stable and reliable file access foundation for spatial merging, regional segmentation, and map service publishing in the upper-layer service engine layer.

[0025] The aforementioned relational database serves as the core for managing cartographic metadata and index information. Its function is to perform structured storage and efficient retrieval management of business records, file storage location indexes, vector patch attribute information, and spatial range index data during the cartographic production process. By establishing logical relationships and spatial indexing mechanisms between data tables, it enables rapid location, status tracking, and attribute querying of cartographic results. It also collaborates with the disk shared directory to form a hybrid storage architecture, providing data consistency assurance and high-performance data access interfaces for the entire system.

[0026] Optionally, the aforementioned shared disk directory is configured to establish a two-level storage structure, consisting of a first-level directory named by a combination of year and province codes under the specified root directory, and a second-level subdirectory named by province or district / county codes. The first-level directory, named by a combination of year and province codes, is used to store the map results data for the corresponding year and province. The second-level subdirectory, named by province or district / county codes, is used to store vector files of changed features, vector files of current features, and image files within the corresponding administrative division unit. The file names include the year, administrative division code, and feature type fields, which are configured as the retrieval index fields when the map service is published.

[0027] The aforementioned shared disk directory employs a two-level hierarchical storage structure. A first-level directory, named according to a combination of year and province codes, is established under a designated root directory. This directory centrally stores the map data for the corresponding year and province. A second-level subdirectory, named according to province or county codes, is further established under the first-level directory. This subdirectory stores vector files of changed and current map features within the corresponding administrative division units, as well as image files generated through mosaicking. File naming follows a unified rule, including the year, administrative division code, and map feature type fields. The map feature type distinguishes between changed and current map features. Each field in this naming rule is configured as a retrieval index field during map service publishing, enabling the map publishing service to automatically parse metadata information in the filenames and build database indexes. This allows for rapid retrieval and dynamic publishing of vector files and image files at the province and county levels.

[0028] like Figure 2 As shown, taking a certain application scenario as an example: the directory structure needs to store vector files and image files of landmarks for each year, province, and district / county. Therefore, the final directory structure is defined as: / shared disk directory / achivement / year_province code / province or district / county code regionCode. The file name naming rules are defined as follows: the landmark vector file is ecomn_year_province or district / county code_landmark type_inner.shp, and the image file is ecomn_year_province or district / county code_change_inner.tif.

[0029] Optionally, the aforementioned relational database stores a map production result record table, a map production document record table, a changed map patch storage table, a map result patch storage table, and a boundary point coordinate table, wherein: A provincial-level production results record table is used to store the unique identifier of the provincial-level production record, as well as the year, map type, and province code information. A map production file record table is used to store the production status and storage path of vector files and image files at the provincial and county levels; The change patch storage table is used to store the vector boundaries of subtask-level change patches and the previous time image code, previous time image year, subsequent time image code, and subsequent time image year information; A map result patch storage table is used to store the vector boundaries and previous time image codes, previous time image years, subsequent time image codes, and subsequent time image years of the merged provincial-level result patches; The coordinate table of the four boundaries is used to store the bounding rectangular vector range of provincial-level results to support map view positioning.

[0030] Examples of implementation methods for the above solutions: like Figure 3 As shown, the first phase of the map design mainly consists of five tables. These include the first phase production result record table t_ecology_warehouse, the first phase production document record table t_ecology_warehouse_file, the change patch storage table t_ecology_pattern, the first phase production result patch storage table t_ecology_graph, and the boundary point coordinate table t_ecology_corners. All fields in each table are of integer (10) data type and marked with N (non-null constraint). The tables are linked through fields such as warehouse_id to establish N:1, 1:N, and 1:1 relationships to support data flow and business logic. Among them: (1) The first-level map production results record table t_ecology_warehouse: mainly stores the production results records of provincial-level changed and current map features. This table contains the following fields: ID, master_task_id, year, name, type, region_code, region_name, status, count, and Column field. Among them, the year, type, and region_code fields can uniquely identify the year, province, and map feature type (including both changed and current map features) of the current first-level map production record. This table has a one-to-many (1:N) relationship with the t_ecology_warehouse_file table and a one-to-many (1:N) relationship with the t_ecology_graph table.

[0031] (2) The first-level map production file record table t_ecology_warehouse_file mainly stores the production status and file location information of vector files and image files of the first-level map production results for provinces and counties. This table contains the following fields: ID, type, year, production record index warehouse_id, region code region_code, region name region_name, vector file path shp_path, vector file status shp_status, image file path image_path, image file status image_status, vector flow identifier shp_flow_id, and image flow identifier image_flow_id. Among them, warehouse_id is a foreign key index associated with the first-level map production result record table, shp_path and image_path record the storage location of vector patch files and image files, respectively, and shp_status and image_status record the corresponding production status. This table has a many-to-one (N:1) relationship with the t_ecology_warehouse table, and is associated through the warehouse_id field.

[0032] (3) Change Patch Storage Table t_ecology_pattern: This table mainly stores the change patches and attribute information parsed by all subtasks under each province. The table contains the following fields: ID, vector boundary geom, subtask ID, code, previous time image code pre_code, previous time image year pre_year, subsequent time image code curr_code, subsequent time image year curr_year, category, region code region_code, region name region_name, and status. Among these, sub_task_id identifies the subtask to which the patch belongs, geom stores the vector boundary of the patch, and pre_code, pre_year, curr_code, and curr_year record the codes and year information of the previous and subsequent time images, used to uniquely determine the temporal attributes and spatial location of the change patch. This table has a one-to-one (1:1) relationship with the t_ecology_graph table.

[0033] (4) The first-phase map generation result map patch storage table t_ecology_graph: mainly stores the map patch information imported into the database during the first-phase map production process. This table contains the following fields: identifier id, vector boundary geom, associated map patch identifier pattern_id, map patch type type, master task identifier master_task_id, production record identifier warehouse_id, code, previous time image code pre_code, previous time image year pre_year, subsequent time image code curr_code, subsequent time image year curr_year, and status status. Among them, warehouse_id is the unique identifier of the first-phase map production result record and is used to associate the production batch, pattern_id is used to associate the original changed map patches, and pre_code, pre_year, curr_code, and curr_year are used to determine the time series type of the vector map patch. This table has a many-to-one (N:1) relationship with the t_ecology_warehouse table, a one-to-one (1:1) relationship with the t_ecology_pattern table, and a one-to-many (1:N) relationship with the t_ecology_corners table. (5) The coordinate table t_ecology_corners: mainly stores the bounding rectangle vector ranges corresponding to the changed and current map production results of the province, so that the Web presentation layer 140 can focus on the vector map when presenting the vector map of the current province. This table contains the following fields: ID, type, region code, production record ID warehouse_id, subtask ID sub_task_id, and vector coordinate geom. Among them, warehouse_id identifies the production result record of the province, region_code identifies the province region code, and geom stores the bounding rectangle vector coordinates. This table has a many-to-one (N:1) relationship with the t_ecology_graph table. The following is an introduction to the above service engine layer 120: Optionally, the aforementioned service engine layer 120 includes: vector image import / export service, vector image merging service, vector file cutting service, image mosaicking and cutting service, vector publishing service, and image publishing service, wherein: The vector map import / export service is configured to perform bidirectional conversion of map data between relational databases and vector files. The vector map patch merging service is configured to spatially overlay and merge the current period change patches with the historical period status patches to generate an updated status patch. The vector file cutting service is configured to spatially segment provincial-level map patch vector files based on administrative division boundary vector data to generate district / county-level map patch vector files. The image mosaicking and cutting service is configured to perform mosaicking and merging of multiple images and image spatial segmentation processing based on administrative boundaries; The vector publishing service and the image publishing service are configured to publish vector files and image files of land features as map services and generate service call identifiers.

[0034] The main functions of the above services are described below: (1) The above vector map import and export service serves as a data conversion hub connecting relational databases and vector files. Its function is to perform bidirectional flow processing of map data: on the one hand, it exports the geometric attribute information of changed or current map stored in the database into a standard vector file format; on the other hand, it imports the spatial geometric data and attribute information of external vector files into the corresponding table structure of the database in batches, thereby realizing the automatic synchronization and format standardization of cartographic data between the file system and the database system.

[0035] (2) The above-mentioned vector patch merging service undertakes the core processing responsibility of the temporal evolution of patches. Its function is to spatially overlay and attribute-integrate the vector data of the changed patches extracted in the current period with the vector data of the current status patches formed in the historical period, and complete the vector merging operation according to the topological relationship and business rules to generate the latest current status patch vector dataset covering historical change information and current status, so as to provide a continuous and complete current status base map for the dynamic monitoring of ecological resources.

[0036] (3) The above vector file cutting service focuses on the splitting of results at the administrative division level. Its function is to perform spatial segmentation calculation on the provincial-level map patch vector file based on the preset provincial and county administrative division boundary vector data, and accurately cut the map patch dataset containing the entire province into independent vector files corresponding to each county administrative unit, ensuring that the cut county results are strictly consistent with the provincial-level master in terms of spatial range and attribute information.

[0037] (4) The above-mentioned image mosaicking and cutting service provides the ability to integrate and regionalize raster data. Its function is to first connect, register and mosaic multiple sub-task image files covering the whole province to generate seamless provincial-level image files. Then, based on the administrative division boundary vector, the provincial-level image is spatially cropped to output image subsets within each district and county, realizing spatial matching and collaborative management of image data and vector results in administrative units.

[0038] (5) The above vector publishing service and image publishing service together constitute the map service publishing layer of the cartographic results. Its function is to automatically scan the vector files and image files that have been produced in the disk shared directory, call the map service engine to publish the static files as a network map service interface that conforms to the OGC standard, and generate a unique service call identifier, so that the Web presentation layer can dynamically load the cartographic results of different years, different administrative divisions and different types of map patches through the service identifier, and realize the rapid online launch and flexible call of the results.

[0039] Optionally, the vector publishing service and image publishing service mentioned above are configured to: automatically scan the vector and image files of the map features in the shared disk directory, and parse the year, administrative division code and map feature type fields contained in the file name; store the fields as index information in a relational database, and establish a mapping relationship between the file storage path and the map service identifier; and respond to the retrieval request of the Web interface layer, query and return the corresponding map service identifier based on the index information.

[0040] In the above scheme, the vector publishing service and the image publishing service continuously monitor the vector and image files in the shared disk directory through an automated scanning mechanism. They perform standardized parsing of the filenames to extract metadata fields such as year, administrative division code, and map patch type. These fields are then persistently stored as structured index information in a relational database, thereby establishing a bidirectional mapping relationship between file storage paths and unique map service identifiers. When the Web interface layer initiates a request to retrieve cartographic results, the publishing service performs a rapid matching query in the database index based on the query conditions such as year, administrative division, and map patch type carried in the request parameters. It locates the corresponding map service identifier and returns it to the caller, achieving a closed-loop process from automatic registration, dynamic discovery, and rapid invocation of physical files to network services.

[0041] The Web Interface Layer 130 is described below: As the central hub for system business logic, its main function is to provide standardized business flow interfaces and mapping result query interfaces for the Web Presentation Layer 140, thereby decoupling and facilitating communication between front-end user operations and back-end service processing. Specifically, this layer receives provincial-level mapping production instructions through a map production interface and asynchronously triggers the parallel execution of the patch merging and image mosaicking processes in the service engine layer; it receives result confirmation instructions through a map submission interface, thereby driving the service engine layer to complete the spatial segmentation and distribution of provincial-level results to district / county-level results; and it receives front-end visualization requests through a mapping result query interface, calling the map service retrieval capabilities of the service engine layer and returning result data. By encapsulating and orchestrating back-end microservice components, the Web Interface Layer 130 provides a unified, highly cohesive API call contract to the upper layer, ensuring standardized access, asynchronous scheduling, and responsive feedback for business requests. This ensures high-concurrency processing capabilities while improving the overall architecture's flexibility and maintainability.

[0042] The Web presentation layer 140 is described below: As the terminal display module for direct interaction between the system and the user, the Web presentation layer 140 primarily provides a graphical user interface, responds to user-initiated business operation commands such as map production, result submission, and result viewing, and dynamically switches the visualization presentation mode based on the map view scale to optimize the multi-scale browsing experience of map results. Specifically, this layer initiates a data retrieval request to the backend through the map result query interface. When the current map view scale is detected to be less than a preset threshold, it calls the vector publishing service to obtain the map service identifier and loads provincial or county-level vector polygons through the map service interface for aggregated rendering to meet the macroscopic overview needs of large-scale polygon data. When the view scale is not less than the preset threshold, it switches to real-time query mode, calls the map result query interface to retrieve the details of vector polygons within the current view range from the map result polygon storage table in the relational database, and refines the geometric boundaries and attribute information on the map view. This satisfies the user's need for in-depth viewing of the microscopic details and attribute information of the polygons while ensuring the rendering performance of the system's front end, achieving a smooth transition and seamless connection between the macroscopic situation and microscopic details of the map results.

[0043] The following describes the solution for implementing the single-page map production function in the aforementioned single-page map drafting system: Optionally, in response to a call to a layout production interface, the aforementioned service engine layer 120 executes the following asynchronous processing flow: After creating the provincial-level map production results record and initial file record in the relational database, the image mosaicking process is triggered to merge the image files of each subtask under the current province to generate a provincial-level image file and store it in the shared disk directory. The image file storage path and production status in the map production file record table are also updated. According to the type of map patch specified in the map production results record, if the map patch type is a changed map patch, the changed map patch production process is triggered. The changed map patch production process includes: extracting valid changed map patches from the changed map patch storage table to generate a provincial-level changed map patch vector file and storing it in a shared disk directory; calculating the outer rectangle coordinates of the vector file and storing it in a relational database; and then importing the changed map patch into the map production results map patch storage table. If the type of map patch is a current status map patch, then the current status map patch production process is triggered; the current status map patch production process includes: retrieving the vector file of the current status map patch from the previous year, spatially merging it with the current year's change map patch to generate the current year's current status map patch vector file and storing it in the disk shared directory, and at the same time importing the merged current status map patch into the map result map patch storage table. After completing the above processing steps, update the production status information in the production results record table of the first version.

[0044] The above implementation method, for example: Map production mainly includes three important processes: provincial-level image file mosaic production, changed map patch production, and current map patch production. During map production, a production record needs to be created in the production result record table `t_ecology_warehouse`, and a generated file record needs to be created in the production file record table `t_ecology_warehouse_file` to store the production file path and production status. For example... Figure 4As shown, the complete process includes: Service engine layer 120 responds to the call of the map production interface and executes the following asynchronous processing flow: (1) Production task initialization: After receiving the map production request, the system first checks whether there is an ongoing production task. If there is, it returns the status of "in production, not repeatable"; if there is no such task, it creates the initial records of the map production record table (L_ecology_warehouse) and the map file record table (L_ecology_warehouse_file) in the relational database. (2) Image mosaic processing: Trigger the image mosaic processing flow, merge the image files of all sub-tasks under the current province to generate a provincial-level image file, and store it in the disk shared directory. Subsequently, update the image file storage path and production status in the map production file record table. (3) Patch type judgment: According to the patch type specified in the map production result record, determine whether it is a production change patch or a current status patch. (4) Production of changed features: If the feature type is changed features, perform the following steps: calculate the coordinates of the four corner points of all features in the Shapefile file and store them in the coordinate table of the four corner points (L_ecology_corners); export the valid changed features to the Shapefile file and store them in the specified location on the disk; update the relevant information in the first-edition map file record table and the first-edition map production record table; store the changed features in the first-edition map library (L_ecology_graph). (5) Production of current features: If the feature type is current features, perform the following steps: retrieve the previous year's current feature Shapefile file; vector merge the previous year's current features with the current year's changed features; export the merged vector feature file and store it in the specified location on the disk; update the relevant information in the file record table and the production record table; store the merged current features in the first-edition map library (L_ecology_graph). (6) Update production status: After completing the above processing steps, update the production status information in the first-edition map production results record table to reflect the completion status of the production task. It is understandable that the entire implementation process of the single-page production function ensures the efficiency and accuracy of single-page production through the automated scheduling and asynchronous execution of the service engine layer 120.

[0045] The following describes the solution for implementing the single-page map submission function in the aforementioned single-page map creation system: Optionally, in response to a map submission interface call, the aforementioned service engine layer 120 executes the following asynchronous processing flow: Based on the production results record of the first map, determine whether the vector plots have been modified or changed. If they have been modified or changed, re-export the vector plot files from the plot storage table of the first map results to overwrite the original provincial-level files. Trigger vector file splitting process, which divides the provincial-level map patch vector file into district / county-level map patch vector files based on the administrative division boundary vector data, and stores them in the corresponding district / county subdirectories of the disk shared directory; Trigger image file segmentation processing, which divides provincial-level image files into district / county-level image files based on administrative division boundary vector data, and stores them in the corresponding district / county subdirectories of the disk shared directory; Create corresponding file records for each district and county in the map production file record table, and update their vector file storage path, image file storage path, and production status information.

[0046] The above implementation methods are, for example: Figure 5As shown, after the production of a map is completed, if the customer has no objection to the production results, the map can be submitted. If there is an objection, the vector patches can be modified directly on the map before the map is submitted. The map submission process is a key step in the map system to realize the spatial division and distribution of provincial-level results to county-level results. The specific process is as follows: (1) Submission task trigger: After the system receives the map submission request, it first checks whether there is a production record that can be submitted. (2) File acquisition and code acquisition: According to the production record ID, the map patch files and image files produced in the current province are obtained, and the code of all counties in the current province is obtained. (3) Modification check: Check whether the vector patches have been modified. If there is a modification, the vector patch files are re-exported from the map result map patch storage table (L_ecology_graph) to overwrite the original provincial-level files. (4) Vector file cutting: Trigger vector file cutting processing, based on administrative division boundary vector data, divide the provincial-level map patch vector file into district / county-level map patch vector files, and store them in the corresponding district / county subdirectories of the shared disk directory. (5) Image file cutting: Trigger image file cutting processing, based on administrative division boundary vector data, divide the provincial-level image file into district / county-level image files, and store them in the corresponding district / county subdirectories of the shared disk directory. (6) File record update: Create file records corresponding to each district / county in the map production file record table (L_ecology_warehouse_file), and update its vector file storage path, image file storage path, and production status information. (7) Asynchronous multi-threaded execution: Adopt an asynchronous multi-threaded execution mechanism, obtain the district / county boundary vector according to the district / county code, and add a record of this district / county in the file record table. According to the district / county boundary, cut out the district / county map patch files on the generated map patch files, and update the storage location to the shp_path and shp_status fields of the file record table. Similarly, based on the district / county boundaries, cut out the district / county image files from the province image files and update the storage location to the image_path and image_status fields of the file record table. (8) Third-party service publishing: Complete the publishing of vector and image files (third-party service completion).

[0047] The following describes the solution for implementing the function of viewing map production results in the aforementioned map production system: Optionally, the Web presentation layer 140 is configured to dynamically switch the map feature visualization mode in response to a mapping result viewing request, based on a comparison between the current map view scale and a preset threshold: when the map view scale is smaller than the preset threshold, the vector publishing service is invoked to obtain the map service identifier, and provincial or county-level vector map features are loaded and aggregated for presentation through the map service interface; when the map view scale is not smaller than the preset threshold, the mapping result query interface is invoked to retrieve the details of vector map features within the current view range from the map result map feature storage table in real time for refined presentation. An example of this implementation is: like Figure 6 As shown, the implementation process of the map-making results viewing function mainly includes viewing the images and vector cutting results of the current province and all districts and counties under the province. The special point is that when viewing the vector of a province or district / county, if the current map is below level 15, because there are many vector vector spots, all vector results published by vector can be viewed. If the current map is above level 15, the corresponding vector vector spots can be queried from the map-making results database table t_ecology_graph through the Web service interface query service. This method improves the performance of the Web presentation, that is, improves the ease of use, and meets the user's need to see the detailed results of specific map spots. The complete implementation process includes: (1) Results viewing request: The user initiates a map-making results viewing request through the Web presentation layer 140. (2) Presentation list generation: The system presents a map-making results list of the current province and districts / counties for the user to select the results to view. (3) Viewing permission judgment: The system checks whether the user has permission to view the map-making results of the selected province or district / county. (4) Image loading: If the user chooses to view the provincial-level results, the system obtains the address of the provincial-level image file and loads the published image; if the user chooses to view the district / county-level results, the system obtains the address of the district / county image file and loads the published image. (5) Vector patch loading: When the map view scale is less than the preset threshold (e.g., below level 15), the system obtains the address of the published provincial-level or district / county-level vector file and loads the vector patches for aggregation and presentation; when the map view scale is not less than the preset threshold (e.g., above level 15), the system uses the API service to query the vector patches from the map results patch storage table (L_ecology_graph) according to the loading range and performs refined presentation. (6) Patch data query: When refined presentation of vector patches is required, the system calls the map results query interface to retrieve the details of vector patches within the current view range in real time from the map results patch storage table. (7) Dynamic visualization switching: The Web presentation layer 140 dynamically switches the patch visualization mode according to the comparison result between the current map view scale and the preset threshold to adapt to the patch presentation requirements at different scales.

[0048] In a certain application scenario, a map creation and submission page is as follows: Figure 7 As shown, this page provides a user-friendly graphical interface for managing and operating the production process of a map. The page layout is clear and the functional modules are clearly divided, mainly including the following parts: (1) Legend: A legend is provided in the lower right corner of the page to explain the geographic information and land use types represented by different colors, helping users understand the data displayed on the map. (2) Production progress bar: There is a progress bar in the upper left corner of the page, which displays the current production progress of the map, allowing users to intuitively understand the completion status of the production task. (3) Operation toolbar: Multiple operation buttons are provided at the top of the page, including "Production", "Submit", "Query", etc. Users can trigger the corresponding service engine layer functions through these buttons, such as starting the merging of map features, image mosaicking, and submission of results. (4) Attribute table: The attribute table is displayed on the right side of the page, listing the detailed information of the currently selected area or map feature, such as type code, area, change type, etc., to facilitate users to query and analyze data. (5) Map view: The map view area is in the center of the page, which displays the geographic information and land use status at the provincial or county level. Users can view the details of different areas through zooming, panning and other operations. (6) Results List: The left side of the page displays a list of results, including production results from different batches and regions. Users can select specific results to view or operate. (7) Status Information: The page provides a status information area to display the current operation status or system prompts, helping users understand the operation results and system feedback.

[0049] In a certain application scenario, the interface for presenting the results of a map drafting project is as follows: Figure 8As shown, this page provides an intuitive visualization platform for displaying and analyzing the results of a map-making project. The interface is designed to help users efficiently browse, query, and understand complex geographic information data. The following are the main components and functions of the interface: (1) Map view: The map view area in the center of the interface displays geographic information and land use at the provincial or county level. Users can view the details of different areas through zooming, panning, and other operations. (2) Legend: A legend is provided in the lower right corner of the interface to explain the land use types and geographic information represented by different colors on the map, helping users to quickly identify and understand the data displayed on the map. (3) Layer control: A layer control panel is provided on the left side of the interface. Users can choose to show or hide different layers, such as the base map, the vector layer of the patch, the image layer, etc., so as to customize the map view as needed. (4) Attribute query: Users can query the attribute information of a specific area or patch on the map by clicking on it. This information will be displayed in the attribute table on the right side of the interface, including detailed data such as land use type, area, and change type. (5) Toolbar: The toolbar at the top of the interface provides various tool buttons, such as zoom in, zoom out, full view, and measurement. Users can use these tools to perform map operations and analysis. (6) Results list: The left side of the interface may also contain a list of map results. Users can select specific results to view or analyze. (7) Status information: The interface provides a status information area to display the current operation status or system prompts, helping users understand the operation results and system feedback.

[0050] Based on the same inventive concept, embodiments of the present invention also provide a method for creating a single-map map, comprising: responding to a single-map production interface call, creating a provincial-level single-map production result record in a relational database, and creating an initial file record in the corresponding production file record table; triggering image mosaicking processing, merging image files of each sub-task under the current province to generate a provincial-level image file and storing it in a shared disk directory, while updating the image file storage path and production status information in the production file record table; and performing corresponding patch production processing according to the patch type specified in the production result record: if the patch type is a changed patch, then from the changed patch storage... Valid change map data is extracted from the storage table, a provincial-level change map vector file is generated and stored in a shared disk directory. The bounding rectangle coordinates of the vector file are calculated and stored in a relational database. The change map data is then imported into the first-level map result map storage table. If the map type is a current status map, the previous year's current status map vector file is retrieved, and it is spatially merged with the current year's change map to generate the current year's current status map vector file, which is then stored in a shared disk directory. Simultaneously, the merged current status map data is imported into the first-level map result map storage table. After the above processing is completed, the production status information in the first-level map production result record table is updated.

[0051] It is understood that the above-mentioned single-page map-making method can achieve any one of the functions of the above-mentioned single-page map-making system. For the specific solutions for achieving each function of the above-mentioned single-page map-making method, please refer to the system implementation section. The method implementation section will not repeat the details.

[0052] In the embodiments provided by this invention, it should be understood that the disclosed systems and methods can be implemented in other ways. The system embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces. Indirect couplings or communication connections between systems or units may be electrical, mechanical, or other forms.

[0053] Furthermore, the units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0054] Furthermore, the functional modules in the various embodiments of the present invention can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0055] The above description is merely an embodiment of the present invention and is not intended to limit the scope of protection of the present invention. For those skilled in the art, the present invention can have various modifications and variations. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A single-page map drafting system, characterized in that, include: The storage component layer, service engine layer, web interface layer, and web presentation layer are connected sequentially, where: The storage component layer is configured to adopt a hybrid storage architecture that combines a file system and a database system to manage vector files, image files and their metadata index information in a hierarchical manner. The service engine layer is configured to perform import and export of patch data, spatial merging of changed patches and existing patches, spatial segmentation of patches and images based on administrative boundaries, and map service publishing processing of patch vectors and images. The Web interface layer is configured to provide a map production interface, a map submission interface, and a map result query interface; wherein, the map production interface triggers the asynchronous execution of the provincial-level map patch merging and image mosaicking process, and the map submission interface triggers the asynchronous execution of the spatial segmentation and distribution process from the provincial-level results to the district / county-level results. The Web presentation layer is configured to dynamically switch visualization modes based on the map view scale, so as to call map services to publish results or query the database in real time to present map features at different scales.

2. The map drafting system according to claim 1, characterized in that, The storage component layer includes a shared disk directory and a relational database, wherein: The shared disk directory is configured to establish a hierarchical storage structure based on year and administrative division level, for persistent storage of map feature vector files and image files; wherein, the map feature vector files include changed map feature vector files and current map feature vector files, and the image files are generated through image mosaicking processing; The relational database is configured to store map production records, file location indexes, vector patch attribute information, and spatial range index data.

3. The map drafting system according to claim 2, characterized in that, The disk shared directory is configured to establish a two-level storage structure, with a first-level directory named by a combination of year and province code under the specified root directory and a second-level subdirectory named by province or county code. The first-level directory is named by a combination of year and province code, and is used to store the map results data for the corresponding year and province; The second-level subdirectories are named by province or county codes and are used to store vector files of changed features, vector files of current features, and image files within the corresponding administrative division units; The file name includes the year, administrative division code, and map patch type fields, which are configured as retrieval index fields when the map service is published.

4. The map drafting system according to claim 2, characterized in that, The relational database stores a map production result record table, a map production document record table, a changed map patch storage table, a map result patch storage table, and a boundary point coordinate table, wherein: The map production results record table is used to store the unique identifier of the provincial-level production record, as well as the year, map type, and province code information. The map production file record table is used to store the production status and storage path of vector files and image files at the provincial and county levels. The change patch storage table is used to store the vector boundary of the subtask-level change patch and the previous time image code, previous time image year, subsequent time image code, and subsequent time image year information; The map result patch storage table is used to store the vector boundaries and previous time image code, previous time image year, subsequent time image code, and subsequent time image year information of the merged provincial-level result patches; The coordinate table of the four boundaries is used to store the bounding rectangular vector range of provincial-level results to support map view positioning.

5. The map drafting system according to claim 2, characterized in that, The service engine layer includes: vector image import / export service, vector image merging service, vector file cutting service, image mosaicking and cutting service, vector publishing service, and image publishing service, wherein: The vector image import / export service is configured to perform bidirectional conversion of image data between the relational database and the vector file; The vector map patch merging service is configured to spatially overlay and merge the current period change patches with the historical period status patches to generate an updated status patch. The vector file cutting service is configured to spatially segment provincial-level map patch vector files based on administrative division boundary vector data to generate district / county-level map patch vector files. The image mosaicking and cutting service is configured to perform mosaicking and merging of multiple images and image spatial segmentation processing based on administrative division boundaries. The vector publishing service and the image publishing service are configured to publish the polygon vector files and image files as map services and generate service call identifiers.

6. The map drafting system according to claim 5, characterized in that, The vector publishing service and image publishing service are configured to: automatically scan the vector and image files in the shared disk directory, and parse the year, administrative division code, and map type fields contained in the file names; store the fields as index information in the relational database, and establish a mapping relationship between the file storage path and the map service identifier; and, in response to the retrieval request of the Web interface layer, query and return the corresponding map service identifier based on the index information.

7. The map drafting system according to claim 2, characterized in that, In response to the call to the production interface of the layout, the service engine layer executes the following asynchronous processing flow: After creating the provincial-level map production results record and initial file record in the relational database, the image mosaicking process is triggered to merge the image files of each sub-task under the current province to generate a provincial-level image file and store it in the disk shared directory, and update the image file storage path and production status in the map production file record table. According to the type of map patch specified in the map production results record, if the map patch type is a changed map patch, then the changed map patch production process is triggered; wherein, the changed map patch production process includes: extracting valid changed map patches from the changed map patch storage table to generate a provincial-level changed map patch vector file and storing it in the disk shared directory; after calculating the outer rectangle coordinates of the vector file and storing it in the relational database, importing the changed map patch into the map production results map patch storage table; If the type of map patch is a current status map patch, then the current status map patch production process is triggered; wherein, the current status map patch production process includes: retrieving the vector file of the current status map patch of the previous year, spatially merging it with the current year's change map patch to generate the current year's current status map patch vector file and storing it in the disk shared directory, and at the same time importing the merged current status map patch into a map result map patch storage table. After completing the above processing steps, update the production status information in the production results record table of the first layout.

8. The map drafting system according to claim 2, characterized in that, In response to the call to the map submission interface, the service engine layer executes the following asynchronous processing flow: Based on the production results record of the first map, determine whether the vector plots have been modified or changed. If they have been modified or changed, re-export the vector plot files from the first map result plot storage table to overwrite the original provincial-level files. Trigger vector file splitting process, based on administrative division boundary vector data, to split the provincial-level map patch vector file into district / county-level map patch vector files, and store them in the corresponding district / county subdirectories of the disk shared directory; Trigger image file segmentation processing, and divide the provincial-level image file into district / county-level image files based on administrative division boundary vector data, and store them in the corresponding district / county subdirectories of the disk shared directory; Create file records for each district and county in the production file record table of the map, and update their vector file storage path, image file storage path and production status information.

9. The map drafting system according to any one of claims 1 to 8, characterized in that, The web presentation layer is configured to dynamically switch the map patch visualization mode in response to a request to view the mapping results, based on a comparison between the current map view scale and a preset threshold. When the map view scale is smaller than a preset threshold, the vector publishing service is invoked to obtain the map service identifier, and the provincial or county-level vector vector patches are loaded and aggregated for presentation through the map service interface. When the map view scale is not less than a preset threshold, the mapping result query interface is invoked to retrieve the details of vector patches within the current view range from the map result patch storage table in real time for refined presentation.

10. A layout drawing method for a system as described in any one of claims 1 to 9, characterized in that, The method includes: In response to the map production interface call, create a provincial-level map production result record in the relational database, and create an initial file record in the corresponding production file record table; Trigger image mosaicking process, merge the image files of each subtask under the current province to generate a provincial-level image file and store it in the shared disk directory, and update the image file storage path and production status information in the production file record table at the same time; Perform the corresponding patch production processing according to the patch type specified in the production result record: If the type of map patch is a changed map patch, then the valid changed map patch data is extracted from the changed map patch storage table, a provincial-level changed map patch vector file is generated and stored in the disk shared directory, the outer rectangle coordinates of the vector file are calculated and stored in the relational database, and then the changed map patch data is imported into the map patch storage table of the first-level map results. If the type of map patch is a current status map patch, then retrieve the vector file of the current status map patch from the previous year, spatially merge it with the current year's change map patch to generate the vector file of the current year's current status map patch and store it in the shared disk directory. At the same time, import the merged current status map patch data into the map result map patch storage table of the first edition. After the above processing steps are completed, update the production status information in the production results record table of the first version.

Images