A new energy site mass geographic vector data backend rendering method and device

Abstract

The present disclosure provides a new energy site mass geographic vector data backend rendering method and device. The backend rendering method comprises: receiving a rendering request sent by the front end, the rendering request containing a style configuration identifier, a tile number sequence and an output format; according to the tile number sequence in the request, locating and reading the corresponding binary vector tile data from the vector tile data package preloaded by the tile service engine; matching the corresponding style attribute data according to the style configuration identifier; completing the graphic drawing based on the binary tile data and the style attribute data in the server memory, and generating the corresponding raster tile according to the requested output format, realizing the backend dynamic rasterization publishing; returning the raster tile to the front end for display, and releasing the server memory after the transmission is completed. Through the above method, efficient backend rendering can be realized, the front end load is reduced, the map response speed is improved, at the same time, rasterization is completed in the memory and resources are released in time, and the server resource utilization efficiency is optimized.

Description

Technical Field

[0001] This disclosure relates to the field of new energy site data visualization technology, specifically to a backend rendering method and device for massive geographic vector data of new energy sites. Background Technology

[0002] In the planning of new energy sites, such as wind power and photovoltaic site selection, it is necessary to load massive amounts of vector data into the three-dimensional geographic information system, such as the three-level adjustment map and the three-zone three-line map.

[0003] Traditional geographic vector data rendering methods mainly employ front-end vector rendering schemes, which have the following shortcomings: On the one hand, the amount of data involved in new energy planning is extremely large, often reaching millions or even tens of millions of map patches. If the front-end directly loads such massive vector data, it will cause the browser's memory usage to spike instantly, easily triggering the OOM (Out Of Memory) mechanism, leading to page freezing or browser crashes. On the other hand, rendering vector data on 3D terrain requires complex "clamp to ground" geometric calculations to prevent map patches from being obscured by the terrain or appearing suspended. However, real-time clamp to ground calculations of massive amounts of data consume a great deal of CPU (Central Processing Unit) and GPU (Graphics Processing Unit) resources, resulting in extremely low browsing frame rate (FPS) and poor smoothness of interactive operations. Summary of the Invention

[0004] This disclosure addresses the problems existing in the prior art by providing a front-end and back-end collaborative rendering method and apparatus for vector data of new energy sites. It can solve the problems of page freezing or browser crashes, low browsing frame rate, and poor interactive smoothness caused by the use of front-end vector rendering in the prior art, thereby meeting the needs of efficient and smooth visualization in the scenario of new energy site planning.

[0005] To achieve the above objectives, the technical solution adopted in this disclosure is as follows: The first aspect of this disclosure provides a backend rendering method for massive geographic vector data of new energy sites, comprising: obtaining a rendering request sent by the frontend, which includes a style configuration identifier, a tile number sequence, and an output format; locating and reading the corresponding binary vector tile data from a pre-loaded vector tile data packet based on the tile number sequence in the rendering request; wherein the vector tile data packet is a single archive format, the vector tile data packet is generated from the original vector data of the new energy site through coordinate transformation and slicing processing, and the vector tile data packet is pre-loaded from a file system or object storage through a tile service engine; determining the corresponding style attribute data based on the style configuration identifier in the rendering request; performing graphic drawing based on the binary vector tile data and style attribute data in the server memory, and generating raster tiles of the corresponding format according to the output format in the rendering request, thereby realizing dynamic rasterization publishing on the backend; returning the generated raster tiles to the frontend for rendering and display, and releasing the server memory after the transmission is completed.

[0006] In one possible implementation, after returning the generated raster tiles to the front end for rendering and display, the method further includes: obtaining a query request sent by the front end containing the latitude and longitude coordinates of the user's click location; locating and reading the corresponding land parcel attribute information from pre-stored vector data based on the latitude and longitude coordinates of the user's click location in the query request; wherein the vector data includes land parcel attribute information, the vector data is vector data transformed from the original vector data through coordinate conversion, and the vector data is stored in a relational database; and returning the land parcel attribute information to the front end for display in a pop-up window or sidebar.

[0007] In one possible implementation, the front end calculates multiple tile number sequences based on the map viewport range and sends multiple rendering requests to the back end in a multi-path concurrent manner, wherein each rendering request corresponds to a unique tile number sequence.

[0008] In one possible implementation, the tile number sequence includes a scaling level Z, a tile column number X, and a tile row number Y; the single archive format includes PMTiles format, and the vector tile data package is a PMTiles archive file; based on the tile number sequence in the rendering request, the corresponding binary vector tile data is located and read from the pre-loaded vector tile data package, including: using the scaling level Z, tile column number X, and tile row number Y as index keys to locate and read the corresponding binary vector tile data from the PMTiles archive file; the binary vector tile data is PBF format data.

[0009] In one possible implementation, graphics are drawn based on binary vector tile data and style attribute data, and raster tiles of the corresponding format are generated according to the output format in the rendering request. This includes: filtering out the target vector geometric coordinates in the binary vector tile data; mapping the target vector geometric coordinates to screen pixel coordinates, combining them with style attributes, and synthesizing the corresponding raster bitmap in the server memory; and encoding the raster bitmap according to the output format in the rendering request to generate raster tiles of the corresponding format.

[0010] In one possible implementation, the output format includes PNG or WebP format.

[0011] In one possible implementation, vector tile data packages are generated from the original vector data of new energy sites through coordinate transformation and slicing processing, including: acquiring the original vector data of new energy sites containing third-level survey data and three-zone three-line data; performing coordinate transformation on the original vector data to obtain transformed vector data; performing slicing processing on the transformed vector data to generate vector tile data packages in a single archive format, and storing them in a file system or object storage.

[0012] In one possible implementation, determining the corresponding style attribute data based on the style configuration identifier in the rendering request includes: reading the corresponding style configuration file based on the style configuration identifier; and parsing the style configuration file to obtain the corresponding style attribute data.

[0013] In one possible implementation, the style attribute data includes at least one of fill color, stroke width, transparency, layer binding relationship, and attribute filtering rules.

[0014] A second aspect of this disclosure provides a backend rendering device for massive geographic vector data of new energy sites, comprising: a request receiving module for acquiring a rendering request sent by the front end, containing a style configuration identifier, a tile number sequence, and an output format; a tile reading module for locating and reading the corresponding binary vector tile data from a pre-loaded vector tile data packet based on the tile number sequence in the rendering request; the vector tile data packet is in a single archive format, generated from the original vector data of the new energy site through coordinate transformation and slicing processing, and pre-loaded from a file system or object storage by a tile service engine; a style parsing module for determining the corresponding style attribute data based on the style configuration identifier in the rendering request; a rasterization drawing module for drawing graphics in server memory based on the binary vector tile data and style attribute data, and generating raster tiles of the corresponding format according to the output format in the rendering request, thereby realizing dynamic rasterization publishing on the backend; and a return and release module for returning the generated raster tiles to the front end for rendering and display, and releasing server memory after transmission is completed.

[0015] This disclosure also provides an electronic device, comprising: a memory for storing at least one instruction; and a processor for invoking the instruction stored in the memory to execute the backend rendering method for massive geographic vector data of new energy sites in the first aspect and any possible implementation thereof.

[0016] This disclosure also provides a computer-readable storage medium storing at least one executable instruction, which is loaded and executed by a processor to implement the back-end rendering method for massive geographic vector data of new energy sites in the first aspect and any possible implementation of the first aspect.

[0017] This disclosure also provides a computer program product, which includes: computer program code, which, when executed by a computer, causes the computer to perform the backend rendering method for massive geographic vector data of new energy sites in the first aspect and any possible implementation thereof.

[0018] Compared with the prior art, this disclosure has the following beneficial effects: The backend rendering method for massive geographic vector data of new energy site provided in this disclosure uses vector tile data packets in a single archive format for storage and loading, which can reduce the management complexity and reading overhead of massive geographic vector data; by performing dynamic rasterization rendering in server memory, the pressure on front-end data parsing and graphics drawing can be greatly reduced, and the loading speed and interactive smoothness of new energy site map scenes can be improved; after the raster tiles are generated, they are directly returned to the front-end without persistent storage, and memory resources are released in a timely manner after transmission, which can effectively reduce server storage occupation and memory overhead, and improve the overall operating efficiency and stability of the system. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating a backend rendering method for massive geographic vector data of new energy sites provided in Embodiment 1 of this disclosure; Figure 2 This is a flowchart illustrating a backend rendering method for massive geographic vector data of new energy sites provided in Embodiment 2 of this disclosure; Figure 3 This is a system architecture diagram of a backend rendering method for massive geographic vector data of new energy sites provided in Embodiment 3 of this disclosure; Figure 4 This is a partial rendering diagram of massive geographic vector data of a new energy site provided in Embodiment 3 of this disclosure; Figure 5 This is a structural block diagram of a backend rendering device for massive geographic vector data of new energy sites provided in Embodiment 4 of this disclosure. Detailed Implementation

[0020] The present disclosure will now be further described with reference to the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solutions of the present disclosure and should not be construed as limiting the scope of protection of the present disclosure. It should be noted that the following detailed descriptions are exemplary and intended to provide further explanation of this application.

[0021] The acquisition, transmission, storage, use, and processing of data in this disclosed technical solution comply with relevant national laws and regulations. In the embodiments of this disclosure, certain existing industry solutions such as software, components, and models may be mentioned. These should be considered exemplary, intended only to illustrate the feasibility of implementing the technical solution of this disclosure, and do not imply that the applicant has already used or necessarily used such solutions.

[0022] All terms used in this disclosure have the same meaning as understood by one of ordinary skill in the art to which this disclosure pertains, unless otherwise specifically defined. It should also be understood that terms defined in general dictionaries should be interpreted as having meanings consistent with their meanings in the context of the relevant art, and not as idealized or highly formalized, unless expressly defined herein.

[0023] In new energy site planning, such as wind power and photovoltaic site selection, massive amounts of vector data, such as the three-dimensional geographic information system, need to be loaded, including maps from the third national geospatial survey and the three-zone, three-line geospatial mapping system. Current technologies primarily employ a "front-end vector rendering" approach, with the following process: Data transmission: The backend server directly transmits GeoJSON (Geographic JSON) data or vector tiles (such as MVT format) to the front-end browser; Front-end parsing and rendering: The front-end uses a WebGL (Web Graphics Library)-based 3D engine (such as Cesium.js, Mapbox GL JS) to receive data on the client (browser), utilizing the client's graphics card (GPU, Graphics Processing Unit) and RAM (RandomAccess Memory) to parse the vector geometric coordinates in real time, and then construct and color-fill the triangulation; Style control: Styles are typically hard-coded in the front-end code or loaded through static configuration files.

[0024] However, the existing technical solutions mentioned above have the following serious drawbacks: Browser memory overflow (OOM) and crashes: The amount of data involved in new energy planning is extremely large, often reaching millions or even tens of millions of map features. Directly loading such a large amount of vector data on the front end will cause the browser's memory usage to spike instantly, which can easily trigger the OOM mechanism, causing the page to freeze or the browser to crash; Low rendering efficiency and severe frame drops in 3D scenes: Rendering vector data on 3D terrain requires complex "clamp to ground" geometric calculations to prevent map features from being occluded or suspended by the terrain. Real-time clamp to ground calculations of massive amounts of data consume a lot of CPU / GPU resources, resulting in extremely low browsing frame rate (FPS) and unsmooth interaction; Fixed styles and poor flexibility: Modifying styles in existing solutions often requires modifying the front-end code and redeploying, or relying on complex static configurations, which cannot meet the needs of business personnel to dynamically configure map styles on the back end, such as real-time modification of colors and transparency; Weak cross-platform compatibility: The requirements for client hardware configuration are extremely high, and low-performance office computers or mobile devices cannot access the site normally.

[0025] Example 1; Figure 1 This is a flowchart illustrating a backend rendering method for massive geographic vector data of new energy sites provided in Embodiment 1 of this disclosure, as shown below. Figure 1 As shown, the backend rendering method specifically includes the following steps S11 to S15.

[0026] Step S11: Obtain the rendering request sent by the front end, which includes the style configuration identifier, tile number sequence, and output format.

[0027] It should be noted that in this embodiment, obtaining the rendering request sent by the front-end is the initial step of the back-end rendering process. Its purpose is to receive the rendering requirements from the front-end, providing a basis for subsequent tile reading, graphic drawing, and other operations. This enables the back-end to accurately respond to the front-end's map rendering requirements, ensuring the relevance and efficiency of the rendering. Here, the front-end refers to the user-interactive client interface, typically a web browser or a dedicated geographic information system client, used to receive user operations, send requests to the back-end, and display the rendering results returned by the back-end. The rendering request refers to the instruction sent by the front-end to the back-end to request the rendering of geographic vector data. This request contains key parameters required to complete the rendering, ensuring the back-end can accurately understand the front-end's rendering requirements. The style configuration identifier refers to a string or code used to uniquely identify a set of style configuration information. Through this identifier, the back-end can quickly locate and obtain the corresponding style attribute data, achieving dynamic matching of rendering styles. The tile number sequence refers to a set of parameters used to uniquely identify a map tile, used by the back-end to locate the corresponding tile data in the vector tile data package. The output format refers to the file format of the raster tiles generated by the back-end rendering, used to specify the tile format displayed by the front-end, ensuring that the front-end can correctly parse and display the data.

[0028] In one possible implementation, the front-end calculates multiple tile number sequences based on the map viewport range and sends multiple rendering requests to the back-end in a multi-path concurrent manner, where each rendering request corresponds to a unique tile number sequence. In another possible implementation, the tile number sequence includes a zoom level z, a tile column number x, and a tile row number y. The zoom level z refers to the map's zoom scale; a larger zoom level z results in richer map detail. The tile column number x refers to the tile's horizontal sequence number, and the tile row number y refers to the tile's vertical sequence number. The combination of the zoom level z, tile column number x, and tile row number y uniquely identifies a specific range of map tiles.

[0029] For example, in one specific implementation, the rendering request is: http: / / server-ip / styles / {style_id} / {z} / {x} / {y}.png, where the parameters have the following meanings: {style_id}: Style configuration identifier. The front-end specifies different IDs (such as style-red or style-dark) to instruct the back-end to call the corresponding style rules (JSON) for rendering, thereby achieving multiple visual expressions from the same data source; {z} (Zoom): Zoom level, representing the current map scale level (such as 0-18); {x} (Column), {y} (Row): Tile grid coordinates, representing the column and row numbers of the tile in the pyramid grid system at the current zoom level; .png: Output format. The request requests the back-end to return a raster image format with an alpha channel.

[0030] The logic for constructing front-end rendering requests: The front-end 3D engine (Cesium) does not directly transmit specific geographic coordinates to the back-end. Instead, based on the Web Mercator Tiling Scheme, it automatically calculates the sequence of all tile numbers (z, x, y) needed to cover the current viewport's bounding box and height, and concurrently sends multiple HTTP GET requests to the back-end. Each request corresponds to a unique tile number.

[0031] Step S12: Based on the tile number sequence in the rendering request, locate and read the corresponding binary vector tile data from the pre-loaded vector tile data package.

[0032] It should be noted that, in this embodiment of the disclosure, locating and reading binary vector tile data based on the tile number sequence is one of the core steps in realizing backend rendering. Its purpose is to obtain the original vector data required for rendering, provide data support for subsequent graphics drawing, and reduce data reading latency and improve rendering efficiency through pre-loading.

[0033] The vector tile data package is a single archive format. It is generated from the original vector data of the new energy site through coordinate transformation and slicing processing. The vector tile data package is pre-loaded from the file system or object storage via a tile service engine. In one possible implementation, generating the vector tile data package from the original vector data of the new energy site through coordinate transformation and slicing processing may specifically include the following steps S101 to S103.

[0034] Step S101: Obtain the raw vector data of the new energy site, including the third national land survey data and the three-region and three-line data.

[0035] Step S102: Perform coordinate transformation on the original vector data to obtain the transformed vector data.

[0036] It should be noted that the converted vector data includes land parcel attribute information, which includes the field structure, field length, attribute information, and attribute values ​​of the vector object.

[0037] For example, the original coordinates might be Gaussian 3 degrees with 2000 degrees and code 32, which after transformation becomes epsg4326. The original file data is stored on a file server, and the transformed geometric objects (including point, multipoint, polygon, multipolygon, linestring, and multilinestring) are stored as vector data in a relational database in geometry format.

[0038] Step S103: Slice the converted vector data to generate a vector tile data package in a single archive format, and store it in the file system or object storage.

[0039] In one possible implementation, the tiling preprocessing module performs data segmentation based on the WebMercator Pyramid model. Specific tiling parameters are based on the following dimensions: Spatial location: Based on the geographic coordinates (latitude and longitude) of vector features, a quadtree spatial indexing algorithm is used to map them to the corresponding tile grid; Level of Detail (LOD): Tile data of different precision is generated according to a preset zoom level range (e.g., 0-16 levels); Visual simplification: Based on pixel resolution thresholds for different levels, the vector geometry is dynamically thinned and simplified to ensure controllable tile volume.

[0040] In one possible implementation, the tile numbering sequence includes a scaling level Z, a tile column number X, and a tile row number Y; the single archive format includes the PMTiles format, and the vector tile data package is a PMTiles archive file.

[0041] It should be noted that PMTiles is a Single-file Archive. This file uses a compact binary structure and is stored in a file system or object storage as the final product of the tile processing. It supports random access via HTTP Range Request technology.

[0042] In one possible implementation, based on the tile number sequence in the rendering request, the corresponding binary vector tile data is located and read from the pre-loaded vector tile data package, including: using the scaling level Z, tile column number X, and tile row number Y as index keys to locate and read the corresponding binary vector tile data from the PMTiles archive file; the binary vector tile data is in PBF format.

[0043] Step S13: Determine the corresponding style attribute data based on the style configuration identifier in the rendering request.

[0044] It should be noted that in this embodiment of the disclosure, the corresponding style attribute data is determined based on the style configuration identifier. The purpose is to obtain the style parameters required for graphic drawing, realize personalized and standardized rendering of vector data, meet the needs of business personnel to dynamically configure rendering styles, and improve the readability and usability of rendering results.

[0045] In one possible implementation, the corresponding style attribute data is determined based on the style configuration identifier in the rendering request, which may specifically include the following steps S301 to S302.

[0046] Step S301: Read the corresponding style configuration file based on the style configuration identifier.

[0047] The style configuration file refers to a file that stores style configuration information, including the correspondence between style configuration identifiers and style attribute data. In one possible implementation, the style configuration file is stored in a backend style configuration library. The style configuration library refers to a database or file collection used to centrally store and manage all style configuration files, facilitating the system to quickly find and call style configuration files, while also supporting dynamic updates and maintenance of style configuration files.

[0048] Step S302: Parse the style configuration file to obtain the corresponding style attribute data.

[0049] In one possible implementation, the style attribute data includes at least one of fill color, stroke width, transparency, layer binding relationship, and attribute filtering rules. Here, fill color refers to the color used to fill vector polygon graphics; stroke width refers to the line width used to draw the boundaries of vector line graphics or polygon graphics; transparency refers to the degree of transparency when the vector graphics are displayed; layer binding relationship refers to the correspondence between the style and the vector data layer, used to specify different rendering styles for different layers; and attribute filtering rules refer to the rules used to filter the vector data to be rendered, allowing target data to be selected for rendering based on the attribute information of the vector data.

[0050] Step S14: In the server memory, draw graphics based on binary vector tile data and style attribute data, and generate raster tiles of the corresponding format according to the output format in the rendering request, so as to realize the backend dynamic rasterization publishing.

[0051] It should be noted that, in this embodiment of the disclosure, completing the drawing of graphics and generating raster tiles in the server memory is the core step of backend dynamic rasterization publishing. Its purpose is to convert vector data into raster data that can be directly displayed on the front end, realize efficient rendering of massive vector data, and at the same time avoid persistent storage of raster tiles, thereby reducing server storage overhead.

[0052] It should be noted that, unlike traditional offline pre-rendering techniques, the raster tiles generated in this disclosure are non-persistent data. After the TileServer GL rendering engine completes image compositing in memory, it directly transmits the data to the front end via an HTTP response stream, without persistent storage in a database or on disk. This mechanism not only saves a massive amount of storage space but also ensures real-time consistency between the rendering results and the current style configuration.

[0053] Server memory refers to the memory space used by the backend server for temporary data storage and computation. Performing graphics drawing and raster tile generation in server memory can significantly improve computation speed and avoid disk I / O overhead. Graphics drawing refers to drawing vector graphics that meet the requirements in server memory based on the vector geometric information in binary vector tile data and style attribute data. In one possible implementation, graphics drawing is performed based on binary vector tile data and style attribute data, and raster tiles of the corresponding format are generated according to the output format in the rendering request. Specifically, this may include the following steps S401 to S403.

[0054] Step S401: Filter out the target vector geometric coordinates in the binary vector tile data.

[0055] Among them, the target vector geometric coordinates refer to the coordinate information of the vector graphics that need to be rendered, which are selected from the binary vector tile data, including the coordinates of geometric types such as points, lines, and surfaces.

[0056] Step S402: Map the target vector geometric coordinates to screen pixel coordinates, and combine them with style attributes to synthesize the corresponding raster bitmap in the server memory.

[0057] Among them, screen pixel coordinates refer to converting vector geometric coordinates into pixel coordinates suitable for screen display, ensuring that the rendered graphics can accurately adapt to the front-end screen; raster bitmap refers to a bitmap composed of pixels, which is an intermediate result after the graphics are drawn and contains the rendered graphic information.

[0058] Step S403: Encode the raster bitmap according to the output format in the rendering request to generate raster tiles of the corresponding format.

[0059] The output format refers to the file format of the raster tiles generated by the backend rendering. In one possible implementation, the output format includes PNG (Portable Network Graphics) or WebP (Web Picture Format). PNG format features lossless compression and supports transparent backgrounds, while WebP format features high compression ratio and fast loading speed. Users can choose the corresponding output format according to their needs, and this disclosure does not specifically limit this choice.

[0060] Additionally, it should be noted that raster tiles refer to tile data formed by cutting raster bitmaps according to preset sizes. This is an image format data that the front end can directly parse and display. Back-end dynamic rasterization publishing refers to converting vector data into raster tiles in real time on the server side and returning them to the front end. The raster tiles are not persistently stored, which enables dynamic rendering and publishing of vector data. This allows for flexible response to front-end rendering requests while reducing server storage pressure.

[0061] For example, in one specific implementation, the backend dynamic rasterization publishing adopts a style-data mapping rendering mechanism. That is, the backend rendering engine realizes the dynamic association between styles and vector tiles through layer binding and attribute filtering mechanisms. Specifically, this includes: source layer anchoring: the style configuration file (Style JSON) indexes the predefined layer name (such as 'pl_sandiao') in the vector tile through the source-layer field, realizing the association between logical layers and physical data; attribute condition filtering: the rendering engine parses the filter expression in the style, reads the attribute table of vector features, and filters out specific types of geometric features as needed (such as filtering cultivated land patches with code=0101); runtime rasterization: the engine maps the filtered vector geometric coordinates to screen pixel coordinates and applies the rendering properties (PaintProperties, such as fill color and stroke width) defined in the style, synthesizing the final raster bitmap in memory and video memory.

[0062] Step S15: Return the generated raster tiles to the front end for rendering and display, and release the server memory after the transfer is complete.

[0063] It should be noted that in this embodiment, returning the raster tiles to the front end and releasing server memory is the final step in the backend rendering process. Its purpose is to display the rendering results to the user while releasing the resources occupied by this rendering, ensuring the server can efficiently respond to subsequent rendering requests and improving server stability and resource utilization. "Returning to the front end" means the backend sends the generated raster tiles to the front end as a data stream, which the front end then parses. "Rendering and display" means the front end stitches and integrates the received raster tiles, overlays them onto a 3D geographic scene, and displays them to the user, allowing the user to intuitively view the geographic vector information of the new energy site. "Transmission complete" means the raster tile data stream has been completely sent to the front end, and the front end confirms receipt. "Releasing server memory" means that after the raster tile transmission is complete, the system releases the server memory resources occupied during this rendering process, including temporary data such as binary vector tile data, style attribute data, and raster bitmaps, to avoid the accumulation of memory resources.

[0064] In one possible implementation, after receiving the grid tiles, the front end splices multiple grid tiles according to the correspondence of the tile number sequence and overlays them on the terrain layer of the three-dimensional geographic information system to realize the three-dimensional rendering and display of the vector data of new energy sites, thereby improving the user's browsing experience.

[0065] It should be noted that, in the backend dynamic rendering process, after receiving the rendering request from the frontend, the backend service does not query the pre-stored static raster file, but instead executes the following real-time compositing process: Vector retrieval: Using (z,x,y) as the index key, locate and read the corresponding binary vector tile data (PBF) from the PMTiles archive file; Style injection: Read the style configuration file corresponding to {style_id} and parse the rendering attributes such as color, line width, and filtering conditions; Real-time rasterization: Combine the vector geometric data with the style attributes to draw the graphics in the server memory, generating PNG format raster tiles in real time; Streaming return: Return the generated image to the frontend in binary stream form, and release the memory after transmission, without persistent storage.

[0066] Additionally, it should be noted that the loading strategy in this embodiment employs a multi-path concurrent loading strategy. The front-end browser, based on HTTP protocol limits (typically 6-20 concurrent connections), simultaneously requests dozens of tiles within the viewport range from the back-end. The back-end TileServer GL possesses high concurrency processing capabilities, enabling it to process these requests concurrently and return rendering results in parallel, thereby quickly stitching together a complete map overlay on the front-end.

[0067] The backend rendering method for massive geographic vector data of new energy site provided in Embodiment 1 of this disclosure has the following beneficial effects: 1. Improved performance and stability: By transferring the computational pressure from the front end to the back end, the problem of browser crashes (OOM) caused by loading millions of vector data is completely solved. 2. Optimized 3D ground-hugging effect: By using raster texture mapping technology to replace vector geometric calculations, perfect data fitting on complex 3D terrain is achieved without consuming front-end computing power. 3. Support for dynamic hot style updates: "Style changes on the back end take effect on the front end immediately," eliminating the need to republish code and reducing operation and maintenance costs and learning costs. 4. Strong cross-platform compatibility: Raster tiles are a standard Web format, compatible with various mobile devices and low-configuration terminals.

[0068] Example 2; Figure 2 This is a flowchart illustrating a backend rendering method for massive geographic vector data of new energy sites provided in Embodiment 2 of this disclosure. After performing the initial rendering of the massive geographic vector data of new energy sites using steps S11 to S15 of Embodiment 1, specific land parcel attribute information can be obtained by clicking on the initial rendering, such as... Figure 2 As shown, after the generated raster tiles are returned to the front end for rendering and display, the following steps S16 to S18 may also be included.

[0069] Step S16: Obtain the query request sent by the front end, which contains the latitude and longitude coordinates of the user's clicked location.

[0070] It should be noted that, in this embodiment, obtaining the query request sent by the front end is the initial step in realizing vector data attribute query interaction. Its purpose is to receive the user's click query instruction in the front-end map scene, providing a basis for subsequent spatial positioning and attribute reading, enabling interactive information query between the user and the three-dimensional geographic scene, and improving the convenience of viewing new energy site information. Here, the query request refers to the interactive instruction generated by the front end based on the user's operation, used to request the acquisition of the corresponding spatial location plot attribute information; the latitude and longitude coordinates of the user's click location refer to the EPSG:4326 coordinate system latitude and longitude coordinates corresponding to the click point automatically collected by the system when the user performs a click operation in the front-end three-dimensional geographic scene, used to uniquely identify the spatial query location.

[0071] In one possible implementation, the user performs a click operation on the new energy site raster map rendered by the front end. The front end collects the latitude and longitude coordinates corresponding to the clicked location in real time and encapsulates them into a query request, which is then sent to the backend server via a network request.

[0072] Step S17: Based on the latitude and longitude coordinates of the user's click location in the query request, locate and read the corresponding land parcel attribute information from the pre-stored vector data.

[0073] It should be noted that, in this embodiment of the disclosure, locating and reading land parcel attribute information based on latitude and longitude coordinates is the core step in achieving spatial location and attribute data association and matching. Its purpose is to match target land parcel data through spatial retrieval, returning accurate land parcel details to the user. This enables rapid association and querying of vector spatial data and attribute data, meeting the land parcel information verification needs in new energy site planning. Vector data includes land parcel attribute information. Vector data refers to standardized geospatial data obtained by coordinate transformation of original vector data. Vector data is stored in a relational database. A relational database is a database used to store the transformed vector data and corresponding land parcel attribute information, supporting spatial indexing and structured queries.

[0074] In one possible implementation, the system uses the latitude and longitude coordinates of the user's click location as the search criteria, performs a spatial inclusion query in a relational database, and locates vector land parcel data that fall within the coordinate range.

[0075] Step S18: Return the land parcel attribute information to the front end for display in a pop-up window or sidebar.

[0076] It should be noted that, in this embodiment, returning and displaying the land parcel attribute information to the front end is the final step in completing the interactive attribute query. Its purpose is to present the query results intuitively to the user, achieving a visual display of land parcel information and improving the interactive experience and readability of new energy site geographic information queries. Specifically, pop-up display refers to the front end directly displaying a floating window at the user's click location to show the land parcel attribute information, while sidebar display refers to the front end displaying the land parcel attribute information in a panel format in the side area of ​​the interface. In one possible implementation, the back end encapsulates the land parcel attribute information into JSON format data and returns it to the front end. After parsing the data, the front end selects either a pop-up or sidebar format for display based on the user's operating habits.

[0077] For example, in one specific implementation, from the user's perspective: the user sees an image, i.e., a raster map. When the user clicks on a plot of land, such as a photovoltaic panel area, a bubble will pop up on the interface or a panel will slide out on the right, listing the detailed information of the plot, such as: plot ID, area, owner, land type, etc.

[0078] This disclosed embodiment employs split storage: Path A (for viewing): the data is processed into PMTiles by a tiling tool (mainly storing graphics, with attributes extremely simplified or discarded) solely for rapid drawing; Path B (for querying): the complete data (original graphics + complete attribute table) is stored intact in the PostGIS database.

[0079] The back-end rendering method for massive geographic vector data of new energy sites provided in Embodiment 2 of this disclosure, through the separation strategy of "using raster to view the map and using the library to query attributes", ensures both browsing speed and data query accuracy.

[0080] Example 3; In this embodiment, unlike the traditional WebGIS front-end model that directly parses vector geometric data, this disclosure designs a hybrid architecture that transfers the heavy vector calculations to the back-end. The back-end is responsible for rendering massive amounts of vector data into raster images with alpha channels in real time, while the front-end Cesium engine uses texture mapping technology to directly apply the two-dimensional raster stream to the three-dimensional terrain surface. This solves the browser memory overflow (OOM) and rendering frame drops caused by the front-end performing complex "clamp to ground" geometric calculations when loading millions / tens of millions of vector vector patches in a three-dimensional scene, achieving zero-latency loading of massive data on complex terrain.

[0081] Figure 3 This is a system architecture diagram of a backend rendering method for massive geographic vector data of new energy sites provided in Embodiment 3 of this disclosure, as shown in the figure. Figure 3 As shown, the system adopts a four-layer architecture, consisting of a front-end 3D visualization layer, a data interaction layer, a dynamic rendering service layer, and a data processing layer, from top to bottom. The data processing layer is responsible for accessing raw vector data, coordinate transformation and standardized storage, and vector tile generation, constructing vector tile data packages in a single archive format such as PMTiles, and storing them in the raw vector database. The dynamic rendering service layer manages style configuration information through a style configuration module. The tile rendering engine responds to front-end requests, completing the dynamic rendering and encoding of vector data into raster tiles in the server's memory, generating PNG or... The architecture uses WebP format raster tiles. The data interaction layer receives rendering requests and click query requests from the front end through tile interfaces and attribute query interfaces, respectively, and realizes the interactive transmission of backend calculation results and frontend display data. The frontend 3D visualization layer receives and displays raster tiles through the raster tile layer, and combines 3D terrain fitting to achieve low memory usage 3D scene rendering. It also responds to user click operations and completes interactive query of land parcel attributes through the process of "sending coordinates - receiving attributes - pop-up / sidebar display". The overall architecture realizes efficient backend rendering and smooth cross-terminal display of massive geographic vector data.

[0082] The implementation process and operational results of the backend rendering architecture are as follows: 1. Environment Deployment: The backend deploys a database with spatial expansion capabilities, installs a vector tile tiling tool, and deploys a vector tile service engine; the frontend builds a 3D Earth display scene based on an open-source 3D geographic framework.

[0083] For example, the backend deploys a PostgreSQL (PostGIS extension) database, installs the Tippecanoe tiling tool, and deploys the TileServer GL service. The frontend uses the Cesium.js open-source framework to build a 3D globe scene.

[0084] 2. Data Processing: Users upload vector data from the Third National Geodetic Survey (approximately 2 million polygon patches). The system uses a backend script to slice the vector data, generating vector tile data packages in a single-file archive format, and simultaneously stores the original data in a spatial database table.

[0085] 3. Style Configuration: Business personnel configure the land type rendering style in the backend management interface, setting cultivated land patches to red and configuring the corresponding transparency, and setting forest land patches to green. The tile service engine automatically reads the style configuration file.

[0086] For example, a business user configures "Farmland" as red (RGB:255,0,0, transparency 0.5) and "Woodland" as green in the backend. The TileServer GL engine reads this style configuration JSON.

[0087] 4. Front-end loading: Add the corresponding map layer to the front-end 3D scene code to complete the layer loading logic configuration.

[0088] For example, add layers to the front-end Cesium code.

[0089] 5. Operational Results: On the 3D Earth scene, the photovoltaic site boundary line perfectly matches the terrain, such as... Figure 4 As shown, regardless of how quickly the map is dragged, the browser's memory usage remains around 500MB (significantly lower than the traditional 4GB+), and the frame rate remains stable at over 50FPS.

[0090] For ease of understanding, the following describes the overall steps of a backend rendering method for massive geographic vector data of new energy sites provided in this disclosure, with reference to specific embodiments.

[0091] Step S1: The data access and standardization system receives the raw vector data uploaded by users (such as vector feature files, geographic databases, etc., including the third national land survey, three-region and three-line data related to new energy site planning).

[0092] Step S2: Coordinate Transformation and Database Storage The backend parsing engine transforms the coordinate system of the original vector data into the universal standard coordinate system (EPSG:4326) and stores the complete geometric and attribute information in a relational database (PostgreSQL / PostGIS) as the data source for attribute queries.

[0093] Step S3: Vector Tile Generation (Preprocessing) The converted vector data is sliced ​​using a slicing tool (Tippecanoe) to generate vector tile packages (PMTiles) in a single archive format. Note: Using the PMTiles format can solve the problem of storing massive amounts of small files and improve reading efficiency.

[0094] Step S4: Backend dynamic rasterization publishing utilizes the TileServer GL engine to load the aforementioned PMTiles data. The system provides a style configuration interface, allowing users to define layer styles (color, image texture, line width, transparency). TileServer GL, on the backend, renders the vector data into raster tiles (such as PNG / WebP format) in real time based on the current style configuration.

[0095] Step S5: Lightweight front-end loading. Front-end web map components (such as Leaflet / OpenLayers / MapLibre) only need to request the standard XYZ raster tile interface. Since the received data is an image, the browser does not need to perform geometric calculations, resulting in extremely low memory usage.

[0096] Step S6: Location-Based Attribute Reverse Lookup. When a user clicks on a point on the map, the front-end obtains the latitude and longitude coordinates of the clicked location and sends a query request to the back-end. The back-end performs a spatial query in the PostgreSQL database to obtain the corresponding land parcel attribute information and returns it to the front-end for display.

[0097] In this process, step S1, which involves the unified access of various input data, adopts the standard Web Service (Web Service) method. Step S2, the coordinate system transformation, uses a parameter-based coordinate transformation method. Step S3, the vector data tiling rules, comply with OGC industry standards to ensure the compliance and accuracy of the tiled data. Step S4, the tile service engine, uses the WMTS map service standard.

[0098] This third embodiment of the present disclosure effectively achieves efficient management and smooth rendering of massive geographic vector data for new energy sites through the entire process of standardized data access, coordinate transformation and warehousing, vector tile preprocessing, backend dynamic rasterization publishing, lightweight frontend loading, and location-based attribute reverse lookup. It not only solves the problem of storing massive small files and improves data reading efficiency through a single archive format tile, but also addresses the pain points of browser memory overflow and interactive lag in traditional frontend rendering solutions by centrally rendering raster tiles on the backend and loading only image data on the frontend. This reduces dependence on terminal hardware configuration and improves cross-terminal compatibility and 3D scene rendering effects. Simultaneously, the standardized style configuration interface supports dynamic adjustment of layer styles, enabling instant updates without modifying the frontend code, reducing operation and maintenance costs. Combined with the spatial retrieval capabilities of a relational spatial database, it realizes linked queries of geographic space and attribute data, significantly improving the interactive experience and data utilization value of new energy site planning and management, and fully meeting the business needs for efficient, flexible, and stable management of massive geographic vector data in new energy site planning.

[0099] Example 4; Figure 5 This is a structural block diagram of a backend rendering device for massive geographic vector data of new energy sites provided in Embodiment 4 of this disclosure, as shown below. Figure 5 As shown, the backend rendering device 100 specifically includes a request receiving module 110, a tile reading module 120, a style parsing module 130, a rasterization drawing module 140, and a return and release module 150.

[0100] The system includes: a request receiving module 110, which receives a rendering request from the front end containing a style configuration identifier, a tile number sequence, and an output format; a tile reading module 120, which locates and reads the corresponding binary vector tile data from a pre-loaded vector tile data packet based on the tile number sequence in the rendering request; the vector tile data packet is a single archive format, generated from the original vector data of the new energy site through coordinate transformation and slicing, and pre-loaded from the file system or object storage by the tile service engine; a style parsing module 130, which determines the corresponding style attribute data based on the style configuration identifier in the rendering request; a rasterization drawing module 140, which performs graphic drawing in the server memory based on the binary vector tile data and style attribute data, and generates raster tiles of the corresponding format according to the output format in the rendering request, realizing dynamic rasterization publishing on the back end; and a return and release module 150, which returns the generated raster tiles to the front end for rendering and display, and releases the server memory after the transmission is completed.

[0101] For details and benefits of the back-end rendering device for massive geographic vector data of new energy sites provided in the embodiments of this disclosure, please refer to the above description of the back-end rendering method for massive geographic vector data of new energy sites, which will not be repeated here.

[0102] This disclosure also provides an electronic device, which includes: a memory for storing at least one instruction; and a processor for calling the instruction stored in the memory to execute the backend rendering method for massive geographic vector data of new energy sites in any of the above embodiments.

[0103] This disclosure also provides a computer-readable storage medium storing at least one executable instruction, which is loaded and executed by a processor to implement the back-end rendering method for massive geographic vector data of new energy sites in any of the above embodiments.

[0104] This disclosure also provides a computer program product, which includes computer program code. When the computer program code is run by a computer, it causes the computer to execute the backend rendering method for massive geographic vector data of new energy sites in any of the above embodiments.

[0105] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0106] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0107] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0108] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0109] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0110] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0111] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0112] It should be noted that the terms "first," "second," and similar terms used in this disclosure do not indicate any order, quantity, or importance, but are merely used to distinguish different parts. Terms such as "including" or "contains" mean that the element preceding the word covers the element listed after the word, and do not exclude the possibility of covering other elements as well.

[0113] Although operations are described in a specific order in the accompanying drawings in this disclosure, it should not be construed as requiring these operations to be performed in the specific order or serial order shown, or requiring all of the shown operations to obtain the desired result. In certain environments, multitasking and parallel processing may be advantageous.

[0114] Finally, it should be noted that the above content is only used to illustrate the technical solution of this disclosure, and is not intended to limit the scope of protection of this disclosure. Simple modifications or equivalent substitutions made by those skilled in the art to the technical solution of this disclosure do not depart from the substance and scope of the technical solution of this disclosure.

Claims

1. A backend rendering method for massive geographic vector data of new energy site, characterized in that, include: Get the rendering request sent by the front end, which includes style configuration identifiers, tile number sequence, and output format; Based on the tile number sequence in the rendering request, the corresponding binary vector tile data is located and read from the pre-loaded vector tile data package; wherein, the vector tile data package is a single archive format, the vector tile data package is generated by coordinate transformation and slicing processing of the original vector data of the new energy site, and the vector tile data package is pre-loaded from the file system or object storage through the tile service engine; Based on the style configuration identifier in the rendering request, determine the corresponding style attribute data; In the server memory, graphics are drawn based on the binary vector tile data and the style attribute data, and raster tiles of the corresponding format are generated according to the output format in the rendering request, so as to realize the backend dynamic rasterization publishing. The generated raster tiles are returned to the front end for rendering and display, and the server memory is released after the transmission is complete.

2. The back-end rendering method for massive geographic vector data of new energy site as described in claim 1, characterized in that, After returning the generated raster tiles to the front end for rendering and display, the process also includes: Get the query request sent by the front end, which contains the latitude and longitude coordinates of the user's click location; Based on the latitude and longitude coordinates of the user's click location in the query request, the corresponding land parcel attribute information is located and read from the pre-stored vector data; wherein, the vector data includes land parcel attribute information, the vector data is vector data transformed from the original vector data through coordinate transformation, and the vector data is stored in a relational database; The land parcel attribute information is returned to the front end for display in a pop-up window or sidebar.

3. The back-end rendering method for massive geographic vector data of new energy site as described in claim 1, characterized in that, The front end calculates multiple tile number sequences based on the map viewport range and sends multiple rendering requests to the back end in a multi-path concurrent manner, wherein each rendering request corresponds to a unique tile number sequence.

4. The back-end rendering method for massive geographic vector data of new energy site according to any one of claims 1-3, characterized in that, The tile numbering sequence includes the scaling level Z, the tile column number X, and the tile row number Y; the single archive format includes the PMTiles format, and the vector tile data package is a PMTiles archive file; the step of locating and reading the corresponding binary vector tile data from the pre-loaded vector tile data package based on the tile numbering sequence in the rendering request includes: Using the scaling level Z, the tile column number X, and the tile row number Y as index keys, the corresponding binary vector tile data is located and read from the PMTiles archive file; the binary vector tile data is in PBF format.

5. The back-end rendering method for massive geographic vector data of new energy site according to any one of claims 1-3, characterized in that, The step of drawing graphics based on the binary vector tile data and the style attribute data, and generating raster tiles of the corresponding format according to the output format in the rendering request, includes: Filter out the target vector geometric coordinates from the binary vector tile data; The target vector geometric coordinates are mapped to screen pixel coordinates, and combined with the style attributes, a corresponding raster bitmap is synthesized in the server memory. The raster bitmap is encoded according to the output format in the rendering request to generate raster tiles of the corresponding format.

6. The back-end rendering method for massive geographic vector data of new energy site according to claim 5, characterized in that, The output format includes PNG or WebP format.

7. The back-end rendering method for massive geographic vector data of new energy site as described in claim 1, characterized in that, The process of generating the vector tile data package from the original vector data of the new energy site through coordinate transformation and slicing includes: Obtain raw vector data of new energy sites, including data from the third national land survey and data from the three regions and three lines. The original vector data is subjected to coordinate transformation to obtain the transformed vector data; The converted vector data is sliced ​​to generate a vector tile data package in a single archive format, and then stored in a file system or object storage.

8. The back-end rendering method for massive geographic vector data of new energy site as described in claim 1, characterized in that, The step of determining the corresponding style attribute data based on the style configuration identifier in the rendering request includes: Based on the style configuration identifier, read the corresponding style configuration file; The style configuration file is parsed to obtain the corresponding style attribute data.

9. The back-end rendering method for massive geographic vector data of new energy site according to claim 1 or 8, characterized in that, The style attribute data includes at least one of the following: fill color, stroke width, transparency, layer binding relationship, and attribute filtering rules.

10. A backend rendering device for massive geographic vector data of new energy site, characterized in that, include: The request receiving module is used to obtain the rendering request sent by the front end, which includes style configuration identifier, tile number sequence and output format; The tile reading module is used to locate and read the corresponding binary vector tile data from the pre-loaded vector tile data package based on the tile number sequence in the rendering request; the vector tile data package is a single archive format, the vector tile data package is generated by coordinate transformation and slicing processing of the original vector data of the new energy site, and the vector tile data package is pre-loaded from the file system or object storage through the tile service engine; The style parsing module is used to determine the corresponding style attribute data based on the style configuration identifier in the rendering request; The rasterization drawing module is used to draw graphics in the server memory based on the binary vector tile data and the style attribute data, and generate raster tiles of the corresponding format according to the output format in the rendering request, so as to realize dynamic rasterization publishing on the backend. The return and release module is used to return the generated raster tiles to the front end for rendering and display, and to release the server memory after the transmission is completed.

Images