A map tile storage and retrieval method and apparatus supporting multi-projection

Abstract

The application discloses a map tile storage and retrieval method and device supporting multiple projections. The method comprises the following steps: analyzing the projection type, zoom level and tile coordinate parameters of a target projection tile in a query request; screening a matching MBTiles file in a file index table according to the projection type, and further screening a candidate file based on the geographical range boundary calculated according to the tile coordinate; generating a candidate file sequence according to the priority of the candidate file, and sequentially retrieving target projection tile data; if the retrieval is successful, the target projection tile data is returned and cached, and if all the retrievals are unsuccessful, a cross-projection data conversion process is started to generate the target projection tile. The application expands the metadata structure of the MBTiles file to support multiple projection information storage, realizes multi-dimensional fast retrieval in combination with spatial indexing and composite indexing, and introduces a dynamic priority scheduling and cross-projection fault tolerance adaptation mechanism, so that the problems of single projection, low mass file retrieval efficiency and insufficient intelligent scheduling of data sources are effectively solved.

Description

Technical Field

[0001] This application relates to the fields of Geographic Information Systems (GIS), spatial databases, and online map services. Specifically, it relates to a method and apparatus for storing and retrieving map tiles that support multiple projections. Background Technology

[0002] With the widespread application of Geographic Information Systems (GIS) and internet map services, MBTiles, as a lightweight and portable map tile storage standard, has become one of the mainstream industry standards due to its advantages of efficient storage, fast access, and cross-platform compatibility. It is widely used in scenarios such as online maps and mobile maps. MBTiles is a format that packages and stores massive amounts of map tiles in a single SQLite database file, primarily used to solve the problems of offline storage, transmission, and management of map data. It can integrate a large number of map tiles into a single file, making the retrieval of offline map images as simple as accessing local files. It is widely used in mobile navigation, field operations, and map applications in environments without network connectivity.

[0003] However, in applications targeting specialized fields (such as surveying and mapping, aerospace remote sensing, and marine engineering) and complex service needs (such as data management and high-concurrency request processing), the existing MBTiles technical solution has the following problems: Traditional MBTiles can only handle Web Mercator projection and cannot adapt to diverse coordinate systems commonly used in professional scenarios, such as transverse Mercator projection, Gauss-Kruger projection, and geodetic coordinate system projection. This results in the need for complex format conversions when fusing multi-source data, increasing system overhead and data errors.

[0004] When the number of MBTiles files reaches a large scale, it is necessary to traverse the file directory or query the file metadata table one by one to locate the target projection tile, which reduces the retrieval efficiency and cannot meet the response requirements of large-scale map services.

[0005] Existing solutions cannot intelligently schedule the optimal data source based on factors such as data accuracy, timeliness, and access frequency, resulting in high-value data being mixed with ordinary data and reducing service quality. At the same time, data updates require a full file replacement and do not support incremental updates or version management, leading to high operation and maintenance costs.

[0006] The storage layout of MBTiles files is disconnected from their geospatial distribution. When querying, the entire file must be loaded to determine whether the target projected tile is included. Furthermore, it lacks fast retrieval capabilities based on multiple dimensions such as projection, hierarchy, and geographical range. The high proportion of invalid disk input / output operations further exacerbates response latency.

[0007] To address the aforementioned issues, current solutions only optimize a single aspect (such as local caching or simple indexing), failing to fundamentally overcome the inherent limitations of MBTiles. Therefore, a map tile storage and retrieval method supporting multiple projections is needed to meet the demands of specialized scenarios and large-scale services. Summary of the Invention

[0008] The main objective of this application is to provide a method and apparatus for storing and retrieving map tiles that support multiple projections. By extending the MBTiles format, constructing a unified indexing system, intelligent query scheduling, and cross-projection fault-tolerant adaptation, it solves the problems of traditional MBTiles, such as only supporting a single projection, inefficient data retrieval, and rigid service scheduling. It achieves efficient storage, fast querying, and flexible adaptation of map tiles in multi-projection scenarios, while ensuring system compatibility, scalability, and high concurrency processing capabilities. It integrates multi-projection support, efficient indexing, intelligent scheduling, and performance optimization.

[0009] To achieve the above objectives, the first aspect of this application proposes a method for storing and retrieving map tiles that supports multiple projections, comprising: Parse the projection type, scaling level, and tile coordinate parameters of the target projected tile in the query request; In response to the query request, MBTiles files that match the projection type of the target projection tile are filtered in a pre-built file index table. The corresponding geographic boundary is calculated based on the scaling level and tile coordinate parameters of the target projection tile, and candidate MBTiles files covering the geographic boundary are further filtered from the filtering results. The candidate MBTiles files are sorted according to their file priority to generate a candidate file sequence; According to the file priority order of the candidate file sequence, the target projection tile data corresponding to the tile coordinate parameters of the target projection tile is retrieved sequentially from the data source indicated by each candidate MBTiles file; If the retrieval is successful, the retrieved target projection tile data is returned and cached. If the target projection tile data is not found in any of the candidate MBTiles files in the candidate file sequence, a cross-projection data conversion process is initiated based on the information in the file index table to generate the target projection tile data that meets the requirements.

[0010] In some embodiments of this disclosure, prior to the step of filtering MBTiles files with matching projection types in a pre-built file index table, a step of creating the MBTiles files is further included, specifically including: A projection type field is added to the metadata table of the MBTiles file to store the projection type, which is represented by a map coordinate reference system identifier. Add a projection parameter description field to the metadata table of the MBTiles file to store projection parameter information describing the projection type; Add a projection conversion parameter field to the metadata table of the MBTiles file to store conversion parameter information between the projection type and other projection types; Add a geographic extent boundary field to the metadata table of the MBTiles file to store the applicable geographic extent boundary information for the projection type; The MBTiles files are named using a naming format that includes the projection type, so that the projection type can be directly identified by the filename; Tile data of different projection types are generated using a tile generation tool, and the tile data is stored in the MBTiles file.

[0011] In some embodiments of this disclosure, after the step of creating the MBTiles file, the method further includes: Create the file index table, which includes at least the path field of the MBTiles file, the projection type field, the geographic range boundary field, the zoom level range field, the tile row and column number range field, the file priority field, the data source field, and the update time field; A spatial index is created on the geographic boundary field for query filtering based on geographic boundary coordinates; A composite index is created on the projection type field, the scaling level range field, and the file priority field for attribute filtering and sorting. Insert the relevant information of the MBTiles file into the file index table. The relevant information includes at least the path of the map tile file, the projection type, the zoom level range, the geographic range boundary, the tile row and column number range, the file priority, the data source, and the update time. The index information in the file index table is updated periodically, and the index information includes at least the file size, the number of tiles, and the update time.

[0012] In some embodiments of this disclosure, the file priority is determined based on a comprehensive evaluation of the following factors: Data accuracy, update time, data source reliability, regional coverage integrity, and usage frequency.

[0013] In some embodiments of this disclosure, an adaptive adjustment step based on file priority using usage statistics is also included, specifically including: Record the number of queries, the number of successful queries, and the query response time for each MBTiles file. The file priority is dynamically adjusted based on the ratio between the number of successful queries and the number of queries, as well as the frequency of the queries. When a query for the MBTiles file with higher file priority fails, the query is automatically downgraded to the MBTiles file with lower file priority for retrieval.

[0014] In some embodiments of this disclosure, the step of initiating the cross-projection data conversion process to generate the target projection tile data that meets the requirements specifically includes: Based on the geographical boundaries, source projection tile files whose projection types differ from those of the target projection tiles are selected from the file index table. The coordinates of the source projection tile are calculated based on the scaling level range, the coordinates, and the projection information; Based on the coordinates of the source projection tile, obtain the source projection tile data corresponding to the geographical location from the source projection tile file; Based on the conversion parameters between the projection type of the source projection tile and the projection type of the target projection tile, coordinate transformation and image resampling are performed on the source projection tile data to generate target projection tile data corresponding to the coordinates of the target projection tile.

[0015] In some embodiments of this disclosure, prior to the step of retrieving target projection tile data corresponding to the coordinates of the target projection tile from the data source indicated by the candidate file sequence, the method further includes: The Bloom filter pre-built for the data source is used to determine whether the target projection tile data corresponding to the coordinates of the target projection tile may exist therein; If it is determined that the target cannot exist, the retrieval operation for the target's projected tile data is skipped.

[0016] In some embodiments of this disclosure, the cache is a multi-level cache, including at least a memory cache for storing hot data and a disk cache for storing full or recent data; Following the step of returning and caching the retrieved target projection tile data, the method further includes: Based on the frequency and timeliness of data access, data scheduling and eviction are performed among the various levels of cache.

[0017] In some embodiments of this disclosure, when the query request is a batch request containing multiple sub-requests, the method further includes: The sub-requests are grouped according to the projection type of their target projection tiles and / or the geographical boundaries, and the multi-level data positioning and acquisition processes triggered by the sub-requests of different groups are processed in parallel.

[0018] In some embodiments of this disclosure, performance monitoring and dynamic optimization steps are also included, specifically including: Record at least one of the following performance metrics: number of queries, average query response time, and cache hit rate; The file priority and cache eviction policy of the candidate MBTiles files are dynamically adjusted based on the performance indicators. Provide a standardized interface for external systems to query the performance metrics.

[0019] A second aspect of this application proposes a map tile storage and retrieval device supporting multiple projections, comprising: The parsing module is used to parse the projection type, scaling level, and tile coordinate parameters of the target projection tile in the query request; The first filtering module is used to respond to the query request and filter MBTiles files that match the projection type in a pre-built file index table according to the projection type of the target projection tile. The second filtering module is used to calculate the corresponding geographic boundary based on the scaling level and tile coordinate parameters of the target projection tile, and further filter out candidate MBTiles files that cover the geographic boundary from the filtering results. The sorting module is used to sort the candidate MBTiles files according to their file priority, and generate a candidate file sequence; The retrieval module is used to retrieve the target projection tile data corresponding to the tile coordinate parameters of the target projection tile from the data source indicated by each of the candidate MBTiles files in the order of file priority of the candidate file sequence. The first processing module is used to return the retrieved target projection tile data and cache it if the retrieval is successful. The second processing module is used to initiate a cross-projection data conversion process to generate the target projection tile data that meets the requirements, based on the information in the file index table, if the target projection tile data is not found in any of the candidate MBTiles files in the candidate file sequence.

[0020] In some embodiments of this disclosure, a first creation module is further included, configured to add a projection type field to the metadata table of the MBTiles file to store the projection type, wherein the projection type is represented by a map coordinate reference system identifier; add a projection parameter description field to the metadata table of the MBTiles file to store information describing the projection parameters; add a projection conversion parameter field to the metadata table of the MBTiles file to store conversion parameter information between the projection type and other projection types; name the MBTiles file using a naming format that includes the projection type so that the projection type can be directly identified by the filename; and generate tile data of different projection types using a tile generation tool and store the tile data in the MBTiles file.

[0021] In some embodiments of this disclosure, a second creation module is further included, used to create the file index table, which includes at least the path field of the MBTiles file, the projection type field, the geographic extent boundary field, the zoom level range field, the tile row and column number range field, the file priority field, the data source field, and the update time field; a spatial index is established on the geographic extent boundary field for query filtering based on geographic boundary coordinates; a composite index is established on the projection type field, the zoom level range field, and the file priority field for attribute fine filtering and sorting; relevant information of the MBTiles file is inserted into the file index table, which includes at least the path of the map tile file, the projection type, the zoom level range, the geographic extent boundary, the tile row and column number range, the file priority, the data source, and the update time; and the index information in the file index table is updated periodically, which includes at least the file size, the number of tiles, and the update time.

[0022] In some embodiments of this disclosure, the file priority is determined based on a comprehensive evaluation of the following factors: Data accuracy, update time, data source reliability, regional coverage integrity, and usage frequency.

[0023] In some embodiments of this disclosure, the first creation module 780 is further configured to record the number of queries, the number of successful queries, and the query response time for each MBTiles file; dynamically adjust the file priority based on the ratio between the number of successful queries and the number of queries, as well as the frequency of the number of queries; and automatically downgrade to searching for MBTiles files with lower file priority when a query for a higher-priority MBTiles file fails.

[0024] In some embodiments of this disclosure, the second creation module 790 is further configured to: filter source projection tile files whose projection types differ from those of the target projection tile from the file index table based on the geographic range boundary; calculate the coordinates of the source projection tile according to the scaling level range, the coordinates, and the projection information; obtain source projection tile data corresponding to the geographic location from the source projection tile files based on the coordinates of the source projection tile; and perform coordinate transformation and image resampling on the source projection tile data based on the conversion parameters between the projection types of the source projection tile and the target projection tile to generate target projection tile data corresponding to the coordinates of the target projection tile.

[0025] In some embodiments of this disclosure, the first processing module 780 is further configured to use a Bloom filter pre-built for the data source to determine whether the target projection tile data corresponding to the coordinates of the target projection tile may exist therein; if it is determined that it is impossible to exist, the retrieval operation of the target projection tile data is skipped.

[0026] In some embodiments of this disclosure, the cache is a multi-level cache, including at least a memory cache for storing hot data and a disk cache for storing full or recent data; In some embodiments of this disclosure, the first processing module 780 is further configured to perform data scheduling and eviction among the caches at each level based on the data access frequency and timeliness.

[0027] In some embodiments of this disclosure, a batch processing module is also included, which is used to group the sub-requests according to the projection type of their target projection tiles and / or the geographical range boundaries, and to perform parallel processing on the multi-level data positioning and acquisition process triggered by the sub-requests of different groups.

[0028] In some embodiments of this disclosure, a monitoring module is also included, which is used to record at least one of the following performance metrics: query count, average query response time, and cache hit rate; dynamically adjust the file priority and cache eviction policy of the candidate MBTiles files according to the performance metrics; and provide a standardized interface for external systems to query the performance metrics.

[0029] The technical solutions provided by the embodiments of this application may include the following beneficial effects: By extending MBTiles metadata and performing cross-projection conversion, multiple projections are supported, expanding the application scope from web maps to fields such as professional surveying and mapping, aerospace remote sensing, and marine engineering, thus solving the problem of multi-source data fusion; A file index table combined with multi-dimensional index optimization enables rapid location of large-scale MBTiles files, shortens index query time, significantly improves system scalability, and meets the needs of massive data management; Dynamic scheduling of tile services is achieved: through a dynamic file priority algorithm combined with a file priority scheduling mechanism, high-precision, high-timeliness, and high-reliability data are automatically selected. Based on the source, service quality is improved; cross-projection fault tolerance and adaptation ensure a projection-independent service experience and improve request success rate; Bloom filters are used to reduce invalid input and output operations, and multi-level caching reduces the response time of repeated queries to milliseconds. Combined with batch parallel processing mechanisms, the system throughput is improved compared to traditional MBTiles services in high-concurrency scenarios, and the average latency per tile is reduced compared to traditional solutions; backward compatibility of the MBTiles format is maintained, and existing MBTiles files and supporting toolchains can be integrated without modification; standardized application programming interfaces are provided to support single-tile acquisition, batch requests, and service capability queries, facilitating client integration and reducing development costs.

[0030] The above description is merely an overview of the technical solutions of the embodiments of this application. In order to better understand the technical means of the embodiments of this application and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of this application more obvious and understandable, specific implementation methods of this application are described below. Attached Figure Description

[0031] The accompanying drawings, which form part of this application, are used to provide a further understanding of the application and to make other features, objects, and advantages of the application more apparent. The illustrative embodiments and descriptions of this application are used to explain the application and do not constitute an undue limitation of the application. In the drawings: Figure 1 This is a schematic diagram of the overall architecture of the system used in this application; Figure 2 A flowchart illustrating a method for storing and retrieving map tiles supporting multiple projections, provided in an embodiment of this application; Figure 3 A schematic diagram of the dynamic file priority calculation process provided in the embodiments of this application; Figure 4 A schematic diagram of the projection conversion process provided in the embodiments of this application; Figure 5 A flowchart illustrating the query process for a single tile request provided in this application embodiment; Figure 6This is a flowchart of the parallel processing for batch tile query provided in an embodiment of this application; Figure 7 This is a schematic diagram of a map tile storage and retrieval device supporting multiple projections provided in an embodiment of this application.

[0032] In the accompanying diagram, markers with the same last two digits correspond to the same elements. It should be noted that the elements in the diagram are schematic and not drawn to scale. Detailed Implementation

[0033] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0034] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this application described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0035] In this application, the terms "upper," "lower," "left," "right," "front," "rear," "top," "bottom," "inner," "outer," "middle," "vertical," "horizontal," "lateral," and "longitudinal" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. These terms are primarily for the purpose of better describing this application and its embodiments, and are not intended to limit the indicated device, element, or component to having a specific orientation, or to be constructed and operated in a specific orientation.

[0036] Furthermore, in addition to indicating location or positional relationship, some of the aforementioned terms may also have other meanings. For example, the term "above" may also be used in some cases to indicate a certain dependency or connection relationship. Those skilled in the art can understand the specific meaning of these terms in this application based on the specific circumstances.

[0037] Furthermore, the terms "installation," "setup," "equipped with," "connection," "linked," and "socketing" should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral structure; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium, or an internal connection between two devices, components, or parts. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0038] In the description of this application, unless otherwise stated, "multiple" means two or more (including two), and similarly, "multiple groups" means two or more (including two groups).

[0039] The system to which this application applies has an architecture comprising five parts: a user request layer, an API interface layer, an index management layer, and a data storage layer. Figure 1 As shown, the functions of each layer are as follows: User Request Layer 110: Covers various request initiating entities such as Web, mobile, and professional GIS clients, supports multiple interaction methods such as single tile query and batch tile request, and the request format follows the RESTful specification (e.g., / tiles / {projection information} / {level} / {column number} / {row number}.{format}). API Interface Layer 120: Provides standardized interfaces to adapt to user requests, including request parsing, index query and file query functions. In addition, it implements interactive scheduling with the index management layer to ensure that requests are transferred to the core processing module according to the preset logic. The index management layer 130 includes a file index table. This application modifies the file index table and adds functions such as spatial indexing and file priority management, realizing the functions of "integrating multi-projection data" and "achieving intelligent scheduling". A cross-file file index table is constructed to break the projection limitations of a single MBTiles file, enabling centralized management and association of multi-projection data. Based on a dynamic file priority algorithm, multi-projection candidate files are sorted by factors such as data accuracy, timeliness, and access frequency. Optimization mechanisms such as Bloom filters, multi-level caching, and connection pools are introduced to achieve efficient scheduling and resource allocation for tile queries, avoiding invalid I / O and resource waste.

[0040] Data storage layer 140: Includes MBTiles files (named according to the "region_projection_date" specification), cache, and connection pool. By extending the format of the MBTiles metadata table, it uniformly stores the metadata of tile files for different projection types. An SQLite connection pool is established to manage connections to MBTiles files. The maximum number of connections in the pool is dynamically adjusted based on the number of MBTiles files in the file index table, avoiding the overhead of frequently establishing or disconnecting connections.

[0041] Figure 2 A flowchart illustrating a method for storing and retrieving map tiles supporting multiple projections, provided in an embodiment of this application. Figure 2 As shown, the method for storing and retrieving map tiles that support multiple projections includes the following steps: S210. Receive the query request and parse the projection type, scaling level and tile coordinate parameters of the target projection tile in the query request. In a specific implementation, a query request from a client is received, and the projection type parameter, scaling level parameter, and tile coordinate parameter of the target projection tile contained in the query request are parsed. The tile coordinate parameter includes at least the tile column number parameter and the tile row number parameter. The validity of the projection type parameter, the scaling level parameter, and the tile coordinate parameter is then verified.

[0042] Optionally, prior to S210, a caching acceleration step is also included: In a specific implementation, the caching acceleration step involves analyzing historical tile query logs to filter out frequently accessed MBTiles files, loading these MBTiles files into a memory cache, and then setting a cache update strategy. Upon receiving a tile query request, the system first checks if the tile exists in the cache; if so, it returns the tile data.

[0043] Optionally, a two-level caching strategy can be adopted. The first level is a memory cache (LRUCache) used to store tile data that is frequently accessed within a certain period of time. In addition, the cache capacity can be set according to the actual server memory configuration. The second level is disk caching, which has a larger capacity than memory caching. Data can be stored long-term and is not lost even when power is off. While its read speed is slower than memory, it is faster than retrieving the original data source. This second-level caching solution compensates for insufficient memory capacity and can handle the storage and retrieval of large-scale tile libraries, forming a complete tile caching system.

[0044] Optionally, tile data that has not been accessed for a long time can be periodically removed from the cache.

[0045] Optionally, it also includes: scheduling and eviction of data among the various levels of cache based on the access frequency and timeliness of the data.

[0046] S220. In response to the query request, based on the projection type of the target tile, filter MBTiles files that match the projection type in a pre-built file index table; In a specific implementation, in response to the query request that has been validated, map tile files with matching projection types are quickly located and filtered in a pre-built file index database based on the projection type parameters of the target projection tile, so as to form a preliminary candidate file set. The file index database stores metadata, the projection type and the priority of multiple map tile files with different projection types and priorities. Optionally, a pre-filtering step may be included before S220: Based on historical query records, preload frequently queried MBTiles files into memory; Use a Bloom filter to quickly determine if a tile exists in a file; Implement query result caching to avoid duplicate queries.

[0047] In the actual implementation, a Bloom filter is pre-built for each MBTiles file to quickly determine whether tiles at a specified level might exist in the tile database, thus skipping a large number of invalid accesses. During initialization, the mbtiles_index.db index is loaded, and the Bloom filters for each MBTiles file are loaded into memory.

[0048] A pre-built Bloom filter for this data source is used to determine whether the target projection tile data might exist there. If it is determined that the data does not exist, the retrieval operation for that data source is skipped. Otherwise, a database connection to the MBTiles file is obtained from the connection pool, and an SQL query is executed to retrieve the tile data.

[0049] S230. Calculate the corresponding geographic boundary based on the scaling level and tile coordinate parameters of the target projection tile, and further filter out candidate MBTiles files that cover the geographic boundary from the filtering results. In a specific implementation, based on the scaling level parameters and tile coordinate parameters of the target projection tile, and combined with the coordinate reference system corresponding to the projection type, the geographical boundary of the target projection tile in geospatial space is calculated. Then, using the spatial index established on the geographical boundary field in the file index database, candidate map tile files covering the geographical boundary are further filtered from the preliminary candidate file set.

[0050] S240. Sort the candidate files according to their file priority to generate a candidate file sequence; In a specific implementation, the priority of each candidate map tile file is obtained. The priority is determined by comprehensively evaluating at least two factors among data accuracy, data timeliness, data source reliability, regional coverage integrity, and historical access statistics. The candidate map tile files are sorted in descending order of the priority to generate an ordered candidate file sequence.

[0051] S250. According to the file priority order of the candidate file sequence, retrieve the target projection tile data corresponding to the tile coordinate parameters of the target projection tile from the data source indicated by each candidate MBTiles file in turn; In a specific implementation, connections are established sequentially with the data sources indicated by each candidate map tile file according to the priority order of the candidate file sequence. The target projection tile data corresponding to the tile coordinate parameters of the target projection tile is retrieved from the data sources. During the retrieval process, a Bloom filter pre-built for each data source is used to determine whether the target projection tile data may exist in the corresponding data source. If it is determined that it may exist, the retrieval operation is performed. If it is determined that it may not exist, the current data source is skipped and the retrieval of the next priority data source continues.

[0052] S260. If the retrieval is successful, the retrieved tile data is returned and cached. In a specific implementation, if a successful retrieval is achieved from the data source indicated by any of the candidate map tile files, the retrieved target projection tile data is obtained, the target projection tile data is returned to the client, the target projection tile data is stored in a multi-level cache, and the access statistics information of the data source corresponding to the target projection tile data is updated.

[0053] S270. If the target projection tile data is not found in any of the candidate MBTiles files in the candidate file sequence, then based on the information in the file index table, a cross-projection data conversion process is initiated to generate tile data that meets the requirements.

[0054] In a specific implementation, if the target projection tile data is not found in any of the candidate map tile files in the candidate file sequence, then based on the projection transformation parameter information stored in the file index database, a source projection tile file with a different projection type but covering the same geographical area as the target projection tile is searched, and a cross-projection data conversion process is initiated. The source projection tile data in the source projection tile file is subjected to coordinate transformation and image resampling processing to generate the target projection tile data that meets the projection type requirements of the target projection tile.

[0055] In an optional implementation, the step of creating the MBTiles file is performed before step S220. Figure 3 A flowchart illustrating the steps for creating the MBTiles file provided in this application embodiment; as shown Figure 3 As shown, the specific steps include: During the data preparation stage, when creating MBTiles files in the data storage layer, a projection type field is added to the metadata table of the MBTiles file to store the projection type. The projection type is represented by the map coordinate reference system identifier code (EPSG code), such as EPSG:4326, EPSG:3857, EPSG:32650, etc. MBTiles is a SQLite database file that conforms to a specific specification. It stores map tiles and the metadata describing those tiles in the same file. It contains two core tables: the tiles table and the metadata table. The tiles table stores the actual tile data, while the metadata table stores metadata describing the tile set, including one or more of the following: tile file path, file unique identifier, zoom level range, geographic boundary range, tile column and row numbers, data source, last update time, number of tiles, and file size.

[0056] This step adds extended information to the map tile files by expanding the metadata table of the MBTiles files, ensuring that multi-projection data can be recognized and parsed by the system. The specific implementation is as follows: Add a projection parameter field (proj4text field) to the metadata table in the MBTiles file to store the PROJ.4 string, which stores information describing the projection parameters.

[0057] Add a projection transformation parameter field (transformation) to the metadata table in the MBTiles file to store the transformation parameter information between the projection type and other projection types, and support WKT (Well-Known Text) format to describe the coordinate reference system.

[0058] Record the applicable bounds of the projection to determine whether the projection is suitable for the requested area.

[0059] In specific implementations, native fields are retained, such as file name, tile format (PNG / JPEG), path, zoom level range (min_zoom / max_zoom), geographic boundary fields (bounds), tile column and row numbers, data source, last update time, number of tiles, and file size, to ensure compatibility with the existing MBTiles toolchain. The geographic boundary field stores the applicable geographic boundary information for the projection type.

[0060] The MBTiles files are named using a naming format that includes the projection type, so that the projection type can be directly identified by the filename; In specific implementations, files can be named according to the "filename_projection.mbtiles" specification, which is "region_projection_date", for example: beijing_EPSG3857.mbtiles, shanghai_EPSG32651.mbtiles. The projection type can be quickly identified by the filename without opening a database query.

[0061] Tile data for different projection types are generated using a tile generation tool, and the tile data is stored in the MBTiles file; In a specific implementation, the MBTiles file generation process includes the following steps: 1. Source Data Processing: Use tools such as GDAL or MapTiler to convert the raw GeoTIFF format imagery into map tile data according to a preset projection and store it in MBTiles files. During the conversion process, set the projection parameters and geographic extent. 2. Metadata Validation and Completion: After generating the MBTiles file, use the SQLite tool to read the metadata table and check if the projection, proj4text, bounds, and transformation fields are complete; if any are missing, manually execute SQL statements to complete them. Optionally, optimizations can be made to spatial continuity. Morton coding (Z-order curve) can be used to optimize the tile storage order, ensuring that tiles adjacent to each other on the map are also geographically adjacent. This storage method not only improves disk I / O efficiency when accessing continuous geographical areas and increases single-tile read speed, but also enables pre-fetching of adjacent tiles. When a user browses a tile, surrounding geographically adjacent tiles can be pre-loaded into the cache. When the user scrolls the map, the target projected tile is already in the cache, improving continuous browsing performance.

[0062] In an optional implementation, before step S220 and after the step of creating the MBTiles file, a step of creating a file index table is further included.

[0063] During the system initialization phase, a file index library is created to centrally register and manage the attributes of scattered MBTiles files, and a file index table with a multi-dimensional index structure is constructed to achieve multi-projection file positioning.

[0064] In the specific implementation process, the file index is a database, the core of which is the file_index table. Each index record in this table corresponds to an MBTiles file, which records the file's attributes. These attributes include, but are not limited to: file path, projection type information, zoom level range information, geographic boundary information, tile number range information, priority information, text describing the data source, timestamp of the file's last update time, total number of tiles contained in the file, and file size in bytes.

[0065] In a specific implementation, as one example, a file index database, namely the file_index table, is created in the SQLite database to store the core attributes of each MBTiles file. The fields are shown in Table 1 below:

[0066] Table 1 In a specific implementation, the step of creating the file index table specifically includes: Create the file index table, which includes at least the path field of the MBTiles file, the projection type field, the geographic range boundary field, the zoom level range field, the tile row and column number range field, the file priority field, the data source field, and the update time field; A spatial index is created on the geographic range boundary fields (bounds_minx / bounds_miny / bounds_maxx / bounds_maxy) for query filtering based on geographic boundary coordinates, mainly for quick coarse filtering of spatial ranges; A composite index is established on the projection type field, the scaling level range field, and the file priority field for attribute screening and sorting. Based on the index database, a discovery and update mechanism is configured to monitor data numbers. When a new compliant MBTiles file is added, or the metadata of an existing file changes, information is extracted and the index record is updated.

[0067] Optionally, Geohash encoding can be used to achieve efficient spatial range lookups.

[0068] Insert the relevant information of the MBTiles file into the file index table. The relevant information includes at least the path of the map tile file, the projection type, the zoom level range, the geographic range boundary, the tile row and column number range, the file priority, the data source, and the update time.

[0069] In the specific implementation process, it also includes: periodically updating the index information in the file index table, the index information including at least the file size, number of tiles, last update time, etc., connecting to the MBTiles file to obtain the number of tiles, and updating the index.

[0070] In an optional implementation, the file priority is determined based on a comprehensive evaluation of the following factors: Data accuracy, update time, data source reliability, regional coverage integrity, and usage frequency.

[0071] One possible implementation also includes an adaptive adjustment step based on file priority using statistics, specifically including: Record the number of queries, the number of successful queries, and the query response time for each MBTiles file. The file priority is dynamically adjusted based on the ratio between the number of successful queries and the number of queries, as well as the frequency of the queries. When a query for the MBTiles file with higher file priority fails, the query is automatically downgraded to the MBTiles file with lower file priority for retrieval.

[0072] Optionally, the file priority is calculated and updated periodically based on a dynamic file priority algorithm using multi-dimensional evaluation factors to ensure that high-value data (high accuracy, high timeliness, high popularity) is queried first. The multi-dimensional evaluation factors include at least two or more of the following: Data accuracy metrics: The metrics are based on the spatial resolution score of MBTiles tile file data. The higher the resolution, the higher the score. For example, aerial imagery is better than satellite imagery. Data timeliness index: The score is calculated using an exponential decay model based on the difference between the file update time and the current time. The more recent the update time, the higher the score. Data source reliability index: Based on the data source type (such as official surveying and mapping institutions, commercial data service providers, open source communities), a pre-set weight score is given. The higher the credibility of the source, the higher the score. For example, official data files have higher priority than third-party data. Regional Coverage Integrity Index: The score is calculated based on the percentage of non-empty tiles in the MBTiles tile file within its geographical coverage area; the higher the percentage, the higher the score. Historical access statistics: The score is mapped based on the number of tile queries for this file over a recent period; the more queries, the higher the score. Optional, dynamic priority adjustment: Priority can be adjusted based on user feedback, or dynamically based on data usage frequency (priority is increased for hot data), or time window priority can be supported (such as adjusting the priority of data during specific seasons or holidays).

[0073] In an optional implementation, a step of dynamic file priority calculation is also included. Figure 3 This is a schematic diagram of the dynamic file priority calculation process provided in the embodiments of this application; as follows: Figure 3 As shown, the file priority calculation process includes the following steps: S310. Obtain file information: Record information such as the number of queries, the number of successful queries, and the update time for each file through service logs, and store it in the statistical database; periodically analyze the proportion of non-empty tiles of files and supplement it to the statistical data. S320, Calculate data accuracy score; S330, Calculate the timeliness score; S340, Calculate the reliability score; S350, Calculate the coverage integrity score; S360, Calculate usage frequency score; S370. Calculate the total score using a weighted summation method: Specifically, the normalized factor scores are summed according to their weights to obtain the total score; S380, return priority.

[0074] The calculated new file priority is updated to the priority field of the file_index table. The update cycle is synchronized with the statistical data collection cycle to ensure that the file priority dynamically adapts to the data status and usage requirements.

[0075] Create an independent file index table, whose core file_index table records metadata such as the path, projection type, minimum and maximum zoom levels, geographic boundary range, tile row and column number range, file priority, data source, and update time for each MBTiles file.

[0076] Optionally, an index data registration process is also included: 1. Scan file directory: Write a tool program to scan all MBTiles files under the / data / mbtiles / directory on the server, and extract the metadata table information (such as projection, zoom level, geographic range) and file attributes (such as path, size, update time) of each file. 2. Insert index records: Assemble the extracted information into records according to the file_index table structure, and insert them into the index database in batches; 3. Incremental Update: Set up a scheduled task to scan for newly added / deleted / updated MBTiles files in the directory and update the index database synchronously; Figure 4 This is a schematic diagram of the projection conversion process provided in an embodiment of this application. In an optional implementation, the projection conversion process in S270 specifically includes the following steps: S401, Based on the geographical boundary, filter out source data files whose source projection type is different from the target projection type from the file index library; The purpose of this step is to attempt to generate target tiles from source data with different projections. The module first queries the Uniform File Index table to find other data source files that, although projected differently, geographically cover the requested area.

[0077] In a specific implementation, based on the file index table, all records in the file index table are traversed, and the target zoom level is matched with the zoom level range information in the projection file list record. If the match is successful, the geographic boundary of the target tile is matched with the geographic boundary information in the projection file list record. If successful, the map tile file is set as the source map tile storage file.

[0078] S402, calculate the coordinates of the source projection tile based on the scaling level range, the coordinates, and the projection information; S403, obtain the source tile data corresponding to the geographical location from the source data file according to the coordinates of the source projected tile.

[0079] S404, based on the conversion parameters between the source projection type and the target projection type, perform coordinate transformation and image resampling on the source tile data to generate tile data corresponding to the coordinates of the target tile and return it.

[0080] In a specific implementation, after determining one or more candidate source projection files, based on the source projection information, target projection type, and transformation parameters, the PROJ.4 parameter strings (including core fields such as projection type, datum, and coordinate units) of the source and target projection types are extracted. The PROJ.4 library, GDAL library, or a similar geographic coordinate transformation library is then called to construct an inverse coordinate transformer from the target projection to the source projection. This transformer performs projection coordinate transformation, converting the planar coordinates of the source projection tile data to the planar coordinates corresponding to the target projection. Simultaneously, the GDAL library is used to perform an image resampling method, adapting the target scaling level to the tile coordinates, generating tile data that conforms to the target projection information. Specifically, for each pixel in the target projection tile image (or a set of sampled grid points selected to balance performance and quality), the module calculates its planar coordinates on the map and obtains its corresponding coordinates on the source projection tile plane through an inverse transformation. From the source projection tile image data, the module uses a resampling algorithm to obtain pixel color values ​​based on these transformed coordinates. Finally, all sampled pixel values ​​are synthesized to generate a new, visually continuous, and geographically accurate target projection tile image.

[0081] Figure 5 A flowchart illustrating the query process for a single tile request provided in an embodiment of this application. Figure 5 As shown, it includes the following steps.

[0082] S500. During service operation, a tile query request is received, which includes the projection type, scaling level, column number, and row number of the target projection tile.

[0083] S510. Generate a cache query key based on the projection information, scaling level, column number and row number of the target projection tile, and query the cache according to the cache query key.

[0084] S520. If the corresponding tile data is found in the cache, the tile data is returned. S530. If the target is not found in the cache, calculate the geographical boundary of the target projection tile based on its projection information, scaling level, column number, and row number. S540. Based on the projection information, zoom level and calculated geographic range boundary, query a preset file index table to find information on one or more candidate MBTiles files containing the target projection tile. The file index table records the file path, column number and row number, projection information, zoom level range, geographic range boundary and priority of multiple MBTiles files. S550. Following the priority order from high to low, query the tile data of the target projection tile sequentially from each of the candidate MBTiles files. If the tile data of the target projection tile is found in a candidate MBTiles file, store the tile data in the cache along with the cache query key, and return the tile data. Calculate the geographical range based on the requested level and tile number. Based on the file list matching the target projection type, filter files covering this range to obtain a candidate tile file list.

[0085] S560. Based on the parsed request parameters, query the file index table and obtain a list of candidate tile files using "projection type matching", "geographic coverage area includes target projection tile area" and "scaling level range covers target projection tile level" as filtering conditions.

[0086] S570. Query each MBTiles file in order of file priority, sort the candidate tile file list in order of file priority from high to low, access all records in the file list in order of priority from high to low, read the file path information in each record, read the MBTiles file information according to the file path information, and obtain the target projection tile according to the MBTiles file information. S580. Determine whether the target projection tile exists in the cache. If it does not exist, put the target projection tile into the cache for caching.

[0087] S590. If no candidate file is found after traversing all candidate files, return an empty result or a default tile. Alternatively, try to dynamically generate a tile from other projections using the projection conversion engine, or return a blank tile.

[0088] The entire management of MBTiles files is handled by an SQLite database. In essence, the file index table is a business data table built on top of the SQLite database; therefore, accessing the file index table is essentially an SQLite database access operation.

[0089] When a large number of users frequently access an SQLite database, contention and locking issues can easily arise. To address this, multiple SQLite database connections can be established and then managed in a List, essentially a database connection pool. When SQLite database access is needed, an unused connection is retrieved from the List and used to access the database.

[0090] Database connection pool management also allows limiting the number of concurrent connections for each file, preventing contention and lock waiting caused by too many threads reading and writing to the same file at the same time.

[0091] Regarding external service interfaces, this system preferably provides a set of API interfaces that conform to RESTful design principles.

[0092] Optional features include performance monitoring and dynamic optimization, specifically: Record at least one of the following performance metrics: number of queries, average query response time, and cache hit rate; The file priority and cache eviction policy of the candidate MBTiles files are dynamically adjusted based on the performance indicators. Provide a standardized interface for external systems to query the performance metrics.

[0093] In some embodiments, multi-threaded parallel queries are used for batch tile requests; a connection pool is used to manage SQLite connections to avoid frequent creation and destruction of connections; and a query pipeline is implemented to improve query throughput.

[0094] Specifically, when the target projection tile acquisition request is a batch request containing multiple sub-requests, the multiple sub-requests are grouped, and the query processes triggered by the sub-requests of different groups are processed in parallel. Figure 6 The parallel processing flowchart for batch tile query provided in this application embodiment is as follows: Figure 6 As shown, the batch query process includes the following steps: S610 receives batch tile requests, requesting multiple tiles at once; S620: Group multiple tile query tasks in batch requests by "target projection type", and group tasks of the same projection type together; within each group, use spatial index to pre-match the geographically close subset of requests with candidate files that may cover them to achieve grouping.

[0095] S630, create parallel tasks; The S640 employs multi-threaded parallel processing, handling different groups of tasks concurrently. The number of threads matches the number of server CPU cores (typically 1-2 times the number of CPU cores). Utilizing a multi-threaded or asynchronous I / O framework, these grouped query tasks are submitted for execution in parallel. Query tasks belonging to different projections or file groups can be executed concurrently. For multiple tile requests that need to query the same file, the system obtains a connection through a connection pool and merges query statements or uses transactions as much as possible to reduce the overhead of single I / O operations.

[0096] S650: Determine if the target projection file has been found. If yes, return the tile; otherwise, search for other projection files. S660, determine if other projection files have been found? Otherwise, return an empty result; if found, calculate the coordinates of the source projection tile and obtain the source projection tile. S670 performs projection conversion; Specifically, first determine a source projection information that is different from the target projection information, and obtain a source map tile storage file that uses the source projection information and whose geographical boundary covers the target projection tile. Then, based on the target projection information and the source projection information, coordinate transformation and image resampling are performed on the source projection tile data obtained from the source map tile storage file to generate target projection tile data corresponding to the target projection information, target scaling level, and coordinates of the target projection tile.

[0097] S680, return the converted tiles; This disclosure provides a map tile storage and retrieval method supporting multiple projections. By adding fields such as projection, projection parameters, and boundaries to the metadata table, a cross-file index table is established. This supports multi-dimensional (projection, level, spatial range, file priority) queries, introduces multi-factor file priority evaluation and dynamic updates, and includes Bloom filters, cache pools, connection pools, batch queries, and projection conversion services. It allows for use with existing MBTiles tools without modification, the index table structure is customizable, supports future new projections or data attributes, and supports RESTful APIs. It supports multi-projection systems, expanding application scenarios; improves file management capabilities and query efficiency; implements intelligent tile services (file priority scheduling, fault tolerance and degradation); optimizes concurrency and batch query performance; Bloom filters reduce unnecessary file queries; connection pools and caching reduce duplicate query response time to milliseconds; the file priority mechanism improves the hit rate of hot data; and optimizes tile retrieval efficiency, reducing map request response time.

[0098] The following detailed explanation of this application is based on a specific implementation example of a national-level geographic information public service platform. This example demonstrates the entire process from data preparation and system construction to service operation and verification.

[0099] Step 1: Standardization of Multi-Projection Tile Data First, raw map tile data from different vendors were integrated. This data employed three different coordinate reference systems: Web Mercator projection (EPSG:3857) for web maps, WGS84 latitude and longitude projection (EPSG:4326) for data exchange, and UTM Zone 50N projection (EPSG:32650) for regional engineering. All data was processed into standard MBTiles format according to the metadata extension specifications of this application. During the generation process, extended fields were injected into the metadata table of each file using a tool: for example, for UTM Zone 50N projected imagery data of Beijing, the injected fields included projection (value "EPSG:32650"), proj4text (value "+proj=utm +zone=50 +datum=WGS84 +units=m +no_defs"), and bounds (value "115.7,39.4,117.4,41.1"). Ultimately, 213 independent MBTiles files were generated, with a total data size of approximately 820GB, covering scaling levels 1 to 18 and a total of approximately 210 million tiles. The files were named according to the specification "region_projection_date.mbtiles" (e.g., beijing_EPSG32650_20231201.mbtiles) and centrally stored in a server directory.

[0100] Step 2: Building the File Index Table and Optimization Components The system described in this application is deployed on a computing server. An index management program is run to automatically scan all MBTiles files, extract their metadata and statistics, and create a unified file index table (file_index) in a separate SQLite database (file_index.db). The table's structure includes fields such as file path, projection, scaling level range, geographic boundary coordinates, and file priority. Subsequently, an index building program is run. This program scans all .mbtiles files under the / data / mbtiles / directory, extracts key information from their metadata tables, calculates the actual number of tiles and file size for each file, and finally inserts this information as a record into the file_index table. For the aforementioned Beijing UTM projection file, its index record includes information such as file path, projection information (EPSG:32650), scaling level range (8-18), geographic boundary coordinates (parsed from the bounds field), and initial priority. An R-tree spatial index is created on the geographic boundary coordinates field of this table, and composite indexes are created on the projection, scaling level, and priority fields to support efficient multi-dimensional queries.

[0101] Meanwhile, the system initializes performance optimization components: it builds a Bloom filter with a capacity of 1 million and a false positive rate of 1% for each MBTiles file to quickly predict whether a tile exists; it establishes an LRU memory cache that can store 10,000 recently accessed tiles; and it configures an SQLite database connection pool with a maximum number of 20 connections to manage connections to each MBTiles file.

[0102] Step 3: Operation flow of the smart tile query service After the system starts, it listens for requests as a network service. When it receives a tile request, such as / tiles / EPSG:32650 / 14 / 210 / 130.png, the service processes it according to the following logic: Analysis and Calculation: The target projection is resolved to "EPSG:32650", with a scaling level of z=14, tile column number x=210, and row number y=130. Subsequently, based on this projection definition, the geographic range (WGS84 latitude and longitude) corresponding to the coordinates of this tile is calculated.

[0103] Candidate File Filtering: The service queries a unified file index table. The query statement uses an R-tree spatial index to quickly find all files whose geographic range intersects with the requested tile range, while simultaneously limiting projection='EPSG:32650' and z-values ​​to within the file's hierarchical range. The query results are returned in descending order of the priority field, forming a candidate file list.

[0104] Priority Query and Caching: The service queries each candidate file in list order. Before querying, a Bloom filter is used to check the file; if the target projected tile is determined to "definitely not exist," the file is skipped. For files that pass the check, a database connection is obtained through the connection pool, and the query is executed. If tile data is found in a file, it is immediately returned to the client and stored in the LRU cache. In this example, the system may find the target projected tile in the file beijing_EPSG32650_20231201.mbtiles.

[0105] Step 4: Dynamic Priority Calculation and Adaptive Scheduling The system's background priority calculation daemon runs automatically every 6 hours. It recalculates the priority of each file based on a preset weight model (data accuracy 30%, timeliness 25%, source reliability 20%, coverage integrity 15%, access frequency 10%).

[0106] For example, a document from the "Beijing Survey Office", with an accuracy of 0.5 meters and updated 30 days ago, has a high accuracy factor score (10 points), a timeliness factor score calculated using the decay model (approximately 8.7 points), and a high reliability factor score (10 points). After comprehensive calculation, its priority may be set as 9.

[0107] Another source, "Commercial Provider A," with an accuracy of 2 meters and updated 7 days ago, is likely to have a priority of 8 based on calculations.

[0108] When a high-priority (9) file becomes inaccessible due to a failure, the system will automatically switch to the next highest priority (8) candidate file after the query times out, thereby achieving seamless service degradation and high availability.

[0109] Step 5: Optimization of Cross-Projection Transformation and Batch Query When the requested projection tile (e.g., EPSG:4326) does not have a directly corresponding file in the index, the system initiates a dynamic projection transformation. For example, the system selects the EPSG:3857 projection file with overlapping geographical areas as the source, uses the PROJ.4 library to build a coordinate converter, resamples the source projection tile (e.g., using bilinear interpolation), generates the target projection tile in real time, and returns it.

[0110] For scenarios where the front-end map library requests dozens of tiles within a viewport at once, the system groups the requests by projection and uses multi-threading to query tiles from different groups in parallel, finally merging the results, which greatly improves batch loading efficiency.

[0111] Step Six: Quantitative Verification of Technical Effects Under the same hardware environment (AWS EC2 c5.2xlarge), the system of this application (Service B) was compared with the standard MBTiles service (Service A) that only supports a single projection: Comparison Service A: Uses the open-source standard MBTiles server software, which can only provide tile services for a single EPSG:3857 projection.

[0112] Service B of this application: A system that has deployed complete multi-projection support, unified indexing, dynamic conversion and optimization modules.

[0113] The test used a simulated client to initiate requests, and the key results are compared in Table 2 below:

[0114] Table 2 V. Case Conclusion The quantification results are as follows: Query performance: The average response time per tile for service B is 3.8 milliseconds, which is significantly lower than the 15.5 milliseconds for service A.

[0115] Concurrency capability: With 100 concurrent threads, the query throughput (QPS) of service B reaches 5620, which is 4.9 times that of service A (approximately 1150 QPS).

[0116] Functional coverage: For cross-projection tile requests (e.g., requesting EPSG:32650 but only having EPSG:3857 data), service B achieved a success rate of over 98% through dynamic conversion, while service A could not support it (0% success rate).

[0117] Management efficiency: Service B, through a unified index, can complete complex range queries (approximately 5,000 tiles) covering the Yangtze River Delta region in 0.4 seconds, while the traditional solution takes 9.8 seconds.

[0118] Through a dynamic prioritization mechanism, the system can automatically select high-quality data sources and seamlessly degrade them in the event of a failure, thereby improving service robustness.

[0119] It not only solves the technical problems of the traditional MBTiles format, such as the single projection, inefficient data management, and lack of intelligent scheduling, but also realizes efficient and intelligent map tile services with multi-projection support.

[0120] Based on the above embodiments, this disclosure also provides a map tile storage and retrieval device that supports multiple projections, such as... Figure 7 As shown, the device includes: The parsing module 710 is used to parse the projection type, scaling level, and tile coordinate parameters of the target projection tile in the query request; The first filtering module 720 is used to respond to the query request and filter MBTiles files that match the projection type in a pre-built file index table according to the projection type of the target projection tile. The second filtering module 730 is used to calculate the corresponding geographic boundary based on the scaling level and tile coordinate parameters of the target projection tile, and further filter out candidate MBTiles files that cover the geographic boundary from the filtering results. The sorting module 740 is used to sort the candidate MBTiles files according to their file priority to generate a candidate file sequence; The retrieval module 750 is used to retrieve the target projection tile data corresponding to the tile coordinate parameters of the target projection tile from the data source indicated by each of the candidate MBTiles files in the order of file priority of the candidate file sequence. The first processing module 760 is used to return the retrieved target projection tile data and cache it if the retrieval is successful. The second processing module 770 is used to initiate a cross-projection data conversion process to generate the target projection tile data that meets the requirements, based on the information in the file index table, if the target projection tile data is not found in any of the candidate MBTiles files in the candidate file sequence.

[0121] In a specific implementation, a first creation module 780 is further included, configured to: add a projection type field to the metadata table of the MBTiles file to store the projection type, wherein the projection type is represented by a map coordinate reference system identifier; add a projection parameter description field to the metadata table of the MBTiles file to store information describing the projection parameters; add a projection conversion parameter field to the metadata table of the MBTiles file to store information on conversion parameters between the projection type and other projection types; name the MBTiles file using a naming format that includes the projection type, so that the projection type can be directly identified by the filename; and generate tile data for different projection types using a tile generation tool and store the tile data in the MBTiles file.

[0122] In a specific implementation, a second creation module 790 is further included, used to create the file index table. The file index table includes at least the path field of the MBTiles file, the projection type field, the geographic extent boundary field, the zoom level range field, the tile row and column number range field, the file priority field, the data source field, and the update time field. A spatial index is established on the geographic extent boundary field for query filtering based on geographic boundary coordinates. A composite index is established on the projection type field, the zoom level range field, and the file priority field for attribute fine filtering and sorting. Relevant information of the MBTiles file is inserted into the file index table. The relevant information includes at least the path of the map tile file, the projection type, the zoom level range, the geographic extent boundary, the tile row and column number range, the file priority, the data source, and the update time. The index information in the file index table is updated periodically. The index information includes at least the file size, the number of tiles, and the update time.

[0123] In a specific implementation, the file priority is determined based on a comprehensive evaluation of the following factors: Data accuracy, update time, data source reliability, regional coverage integrity, and usage frequency.

[0124] In a specific implementation, the first creation module 780 is further configured to record the number of queries, the number of successful queries, and the query response time for each MBTiles file; dynamically adjust the file priority based on the ratio between the number of successful queries and the number of queries, as well as the frequency of the queries; and automatically downgrade to searching for MBTiles files with lower file priority when a query for a higher-priority MBTiles file fails.

[0125] In a specific implementation, the second creation module 790 is further configured to: filter source projection tile files whose projection types differ from those of the target projection tile from the file index table based on the geographic range boundary; calculate the coordinates of the source projection tile according to the scaling level range, the coordinates, and the projection information; obtain source projection tile data corresponding to the geographic location from the source projection tile files based on the coordinates of the source projection tile; and perform coordinate transformation and image resampling on the source projection tile data based on the conversion parameters between the projection types of the source projection tile and the target projection tile to generate target projection tile data corresponding to the coordinates of the target projection tile.

[0126] In a specific implementation, the first processing module 780 is further configured to use a Bloom filter pre-built for the data source to determine whether the target projection tile data corresponding to the coordinates of the target projection tile may exist therein; if it is determined that it is impossible to exist, the retrieval operation of the target projection tile data is skipped.

[0127] In a specific implementation, the cache is a multi-level cache, including at least a memory cache for storing hot data and a disk cache for storing full or recent data; In a specific implementation, the first processing module 780 is further configured to perform data scheduling and eviction among the caches at each level based on the data access frequency and timeliness.

[0128] In a specific implementation, a batch processing module is also included, which is used to group the sub-requests according to the projection type of their target projection tiles and / or the geographical range boundary, and to perform parallel processing on the multi-level data positioning and acquisition process triggered by the sub-requests of different groups.

[0129] In a specific implementation, a monitoring module is also included, which is used to record at least one of the following performance indicators: number of queries, average query response time, and cache hit rate; dynamically adjust the file priority and cache eviction policy of the candidate MBTiles files according to the performance indicators; and provide a standardized interface for external systems to query the performance indicators.

[0130] The map tile storage and retrieval device supporting multiple projections provided in this disclosure establishes a cross-file index table by adding fields such as projection, projection parameters, and boundaries to the metadata table. It supports multi-dimensional (projection, hierarchy, spatial range, file priority) queries, introduces multi-factor file priority evaluation and dynamic updates, and includes Bloom filters, a cache pool, a connection pool, batch queries, and projection conversion services. This allows for use with existing MBTiles tools without modification. The index table structure is customizable, supports future new projections or data attributes, and natively supports RESTful APIs for easy integration. It supports multi-projection systems, expanding application scenarios; improves file management capabilities and query efficiency; implements intelligent tile services (file priority scheduling, fault tolerance and degradation); optimizes concurrency and batch query performance; Bloom filters reduce unnecessary file queries; connection pools and caching reduce duplicate query response time to milliseconds; the file priority mechanism improves the hit rate of hot data; and optimizes tile retrieval efficiency, reducing map request response time.

[0131] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and 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 modules can be selected to achieve the purpose of the present invention according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0132] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0133] In the various embodiments of this application, the functional units or modules can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0134] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0135] Unless otherwise expressly indicated by the context, the singular form of words used herein and in the appended claims includes the plural form, and vice versa. Thus, when referring to the singular, the plural form of the corresponding term is generally included. Similarly, the terms “comprising” and “including” shall be interpreted as including rather than exclusively. Likewise, the terms “including” and “or” shall be interpreted as including unless such interpretation is expressly prohibited herein. Where the term “example” is used herein, particularly when it follows a set of terms, the “example” is merely exemplary and illustrative and should not be considered exclusive or extensive.

[0136] Further aspects and scope of adaptation become apparent from the description provided herein. It should be understood that various aspects of this application may be implemented individually or in combination with one or more other aspects. It should also be understood that the descriptions and specific embodiments herein are for illustrative purposes only and are not intended to limit the scope of this application.

[0137] Several embodiments of this disclosure have been described in detail above. However, it is obvious that those skilled in the art can make various modifications and variations to the embodiments of this disclosure without departing from the spirit and scope of this disclosure. The scope of protection of this disclosure is defined by the appended claims.

[0138] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0139] Obviously, those skilled in the art should understand that the various units or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device, or fabricating them separately as individual integrated circuit modules, or fabricating multiple modules or steps into a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0140] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for storing and retrieving map tiles supporting multiple projections, characterized in that, include: Parse the projection type, scaling level, and tile coordinate parameters of the target projected tile in the query request; In response to the query request, MBTiles files that match the projection type of the target projection tile are filtered in a pre-built file index table. The corresponding geographic boundary is calculated based on the scaling level and tile coordinate parameters of the target projection tile, and candidate MBTiles files covering the geographic boundary are further filtered from the filtering results. The candidate MBTiles files are sorted according to their file priority to generate a candidate file sequence; According to the file priority order of the candidate file sequence, the target projection tile data corresponding to the tile coordinate parameters of the target projection tile is retrieved sequentially from the data source indicated by each candidate MBTiles file; If the retrieval is successful, the retrieved target projection tile data is returned and cached. If the target projection tile data is not found in any of the candidate MBTiles files in the candidate file sequence, a cross-projection data conversion process is initiated based on the information in the file index table to generate the target projection tile data that meets the requirements.

2. The method according to claim 1, characterized in that, Prior to the step of filtering MBTiles files with matching projection types in a pre-built file index table, the method further includes a step of creating the MBTiles files, specifically including: A projection type field is added to the metadata table of the MBTiles file to store the projection type, which is represented by a map coordinate reference system identifier. Add a projection parameter description field to the metadata table of the MBTiles file to store information describing the projection parameters; Add a projection conversion parameter field to the metadata table of the MBTiles file to store conversion parameter information between the projection type and other projection types; The MBTiles files are named using a naming format that includes the projection type, so that the projection type can be directly identified by the filename; Tile data of different projection types are generated using a tile generation tool, and the tile data is stored in the MBTiles file.

3. The method according to claim 2, characterized in that, Following the step of creating the MBTiles file, the following is also included: Create the file index table, which includes at least the path field of the MBTiles file, the projection type field, the geographic range boundary field, the zoom level range field, the tile row and column number range field, the file priority field, the data source field, and the update time field; A spatial index is created on the geographic boundary field for query filtering based on geographic boundary coordinates; A composite index is created on the projection type field, the scaling level range field, and the file priority field for attribute filtering and sorting. Insert the relevant information of the MBTiles file into the file index table. The relevant information includes at least the path of the map tile file, the projection type, the zoom level range, the geographic range boundary, the tile row and column number range, the file priority, the data source, and the update time. The index information in the file index table is updated periodically, and the index information includes at least the file size, the number of tiles, and the update time.

4. The method according to claim 1, characterized in that, The file priority is evaluated based on a comprehensive assessment of the following factors: Data accuracy, update time, data source reliability, regional coverage integrity, and usage frequency.

5. The method according to claim 1, characterized in that, It also includes an adaptive adjustment step for file priority based on usage statistics, specifically including: Record the number of queries, the number of successful queries, and the query response time for each MBTiles file. The file priority is dynamically adjusted based on the ratio between the number of successful queries and the number of queries, as well as the frequency of the queries. When a query for the MBTiles file with higher file priority fails, the query is automatically downgraded to the MBTiles file with lower file priority for retrieval.

6. The method according to claim 1, characterized in that, The step of initiating the cross-projection data conversion process to generate the target projection tile data that meets the requirements specifically includes: Based on the geographical boundaries, source projection tile files whose projection types differ from those of the target projection tiles are selected from the file index table. The coordinates of the source projection tile are calculated based on the scaling level range, the coordinates, and the projection information; Based on the coordinates of the source projection tile, obtain the source projection tile data corresponding to the geographical location from the source projection tile file; Based on the conversion parameters between the projection type of the source projection tile and the projection type of the target projection tile, coordinate transformation and image resampling are performed on the source projection tile data to generate target projection tile data corresponding to the coordinates of the target projection tile.

7. The method according to claim 1, characterized in that, Before the step of retrieving the target projection tile data corresponding to the coordinates of the target projection tile from the data source indicated by the candidate file sequence, the method further includes: The Bloom filter pre-built for the data source is used to determine whether the target projection tile data corresponding to the coordinates of the target projection tile may exist therein; If it is determined that the target cannot exist, the retrieval operation for the target's projected tile data is skipped.

8. The method according to claim 1, characterized in that, The cache is a multi-level cache, including at least a memory cache for storing hot data and a disk cache for storing full or recent data; Following the step of returning and caching the retrieved target projection tile data, the method further includes: Based on the frequency and timeliness of data access, data scheduling and eviction are performed among the various levels of cache.

9. The method according to claim 1, characterized in that, When the query request is a batch request containing multiple sub-requests, the method further includes: The sub-requests are grouped according to the projection type of their target projection tiles and / or the geographical boundaries, and the multi-level data positioning and acquisition processes triggered by the sub-requests of different groups are processed in parallel.

10. A map tile storage and retrieval device supporting multiple projections, characterized in that, include: The parsing module is used to parse the projection type, scaling level, and tile coordinate parameters of the target projection tile in the query request; The first filtering module is used to respond to the query request and filter MBTiles files that match the projection type in a pre-built file index table according to the projection type of the target projection tile. The second filtering module is used to calculate the corresponding geographic boundary based on the scaling level and tile coordinate parameters of the target projection tile, and further filter out candidate MBTiles files that cover the geographic boundary from the filtering results. The sorting module is used to sort the candidate MBTiles files according to their file priority, and generate a candidate file sequence; The retrieval module is used to retrieve the target projection tile data corresponding to the tile coordinate parameters of the target projection tile from the data source indicated by each of the candidate MBTiles files in the order of file priority of the candidate file sequence. The first processing module is used to return the retrieved target projection tile data and cache it if the retrieval is successful. The second processing module is used to initiate a cross-projection data conversion process to generate the target projection tile data that meets the requirements, based on the information in the file index table, if the target projection tile data is not found in any of the candidate MBTiles files in the candidate file sequence.

Images