Opened 19 years ago

Closed 15 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 dmorissette)

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 tomkralidis, 16 years ago

Cc: mapserverbugs assefa dmorissette bartvde added
Milestone: 5.4 release
Owner: changed from mapserverbugs to tomkralidis
Version: unspecifiedsvn-trunk (development)

I'll take this one. Basic approach:

  • if sld_enabled == 0
    • GetCapabilities: do not advertise
    • GetMap: return exception "SLD is not enabled on this WMS"
    • GetFeatureInfo: return exception "SLD is not enabled on this WMS"

Comments?

comment:2 by tomkralidis, 15 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 assefa, 15 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)
  • 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 dmorissette, 15 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 assefa, 15 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:6 by dmorissette, 15 years ago

worksforme

comment:7 by tomkralidis, 15 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:8 by assefa, 15 years ago

Tom, option2 should be enough I think.

comment:9 by tomkralidis, 15 years ago

Milestone: 5.4 release6.0 release

Pushing to 6.0

comment:10 by tomkralidis, 15 years ago

Cc: jmckenna added

Implemented:

comment:11 by tomkralidis, 15 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.