Opened 19 years ago
Closed 16 years ago
#1395 closed defect (fixed)
[WMS Server] enable metadata to turn off SLD functionality
Reported by: | tomkralidis | Owned by: | tomkralidis |
---|---|---|---|
Priority: | high | Milestone: | 6.0 release |
Component: | WMS Server | Version: | svn-trunk (development) |
Severity: | normal | Keywords: | |
Cc: | mapserverbugs, assefa, dmorissette, bartvde, jmckenna |
Description (last modified by )
For WMS Server, I have had numerous requests/desires from stakeholders to have SLD functionality turned OFF. This is because some activities do not want their maps restyled by an arbitrary user SLD for whatever reason (lying with maps). I think this is a valid issue. I think an "sld_enabled" directive in the WEB/METADATA object would do the trick: "sld_enabled" "0" OR "sld_enabled" "1" If 1, then SLD is enabled. If 0, then SLD is turned off. If not specified in mapfile, then SLD is enabled.
Change History (11)
comment:1 by , 16 years ago
Cc: | added |
---|---|
Milestone: | → 5.4 release |
Owner: | changed from | to
Version: | unspecified → svn-trunk (development) |
comment:2 by , 16 years ago
Any comments on the approach suggested? i.e. should the value be 0|1 or true|false
Default would be SLD-enabled.
The code would check for sld_enabled being "0" to turn off SLD in GetCapabilities.
For GetMap and GetFeatureInfo, should we return exception, or return as usual, with the change that the response would be as if SLD was not applied in the request?
Please advise.
comment:3 by , 16 years ago
maps don't lie :)
It is I think a valid request. I had the same request from some one few months back where he wanted to have some layers flagged as not supporting the SLD. I think I left code inside mapogcsl.c (inside #ifdef (SLD_NOT_SUPPORTED) to show him how it would be done).
Couple of comments:
- I like the approach of setting with the map level metadata (preference is true/false)
- I think you have also to report an error with the GetLegendGraphic
- Would this affect at all the GetStyle call (returning an SLD)?
- Would it make sense to have this metadata also available at the layer levels?
comment:4 by , 16 years ago
Description: | modified (diff) |
---|
I agree with adding this, at least at the map level. Not sure if it's worth the overhead to add it at the layer level as well... your call.
I think that should disable GetStyle as well... not sure about disabling GetLegendGraphic since this one is also useful to build a legend even in non-SLD contexts.
comment:5 by , 16 years ago
One comment I forgot to make:
- I think ignoring the SLD parameter would be the appropriate behavior if it is not enabled. I don't think the spec says to return an exception in this case, does it?
for GetLegendGraphic, I meant ignoring the SLD or SLD_BODY parameter is passed (or return an expetion of that is waht is decided for the other wms operations)
comment:7 by , 16 years ago
More observations / thoughts:
WMS 1.1.1 (01-068r3) specifies the following requests as SLD WMS only:
- section 7.4 DescribeLayer
- section 7.5 GetLegendGraphic
- section 7.6 GetStyles
- section 7.7 PutStyles (not supported by MapServer)
I interpret this as follows: if SLD is disabled, then these requests are not supported, and the SLD or SLD_BODY are ignored per comment:5
So then the question is what do we really want here:
- to disable SLD, obeying the WMS spec
- to disable applying SLD and SLD_BODY in WMS requests (thus also not advertising SLD in Capabilities XML). This is more lax, but meets the requirements of those who made the original request to me (i.e. they don't really care about following the spec to the max, just turn off remote styling)
- to allow for both types of disabling (getting way to complicated)
Wonder what folks think here. I think option 2 would be sufficient. In any case, this won't be enabled unless explicitly set in the mapfile, so current functionality would not be affected.
comment:10 by , 16 years ago
Cc: | added |
---|
comment:11 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I'll take this one. Basic approach:
Comments?