Allow including hidden map layers to map links

[ernoma]

Currently, when I create a map link from the Oskari UI (Oskari v. 1.56) only the visible map layers will be included in the link even if I have opened map layers but hidden them. However, it would be useful to let user to choose whether to include the hidden maps to the link or not.

The maps that have 100% transparency are included in the link but it maybe a bit confusing.

[ernoma]

Also, if there is / would be a way to manually include hidden map layers to the URL that would be useful.

[jampukka]

Seems inconsistent to filter off temporarily hidden layers but allow 0% opacity layers to show up in links. Checkbox for "Include hidden map layers in the link" sounds like a good solution.

[ZakarFin]

I think the reason why hidden layers are not included in a link is the fact that hidden layers are used on extensively on embedded maps and they provide a link back to the geoportal. Embedded maps might have tens of layers selected on them that are switched between shown/hidden.

Embedded maps need to have all the layers as "selected" == "on map" but some or most layers can be hidden so they are not shown immediately at startup but can be switched on/off with the UI or using RPC API. This method is a bit clunky workaround for the fact that it's currently the only way to store which layers are presented as layer choices for the user on an embedded map.

I'm not sure if it's a problem to just add the hidden layers to the link but it's good to know that embedded maps use hidden layers to work around this fact. We could of course just remove hidden layers from the link back to geoportal as well. We have identified some problems with hidden layers not being linked when transitioning between a 2D and 3D geoportals for example.

To summarize, there's a reason for this and we might need to think a bit further than just blindly add the hidden layers on links.

[ZakarFin]

The layers are currently referenced in links with [id]+[opacity]+[style] so that is why transparent layers are included. We know that we always have at least the first two for links but I'm not sure if style is optional and if styles can have spaces in the name. I think we would at least need to separate an optional "hidden" status with another separator mark that is less likely to be part of a style name and make sure all existing links will work after the addition.

[ZakarFin]

Also whenever there's talk about adding more state information to the URL it's customary or almost mandatory to say that maybe we should add a tinyurl'ish functionality where we store the state/link information in the database and just provide an identifier for the link. So there's that to consider too :)

[ZakarFin]

Also, if there is / would be a way to manually include hidden map layers to the URL that would be useful.

Currently a workaround is to not hide the layer but set it to be transparent since opacity is stored in the URL. We have actually talked about having the "selected layers" show layers with 0% opacity as hidden. This would solve at least part of the problem, right? We should just store the "default opacity" on the frontend that has been set by the admin for the layer so we could set the opacity to that default value after the user clicks the "show layer". This would also fix the issue of setting opacity to 0 AND hiding the layer -> when the user clicks show layer the opacity stays at 0 and the layer is not visible to the user. Then the question becomes do we still need the "hidden" status for layers 🤔

[ernoma]

We have actually talked about having the "selected layers" show layers with 0% opacity as hidden. This would solve at least part of the problem, right?

I think that for the users 100% transparency often is pretty much equal to hidden, so I guess that showing "show"-link for the map layer in the UI that has 100% transparency would be good option too. I guess clicking that link could then change the layer transparency to 0%.

[rekjuh]

I tried to replicate the problem and got the same results with the latest Oskari version. @ernoma is this still a valid issue in your use case? Is this something that should be fixed in the upcoming Oskari releases? If so, could you open this issue on Oskari-documentation repo? https://github.com/oskariorg/oskari-documentation/issues

[ernoma]

@rekjuh Oskari used by City of Tampere still has the same functionality. I opened the issue in the Oskari-documentation repository: oskariorg/oskari-documentation#54

[rekjuh]

Thank you! 🙏 @ernoma

[ZakarFin]

Moved to oskariorg/oskari-documentation#54