Part 2:
On Fri, Jul 14, 2017 at 9:37 AM, Andrea Aime <[email protected]>
wrote:
> Ah, forgot one more concern, which is related to workspace specific
> services.
> I setup an example group on a demo server for you to look at, it's a globa
> one called test,
> referring two layers in different workspaces:
>
> [image: Inline image 1]
>
>
> Nowadays the usage of test is allowed from both global and workspace
> specific services, and the
> catalog will automatically shave off the layers that are not part of the
> current workspace
> transparently, please see and compare:
>
> http://demo.geo-solutions.it/geoserver/wms?service=WMS&;
> version=1.1.0&request=GetMap&layers=test&styles=&bbox=-180.
> 0,-90.0,180.0,90.0&width=768&height=384&srs=EPSG:4326&
> format=application/openlayers
> http://demo.geo-solutions.it/geoserver/geosolutions/wms?
> service=WMS&version=1.1.0&request=GetMap&layers=test&
> styles=&bbox=-180.0,-90.0,180.0,90.0&width=768&height=384&
> srs=EPSG:4326&format=application/openlayers
> http://demo.geo-solutions.it/geoserver/topp/wms?service=
> WMS&version=1.1.0&request=GetMap&layers=test&styles=&
> bbox=-180.0,-90.0,180.0,90.0&width=768&height=384&srs=EPSG:
> 4326&format=application/openlayers
>
> What happens when style groups enter the picture? Is the catalog going to
> alter the style
> on the fly to remove references to layers that are not visible in the
> current workspace?
>
> Good question. My first response would be what do we do currently if you
use an external SLD via the WMS SLD parameter while making a WMS request
from a workspace specific service.
After trying it out, it handles it as if the layer doesn't exist, and fails
with org.geoserver.platform.ServiceException: Unknown layer: poi.
This is a bit more brittle than I would like, but it does at least seem to
respect security and virtual service restrictions. It may be better to
change this behaviour to simply exclude layers that can't be found (and log
a warning), although this might be something that can be controlled by an
additional parameter, so that we can still treat missing layers in a more
strict fashion.
For the StyleGroup, I would expect it would trim out any layers when
parsing the SLD. The current code for handling the SLD parameter (In
GetMapKVPRequestReader / GetMapXMLRequestReader) already splits each
NamedLayer within the SLD into separate MapLayer and Style objects, so I
expect it would be possible to trim out any layers that would be hidden to
to workspace-specific services or security rules at this point.
And the same should happen with security, if a layer is not visible and
> referenced by a group today, the
> layer is removed transparently from the group as it gets out of the
> catalog, I assume the same would
> have to happen for nested style groups, right?
>
> I'm also wondering, is nesting style groups in standard groups a
> requirement for you, or just a way to
> make style groups viewable without making them catalog first class objects?
>
> If it's the latter, wouldn't it be simpler to extend the current GetMap
> protocol with a new parameter that
> would mimick SLD and SLD_BODY, but so that you can refer to an internal
> style known by GeoServer?
> Hell, wouldn't it be even simpler to allow SLD to take either a URL, or a
> style name, and be done with it [1]? :-)
>
> It mostly the latter, although it would still be useful to be able to
refer to regular layers and StyleGroups in the same WMS, such as if you had
a style group that defines a basemap, and wanted to show some additional
layers on top of it.
It is actually already possible to pass a URL into the SLD parameter, and
you can use a GeoServer-internal style this way via the styles endpoint
(localhost:8080/geoserver/styles/stylename.sld). Adding the ability to
refer to an internal style by name / relative URL would be a simple
improvement, and a potential alternative.
> If you need to mix it with other layers, how about allowing an empty layer
> name in the layer list,
> and if that happens then take the style name a group?
>
> You mentioned this in your earlier mail, and I think that would be a
perfectly workable alternative to an actual StyleGroup object.
> Just thinking out loud here! :-)
>
> Cheers
> Andrea
>
> [1] Well, almost be done, even using a style like this would incur in
> security and more in general
> catalog filtering related issues.
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
