WMTS layer rendering request processing method and device, equipment and storage medium

Abstract

The invention discloses a WMTS layer rendering request processing method and device, equipment and a storage medium, a request construction and rendering conversion step is added between layer configuration and a DOM label of a WMTS layer by inheriting an existing method for obtaining a WMTS layer, switching into a WMTS layer rendering pipeline, and a rendering conversion step is added between the layer configuration and the DOM label of the WMTS layer, and the WMTS layer rendering request is obtained according to the attribute of each tile of a map in a current view and the CQL: Filter attribute. In addition, a fetch-POST request is constructed, and tile data of a target tile is obtained from a geographic server, so that the length of a request parameter is not limited by a GET request mode, and the problems that due to the fact that the URL length of an HTTP GET request is usually limited, when the OGC: CQLFilter condition is too long, the request is possibly cut off, consequently, part of query conditions are lost, and the query efficiency is improved are solved. And the technical problem of abnormal map rendering is solved.

Description

Technical Field

[0001] The present application relates to the field of map technology, and in particular to a WMTS layer rendering request processing. Background Art

[0002] Hawkeye System DRS2.0 is a professional natural disaster risk management platform. The wind module of DRS2.0 is connected to a large amount of meteorological data to provide natural disaster warning, forecast and visualization services. The national waterlogging disaster function requires the construction of complex WMTS requests based on dynamic conditions.

[0003] When dealing with electronic map services, WMTS (Web Map Tile Service) is a widely used protocol that allows clients to obtain map tiles through HTTP requests. It supports multiple map formats, such as JPEG, PNG, etc., and allows clients to specify the required map layer, zoom level, format, etc. through parameters.

[0004] OGC: CQL (Open Geospatial Consortium: Common Query Language) is a standard query language for querying geospatial data. It allows users to construct query conditions through logical operators (such as AND, OR, NOT) and comparison operators (such as =, <, >).

[0005] Since the URL length of HTTP GET requests is usually limited to about 2000 characters, when the OGC:CQLFilter condition is too long, the request may be truncated, resulting in the loss of some query conditions and abnormal map rendering. Summary of the invention

[0006] The present application provides a WMTS layer rendering request processing method, apparatus, device and storage medium, which solves the technical problem that since the URL length of the HTTP GET request is usually limited, when the OGC:CQLFilter condition is too long, the request may be truncated, resulting in the loss of part of the query condition and abnormal map rendering.

[0007] In view of this, the first aspect of the present application provides a WMTS layer rendering request processing method, the method comprising:

[0008] Step S1, parsing WMTS layer configuration information;

[0009] Step S2: Determine the coordinates and range of the target tile according to the current map view state;

[0010] Step S3: construct a fetch-POST request based on the coordinates, range and CQL:Filter attribute of the target tile;

[0011] Step S4: Request the geographic server to obtain tile data of the target tile through the fetch-POST request.

[0012] Optionally, after step S4, the following steps are further included:

[0013] Step S5: Convert the tile data of the target tile into DataURL format.

[0014] Optionally, after step S5, the following steps are further included:

[0015] Step S6: Bind the tile data of the target tile in DataURL format to the img tag of the browser DOM to achieve rendering and display of the target tile.

[0016] Optionally, the step S1 specifically includes:

[0017] Parse the WMTS layer configuration information and obtain the layer information including the service URL, layer name, and layer style.

[0018] Optionally, the step S2 specifically includes:

[0019] Listen to the view change event of the current map and determine the view state of the current map, wherein the view state includes the zoom level and the center point coordinates;

[0020] The coordinates and range of the target tile are determined according to the view state.

[0021] Optionally, the step S3 specifically includes:

[0022] Construct CQL:Filter conditions and determine CQL:Filter attributes;

[0023] A POST request is constructed using the fetchAPI, wherein the request body of the POST request includes the coordinates and range of the target tile and the CQL:Filter attribute.

[0024] Optionally, after step S4, the following steps are further included:

[0025] The fetch-POST request is processed based on throttling or anti-shake technology.

[0026] A second aspect of the present application provides a WMTS layer rendering request processing device, the device comprising:

[0027] Parsing unit, used to parse WMTS layer configuration information;

[0028] The positioning unit is used to determine the coordinates and range of the target tile according to the current map view state;

[0029] A request building unit, used to build a fetch-POST request based on the coordinates, range and CQL:Filter attribute of the target tile;

[0030] The request unit is used to request the geographic server to obtain the tile data of the target tile through the fetch-POST request.

[0031] Optionally, it also includes:

[0032] The format conversion unit is used to convert the tile data of the target tile into a DataURL format.

[0033] Optionally, it also includes:

[0034] The display unit is used to bind the tile data of the target tile in DataURL format to the img tag of the browser DOM to achieve rendering and display of the target tile.

[0035] Optionally, the parsing unit is specifically used for:

[0036] Parse the WMTS layer configuration information and obtain the layer information including the service URL, layer name, and layer style.

[0037] Optionally, the positioning unit is specifically used for:

[0038] Listen to the view change event of the current map and determine the view state of the current map, wherein the view state includes the zoom level and the center point coordinates;

[0039] The coordinates and range of the target tile are determined according to the view state.

[0040] Optionally, the request construction unit is specifically used to:

[0041] Construct CQL:Filter conditions and determine CQL:Filter attributes;

[0042] A POST request is constructed using the fetchAPI, wherein the request body of the POST request includes the coordinates and range of the target tile and the CQL:Filter attribute.

[0043] Optionally, it also includes:

[0044] The optimization unit is used to process the fetch-POST request based on throttling or anti-shake technology.

[0045] A third aspect of the present application provides a WMTS layer rendering request processing device, the device comprising a processor and a memory:

[0046] The memory is used to store program code and transmit the program code to the processor;

[0047] The processor is used to execute the steps of the method for processing WMTS layer rendering requests as described in the first aspect according to the instructions in the program code.

[0048] A fourth aspect of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium is used to store program code, and the program code is used to execute the method described in the first aspect above.

[0049] It can be seen from the above technical solutions that the embodiments of the present application have the following advantages:

[0050] In the present application, a WMTS layer rendering request processing method, device, equipment and storage medium are provided. By inheriting the existing WMTS layer, the WMTS layer rendering pipeline is cut into, and a request construction and rendering conversion step is added between the layer configuration and the DOM tag of the WMTS layer. According to the properties of each tile of the map in the current view and the CQL:Filter property, a fetch-POST request is constructed to obtain the tile data of the target tile from the geographic server, so that the length of the request parameter is not limited by the GET request method, and the technical problem that the request may be truncated when the OGC:CQLFilter condition is too long, which causes the loss of part of the query condition and makes the map rendering abnormal, is solved. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 A method flow chart of a WMTS layer rendering request processing method in an embodiment of the present application;

[0052] Figure 2 This is a structural diagram of a WMTS layer rendering request processing device in an embodiment of the present application;

[0053] Figure 3 It is a schematic diagram of the structure of the WMTS layer rendering request processing device in the embodiment of the present application. DETAILED DESCRIPTION

[0054] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0055] The present application designs a WMTS layer rendering request processing method, apparatus, device and storage medium, which solves the technical problem that since the URL length of the HTTP GET request is usually limited, when the OGC:CQLFilter condition is too long, the request may be truncated, resulting in the loss of part of the query condition and abnormal map rendering.

[0056] For easier understanding, see Figure 1 , Figure 1 Flowchart of the method for processing a WMTS layer rendering request in an embodiment of the present application. Figure 1 As shown, specifically:

[0057] Step S1, parsing WMTS layer configuration information;

[0058] It should be noted that the configuration information of the WMTS layer, such as the service URL, layer name, style, etc., is obtained by reading the layer configuration file or API response.

[0059] First, you need to get the configuration information from the WMTS service. This is usually done by sending an HTTP GET request to the GetCapabilities endpoint of the service.

[0060] Choose an XML parsing library suitable for your programming language, such as xml.etree.ElementTree for Python, javax.xml.parsers for Java, or use specialized GIS software and libraries such as GDAL or QGIS.

[0061] Read the response content of the GetCapabilities request, which is usually an XML document.

[0062] Load the XML document using your chosen XML parsing library and start parsing the required information. For example, you can search for <layer>element to get the layer information, <service>element to obtain the service URL, etc.

[0063] Extract the name, style, tile matrix set, etc. of each layer. This information is usually contained in the corresponding elements and attributes of XML.

[0064] Construct the parsed configuration information into an object or data structure for subsequent use.

[0065] You can also verify that the extracted configuration information is complete and correct, ensuring that all necessary information has been obtained.

[0066] Store the parsed configuration information in an appropriate format, such as JSON, a database, or a configuration file, or output it directly to the console for inspection.

[0067] Step S2: Determine the coordinates and range of the target tile according to the current map view state;

[0068] It should be noted that the parameters of the current map view are determined, such as the zoom level, center point coordinates, etc. Specifically:

[0069] Get the map's current zoom level (Zoom Level), center point coordinates (Latitude and Longitude), and other information.

[0070] Calculate the tile matrix corresponding to the current view according to the zoom level and the metadata of the tile matrix set.

[0071] Convert the center point coordinates to tile coordinates. This usually involves converting the longitude and latitude coordinates to a tile coordinate system (such as Web Mercator).

[0072] Determine the tile range required for the current view, including the coordinates of the start and end tiles. This usually involves calculating the tile coordinates of the edge of the view.

[0073] Update the map's view state based on the user's actions (such as zooming, panning), and repeat the above steps to request new tiles.

[0074] Step S3: construct a fetch-POST request based on the coordinates, range and CQL:Filter attribute of the target tile;

[0075] It should be noted that the query conditions are constructed according to user needs and map views, specifically:

[0076] Generates a CQL:Filter string based on business logic and user input.

[0077] Construct request parameters using tile coordinates and CQL:Filter conditions.

[0078] Use fetchAPI to construct a POST request and send the request parameters through the request body.

[0079] Step S4: Request the geographic server to obtain tile data of the target tile through a fetch-POST request.

[0080] To be clear, a POST request is sent to the geoserver.

[0081] Receive tile data from the server response.

[0082] Furthermore, after step S4, the following steps are further included:

[0083] Step S5: Convert the tile data of the target tile into DataURL format.

[0084] It should be noted that the tile data responded by the server is converted into a format that can be recognized by the browser, specifically:

[0085] Convert binary tile data to DataURL format.

[0086] Furthermore, it is also necessary to ensure data integrity and correctness during the conversion process.

[0087] Furthermore, after step S5, the following steps are further included:

[0088] Step S6: Bind the tile data of the target tile in the DataURL format to the img tag of the browser DOM to achieve rendering and display of the target tile.

[0089] It should be noted that the converted tile data is bound to the browser DOM On the label, realize the display of tiles, specifically:

[0090] Create a new one for each tile Label.

[0091] Set DataURL to The src attribute of the tag.

[0092] Furthermore, step S1 specifically includes:

[0093] Parse the WMTS layer configuration information and obtain the layer information including the service URL, layer name, and layer style.

[0094] It should be noted that the configuration information of the WMTS layer, such as the service URL, layer name, style, etc., is obtained by reading the layer configuration file or API response.

[0095] First, you need to get the configuration information from the WMTS service. This is usually done by sending an HTTP GET request to the GetCapabilities endpoint of the service.

[0096] Choose an XML parsing library suitable for your programming language, such as xml.etree.ElementTree for Python, javax.xml.parsers for Java, or use specialized GIS software and libraries such as GDAL or QGIS.

[0097] Read the response content of the GetCapabilities request, which is usually an XML document.

[0098] Load the XML document using your chosen XML parsing library and start parsing the required information. For example, you can search for <layer>element to get the layer information, <service>element to obtain the service URL, etc.

[0099] Extract the name, style, tile matrix set, etc. of each layer. This information is usually contained in the corresponding elements and attributes of XML.

[0100] Construct the parsed configuration information into an object or data structure for subsequent use.

[0101] You can also verify that the extracted configuration information is complete and correct, ensuring that all necessary information has been obtained.

[0102] Store the parsed configuration information in an appropriate format, such as JSON, a database, or a configuration file, or output it directly to the console for inspection.

[0103] Furthermore, step S2 specifically includes:

[0104] Listen to the view change event of the current map and determine the view state of the current map, which includes the zoom level and center point coordinates;

[0105] Determine the coordinates and range of the target tile based on the view state.

[0106] It should be noted that the parameters of the current map view are determined, such as the zoom level, center point coordinates, etc. Specifically:

[0107] Get the map's current zoom level (Zoom Level), center point coordinates (Latitude and Longitude), and other information.

[0108] Calculate the tile matrix corresponding to the current view according to the zoom level and the metadata of the tile matrix set.

[0109] Convert the center point coordinates to tile coordinates. This usually involves converting the longitude and latitude coordinates to a tile coordinate system (such as Web Mercator).

[0110] Determine the tile range required for the current view, including the coordinates of the start and end tiles. This usually involves calculating the tile coordinates of the edge of the view.

[0111] Update the map's view state based on the user's actions (such as zooming, panning), and repeat the above steps to request new tiles.

[0112] Furthermore, step S3 specifically includes:

[0113] Construct CQL:Filter conditions and determine CQL:Filter attributes;

[0114] Use fetchAPI to construct a POST request. The request body of the POST request contains the coordinates, range, and CQL:Filter attributes of the target tile.

[0115] It should be noted that the query conditions are constructed according to user needs and map views, specifically:

[0116] Generates a CQL:Filter string based on business logic and user input.

[0117] Construct request parameters using tile coordinates and CQL:Filter conditions.

[0118] Use fetchAPI to construct a POST request and send the request parameters through the request body.

[0119] Furthermore, after step S4, the following steps are further included:

[0120] Process the fetch-POST request based on throttling or anti-shake technology.

[0121] It should be noted that throttling or anti-shake technology can be used to reduce repeated requests caused by frequent map view changes.

[0122] Throttling and debouncing are two techniques commonly used to optimize event processing and API requests, especially when user input or high-frequency events are triggered. For POST requests initiated by fetch, these techniques can reduce the frequency of requests, thereby reducing server pressure and optimizing performance.

[0123] Specifically:

[0124] Create a throttling function that receives a base time (usually the minimum interval between requests) as a parameter.

[0125] Inside the throttling function, wrap the fetch request. If the time between two calls is less than the benchmark time, the request will not be executed.

[0126] Use a closure to save the timestamp of the previous request so that you can check the time interval on the next call.

[0127] Bind the throttle function to the event that triggers the POST request, such as a button click or a typing event in an input box.

[0128] When the event is triggered, the throttling function is called, and if the time interval condition is met, the fetch request is executed.

[0129] or

[0130] Create a debounce function that receives a delay time (the time to wait after the event is triggered) as a parameter.

[0131] A timer is set inside the anti-shake function to delay the execution of the fetch request.

[0132] If the event is triggered again before the timer is triggered, the previous timer is cleared and a new timer is set again.

[0133] When the timer reaches the set time, the fetch request is executed.

[0134] Bind the anti-shake function to the event that triggers the POST request.

[0135] Furthermore, in order to ensure the robustness of the request and the user experience, you can also implement error handling logic, such as request failure, data parsing error, etc.; set up a retry mechanism to automatically retry when the request fails.

[0136] Furthermore, in order to improve the efficiency and effect speed of map rendering, a tile cache strategy can also be implemented to avoid repeated requests for data that has already been obtained.

[0137] Furthermore, in order to ensure the security and compliance of data requests, the HTTPS protocol can also be used to ensure the security of data transmission.

[0138] Verify user permissions to ensure only authorized users can access data.

[0139] Furthermore, in order to provide a good user experience and interactive feedback, a loading status prompt, such as a loading animation or a progress bar, may also be provided.

[0140] When a request fails, give the user appropriate feedback, such as an error message or a retry button.

[0141] See also Figure 2 , Figure 2 FIG. 1 is a schematic diagram of the structure of a WMTS layer rendering request processing device in an embodiment of the present application. Figure 2 As shown, specifically:

[0142] Parsing unit 201, used for parsing WMTS layer configuration information;

[0143] It should be noted that the configuration information of the WMTS layer, such as the service URL, layer name, style, etc., is obtained by reading the layer configuration file or API response.

[0144] First, you need to get the configuration information from the WMTS service. This is usually done by sending an HTTP GET request to the GetCapabilities endpoint of the service.

[0145] Choose an XML parsing library suitable for your programming language, such as xml.etree.ElementTree for Python, javax.xml.parsers for Java, or use specialized GIS software and libraries such as GDAL or QGIS.

[0146] Read the response content of the GetCapabilities request, which is usually an XML document.

[0147] Load the XML document using your chosen XML parsing library and start parsing the required information. For example, you can search for <layer>element to get the layer information, <service>element to obtain the service URL, etc.

[0148] Extract the name, style, tile matrix set, etc. of each layer. This information is usually contained in the corresponding elements and attributes of XML.

[0149] Construct the parsed configuration information into an object or data structure for subsequent use.

[0150] You can also verify that the extracted configuration information is complete and correct, ensuring that all necessary information has been obtained.

[0151] Store the parsed configuration information in an appropriate format, such as JSON, a database, or a configuration file, or output it directly to the console for inspection.

[0152] A positioning unit 202, used to determine the coordinates and range of the target tile according to the current map view state;

[0153] It should be noted that the parameters of the current map view are determined, such as the zoom level, center point coordinates, etc. Specifically:

[0154] Get the map's current zoom level (Zoom Level), center point coordinates (Latitude and Longitude), and other information.

[0155] Calculate the tile matrix corresponding to the current view according to the zoom level and the metadata of the tile matrix set.

[0156] Convert the center point coordinates to tile coordinates. This usually involves converting the longitude and latitude coordinates to a tile coordinate system (such as Web Mercator).

[0157] Determine the tile range required for the current view, including the coordinates of the start and end tiles. This usually involves calculating the tile coordinates of the edge of the view.

[0158] Update the map's view state based on the user's actions (such as zooming, panning), and repeat the above steps to request new tiles.

[0159] The request construction unit 203 is used to construct a fetch-POST request based on the coordinates, range and CQL:Filter attribute of the target tile;

[0160] It should be noted that the query conditions are constructed according to user needs and map views, specifically:

[0161] Generates a CQL:Filter string based on business logic and user input.

[0162] Construct request parameters using tile coordinates and CQL:Filter conditions.

[0163] Use fetchAPI to construct a POST request and send the request parameters through the request body.

[0164] The request unit 204 is used to request the geographic server to obtain tile data of the target tile through a fetch-POST request.

[0165] To be clear, a POST request is sent to the geoserver.

[0166] Receive tile data from the server response.

[0167] Furthermore, it also includes:

[0168] The format conversion unit is used to convert the tile data of the target tile into the DataURL format.

[0169] It should be noted that the tile data responded by the server is converted into a format that can be recognized by the browser, specifically:

[0170] Convert binary tile data to DataURL format.

[0171] Furthermore, it also includes:

[0172] The display unit is used to bind the tile data of the target tile in DataURL format to the img tag of the browser DOM to realize the rendering and display of the target tile.

[0173] It should be noted that the converted tile data is bound to the browser DOM On the label, realize the display of tiles, specifically:

[0174] Create a new one for each tile Label.

[0175] Set DataURL to The src attribute of the tag.

[0176] Furthermore, the parsing unit 201 is specifically used for:

[0177] Parse the WMTS layer configuration information and obtain the layer information including the service URL, layer name, and layer style.

[0178] It should be noted that the configuration information of the WMTS layer, such as the service URL, layer name, style, etc., is obtained by reading the layer configuration file or API response.

[0179] First, you need to get the configuration information from the WMTS service. This is usually done by sending an HTTP GET request to the GetCapabilities endpoint of the service.

[0180] Choose an XML parsing library suitable for your programming language, such as xml.etree.ElementTree for Python, javax.xml.parsers for Java, or use specialized GIS software and libraries such as GDAL or QGIS.

[0181] Read the response content of the GetCapabilities request, which is usually an XML document.

[0182] Load the XML document using your chosen XML parsing library and start parsing the required information. For example, you can search for <layer>element to get the layer information, <service>element to obtain the service URL, etc.

[0183] Extract the name, style, tile matrix set, etc. of each layer. This information is usually contained in the corresponding elements and attributes of XML.

[0184] Construct the parsed configuration information into an object or data structure for subsequent use.

[0185] You can also verify that the extracted configuration information is complete and correct, ensuring that all necessary information has been obtained.

[0186] Store the parsed configuration information in an appropriate format, such as JSON, a database, or a configuration file, or output it directly to the console for inspection.

[0187] Furthermore, the positioning unit 202 is specifically used for:

[0188] Listen to the view change event of the current map and determine the view state of the current map, which includes the zoom level and center point coordinates;

[0189] Determine the coordinates and range of the target tile based on the view state.

[0190] It should be noted that the parameters of the current map view are determined, such as the zoom level, center point coordinates, etc. Specifically:

[0191] Get the map's current zoom level (Zoom Level), center point coordinates (Latitude and Longitude), and other information.

[0192] Calculate the tile matrix corresponding to the current view according to the zoom level and the metadata of the tile matrix set.

[0193] Convert the center point coordinates to tile coordinates. This usually involves converting the longitude and latitude coordinates to a tile coordinate system (such as Web Mercator).

[0194] Determine the tile range required for the current view, including the coordinates of the start and end tiles. This usually involves calculating the tile coordinates of the edge of the view.

[0195] Update the map's view state based on the user's actions (such as zooming, panning), and repeat the above steps to request new tiles.

[0196] Furthermore, the request construction unit 203 is specifically used for:

[0197] Construct CQL:Filter conditions and determine CQL:Filter attributes;

[0198] Use fetchAPI to construct a POST request. The request body of the POST request contains the coordinates, range, and CQL:Filter attributes of the target tile.

[0199] It should be noted that the query conditions are constructed according to user needs and map views, specifically:

[0200] Generates a CQL:Filter string based on business logic and user input.

[0201] Construct request parameters using tile coordinates and CQL:Filter conditions.

[0202] Use fetchAPI to construct a POST request and send the request parameters through the request body.

[0203] Furthermore, it also includes:

[0204] The optimization unit is used to process fetch-POST requests based on throttling or anti-shake technology.

[0205] It should be noted that throttling or anti-shake technology can be used to reduce repeated requests caused by frequent map view changes.

[0206] Throttling and debouncing are two techniques commonly used to optimize event processing and API requests, especially when user input or high-frequency events are triggered. For POST requests initiated by fetch, these techniques can reduce the frequency of requests, thereby reducing server pressure and optimizing performance.

[0207] Specifically:

[0208] Create a throttling function that receives a base time (usually the minimum interval between requests) as a parameter.

[0209] Inside the throttling function, wrap the fetch request. If the time between two calls is less than the benchmark time, the request will not be executed.

[0210] Use a closure to save the timestamp of the previous request so that you can check the time interval on the next call.

[0211] Bind the throttle function to the event that triggers the POST request, such as a button click or a typing event in an input box.

[0212] When the event is triggered, the throttling function is called, and if the time interval condition is met, the fetch request is executed.

[0213] or

[0214] Create a debounce function that receives a delay time (the time to wait after the event is triggered) as a parameter.

[0215] A timer is set inside the anti-shake function to delay the execution of the fetch request.

[0216] If the event is triggered again before the timer is triggered, the previous timer is cleared and a new timer is set again.

[0217] When the timer reaches the set time, the fetch request is executed.

[0218] Bind the anti-shake function to the event that triggers the POST request.

[0219] Furthermore, in order to ensure the robustness of the request and the user experience, the optimization unit can also implement error handling logic, such as request failure, data parsing error, etc.; set up a retry mechanism to automatically retry when the request fails.

[0220] Furthermore, in order to improve the efficiency and effect speed of map rendering, the optimization unit can also implement a tile cache strategy to avoid repeated requests for data that has already been obtained.

[0221] Furthermore, in order to ensure the security and compliance of data requests, the optimization unit can also use the HTTPS protocol to ensure the security of data transmission.

[0222] Verify user permissions to ensure only authorized users can access data.

[0223] Furthermore, in order to provide a good user experience and interactive feedback, the display unit may also provide a loading status prompt, such as a loading animation or a progress bar.

[0224] When a request fails, give the user appropriate feedback, such as an error message or a retry button.

[0225] The present application embodiment also provides another WMTS layer rendering request processing device, such as Figure 3 For the sake of convenience, only the parts related to the embodiments of the present application are shown. For specific technical details not disclosed, please refer to the method part of the embodiments of the present application. The terminal can be any terminal device including a mobile phone, a tablet computer, a personal digital assistant (English full name: Personal Digital Assistant, English abbreviation: PDA), a sales terminal (English full name: Point of Sales, English abbreviation: POS), a car computer, etc., taking the terminal as a mobile phone as an example:

[0226] Figure 3 FIG. 1 is a block diagram showing a partial structure of a mobile phone related to a terminal provided in an embodiment of the present application. Figure 3 The mobile phone includes: a radio frequency (RF) circuit 1010, a memory 1020, an input unit 1030, a display unit 1040, a sensor 1050, an audio circuit 1060, a wireless fidelity (WiFi) module 1070, a processor 1080, and a power supply 1090. Those skilled in the art can understand that Figure 3 The mobile phone structure shown in the figure does not constitute a limitation on the mobile phone, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0227] Combine the following Figure 3 A detailed introduction to the various components of the mobile phone:

[0228] The RF circuit 1010 can be used for receiving and sending signals during information transmission or calls. In particular, after receiving the downlink information of the base station, it is sent to the processor 1080 for processing; in addition, the designed uplink data is sent to the base station. Generally, the RF circuit 1010 includes but is not limited to an antenna, at least one amplifier, a transceiver, a coupler, a low noise amplifier (full name: Low Noise Amplifier, English abbreviation: LNA), a duplexer, etc. In addition, the RF circuit 1010 can also communicate with the network and other devices through wireless communication. The above-mentioned wireless communications can use any communication standard or protocol, including but not limited to Global System of Mobile communications (Global System of Mobile communication, English abbreviation: GSM), General Packet Radio Service (General Packet Radio Service, GPRS), Code Division Multiple Access (Code Division Multiple Access, English abbreviation: CDMA), Wideband Code Division Multiple Access (WCDMA), Long Term Evolution (Long Term Evolution, English abbreviation: LTE), e-mail, Short Messaging Service (SMS), etc.

[0229] The memory 1020 can be used to store software programs and modules. The processor 1080 executes various functional applications and data processing of the mobile phone by running the software programs and modules stored in the memory 1020. The memory 1020 can mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, an application required for at least one function (such as a sound playback function, an image playback function, etc.), etc.; the data storage area can store data created according to the use of the mobile phone (such as audio data, a phone book, etc.), etc. In addition, the memory 1020 can include a high-speed random access memory, and can also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage devices.

[0230] The input unit 1030 can be used to receive input digital or character information, and to generate key signal input related to the user settings and function control of the mobile phone. Specifically, the input unit 1030 may include a touch panel 1031 and other input devices 1032. The touch panel 1031, also known as a touch screen, can collect the user's touch operation on or near it (such as the user's operation on the touch panel 1031 or near the touch panel 1031 using any suitable object or accessory such as a finger, stylus, etc.), and drive the corresponding connection device according to a pre-set program. Optionally, the touch panel 1031 may include two parts: a touch detection device and a touch controller. Among them, the touch detection device detects the user's touch orientation, detects the signal brought by the touch operation, and transmits the signal to the touch controller; the touch controller receives the touch information from the touch detection device, converts it into the touch point coordinates, and then sends it to the processor 1080, and can receive and execute the command sent by the processor 1080. In addition, the touch panel 1031 can be implemented in various types such as resistive, capacitive, infrared, and surface acoustic waves. In addition to the touch panel 1031, the input unit 1030 may further include other input devices 1032. Specifically, the other input devices 1032 may include but are not limited to one or more of a physical keyboard, function keys (such as volume control keys, switch keys, etc.), a trackball, a mouse, a joystick, and the like.

[0231] The display unit 1040 can be used to display information input by the user or information provided to the user and various menus of the mobile phone. The display unit 1040 may include a display panel 1041. Optionally, the display panel 1041 may be configured in the form of a liquid crystal display (full name in English: Liquid Crystal Display, English abbreviation: LCD), an organic light-emitting diode (full name in English: Organic Light-Emitting Diode, English abbreviation: OLED), etc. Further, the touch panel 1031 may cover the display panel 1041. When the touch panel 1031 detects a touch operation on or near it, it is transmitted to the processor 1080 to determine the type of touch event. Subsequently, the processor 1080 provides a corresponding visual output on the display panel 1041 according to the type of touch event. Although in Figure 3 In the embodiment, the touch panel 1031 and the display panel 1041 are used as two independent components to realize the input and output functions of the mobile phone, but in some embodiments, the touch panel 1031 and the display panel 1041 can be integrated to realize the input and output functions of the mobile phone.

[0232] The mobile phone may also include at least one sensor 1050, such as a light sensor, a motion sensor, and other sensors. Specifically, the light sensor may include an ambient light sensor and a proximity sensor, wherein the ambient light sensor may adjust the brightness of the display panel 1041 according to the brightness of the ambient light, and the proximity sensor may turn off the display panel 1041 and / or the backlight when the mobile phone is moved to the ear. As a type of motion sensor, the accelerometer sensor can detect the magnitude of acceleration in all directions (generally three axes), and can detect the magnitude and direction of gravity when stationary. It can be used for applications that identify the posture of the mobile phone (such as horizontal and vertical screen switching, related games, magnetometer posture calibration), vibration recognition related functions (such as pedometer, tapping), etc.; as for other sensors that can be configured in the mobile phone, such as gyroscopes, barometers, hygrometers, thermometers, infrared sensors, etc., they will not be repeated here.

[0233] The audio circuit 1060, the speaker 1061, and the microphone 1062 can provide an audio interface between the user and the mobile phone. The audio circuit 1060 can transmit the received audio data to the speaker 1061 after converting the received audio data into an electrical signal, which is converted into a sound signal for output; on the other hand, the microphone 1062 converts the collected sound signal into an electrical signal, which is received by the audio circuit 1060 and converted into audio data, and then the audio data is output to the processor 1080 for processing, and then sent to another mobile phone through the RF circuit 1010, or the audio data is output to the memory 1020 for further processing.

[0234] WiFi is a short-range wireless transmission technology. The mobile phone can help users send and receive emails, browse web pages and access streaming media through the WiFi module 1070. It provides users with wireless broadband Internet access. Figure 3 A WiFi module 1070 is shown, but it is understandable that it is not an essential component of the mobile phone and can be omitted as needed without changing the essence of the invention.

[0235] The processor 1080 is the control center of the mobile phone. It uses various interfaces and lines to connect various parts of the entire mobile phone. By running or executing software programs and / or modules stored in the memory 1020 and calling data stored in the memory 1020, it executes various functions of the mobile phone and processes data, thereby monitoring the mobile phone as a whole. Optionally, the processor 1080 may include one or more processing units; preferably, the processor 1080 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface and application programs, etc., and the modem processor mainly processes wireless communications. It is understandable that the above-mentioned modem processor may not be integrated into the processor 1080.

[0236] The mobile phone also includes a power supply 1090 (such as a battery) for supplying power to various components. Preferably, the power supply can be logically connected to the processor 1080 through a power management system, so that the power management system can manage functions such as charging, discharging, and power consumption.

[0237] Although not shown, the mobile phone may also include a camera, a Bluetooth module, etc., which will not be described in detail here.

[0238] In the embodiment of the present application, the processor 1080 included in the terminal also has the following functions:

[0239] Step S1, parsing WMTS layer configuration information;

[0240] It should be noted that the configuration information of the WMTS layer, such as the service URL, layer name, style, etc., is obtained by reading the layer configuration file or API response.

[0241] First, you need to get the configuration information from the WMTS service. This is usually done by sending an HTTP GET request to the GetCapabilities endpoint of the service.

[0242] Choose an XML parsing library suitable for your programming language, such as xml.etree.ElementTree for Python, javax.xml.parsers for Java, or use specialized GIS software and libraries such as GDAL or QGIS.

[0243] Read the response content of the GetCapabilities request, which is usually an XML document.

[0244] Load the XML document using your chosen XML parsing library and start parsing the required information. For example, you can search for <layer>element to get the layer information, <service>element to obtain the service URL, etc.

[0245] Extract the name, style, tile matrix set, etc. of each layer. This information is usually contained in the corresponding elements and attributes of XML.

[0246] Construct the parsed configuration information into an object or data structure for subsequent use.

[0247] You can also verify that the extracted configuration information is complete and correct, ensuring that all necessary information has been obtained.

[0248] Store the parsed configuration information in an appropriate format, such as JSON, a database, or a configuration file, or output it directly to the console for inspection.

[0249] Step S2: Determine the coordinates and range of the target tile according to the current map view state;

[0250] It should be noted that the parameters of the current map view are determined, such as the zoom level, center point coordinates, etc. Specifically:

[0251] Get the map's current zoom level (Zoom Level), center point coordinates (Latitude and Longitude), and other information.

[0252] Calculate the tile matrix corresponding to the current view according to the zoom level and the metadata of the tile matrix set.

[0253] Convert the center point coordinates to tile coordinates. This usually involves converting the longitude and latitude coordinates to a tile coordinate system (such as Web Mercator).

[0254] Determine the tile range required for the current view, including the coordinates of the start and end tiles. This usually involves calculating the tile coordinates of the edge of the view.

[0255] Update the map's view state based on the user's actions (such as zooming, panning), and repeat the above steps to request new tiles.

[0256] Step S3: construct a fetch-POST request based on the coordinates, range and CQL:Filter attribute of the target tile;

[0257] It should be noted that the query conditions are constructed according to user needs and map views, specifically:

[0258] Generates a CQL:Filter string based on business logic and user input.

[0259] Construct request parameters using tile coordinates and CQL:Filter conditions.

[0260] Use fetchAPI to construct a POST request and send the request parameters through the request body.

[0261] Step S4: Request the geographic server to obtain tile data of the target tile through a fetch-POST request.

[0262] To be clear, a POST request is sent to the geoserver.

[0263] Receive tile data from the server response.

[0264] Furthermore, after step S4, the following steps are further included:

[0265] Step S5: Convert the tile data of the target tile into DataURL format.

[0266] It should be noted that the tile data responded by the server is converted into a format that can be recognized by the browser, specifically:

[0267] Convert binary tile data to DataURL format.

[0268] Furthermore, it is also necessary to ensure data integrity and correctness during the conversion process.

[0269] Furthermore, after step S5, the following steps are further included:

[0270] Step S6: Bind the tile data of the target tile in the DataURL format to the img tag of the browser DOM to achieve rendering and display of the target tile.

[0271] It should be noted that the converted tile data is bound to the browser DOM On the label, realize the display of tiles, specifically:

[0272] Create a new one for each tile Label.

[0273] Set DataURL to The src attribute of the tag.

[0274] Furthermore, step S1 specifically includes:

[0275] Parse the WMTS layer configuration information and obtain the layer information including the service URL, layer name, and layer style.

[0276] It should be noted that the configuration information of the WMTS layer, such as the service URL, layer name, style, etc., is obtained by reading the layer configuration file or API response.

[0277] First, you need to get the configuration information from the WMTS service. This is usually done by sending an HTTP GET request to the GetCapabilities endpoint of the service.

[0278] Choose an XML parsing library suitable for your programming language, such as xml.etree.ElementTree for Python, javax.xml.parsers for Java, or use specialized GIS software and libraries such as GDAL or QGIS.

[0279] Read the response content of the GetCapabilities request, which is usually an XML document.

[0280] Load the XML document using your chosen XML parsing library and start parsing the required information. For example, you can search for <layer>element to get the layer information, <service>element to obtain the service URL, etc.

[0281] Extract the name, style, tile matrix set, etc. of each layer. This information is usually contained in the corresponding elements and attributes of XML.

[0282] Construct the parsed configuration information into an object or data structure for subsequent use.

[0283] You can also verify that the extracted configuration information is complete and correct, ensuring that all necessary information has been obtained.

[0284] Store the parsed configuration information in an appropriate format, such as JSON, a database, or a configuration file, or output it directly to the console for inspection.

[0285] Furthermore, step S2 specifically includes:

[0286] Listen to the view change event of the current map and determine the view state of the current map, which includes the zoom level and center point coordinates;

[0287] Determine the coordinates and range of the target tile based on the view state.

[0288] It should be noted that the parameters of the current map view are determined, such as the zoom level, center point coordinates, etc. Specifically:

[0289] Get the map's current zoom level (Zoom Level), center point coordinates (Latitude and Longitude), and other information.

[0290] Calculate the tile matrix corresponding to the current view according to the zoom level and the metadata of the tile matrix set.

[0291] Convert the center point coordinates to tile coordinates. This usually involves converting the longitude and latitude coordinates to a tile coordinate system (such as Web Mercator).

[0292] Determine the tile range required for the current view, including the coordinates of the start and end tiles. This usually involves calculating the tile coordinates of the edge of the view.

[0293] Update the map's view state based on the user's actions (such as zooming, panning), and repeat the above steps to request new tiles.

[0294] Furthermore, step S3 specifically includes:

[0295] Construct CQL:Filter conditions and determine CQL:Filter attributes;

[0296] Use fetchAPI to construct a POST request. The request body of the POST request contains the coordinates, range, and CQL:Filter attributes of the target tile.

[0297] It should be noted that the query conditions are constructed according to user needs and map views, specifically:

[0298] Generates a CQL:Filter string based on business logic and user input.

[0299] Construct request parameters using tile coordinates and CQL:Filter conditions.

[0300] Use fetchAPI to construct a POST request and send the request parameters through the request body.

[0301] Furthermore, after step S4, the following steps are further included:

[0302] Process the fetch-POST request based on throttling or anti-shake technology.

[0303] It should be noted that throttling or anti-shake technology can be used to reduce repeated requests caused by frequent map view changes.

[0304] Throttling and debouncing are two techniques commonly used to optimize event processing and API requests, especially when user input or high-frequency events are triggered. For POST requests initiated by fetch, these techniques can reduce the frequency of requests, thereby reducing server pressure and optimizing performance.

[0305] Specifically:

[0306] Create a throttling function that receives a base time (usually the minimum interval between requests) as a parameter.

[0307] Inside the throttling function, wrap the fetch request. If the time between two calls is less than the benchmark time, the request will not be executed.

[0308] Use a closure to save the timestamp of the previous request so that you can check the time interval on the next call.

[0309] Bind the throttle function to the event that triggers the POST request, such as a button click or a typing event in an input box.

[0310] When the event is triggered, the throttling function is called, and if the time interval condition is met, the fetch request is executed.

[0311] or

[0312] Create a debounce function that receives a delay time (the time to wait after the event is triggered) as a parameter.

[0313] A timer is set inside the anti-shake function to delay the execution of the fetch request.

[0314] If the event is triggered again before the timer is triggered, the previous timer is cleared and a new timer is set again.

[0315] When the timer reaches the set time, the fetch request is executed.

[0316] Bind the anti-shake function to the event that triggers the POST request.

[0317] Furthermore, in order to ensure the robustness of the request and the user experience, you can also implement error handling logic, such as request failure, data parsing error, etc.; set up a retry mechanism to automatically retry when the request fails.

[0318] Furthermore, in order to improve the efficiency and effect speed of map rendering, a tile cache strategy can also be implemented to avoid repeated requests for data that has already been obtained.

[0319] Furthermore, in order to ensure the security and compliance of data requests, the HTTPS protocol can also be used to ensure the security of data transmission.

[0320] Verify user permissions to ensure only authorized users can access data.

[0321] Furthermore, in order to provide a good user experience and interactive feedback, a loading status prompt, such as a loading animation or a progress bar, may also be provided.

[0322] When a request fails, give the user appropriate feedback, such as an error message or a retry button.

[0323] An embodiment of the present application also provides a computer-readable storage medium for storing program code, wherein the program code is used to execute any one of the implementation methods of a WMTS layer rendering request processing method described in the aforementioned embodiments.

[0324] In the embodiment of the present application, a WMTS layer rendering request processing method, apparatus, device and storage medium are provided. The WMTS layer is obtained by inheriting the existing one, and the WMTS layer rendering pipeline is cut into. A request construction and rendering conversion step is added between the layer configuration and the DOM tag of the WMTS layer. According to the properties of each tile of the map in the current view and the CQL:Filter property, a fetch-POST request is constructed to obtain tile data of the target tile from the geographic server, so that the length of the request parameter is not limited by the GET request method. This solves the technical problem that the request may be truncated when the OGC:CQL Filter condition is too long, which may cause the loss of part of the query condition and abnormal map rendering.

[0325] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0326] The terms "first", "second", "third", "fourth", etc. (if any) in the specification of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein, for example. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0327] It should be understood that in the present application, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or plural.

[0328] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

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

[0330] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0331] If the integrated unit is implemented in the form of 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 the present application is essentially 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, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (full name in English: Read-Only Memory, English abbreviation: ROM), random access memory (full name in English: Random Access Memory, English abbreviation: RAM), disk or optical disk and other media that can store program codes.

[0332] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.< / service> < / layer> < / service> < / layer> < / service> < / layer> < / service> < / layer> < / service> < / layer> < / service> < / layer>

Claims

1. A WMTS layer rendering request processing method, characterized in that: include: Step S1, parsing WMTS layer configuration information; Step S2: Determine the coordinates and range of the target tile according to the current map view state; Step S3: construct a fetch-POST request based on the coordinates, range, and CQL:Filter attribute of the target tile; Step S4: Request the geographic server to obtain the tile data of the target tile through the fetch-POST request.

2. The WMTS layer rendering request processing method according to claim 1, wherein: After step S4, the following steps are also included: Step S5: Convert the tile data of the target tile into DataURL format.

3. The WMTS layer rendering request processing method according to claim 2, characterized in that: After step S5, the following steps are also included: Step S6: Bind the tile data of the target tile in the DataURL format to the img tag of the browser DOM to achieve rendering and display of the target tile.

4. The WMTS layer rendering request processing method according to claim 1, characterized in that: The step S1 specifically includes: Parse WMTS layer configuration information and obtain layer information including service URL, layer name, and layer style.

5. The WMTS layer rendering request processing method according to claim 1, characterized in that: The step S2 specifically includes: Listen for view change events of the current map and determine the view state of the current map, including the zoom level and center point coordinates; The coordinates and range of the target tile are determined according to the view state.

6. The WMTS layer rendering request processing method according to claim 1, characterized in that: The step S3 specifically includes: Construct CQL:Filter conditions and determine CQL:Filter attributes; A POST request is constructed using the fetchAPI, wherein the request body of the POST request includes the coordinates and range of the target tile and the CQL:Filter attribute.

7. The WMTS layer rendering request processing method according to claim 1, characterized in that: After step S4, the following steps are also included: The fetch-POST request is processed based on throttling or anti-shake technology.

8. A WMTS layer rendering request processing device, characterized in that: include: Parsing unit, used to parse WMTS layer configuration information; The positioning unit is used to determine the coordinates and range of the target tile according to the current map view state; A request construction unit, configured to construct a fetch-POST request based on the coordinates, range, and CQL:Filter attribute of the target tile; The requesting unit is configured to request the geographic server to obtain the tile data of the target tile through the fetch-POST request.

9. A WMTS layer rendering request processing device, characterized in that: The device includes a processor and a memory: The memory is used to store program code and transmit the program code to the processor; The processor is used to execute the WMTS layer rendering request processing method according to any one of claims 1 to 7 according to the instructions in the program code.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium is used to store program code, and the program code is used to execute the WMTS layer rendering request processing method according to any one of claims 1 to 7.

Images