Proposal: Removing support for "collection" layers

[ZakarFin]

The currently available admin-tools don't support layers that are of type collection in oskari_maplayer (in database) and of type group/base in frontend. It's not a widely used feature that allows using multiple WMS-layers for OpenLayers while showing them as a single maplayer from end-user perspective (in layer listing etc).

Proposal: As the feature isn't widely used and not supported by current layer admin tools we are planning on removing support for them from the database. This would mean removal of parentid and base_map columns from oskari_maplayer table in the database and migrating all current layers accordingly by mapping name, permissions etc from the "parent" layer to these sublayers (and making the sublayers "normal" layers). Also refactoring some frontend code regarding the group/base handling.

[jampukka]

The functionality does sound nice but I guess most Oskari users also control large part of the WMS layers available in their Oskari installations and as such can create the necessary layer groups at the WMS-level. WMS-level layer groups also reduce the amount of network calls massively. Admittedly they aren't as flexible as collection layers at Oskari-level.

However, if admin-tools do not support them (and haven't for some time now) and there are no plans for adding support for them again then I'd say these are pretty safe to remove. If someone is actually using collection layers they surely haven't updated their installation in a while.

Something for PSC to decide whether dropping the support for these altogether in a future release is ok?

[ZakarFin]

Something for PSC to decide whether dropping the support for these altogether in a future release is ok?

Yes, while the collection layers are nice they have a couple of issues:

• they are not currently supported by the new admin functionality/they can't be managed with an UI.
• from the beginning it has only been supported for WMS-layers which should be clearly stated if we want to keep these (and we should have some admin UI for them. Otherwise it just complicates the frontend code if we keep the current code that no-one is actually able to use)
• would be nice to have non-WMS supported, but for vector layers it quickly becomes tricky to handle the object data table and probably editing functionalities would require work as well

At some point it has been discussed that a similar "collection layer" concept could be used for end-user and there could be several services of different types linked to that layer. The main selling point of this would be having a single layer for end user, but when used on the map the user could get raster for the map from WMS/WMTS and at the same time the object data from WFS. And the client-code could then switch between the sources for that layer depending on what functionalities are used with it. But that isn't a trivial thing to implement either.

[jampukka]

So something like, for zoom level (or resolution)

• 1-9 use a wmts layer
• 10-13 use another wmts layer
• 14-> use vector features

or something even more complex?

That indeed would be nice, but certainly would require some work.

[ZakarFin]

Yes or not even tied to zoom-levels, but just getting the raster for map IF the user isn't using custom styling (WFS if the layer has custom style if we want to allow that) and still getting the object/feature data table from corresponding WFS source. Instead of listing both WMS and WFS as layers for end users like this:

[ZakarFin]

The zoom level case is valid also though and that's basically what the collection layers was previously used for. Might be nightmarish trying to do an UI to manage all of this though AND making it work properly for end users :D