[WMS] Need a way to prevent layers from being served via WMS

[dmorissette]

Jean-Francois.Doyon@ccrs.nrcan.gc.ca wrote:
> 
> Yup, that is correct, right now, you can't hide a WMS layer in a given
> mapfile, from showing up in GetCapabilities ... Weren't you paying attention
> in our workshop debbie ? :)
> 
> I haven't checked, but I'd encourage you to file a feature enhancement into
> the MapServer bugzilla about this if there isn't one already ... I could use
> that feature too :)
> 
> Cheers,
> J.F.
> 
> -----Original Message-----
> From: Lowell Filak [mailto:lfilak@medinaco.org]
> Sent: Wednesday, June 11, 2003 4:17 PM
> To: Debbie Pagurek; mapserver-users@lists.gis.umn.edu
> Subject: Re: [Mapserver-users] preventing certain layers from appearing
> in thegetCapabilities doc?
> 
> If I recall a discussion from the User Meeting correctly, you will need to
> use a different Mapfile to do that.
> HTH
> Lowell F.
> 
> The following message was sent by "Debbie Pagurek" <pagurekd@agr.gc.ca> on
> Wed, 11 Jun 2003 13:49:05 -0400.
> 
> > Hi all,
> > I have a mapfile that I am using for an web mapping interface, as well as
> doubling as a WMS server.  There are layers used in the interface that I
> don't want appearing in the getCapabilities document though and I thought I
> could prevent them from appearing there by omitting the METADATA tags for
> those layers, but that is not the case.  Is there a way to select which
> layers in a mapfile should appear in a GetCapabilities document?
> >
> > Thanks,
> > Debbie
> >

[dmorissette]

Actually, during (and after) the OGC workshop at the MUM we talked about
using the 'DUMP FALSE' flag to explicitly request specific layers to not
be served via WMS with the default being to include all layers in WMS if
the DUMP value is not set.  

However when I came to implement that yesterday I realized that this
wouldn't work because the default value for DUMP is FALSE... so there is
no way at the moment for MapServer to differenciate between a layer in
which DUMP is explicitly set to FALSE or another one in which it is
simply not specified.  And we cannot change the default to TRUE because
that would make all layers available via WFS by default and we don't
want that.

There are a few options that I can think of, but none of them is very clean:

1- Bring WMS in line with WFS, and do not serve any layer in WMS by default 
unless DUMP=TRUE is set.  This would break backwards compatibility with 3.6 WMS 
mapfiles and would not allow having layers that are served via WMS but not via 
WFS, or vice-versa.

2- Initialize DUMP=MS_DEFAULT internally by default meaning that the value was 
not set.  Then, layers would not be served via WFS unless DUMP=TRUE was 
explicitly set, and layers would be served via WMS unless DUMP=FALSE was 
explicitly set.  This solution maintains backwards compatibility with 3.6 but 
still doesn't allow enabling a layer only for WMS or only for WFS.

3- Turn the DUMP flag into a value that can be OR'ed, and then you explicitly 
list the protocols for which the layer should be enabled, e.g.
    DUMP WFS
    DUMP WMS|WFS 
    DUMP TRUE     # This layer available via all interfaces
    DUMP FALSE    # This layer not available via any interface

I think the third option would need some more thinking and may have to be 
renamed from DUMP to something else more significant...

Any thoughts, better ideas?

[jdoyon@…]

Well, one simple option that comes to mind is to add another keyword that has
the same functionality as "DUMP", but for WMS instead of WFS ...

Honestly in order to keep backwards compatibility of the DUMP parameter, I don't
see how we could use it to accomplish this ... Someone out there may already
have a mapfile with DUMP not set used for WMS ... if we use it to specifically
enable WMS layers, we break their apps.  One option would be to specifically
disable WMS layers from being served over WMS, and keeping the default as it is,
though as Daniel pointed out, we'd still need a seperate keyword to do that.

Also, this becomes opposite logic to the WFS (disabled by default, specifically
enable).  Honestly I think WMS should behave exactly the same way ... Even at
the risk of breaking backwards compatibility ... The sooner that owuld get done,
the less headaches it creates for people ... If one lets this go on, I'm
guessing we could expect a lot of e-mails on the list about this and why they
work in opposite ways ... (Much like the STATUS ON issue for instance!)

Cheers,
J.F.

[jdoyon@…]

I agree with option 1 in principle, but also with 3 ... So they should behave
the same way, but they shouldn't be tied (One has to be able to enable/disable
these services independently)

And yes DUMP might be renamed ... how about "SERVICES" ?

Such a change, as I'm sure you know, should be done for 4.0 stable ... don't
want to break backwards compatibility on a minor revision (4.1?) ...

Thanks,
J.F.

[sdlime]

Funny, I sent a pptential solution to this awhile back but never heard from
anyone, and it's not part of the bug. I'll check though my messages tomorrow and
repost to Bugzilla. It basically dumped DUMP but allowed differentiation between
WMS with and without GML export. Dan, I'm assuming this is one of the larger
bugs to be fixed pre-4.0.

Steve

[dmorissette]

Bug 300 is indirectly related to this.  In bug 300 comment 5, Steve wrote:

----------8<--------
It's not that critical and we could plan for a 4.1 release in the fall. With 
the MapText support comming I think that will be a necessity. I go back and 
forth on the implementation anyway. Me thinks it can be as simple as SERVICES 
WMS|WFS|NONE where:

  - WFS is essentially the same as DUMP TRUE
  - WMS is essentially the same as DUMP FALSE
  - NONE turns it all off

The only drawback to this is that you get geometry by default with WFS and I 
don't know if that's ok. Seems to me that if it's a feature service then you 
should get the features. As a workaround we could support WMSGML and WFSGML.
---------->8--------

BTW, I'll mark this as a version 4.1 issue as Steve suggested, timing is not 
good to do this for 4.0

[dmorissette]

Not in 4.4 for sure. Settign FUTURE milestone.

[pramsey]

Feature freeze means this feature is moved to 5.4

[jmckenna]

I think this needs to be solved once and for all, for the 5.4 release, for all OWS services (WMS/WFS/WCS/SOS). (ticket:2582 was just fixed, but that only handles the mapscript case)

I've read this ticket discussion, and I am wondering why the possibility of a new layer metadata, such as boolean "ignore_layer" (which would default to false) has not been discussed.

[dmorissette]

The page wiki:HidingLayersInOGCWebServices has been created to collect use cases and try to come up with a solution for this ticket and a few related ones.

[aboudreault]

A solution has been implemented, see #3703.