Thanx for your extended reply Andrea, introducing an optional layergroup to
replace the rootlayer seemed a feasible low impact change to fix 2 issues. But
sure if you have better suggestion to improve it, happy to follow that. My
issues: There is no option to set the title of the root layer (although a field
can be added for that property quite easily at the place where authority url’s
for the root layer are defined; at wms-service-properties). The other issue is
the layer ordering in the root layer. Sure, we can add it as a numeric value on
the layer-properties. Indeed maybe the impact of these changes would be lower
then my suggestion.
I added some comments to your comments inline
>
> It interacts with the advertised flag, adding two ways not to advertise a
> flag or a group (unchecking, or just not adding the layer to the group).
> However, the interaction is WMS specific, as the layer would still show up in
> the other protocols (wfs/wcs/csw)
You probably reply to my suggestion not to add layers to the capabilities if
they are not part of any group. Sure, better approach is to add them to the
root layer anyways, if they are not added to any layer
> It interacts with workspaces somehow, in that the root group would have to be
> global for global services, but would have to be ws specific for ws specific
> services
My suggestion would be to only allow root layer as part of a virtual
(workspace) service
> I don't think it's going to play well with installations with many layers,
> the UI for groups is not exactly designed to handle many nested layers
I agree on the limitations of the current UI related to multiple nesting. In
general though grouping layers in nested groups actually works out very well
for installations with many many layers :-)
> It makes publishing a layer a two steps process, first create the layer, the
> lookup the root group and add it there (or a 3 steps process if workspace
> specific services are in the picture, add it also to the workspace specific
> root)
Yes, setting up layers in a layertree (and later updating it) really is a
challenge, would be good to look at that aspect in a next iteration. Mind that
in my proposal if people don’t define a root layer, the current root layer
behaviour will be untouched.
> Sorting the layers "elsewhere" may be a better option, just add a numeric
> field to both layers and groups and then sort on it instead of sorting on
> name? Just thinking out loud here :-)
> And it would also allow to have consistent sorting across services.
Yes this is a valid argument, my sorting would not be available in other
services
>
> Adding a layer sorting UI that scales up to large installations can be tricky
> in this case too. I'd venture to say that people caring for layer order have
> relatively few layers (something like 100 but not 10000), but the UI for
> controlling the ordering should scale anyways. And maybe have some REST API
> equivalent too.
>
I agree, 100-ish layer per (virtual) service is my use case
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
