Opened 15 years ago

Closed 14 years ago

#2582 closed defect (fixed)

OWS GetCapabilities should skip layers with status == MS_DELETE

Reported by: dmorissette Owned by: aboudreault
Priority: normal Milestone: 5.4 release
Component: WMS Server Version: unspecified
Severity: normal Keywords:
Cc: mapserver@…, jmckenna, mko

Description

It has been reported that setting layers status to MS_DELETE has no effect with WMS/WFS/WCS/SOS GetCapabilities. We should skip layers with status MS_DELETE when producing GetCapabilities output so that MapScript can be used to hide some layers from the Capabilities.

Change History (12)

comment:1 by nhermann, 15 years ago

Cc: mapserver@… added

comment:2 by dmorissette, 14 years ago

Milestone: 5.2 release5.4 release
Owner: changed from mapserverbugs to dmorissette

comment:3 by dmorissette, 14 years ago

Owner: changed from dmorissette to aboudreault

Assigned to Alan to fix this for 5.4

comment:4 by aboudreault, 14 years ago

Committed in SVN trunk in r8575.

The layers with status == MS_DELETE are now skipped for GetCapabilities. Is it a problem if the ows services can still serve other requests for these layers: like GetFeature, DescribeFeature etc... Should we apply a fix for all requests ?

comment:5 by jmckenna, 14 years ago

Cc: jmckenna added

ticket:337 already exists, so i think the bigger problem of ignoring all OWS requests for a layer should be handled there (unfortunately this ticket:2582 was only opened for the mapscript issue).

comment:6 by mko, 14 years ago

Cc: mko added

in reply to:  5 comment:7 by mko, 14 years ago

I did add a patch to #1952 for mapserv-5.4.0.beta1 which adds a feature to hide specific layers from the getCapabilities dump by using a new ows_hidden_layer matadata in the mapfile.

In my understanding #337 requests a way to prevent a layer to be served by a special ows at all while #1952 and #2582 request to hide a layer.

comment:8 by aboudreault, 14 years ago

mko, badly i didn't see you patch before i begin this one. My patch will do the the same thing, but for all ows services, and for all requests. (getmap, getfeatureinfo getlegendgraphic, etc..) I've also used "[service]_dump" metadata instead of *_ignore, or hidden.

in reply to:  8 comment:9 by mko, 14 years ago

The intention of #1952 (and #2582 !?) was to hide a layer only for capabilities requests. E.g. in order to hide grouped layers with different resolutions which shall be used only by the group name. So getmap requests (e.g. using the group name) shall definitely work even if a layer is hidden. I think your work will prevent the layer to be served at all?!

comment:10 by aboudreault, 14 years ago

Yes, the intention was to hide the layer for capabilities requests. [service]_dump will tell MapServer that the layer is not allowed to be served for all [service] request. Why only hide a layer of getcapabilities requests and allow a getfeatureinfo on it?

in reply to:  10 comment:11 by mko, 14 years ago

There are probably different understandings of dumping, hiding and ignoring. That's why we have some different tickets for more or less the same issue. One might want to disable all requests for a service, another only supporting getmap requests (see the example of grouped layers). Who knows what comes next.

In order to solve these issues we should harmonise the tickets. Do you think a metadata likewise [service]_disable_request 'getcapabilities getfeatureinfo' will solve all related tickets?

comment:12 by dmorissette, 14 years ago

Resolution: fixed
Status: newclosed

Closing this ticket as fixed. The original issue was hiding of layers with status = MS_DELETE for MapScript use and that was done in r8575 (see comment:4). With respect to handling MS_DELETE in other request types, since setting "STATUS DELETE" in a mapfile is not accepted by the parser, this is a non-issue for the mapserv CGI and there is little/no value in doing this for MapScript.

The rest of the discussions are interesting but off-topic for this ticket. We'll try to come up with a RFC to solve those other use cases and that will be discussed on the mapserver-dev list.

Note: See TracTickets for help on using tickets.