A WMS map hierarchical management method, system, device and medium

Abstract

This invention relates to the field of geographic information service security control technology, and discloses a method, system, device, and medium for hierarchical management and control of WMS maps. The method generates a cacheKey corresponding to the user's identity and caches the permission context when processing GetCapabilities requests, and performs layer filtering and access path rewriting on service capability documents. In subsequent GetMap requests, the permission context is restored based on the cacheKey, and transparent return, pass-through, or clipping is performed according to spatial relationships. In GetFeatureInfo requests, pixel coordinates are mapped to geographic rectangles, spatial verification is performed, and attribute results are filtered according to a field whitelist. This solution achieves collaborative management and control of layers, spaces, and attributes without modifying the backend WMS service.

Description

Technical Field

[0001] This invention relates to the field of geographic information service security control technology, and in particular to a WMS map hierarchical management and control method, system, device and medium. Background Technology

[0002] WMS map services are widely used in the sharing and publishing of government maps, industry thematic maps, and internal business maps due to their high degree of standardization and good compatibility with mainstream GIS platforms. With the increasing demand for multiple roles and levels of users to access the same map service, establishing a controllable data exposure mechanism around the WMS request chain has become a crucial issue in the security control of geographic information services.

[0003] Existing technologies already include control schemes for layer filtering, spatial restrictions, or request forwarding for WMS services. In particular, schemes most similar to the existing technology CN108924115B, "A Spatial Service Access Control Method and System," can impose access constraints on layers and spatial extents during GetCapabilities or GetMap processing. However, these schemes focus more on single-request level control and lack a stable and unified method for ensuring that subsequent requests after capability document filtering continuously carry the same permission semantics in the stateless WMS access chain.

[0004] Furthermore, in existing technologies, if the target area of ​​a GetMap request does not intersect with the authorized spatial area, it usually still needs to go through a backend request or a unified pruning process, resulting in unnecessary processing overhead. In the GetFeatureInfo scenario, if only the existence of click points or simple parameters is used as the criterion, it is difficult to accurately reflect the real geographic area corresponding to the pixel-level query, thus affecting the accuracy of attribute query authorization. Therefore, it is still necessary to propose a WMS map hierarchical management scheme that can continuously pass the permission context between GetCapabilities, GetMap, and GetFeatureInfo requests, and implement differentiated processing for map rendering requests and attribute query requests respectively. Summary of the Invention

[0005] This invention addresses the technical problems existing in the prior art by proposing a WMS map hierarchical management and control method, system, equipment, and medium.

[0006] The technical solution of the present invention to solve the above-mentioned technical problems is as follows:

[0007] A hierarchical management method for WMS maps is proposed. This method includes: receiving a GetCapabilities request between the client and the WMS geographic service; parsing the user's identity identifier; generating a corresponding cache key (cacheKey); and constructing or obtaining a permission context based on the user's identity identifier. The permission context includes at least an accessible layer set Lu, the spatial visibility Ru(l) corresponding to each layer, and a whitelist of attribute fields Fu(l). The GetCapabilities request is forwarded to the backend WMS geographic service to obtain the original service capability document. Layer filtering is performed on the original service capability document, retaining only the layers in the accessible layer set Lu, and rewriting the service access path corresponding to the retained layers as a proxy path carrying the cacheKey. A GetMap request or GetFeatureInfo request initiated based on the proxy path is received. The cacheKey is extracted from the proxy path, and the corresponding permission context is restored based on the cacheKey. Upon receiving the GetMap request, it is determined whether the requested layer belongs to the accessible layer set Lu, and the request range is compared with the corresponding layer's spatial visibility Ru(l). The system determines the spatial relationship between the requested area and the spatial visible area. When the requested area does not intersect with the spatial visible area, a transparent map image is returned directly. When the requested area is completely contained within the spatial visible area, the original map image returned by the backend is passed through. In other cases, the original map image returned by the backend is cropped according to the spatial visible area and then returned. Upon receiving the GetFeatureInfo request, the system maps the pixel coordinates to a geographic rectangle Gpixel based on the bounding box, image size, and pixel coordinates in the request. If the Gpixel intersects with the corresponding layer's spatial visible area Ru(l) and the requested layer belongs to the accessible layer set Lu, the system forwards the GetFeatureInfo request and filters the returned result based on the corresponding layer's attribute field whitelist Fu(l). Otherwise, an empty attribute response is returned.

[0008] Furthermore, the cacheKey is generated by a hash function from the user's identity identifier, and the permission context is stored in the caching system with the cacheKey as the key, and a time-to-live or expiration update mechanism is set.

[0009] Furthermore, when performing layer filtering on the original service capability document, layer nodes that do not belong to the accessible layer set Lu are deleted, and the access addresses of the retained layers are rewritten using a unified proxy path.

[0010] Furthermore, the proxy path contains both the cacheKey and the target layer identifier. Subsequent GetMap or GetFeatureInfo requests initiated based on the proxy path carry the cacheKey through the proxy path.

[0011] Furthermore, when the requested range does not intersect with the spatial visible area, a transparent map image with the same image format and image size as the GetMap request is returned.

[0012] Furthermore, when cropping the original map image returned by the backend, the original map image is converted into image data or raster data, a mask region is constructed based on the spatial visible area, and the image data or raster data is cropped based on the mask region. The cropping result is output according to the image format specified in the GetMap request.

[0013] Further, mapping the pixel coordinates to a geographic rectangle Gpixel includes: determining the geographic resolution of the pixel in the x and y directions based on the geographic extent of the bounding box, the image width, and the image height; and determining the geographic rectangle Gpixel corresponding to the pixel unit of the pixel coordinates based on the pixel coordinates and the geographic resolution in the x and y directions.

[0014] This invention also provides a WMS map hierarchical management system, including a request interception module, an identity parsing module, a permission context caching module, a capability document processing module, a map request processing module, and an attribute query processing module. The request interception module intercepts GetCapabilities, GetMap, and GetFeatureInfo requests sent by the client to the backend WMS geographic service. The identity parsing module parses the user's identity identifier and generates a cache key (cacheKey) upon receiving a GetCapabilities request. The permission context caching module establishes or retrieves a permission context based on the user's identity identifier and caches the permission context using the cacheKey as an index. The permission context includes at least an accessible layer set Lu, a spatial visibility Ru(l) corresponding to each layer, and a whitelist of attribute fields Fu(l). The capability document processing module forwards the GetCapabilities request to the backend WMS geographic service, retrieves the original service capability document, performs layer filtering on the original service capability document, retains only the layers in the accessible layer set Lu, and rewrites the service access path corresponding to the retained layers to carry the cacheKey. The proxy path; the map request processing module is used to extract the cacheKey from the proxy path to restore the corresponding permission context when receiving a GetMap request initiated based on the proxy path, determine whether the requested layer belongs to the accessible layer set Lu, and determine the spatial relationship between the requested range and the corresponding layer's spatial visibility Ru(l). When the requested range and the spatial visibility have no intersection, a transparent map image is returned. When the requested range is completely contained by the spatial visibility, the original map image returned by the backend is passed through. In other cases, the original map image returned by the backend is cropped according to the spatial visibility and returned. The attribute query processing module is used to extract the cacheKey from the proxy path to restore the corresponding permission context when receiving a GetFeatureInfo request initiated based on the proxy path, determine the geographic rectangle Gpixel according to the bounding box, image size, and pixel coordinates in the request, and when the Gpixel intersects with the corresponding layer's spatial visibility Ru(l) and the requested layer belongs to the accessible layer set Lu, forward the GetFeatureInfo request and apply the whitelist Fu(l) of the corresponding layer's attribute fields. Filter the returned results by field; otherwise, return an empty attribute response.

[0015] The present invention also provides an electronic device, including a processor and a memory, wherein the memory stores a computer program, which, when executed by the processor, implements the above-described method.

[0016] The present invention also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method.

[0017] The beneficial effects of this invention are:

[0018] Compared with existing technologies, this invention generates cache keys in the GetCapabilities stage and filters layers and rewrites access paths in the capability document, enabling subsequent GetMap requests and GetFeatureInfo requests to restore the same permission context without modifying the backend WMS service, thereby achieving consistent linkage between layer visibility control, spatial visibility control, and attribute field control.

[0019] This invention performs three-branch processing when handling GetMap requests: transparent return without intersection, full pass-through, and pruning of other cases, based on spatial relationships. This avoids continuing to initiate backend requests for obviously invalid request ranges or uniformly entering the pruning chain, which helps reduce invalid processing overhead and improve request processing efficiency.

[0020] When processing GetFeatureInfo requests, this invention does not simply determine the authorization relationship based on a single point location. Instead, it first calculates the corresponding geographic rectangle (Gpixel) based on the bounding box, image size, and pixel coordinates, and then performs verification in conjunction with the spatial visibility. This helps improve the accuracy of attribute query authorization judgment. After passing spatial verification, it further filters the returned attributes based on the field whitelist, reducing the risk of sensitive attribute exposure.

[0021] Furthermore, this invention uses an independent proxy layer to carry identity resolution, context caching, capability document processing, map request processing, and attribute query processing logic, which facilitates decoupling and deployment from different backend WMS services and improves the system's adaptability and maintenance convenience. Attached Figure Description

[0022] Figure 1 This is a schematic diagram of the structure of the map hierarchical and layered management system based on WMS services of the present invention;

[0023] Figure 2 This is a schematic diagram of the overall process of the map hierarchical and layered management method based on WMS services of the present invention;

[0024] Figure 3 This is a flowchart illustrating the GetMap request processing procedure in this invention.

[0025] Figure 4 This is a flowchart illustrating the GetFeatureInfo request processing procedure in this invention. Detailed Implementation

[0026] The present invention will be further described below with reference to specific embodiments. Those skilled in the art should understand that equivalent substitutions made to specific parameter forms, deployment methods, or object conversion details without departing from the technical concept of the present invention should all fall within the protection scope of the present invention.

[0027] Example 1:

[0028] like Figure 1 As shown, the overall system architecture of this invention includes a proxy layer located between the client and the backend WMS geographic service; as Figure 2 As shown, the method flow of this invention takes the GetCapabilities request processing as the entry point and continuously reuses the same permission context in subsequent GetMap and GetFeatureInfo requests. In this embodiment, the proxy layer is deployed between the client and the backend WMS geographic service to uniformly intercept GetCapabilities, GetMap, and GetFeatureInfo requests, and perform corresponding hierarchical control on the three types of requests. To avoid ambiguity in terminology, in this embodiment, "hierarchical" is used to refer to layer-level visibility control, and "hierarchical" is used to refer to spatial visibility control and attribute field control within an authorized layer.

[0029] For ease of explanation, let's first define the layer set, role set, and user set. Let the total layer set published by the backend geographic service be...

[0030]

[0031] Indicates the first There are 10 layers, where n represents the total number of layers.

[0032] The system predefined set of roles is

[0033] m represents the total number of characters. This represents the m-th character.

[0034] The user set is For any user Let its set of roles be denoted as . Further define the authorization function from character to layer.

[0035]

[0036] in For layer collection The power set. Then the user The set of accessible layers can be represented as

[0037]

[0038] Where A(r) represents the authorization query function for any visible layer of a role. It takes the role identifier r as input parameter, performs a search and matching based on the system's preset permission mapping relationship, and queries and returns the set of visible layers bound to the role identifier r. For any authorized layer ,set up Indicates user In layers The spatial field of view on the surface Indicates user In layers The collection of visible attribute fields. This allows users to... The permission context can be abstractly represented as

[0039]

[0040] In one implementation, if the user views the layer If there are no space restrictions, then... Recorded as If the user has a layer If there are no attribute restrictions, then let This is the complete set of fields for this layer.

[0041] To ensure that the aforementioned permission context is applied across the three types of requests, this implementation also defines request control semantics.

[0042]

[0043] in, Indicates the request type; Indicates the target layer specified in the request; Indicates user The set of layers authorized for access; Indicates user In layers The visible area of ​​space below; Indicates user In layers The whitelist of readable attribute fields; This represents the geographic rectangle (i.e., the feature location range) obtained by converting the clicked pixel coordinates through reverse geocoding. Indicates according to user The authorized access layer set filters the layer information in the metadata, retaining only the authorized layers; Indicates according to user In layers Within the visible spatial range, crop out pixels of tiles that are outside the visible spatial range; Indicates according to user In layers The system uses a whitelist of readable attribute fields to filter out fields not included in the whitelist. The control logic is as follows: only when the request type matches and the parameter conditions belong to the user's authorized set is entry into the corresponding spatial or attribute control stage permitted, returning the data the user is authorized to request. In this embodiment, the proxy layer invokes the same permission context for all three types of requests, ensuring that layer visibility control, spatial visibility control, and attribute field control are continuously effective within the same request chain.

[0044] This embodiment has the following advantages:

[0045] 1. Non-intrusive architecture, low implementation cost, and strong compatibility: No modification to the internal implementation or configuration of geoservers (such as GeoServer and MapServer) is required. WMS requests are intercepted and processed through a lightweight middleware proxy layer to achieve access control. Completely transparent to the original service, existing WMS services are plug-and-play, significantly reducing system integration, deployment, and maintenance costs. The core request parameters of the OGC WMS protocol remain unchanged, ensuring full compatibility with mainstream clients such as OpenLayers, Leaflet, and QGIS. Users can seamlessly integrate without any code adjustments.

[0046] 2. Loosely coupled modules, combining scalability and elasticity: Functional modules such as request interception, authentication, permission caching, spatial analysis, and attribute filtering are decoupled from each other and communicate through standardized interfaces, supporting independent upgrades, replacements, or horizontal scaling. Computationally intensive operations can be deployed on dedicated nodes to achieve elastic scaling.

[0047] 3. Layered and hierarchical control with fine-grained security: A three-tiered collaborative control system ("layer-space-attribute") is implemented across the entire WMS chain: Layer access control: Personalized GetCapabilities metadata is dynamically generated based on user identity, hiding unauthorized layers; Spatial visibility: Pixel-level spatial masking is applied to raster tiles during the GetMap phase to ensure sensitive areas are invisible; Attribute readability: Response content is filtered by field whitelist during the GetFeatureInfo phase to prevent the leakage of sensitive attributes. All three share the same permission context, forming a closed-loop linkage mechanism that ensures geographic information security while supporting on-demand differentiated disclosure of public data.

[0048] 4. Overcoming the inherent limitations of MapProxy and GeoFence to achieve truly dynamic, universal, and end-to-end access control: Compared to MapProxy's static policy model, which cannot perceive user identity and does not support attribute filtering, this invention supports real-time user-level permission changes; compared to GeoFence's server-side binding mode (intrusive), which only applies to WFS and has a closed role system, this invention does not require modification of the geoserver kernel and is the first to implement a spatial mask for raster images in WMS GetMap; more importantly, neither of them can build a unified permission semantic covering GetCapabilities, GetMap, and GetFeatureInfo, while this invention, through a middleware proxy layer, achieves the first-ever collaborative linkage and context passing of the three, solving the fundamental problem that existing solutions cannot balance flexibility, security, and cross-platform compatibility.

[0049] 5. High-performance design, supporting high concurrency: By preloading user permission policies through distributed caching, the system avoids real-time calls to the authentication system or permission database for each request, significantly reducing request chain latency; combined with the stateless design of cacheKey, it supports horizontal scaling and can efficiently handle high-concurrency tile and feature query scenarios, ensuring stable and low-latency response of the system under large-scale access.

[0050] Example 2:

[0051] Combination Figure 2 The overall process shown in the GetCapabilities request processing example mainly includes stages such as identity resolution, cacheKey generation, permission context caching, capability document filtering, and access path rewriting.

[0052] 1. Identity Resolution and Cache Key Generation

[0053] In one implementation, after receiving a GetCapabilities request from the client, the proxy layer first extracts the user identity token or other trusted identity information from the request, verifies its signature and validity period, and parses it to obtain the trusted user's unique identifier. Then, a cache key is generated based on the user's unique identifier.

[0054]

[0055] in This represents a hash function. In one specific implementation, The MD5 algorithm can be used to output a fixed-length hexadecimal string; other one-way hash functions can also be used in other implementations. The choice of hash algorithm does not change the technical approach of this invention, which uses a cache key to carry the permission context.

[0056] 2. Permission context cache

[0057] In one implementation, the proxy layer checks whether the cache already exists in the cache system. The permission context for the key. If it does not exist, then according to the... Load the complete access control policy from the access control system. The access control policy includes at least: a set of accessible layers. Spatial viewport corresponding to each layer And the whitelist of attribute fields corresponding to each layer. After loading is complete, as described... Write the key to the cache system and set its time-to-live. If the business system detects a change in user permissions, it can proactively clear the corresponding cache through an external interface, causing subsequent requests to reload the new permission context.

[0058] 3. Original Capability Document Acquisition and Layer Filtering

[0059] In one implementation, the proxy layer forwards the GetCapabilities request to the backend WMS geoservice to obtain the original service capability document. Let the set of layers contained in the original service capability document be denoted as .

[0060]

[0061] The proxy layer traverses the layer nodes in the original service capability document, and identifies those that do not belong to... The layer nodes are deleted, retaining only the authorized layers. The corresponding set of retained layers can be represented as follows:

[0062]

[0063] in, This indicates the layer nodes that are retained in the proxy capability document after filtering.

[0064] 4. Service path rewriting

[0065] In one implementation, for each preserved layer Let its original access path in the backend WMS geoservice be... The proxy layer rewrites it to include the above. proxy access path

[0066]

[0067] For example:

[0068]

[0069] in, This represents the address of the layer after it has been proxied; The parentheses () function represents the operation of rewriting the layer request address; This explanation uses a traffic layer as an example. For instance, the request path for a traffic layer is: I inserted a cacheKey at the position of the last path to form a proxy request path.

[0070] The rewritten path is updated to middle.

[0071] For example, in one specific implementation, the rewritten path can be organized as a proxy address carrying the cacheKey, so that when the client initiates a subsequent GetMap request or GetFeatureInfo request based on the filtered capability document, it does not need to explicitly attach the user identity information again, but the cacheKey is automatically carried through the rewritten proxy path.

[0072] 5. Response Refactoring and Return

[0073] In one implementation, the proxy layer will complete the service capability documentation after layer filtering and access path rewriting. Reserialize to XML text, preserving the original XML's hierarchy and indentation structure during serialization, and then... The response is returned to the client. At this point, the client only sees the authorized layer and its corresponding proxy access path, while the backend WMS geoservice itself does not need to be aware of the filtering and path rewriting process. Thus, the continuous processing chain of cacheKey generation, capability document filtering, and path rewriting in the GetCapabilities phase is fully implemented.

[0074] Example 3:

[0075] like Figure 3 As shown, the GetMap request processing embodiment corresponds to the map rendering control chain in this invention, which includes permission context restoration, request parameter extraction, spatial relationship determination, and transparent return, pass-through, or clipping processing.

[0076] 1. Obtaining the permission context

[0077] In one implementation, the client initiates a GetMap request based on the filtered and rewritten capability document. The proxy layer first extracts the cacheKey from the request path; if the request path does not carry a cacheKey, it checks whether the request parameters contain an authentication token, and regenerates or restores the corresponding cacheKey after verifying the token. If the caching system does not have a permission context corresponding to the cacheKey, or if the permission context has expired, the proxy layer directly rejects the request; in one specific implementation, an unauthorized response, such as an HTTP 401 response, can be returned.

[0078] 2. Parameter Extraction and Spatial Visibility Modeling

[0079] In one implementation, the proxy layer extracts the bounding box parameters from the GetMap request. Information such as coordinate reference system parameters, image width, image height, requested layer identifier, and image format. For the currently requested layer... First, determine Is the condition met? If not, access is denied.

[0080] For the establishment In this case, the proxy layer reads the corresponding spatial visible area. If the visible space is composed of multiple polygons, it can be represented as follows:

[0081]

[0082] This means that the spatial visible field is composed of multiple closed two-dimensional geometric regions. It can be read as: equal arrive All The union of , where M represents the total number of all spatially visible areas that the user can see. Each of Each represents a closed two-dimensional geometric region. If the user has no spatial restrictions on this layer, then... .

[0083] 3. Determination of Spatial Topological Relationships

[0084] In one implementation, the proxy layer determines the request bounding box based on the request bounding box. With the current layer space visible area The intersection relationship is used to execute a three-branch processing logic: transparent return without intersection, full containment pass-through, and partial overlap pruning. Let...

[0085]

[0086] but:

[0087] If the requested scope does not intersect with the authorized visible space, the proxy layer directly returns a transparent map image with the same image format and size as the GetMap request image;

[0088]

[0089] If the requested area is completely within the authorized spatial visible area, the proxy layer will directly pass the original map image returned by the backend WMS geographic service to the client; otherwise, if the requested area only partially overlaps with the authorized spatial visible area, the proxy layer needs to perform spatial clipping processing.

[0090] 4. Object conversion and masking for branch trimming

[0091] In one implementation, for partially overlapping branches, the proxy layer first sends an initial GetMap request to the backend WMS geoservice to obtain the original image data stream. Subsequently, the raw image data stream is converted into an image object. And further converted into a raster object. After that, according to Construct clipping region ROI stands for Region of Interest, and it is used to perform clipping operations.

[0092] in, Represents the original raster object. This represents the cropped grid object.

[0093] In one implementation, the clipping region can also be represented using a binary mask, i.e.:

[0094] ,

[0095] The proxy layer retains only the image pixels corresponding to the authorized area based on the mask. This represents a mask image. In coordinates The pixel value at this location, here Represents spatial coordinates within raster data. Overall formula understanding: If the coordinates... If it is within the visible spatial range, it is considered valid and will be retained; otherwise, it is considered invalid and will be discarded.

[0096] 5. Output format processing

[0097] In one implementation, the cropped grid object Converted via rendering interface Then convert it for output. If the requested image format is PNG, a four-channel image including an alpha channel can be used; if the requested image format is JPEG, a three-channel image can be used. To match geographic coordinate orientation, in one specific implementation, orientation correction processing can be performed on the output image before serialization and return. Thus, the technical chain of image object or raster object conversion, mask cropping, and output according to the requested format is fully elaborated in this embodiment.

[0098] Example 4:

[0099] like Figure 4 As shown, the GetFeatureInfo request processing embodiment corresponds to the attribute query control chain in this invention, which includes permission context recovery, pixel rectangle conversion, spatial verification, and field whitelist filtering in sequence.

[0100] 1. Permission Context Restoration

[0101] In one implementation, the client initiates a GetFeatureInfo request based on the filtered proxy capability document. Similar to handling GetMap requests, the proxy layer first extracts the cacheKey from the request path; if not found, it checks the authentication token. Subsequently, it restores the corresponding permission context from the caching system and confirms the request layer. If the requested layer is not in the authorized layer set. If the condition is met, an empty property response or an error response will be returned directly.

[0102] 2. Conversion of pixel rectangles (Gpixels)

[0103] In one implementation, the proxy layer extracts the bounding box from the GetFeatureInfo request. Image width Image height Pixel coordinates And parameters such as coordinate reference system. The OGC WMS standard includes a BBOX request parameter, formatted as: "27.76234375,105.15046875000002,28.7178125,106.10593750000001". This is a comma-separated string, which, when broken down, can be represented as shown in the formula: Based on the geometric relationships of the image, first calculate the geographic resolution corresponding to each pixel.

[0104]

[0105] Then construct the geographic rectangle corresponding to the current pixel. For example, it can be represented as:

[0106] In the above conversion process, The orientation is flipped relative to the conventional geographic coordinate system, so it needs to be corrected by considering the orientation differences between the image coordinate system and the geographic coordinate system. In this way, the proxy layer does not use a single point as the basis for authorization, but rather uses the geographic rectangle covering the current pixel as the basis for judgment.

[0107] 3. Spatial verification and request forwarding

[0108] In one implementation, the proxy layer determines... ;

[0109] Check if the condition is met. If not, the current attribute query request is considered to be outside the authorized spatial range, and an empty attribute response or an error response is returned directly. If the condition is met, the original GetFeatureInfo request is forwarded to the backend WMS geographic service to receive the returned feature information response.

[0110] 4. Response format restrictions and field whitelist filtering

[0111] In one implementation, the proxy layer reads the GetFeatureInfo request... Parameters. If INFO_FORMAT is application / vnd.ogc.gml: Load using the XML parser. Iterate through all feature nodes, extract the field name and value of each attribute, and form an attribute set. ,in For field names, This corresponds to the value. If INFO_FORMAT is application / json: use a JSON parser to... Convert to an object structure, recursively extract the key-value pairs of all leaf nodes, and construct an attribute set. To facilitate structured field filtering, deep parsing can be performed only on the returned results in GML and JSON formats; if If a field does not belong to the set of structured formats, the proxy layer can directly return an error response or refuse to process it. For GML format, the proxy layer uses XML parsing to extract attribute nodes, removing fields that do not belong to the whitelist while preserving geometric information and namespaces. For attribute nodes, unauthorized attribute nodes are removed from the original XML document, while preserving geometric information and namespaces, generating a valid GML response; for JSON format, a new JSON object is constructed, with other attributes remaining consistent with the original data, and the field list containing only the specified attributes. The fields in the data maintain the original nested structure (if they exist). The proxy layer parses the returned object, extracts the attribute key-value pairs, and then...

[0112]

[0113] Retain authorized fields, delete or empty unauthorized fields, and preserve geometric objects, hierarchical relationships, and necessary metadata unrelated to authorized fields in the original response structure. Set the Content-Type header to match the original request, and write the reconstructed data into the response, returning it to the client. This further specifies the technical steps for pixel rectangle validation and field filtering. This mechanism ensures that sensitive attributes are not leaked due to unauthorized access, while maintaining compatibility with OGC WMS clients.

[0114] Example 5:

[0115] In one embodiment, the business system can pre-configure permission contexts corresponding to multiple users or roles. For example, for users... In other words, accessible layer collections This includes a transportation network layer and a public facilities layer. The transportation network layer can be set to be visible across the entire space, but the attribute fields are only allowed to return road names, road grades, and road numbers. The public facilities layer can be set to be visible only within a specified administrative region, and the source fields for sensitive facility coordinates are not returned. (For users...) In other words, accessible layer collections It may also include an emergency resource layer, but its spatial visibility is limited to the authorized operation area, and attribute fields are only allowed to return resource type, status, and number. When handling GetCapabilities requests initiated by different users, the proxy layer will act according to the respective... Returns different capability document contents; when processing GetMap requests, it will be based on their respective... Returns a fully transparent image, the original image, or a cropped image; when processing a GetFeatureInfo request, it will be determined according to the respective... It returns differentiated attribute results. Thus, the same backend WMS geoservice can provide differentiated layer, spatial, and attribute access results to different users without modifying the original service configuration.

[0116] Example 6:

[0117] like Figure 1 As shown, the present invention also provides a system embodiment corresponding to the aforementioned method. The system includes a request interception module, an identity parsing module, a permission context caching module, a capability document processing module, a map request processing module, and an attribute query processing module. The request interception module intercepts GetCapabilities, GetMap, and GetFeatureInfo requests sent by the client to the backend WMS geographic service. The identity parsing module parses the user's identity identifier and generates a cache key (cacheKey) upon receiving a GetCapabilities request. The permission context caching module establishes or retrieves a permission context based on the user's identity identifier and caches the permission context using the cacheKey as an index. The permission context includes at least an accessible layer set Lu, a spatial visibility Ru(l) corresponding to each layer, and a whitelist of attribute fields Fu(l). The capability document processing module forwards the GetCapabilities request to the backend WMS geographic service, retrieves the original service capability document, performs layer filtering on the original service capability document, retains only the layers in the accessible layer set Lu, and rewrites the service access path corresponding to the retained layers as a proxy path carrying the cacheKey. The map request processing module receives GetMap requests initiated based on the proxy path. When a request is made, the cacheKey is extracted from the proxy path to restore the corresponding permission context. It is determined whether the requested layer belongs to the accessible layer set Lu, and the spatial relationship between the requested range and the corresponding layer's spatial visibility Ru(l) is determined. If the requested range and the spatial visibility have no intersection, a transparent map image is returned. If the requested range is completely contained by the spatial visibility, the original map image returned by the backend is passed through. In other cases, the original map image returned by the backend is cropped according to the spatial visibility and then returned. The attribute query processing module is used to extract the cacheKey from the proxy path to restore the corresponding permission context when a GetFeatureInfo request is received based on the proxy path. It determines the geographic rectangle Gpixel according to the bounding box, image size, and pixel coordinates in the request. If the Gpixel intersects with the corresponding layer's spatial visibility Ru(l) and the requested layer belongs to the accessible layer set Lu, the GetFeatureInfo request is forwarded and the returned result is filtered according to the whitelist of attribute fields Fu(l) of the corresponding layer. Otherwise, an empty attribute response is returned.

[0118] Example 7:

[0119] The present invention also provides an embodiment of an electronic device. The electronic device includes a processor and a memory, the memory storing a computer program. When the processor executes the computer program, the electronic device performs the steps of the aforementioned WMS map hierarchical management method. The electronic device may be a server, an edge node device, or other computing device with network request processing capabilities.

[0120] Example 8:

[0121] The present invention also provides an embodiment of a computer-readable storage medium. The computer-readable storage medium stores a computer program, which, when executed by a processor, causes the processor to complete the steps of the aforementioned WMS map hierarchical management method. Using the aforementioned electronic device embodiment and storage medium embodiment, the aforementioned method flow can be deployed programmatically on different computing platforms.

Claims

1. A WMS map hierarchical management and control method, characterized in that, include: The system receives GetCapabilities requests between the client and the WMS geographic service, parses the user identity identifier, generates a corresponding cache key (cacheKey), and constructs or obtains a permission context based on the user identity identifier. The permission context includes at least an accessible layer set Lu, the spatial visibility Ru(l) corresponding to each layer, and a whitelist of attribute fields Fu(l). The GetCapabilities request is forwarded to the backend WMS geographic service to obtain the original service capability document. Layer filtering is performed on the original service capability document, retaining only the layers in the accessible layer set Lu, and rewriting the service access path corresponding to the retained layers as a proxy path carrying the cacheKey. The system receives GetMap requests or GetFeatureInfo requests initiated based on the proxy path, extracts the cacheKey from the proxy path, and restores the corresponding permission context based on the cacheKey. Upon receiving the GetMap request, the system determines whether the requested layer belongs to the accessible layer set Lu and compares the request range with the corresponding layer's spatial visibility Ru(l). The system determines the spatial relationship between the requested area and the spatial visible area. When the requested area does not intersect with the spatial visible area, a transparent map image is returned directly. When the requested area is completely contained within the spatial visible area, the original map image returned by the backend is passed through. In other cases, the original map image returned by the backend is cropped according to the spatial visible area and then returned. Upon receiving the GetFeatureInfo request, the system maps the pixel coordinates to a geographic rectangle Gpixel based on the bounding box, image size, and pixel coordinates in the request. If the Gpixel intersects with the corresponding layer's spatial visible area Ru(l) and the requested layer belongs to the accessible layer set Lu, the system forwards the GetFeatureInfo request and filters the returned result based on the corresponding layer's attribute field whitelist Fu(l). Otherwise, an empty attribute response is returned.

2. The WMS map hierarchical management method according to claim 1, characterized in that, The cacheKey is generated by a hash function from the user's identity identifier. The permission context is stored in the caching system with the cacheKey as the key, and a time-to-live or expiration update mechanism is set.

3. The WMS map hierarchical management method according to claim 1, characterized in that, When performing layer filtering on the original service capability document, layer nodes that do not belong to the accessible layer set Lu are deleted, and the access addresses of the retained layers are rewritten to proxy paths carrying the cacheKey.

4. The WMS map hierarchical management method according to claim 1, characterized in that, The proxy path contains both the cacheKey and the target layer identifier. Subsequent GetMap or GetFeatureInfo requests initiated based on the proxy path carry the cacheKey through the proxy path.

5. The WMS map hierarchical management method according to claim 1, characterized in that, If the requested range does not intersect with the spatial visible area, return a transparent map image with the same image format and image size as the GetMap request.

6. The WMS map hierarchical management method according to claim 1, characterized in that, When cropping the original map image returned by the backend, the original map image is converted into image data or raster data, a mask region is constructed based on the spatial visible area, and the image data or raster data is cropped based on the mask region. The cropping result is output according to the image format specified in the GetMap request.

7. The WMS map hierarchical management method according to claim 1, characterized in that, The step of mapping the pixel coordinates to a geographic rectangle Gpixel includes: determining the geographic resolution of the pixel in the x and y directions based on the geographic extent of the bounding box, the image width, and the image height; and determining the geographic rectangle Gpixel corresponding to the pixel unit of the pixel coordinates based on the pixel coordinates and the geographic resolution in the x and y directions.

8. A WMS map hierarchical management system, characterized in that, The system includes a request interception module, an identity resolution module, a permission context caching module, a capability document processing module, a map request processing module, and an attribute query processing module. The request interception module intercepts GetCapabilities, GetMap, and GetFeatureInfo requests sent by the client to the backend WMS geographic service. The identity resolution module parses the user's identity and generates a cache key (cacheKey) upon receiving a GetCapabilities request. The permission context caching module establishes or retrieves a permission context based on the user's identity and caches the permission context using the cacheKey as an index. The permission context includes at least a set of accessible layers (Lu), a spatial visibility area (Ru(l)) corresponding to each layer, and a whitelist of attribute fields (Fu(l)). The capability document processing module forwards the GetCapabilities request to the backend WMS geographic service, retrieves the original service capability document, performs layer filtering on the original service capability document, retains only the layers in the set of accessible layers (Lu), and rewrites the service access path corresponding to the retained layers as a proxy path carrying the cacheKey. The map request processing module receives GetMap requests initiated based on the proxy path. When a request is made, the cacheKey is extracted from the proxy path to restore the corresponding permission context. It is determined whether the requested layer belongs to the accessible layer set Lu, and the spatial relationship between the requested range and the corresponding layer's spatial visibility Ru(l) is determined. If the requested range and the spatial visibility have no intersection, a transparent map image is returned. If the requested range is completely contained by the spatial visibility, the original map image returned by the backend is passed through. In other cases, the original map image returned by the backend is cropped according to the spatial visibility and then returned. The attribute query processing module is used to extract the cacheKey from the proxy path to restore the corresponding permission context when a GetFeatureInfo request is received based on the proxy path. It determines the geographic rectangle Gpixel according to the bounding box, image size, and pixel coordinates in the request. If the Gpixel intersects with the corresponding layer's spatial visibility Ru(l) and the requested layer belongs to the accessible layer set Lu, the GetFeatureInfo request is forwarded and the returned result is filtered according to the whitelist of attribute fields Fu(l) of the corresponding layer. Otherwise, an empty attribute response is returned.

9. An electronic device, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program that, when executed by the processor, implements the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 7.

Images