An optimized method, system, and storage medium for online map tile loading.

Abstract

This invention discloses an optimized method for online map tile loading, belonging to the technical field of geographic information systems. The method includes: performing a layer refresh; determining whether all tiles for the current layer have been loaded; if yes, storing the request result for the current layer in a tile index table; if no, loading each tile sequentially; querying the loading record of the tile to be loaded; if it has been loaded and the current tile also has a tile image, determining whether the tile image exists in the terminal; if it exists, performing view drawing; if it does not exist, performing view creation; if it has been loaded but the current tile does not have a tile image, not loading the tile; if it has not been loaded, sending a header request to the tile address and determining whether the tile exists; if it exists, performing view creation; if it does not exist, not loading the tile; thereby reducing client resource consumption and minimizing server and network resource waste.

Description

Technical Field

[0001] This invention belongs to the technical field of geographic information systems, and more specifically, relates to an optimized method and system for online loading of map tiles. Background Technology

[0002] With the popularization of Web Geographic Information Systems (WebGIS), tile-based map loading technology has become the core of online electronic map services. This technology cuts the map into countless standard square images (i.e., tiles) at different zoom levels and displays the map by dynamically stitching these tiles together on the client side.

[0003] In existing technologies, when a map view needs to be refreshed, for example when a user performs a panning or zooming operation, the typical tile loading process is as follows:

[0004] S1: Calculate map extent

[0005] Calculate the geographic area to be displayed based on the center point, zoom level, and size of the current map;

[0006] S2: Calculate the tile index

[0007] Based on this geographical range and zoom level, the level, row (X), and column (Y) index numbers of the tiles to be loaded are calculated using specific mapping rules (such as the tile map pyramid model).

[0008] S3: Creating Views and Asynchronous Loading

[0009] For each calculated tile index, a view container is created at the corresponding screen position. Then, each view asynchronously sends a URL-based request to the server (usually filling the URL template with Level, X, and Y as parameters) to load the corresponding tile image.

[0010] However, when map data is not a continuous grid covering the entire globe, but rather presents an irregular shape—for example, a map displaying only the administrative boundaries of a province or municipality—the aforementioned general methods reveal significant shortcomings. Numerous "blank tiles" with no actual map data are generated around the data area, yet views are still created and network requests are initiated for them, leading to the following two main problems:

[0011] (1) Client resource consumption: Creating a large number of blank view elements, even if they have no actual content, will consume memory and computing resources, especially on low-performance devices, which may cause slow page response or even lag.

[0012] (2) Waste of server and network resources: Sending a large number of invalid requests to the server for blank tiles not only occupies valuable network connections (the number of concurrent requests from the client to the same domain name is limited), but also increases the server's invalid calculation and I / O pressure, especially in high-concurrency access scenarios, which wastes server resources and bandwidth.

[0013] Therefore, there is an urgent need in this field for an optimization method that can avoid loading these blank tiles in order to reduce client resource consumption and reduce server and network resource waste. Summary of the Invention

[0014] In view of this, in order to solve the above-mentioned problems existing in the prior art, the purpose of this invention is to provide an optimized method and system for online loading of map tiles, so as to reduce client resource consumption and reduce server and network resource waste.

[0015] The technical solution adopted in this invention is: an optimized method for online loading of map tiles, the optimized method comprising:

[0016] S1: Perform a layer refresh;

[0017] S2: Determine whether the current layer has finished loading all tiles. If yes, store the request result of the current layer into the tile index table. If no, load each tile in sequence.

[0018] S3: Query the loading records of the tiles to be loaded. If they have been loaded, execute S4; otherwise, execute S5.

[0019] S4: Determine if a tile image exists for the current tile. If it exists, execute S6; otherwise, do not load the tile and return to S2. This can effectively reduce client memory consumption and improve rendering performance and user experience.

[0020] S5: Send a head request to the tile address and check if the tile exists. If it exists, execute view creation and return to S2; if it does not exist, do not load the tile and return to S2.

[0021] S6: Determine if the tile image exists in the terminal. If it exists, execute view drawing; if it does not exist, execute view creation and return to S2.

[0022] Furthermore, the layer refresh in S1 includes:

[0023] S101: Execute map loading and obtain map extent;

[0024] S102: Perform layer loading based on the map range and calculate the parameter information of the tiles to be loaded for the current layer;

[0025] S103: Based on the parameter information, query the loading record of each tile to be loaded in the tile index table.

[0026] Furthermore, the table structure of the tile index table includes: tile level, tile row number, tile column number, and tile validity flag.

[0027] Furthermore, the map loading process is as follows: determine whether a database file exists; if it exists, open the database; if it does not exist, create the database and open it.

[0028] Furthermore, the layer loading process is as follows: determine whether the tile index table for the layer exists in the database; if it exists, call the tile index table; if it does not exist, create the tile index table for the layer.

[0029] Furthermore, in S5, after initiating a head request to the tile address, the result of determining whether the tile exists is temporarily stored in the terminal's memory.

[0030] Furthermore, the execution process for creating the view is as follows:

[0031] A1: Convert the tile's parameter information into screen coordinates;

[0032] A2: Create a view in screen coordinates;

[0033] A3: Creating a child thread is intended to avoid blocking the main thread;

[0034] A4: Initiate a GET request to the tile address;

[0035] A5: After obtaining the tile image, draw the tile image in the view.

[0036] Furthermore, the execution process of drawing the view is as follows:

[0037] B1: Convert the tile's parameter information into screen coordinates;

[0038] B2: Create a view in screen coordinates;

[0039] B3: Draw the tile image in the view.

[0040] The present invention also discloses an optimization system for online loading of map tiles, the optimization system comprising: at least one processor and at least one memory, wherein at least one memory stores program instructions, and at least one processor reads the program instructions and executes the above-described optimization method for online loading of map tiles.

[0041] The present invention also discloses a storage medium storing program instructions, wherein a computer reads the program instructions and executes the above-described optimized method for online loading of map tiles.

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

[0043] The optimized online map tile loading method provided by this invention can accurately identify "valid tiles" and "blank tiles" through a predictive mechanism after calculating the tile index and before creating the view and initiating the request. For tiles identified as blank, the subsequent loading process is skipped, which drastically reduces the number of HTTP requests sent to the server. This directly reduces the computational, I / O, and bandwidth pressure on the map server, enabling it to process valid requests more efficiently, improving service stability and scalability. At the same time, it also saves network traffic for the client, which is particularly beneficial for users in mobile network environments. Ultimately, it can significantly reduce invalid requests and save server and network resources. Attached Figure Description

[0044] Figure 1 This is a flowchart illustrating the operational logic of the optimized method for online map tile loading provided by this invention.

[0045] Figure 2 This is a diagram illustrating the operational logic of map loading in the optimized online map tile loading method provided by this invention. Detailed Implementation

[0046] The embodiments of this application are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar modules or modules having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application. Rather, the embodiments of this application include all variations, modifications, and equivalents falling within the spirit and scope of the appended claims.

[0047] Example 1

[0048] To significantly reduce invalid requests and conserve server and network resources, such as Figure 1 and Figure 2 As shown, this embodiment aims to provide an optimized method for online loading of map tiles, which includes:

[0049] S1: Perform a layer refresh. Specifically, the layer refresh includes:

[0050] S101: Execute map loading and obtain map range. The map loading process is as follows: determine whether a database file exists. If it exists, open the database to prepare for subsequent tile record query and storage; if it does not exist, create the database and open it to prepare for subsequent tile record query and storage.

[0051] S102: Perform layer loading based on the map extent and calculate the parameter information of the tiles to be loaded for the current layer; the layer loading process is as follows: determine whether the tile index table for this layer exists in the database; if it exists, call the tile index table; if it does not exist, create the tile index table for this layer; wherein, the table structure of the tile index table includes: tile level, tile row number, tile column number, and tile validity flag (isNull).

[0052] S103: Based on the parameter information, query the loading record of each tile to be loaded in the tile index table. The parameter information of the tile includes: tile level, tile row number, and tile column number. Specifically, the parameter information stored in the tile index table corresponds one-to-one with the parameter information of the "currently loading tile." For example, if the tile with "level=3, row=5, column=8" needs to be loaded, the query operation involves searching the tile index table for a row of data that perfectly matches this parameter set.

[0053] S2: Determine whether the current layer has finished loading all tiles. If yes, store the request result of the current layer in the tile index table for easy reuse later. If no, load each tile in sequence, that is, load all the required tiles in order, and load the next tile only after loading the previous one to ensure the loading is orderly.

[0054] S3: Query the loading record of the tile to be loaded. If it has been loaded, proceed to S4; otherwise, proceed to S5. The core requirement of this step is efficiency, avoiding the repetitive loading of existing tiles and saving network, memory, and time resources. Therefore, the above "querying the loading record of each tile to be loaded in the tile index table" is the priority verification step.

[0055] ① If a matching record is found, it means that the tile has been loaded before, and there is no need to initiate a network request or memory check again. You can directly proceed to the subsequent view drawing stage.

[0056] ②If no matching record is found, subsequent steps such as "sending a Head request to the tile address" will be triggered to ensure the necessity of loading at each step.

[0057] S4: Determine if a tile image exists for the current tile based on the record information in the tile index table. If it exists, it is considered a "valid tile," and S6 is executed; if it does not exist, it is considered a "blank tile," and the tile is not loaded, returning to S2. Based on the execution logic of this step, since no corresponding view container is created for blank tiles, the number of views that the client needs to maintain is greatly reduced, which directly leads to a significant reduction in memory usage. This avoids the memory bloat and garbage collection pressure that may be caused by a large number of blank views. Less memory usage and a lighter view structure make map rendering and interaction (such as panning and zooming) smoother, effectively reducing page lag, improving the application's frame rate and overall user experience smoothness, which is particularly noticeable for terminal devices with limited performance.

[0058] S5: Send a head request to the tile address and determine whether the tile exists, that is, whether there is a valid tile image at the tile address, or whether the tile image has been deleted; the core purpose of sending the head request is to "verify availability" rather than "obtain the image itself"; the result of the request to determine whether the tile exists after sending the head request to the tile address is temporarily stored in the terminal's memory;

[0059] If it exists, then execute view creation and return to S2; the execution process of view creation is as follows:

[0060] A1: Convert the tile parameter information into screen coordinates; establish the correspondence between the geographic coordinate system and the screen pixel coordinate system based on the current map's "zoom level, rotation angle, screen resolution" and other parameters, and finally calculate the precise pixel position of each tile on the screen. For example, a certain tile corresponds to a rectangular area on the screen from x=100px, y=200px to x=356px, y=456px.

[0061] A2: Create a view in screen coordinates. The view is the basic container for interface rendering, and is essentially a rectangular display area that matches the screen coordinates of the tiles. This step creates a view container at the corresponding position on the screen based on the screen coordinates calculated in A1 (such as the top-left corner pixel and the width and height pixel values ​​of the rectangle). The size and position of the view container are completely consistent with the screen mapping range of the tiles.

[0062] A3: Create a child thread. A child thread is an auxiliary thread that is independent of the main thread. Its purpose is to avoid blocking the main thread and ensure a smooth interface.

[0063] A4: Send a GET request to the tile address; the "tile address" is the unique URL where the tile image is stored on the server (e.g., http: / / xxx.com / tile / level=3 / row=5 / column=8.png), generated by concatenating the tile's level / row / column parameters; the "GET request" is an HTTP request method. In the sub-thread created in A3, a GET request is sent to the target tile address. After the server receives the request, since the Head request returned that the tile exists, the GET request will return the binary data of the tile image.

[0064] A5: After obtaining the tile image, draw the tile image in the view; download the image binary data from the server via a Get request in A4, and decode the data (convert the binary data into a screen-recognizable image format, such as Bitmap or PNG); call the rendering interface to accurately fill the decoded tile image into the view container created in step A2, and ensure that the pixels of the tile image are perfectly aligned with the pixels of the view container.

[0065] If the image does not exist, there is no need to directly initiate a Get request to download the complete image. Instead, this tile is not loaded and S2 is returned to avoid wasting network traffic and save loading time. The same applies to S4 above, so it will not be repeated here.

[0066] This step only sends a Head request. If the server returns a success status code like "200 OK", it means that a usable tile image exists at that tile address, and a subsequent GET request will be sent to download the image. If it returns "404 Not Found", it means that the tile image does not exist, and loading will be skipped to avoid unnecessary resource consumption.

[0067] For example, assuming a tile address is "http: / / xxx.com / tile / level=1 / row=2 / column=3.png", after initiating a header request, the server will only return header information such as "whether this address is valid and what the image size is", without transmitting several KB or even tens of KB of image data. "Lightweight validation" can significantly reduce the waste of network resources, especially in weak network environments, and can greatly improve the efficiency and smoothness of map loading.

[0068] S6: Determine if the tile image exists in the terminal, i.e., the tile image temporarily cached in the terminal's memory, with a millisecond-level response time. The determination method is as follows: Build a tile cache pool in the terminal's memory, where: key = unique tile identifier, value = tile image object; use the current tile's level + row + column as the key to query the cache pool for the corresponding value; if it exists and the image object is not corrupted (e.g., not reclaimed from memory, and has a normal format), then it is directly determined that the terminal has the tile image; if the image does not exist or is corrupted, then the terminal does not have the tile image.

[0069] If the tile image exists, then the tile image is used directly and the view is drawn; the view drawing process is as follows:

[0070] B1: Convert the tile parameter information into screen coordinates; establish the correspondence between the geographic coordinate system and the screen pixel coordinate system based on the current map's "zoom level, rotation angle, screen resolution" and other parameters, and finally calculate the precise pixel position of each tile on the screen. For example, a certain tile corresponds to a rectangular area on the screen from x=100px, y=200px to x=356px, y=456px.

[0071] B2: Create a view in screen coordinates; Based on the screen coordinates calculated by B1 (such as the top left corner pixel and width and height pixel values ​​of the rectangle), create a view container at the corresponding position on the screen. The size and position of the view container are completely consistent with the screen mapping range of the tile.

[0072] B3: Draw the tile image in the view; by calling the tile image binary data in the terminal and decoding the data (converting the binary data into a screen-recognizable image format, such as Bitmap or PNG), the rendering interface is called to accurately fill the decoded tile image into the view container created in step B2, and the pixels of the tile image are perfectly aligned with the pixels of the view container.

[0073] If the tile image does not exist, view creation is performed and S2 is returned. The execution process of view creation is the same as described above, and will not be repeated here.

[0074] It should be noted that the triggering conditions / scenarios for map loading, layer loading, and layer refresh mentioned in this embodiment are as follows: map loading is triggered when the map is opened for the first time or when switching maps; layer loading is automatically triggered when the map is loaded; and layer refresh is triggered when the view changes (when zooming) or when data is updated.

[0075] Head requests and GET requests are two common request methods in the HTTP protocol. The characteristic of a head request is that it only requires the server to return "response header information" and does not return the actual resource content (such as the binary data of a tile image); while a GET request requires the server to return both the response header and the complete resource content.

[0076] Based on the above, this map tile loading optimization method can improve the efficiency of concurrent client requests and accelerate the loading of valid tiles. When a large number of requests (such as those containing several invalid blank tiles) block the request queue, requests for valid tiles that actually need to be displayed may be delayed. The optimization method allows requests for valid tiles to be sent and responded to more quickly, essentially creating a "green channel" for critical requests. This shortens the overall loading time of the effective map area, allowing users to see the actual map content faster and reducing the visual waiting period.

[0077] Example 2

[0078] This embodiment discloses an optimization system based on the online map tile loading optimization method in Embodiment 1. The optimization system includes a processor and a memory. The memory stores program instructions, and the processor reads the program instructions and executes the online map tile loading optimization method in Embodiment 1.

[0079] Example 3

[0080] This embodiment discloses a storage medium based on the online map tile loading optimization method in Embodiment 1. The storage medium stores program instructions, and the computer reads the program instructions and executes the online map tile loading optimization method in Embodiment 1.

[0081] It should be noted that any process or method description in the flowchart or otherwise described herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including in substantially the same manner or in the reverse order of the functions involved, as should be understood by those skilled in the art to which the embodiments of this application pertain.

[0082] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0083] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0084] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0085] The storage media mentioned above can be read-only memory, disk, or optical disk, etc.

[0086] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. An optimized method for online loading of map tiles, characterized in that, The optimization method includes: S1: Perform a layer refresh; S2: Determine whether the current layer has finished loading all tiles. If yes, store the request result of the current layer into the tile index table. If no, load each tile in sequence. S3: Query the loading record of the tile to be loaded. If it has been loaded, execute S4; if it has not been loaded, execute S5. S4: Determine if a tile image exists for the current tile. If it exists, proceed to S6; otherwise, do not load the tile and return to S2. S5: Send a head request to the tile address and check if the tile exists. If it exists, execute view creation and return to S2; if it does not exist, do not load the tile and return to S2. S6: Determine if the tile image exists in the terminal. If it exists, execute view drawing; if it does not exist, execute view creation and return to S2.

2. The optimized method for online loading of map tiles according to claim 1, characterized in that, The layer refresh in S1 includes: S101: Execute map loading and obtain map extent; S102: Perform layer loading based on the map range and calculate the parameter information of the tiles to be loaded for the current layer; S103: Based on the parameter information, query the loading record of each tile to be loaded in the tile index table.

3. The optimized method for online loading of map tiles according to claim 2, characterized in that, The structure of the tile index table includes: tile level, tile row number, tile column number, and tile validity flag.

4. The optimized method for online loading of map tiles according to claim 2, characterized in that, The map loading process is as follows: determine if a database file exists; if it exists, open the database; if it does not exist, create the database and open it.

5. The optimized method for online loading of map tiles according to claim 4, characterized in that, The layer loading process is as follows: determine whether the tile index table for the layer exists in the database. If it exists, call the tile index table; if it does not exist, create the tile index table for the layer.

6. The optimized method for online loading of map tiles according to claim 1, characterized in that, In step S5, after sending a head request to the tile address, the result of determining whether the tile exists is temporarily stored in the terminal's memory.

7. The optimized method for online loading of map tiles according to claim 1, characterized in that, The execution process for creating the view is as follows: A1: Convert the tile's parameter information into screen coordinates; A2: Create a view in screen coordinates; A3: Create a child thread; A4: Initiate a GET request to the tile address; A5: After obtaining the tile image, draw the tile image in the view.

8. The optimized method for online loading of map tiles according to claim 1, characterized in that, The execution process of drawing the view is as follows: B1: Convert the tile's parameter information into screen coordinates; B2: Create a view in screen coordinates; B3: Draw the tile image in the view.

9. An optimized system for online loading of map tiles, characterized in that, The optimization system includes at least one processor and at least one memory, wherein at least one memory stores program instructions, and at least one processor reads the program instructions and executes the online map tile loading optimization method as described in any one of claims 1-8.

10. A storage medium, characterized in that, The storage medium stores program instructions, and the computer reads the program instructions and executes the optimized method for online loading of map tiles as described in any one of claims 1-8.

Images