Easy style switch for datasets

[gannebamm]

Is your feature request related to a problem? Please describe. I'm always frustrated using multiple styles in the current map for a dataset. As an editor, I have to click multiple controls to be able to switch the style of a layer:

And after I switched the style I have to close everything again to see the legend. The legend itself is not displayed fully and the SLD title and abstract is not shown.

As an anonymous viewer, I am not able to do so since the layer properties tools are not shown in map_view for TOC.

Describe the solution you'd like

Provide a layer style switch dropdown. A working example is part of terria.io map and looks like this:

The dropdown is filled with associated styles and the legend will get fetched automatically after you pick your new style. The timeline tool is properly defined for the layer itself.

Describe alternatives you've considered

Currently, there are two options to mitigate that user-experience issue:

1. Using the preview (layer detail view)
2. Using a map with multiple layers

Both have downsides.

1. Using the preview (layer detail view) In the layers detail view (not the map view) I am able to switch style with radio buttons:

1. default

2. switch

3. reflected changes

But in that template the map view is small and the focus lies on the metadata of the dataset.

2. Using a map with multiple layers

You can create a map with multiple layers for the same dataset like this:

But since the TOC is closed by default and the legends of each layer is not displayed as default you as a viewer still have to click multiple times to switch layer styles.

Furthermore, the map logic in terms of widget configuration will be shaky since a widget is always bound to a layer. With multiple layers using the same dataset (but displaying it differently) there will be errors like #8564

Additional context The Thünen-Institute will provide funding for this feature request. We want to discuss possible solutions with the community and upstream our solution.

[gannebamm]

There already was a discussion about this in the mapstore dev group: https://groups.google.com/g/mapstore-developers/c/-ZIXCcQ8K7E https://groups.google.com/g/mapstore-developers/c/19trkb0IlN4

Both contain ideas on improving the experience

[giohappy]

@gannebamm to me the problematic management of styles is rooted in the not clear separation of layer (dataset in master branch) previews and proper maps. Of course we also have the additional complexity of having multiple ways of selecting / setting default styles for layers, styles for a layer in a map, etc.

Your description applies mainly to the 3.3.x branch, since on master the following functionality has been removed:

• multiple styles for a dataset. Now a dataset preview is just a preview, and only one default style is available for it (which can still be edited)
• having a single default style any related management tool has been removed
• when a dataset is used as a map layer, you can create additional styles for it. A map becomes the central model to customize the appearance of a dataset

This requires limiting what can be done on a dataset from the point of view of visualizazion, since a dataset should be considered just a building block. On this side more work is probably needed to enforce and clarify the separation and the connection between maps and datasets.

We're already working on making style selection more straightforwars (and seprate it from the styled editing tools). On the current master you will see that now a style selection is available under the layer settings panel (which has been changed from a tab to a single panel view). Not perfect yet, and probably still too buried, but it's a first move in that direction.

If you're willing to improve this on 3.3.x I don't know how much we will be able to support it, but any discussion is welcome. We want to make furhter steps on master branch to make the UX better and simpler.

[gannebamm]

To provide a link to the geonode-mapstore-client issue: https://github.com/GeoNode/geonode-mapstore-client/issues/575 And a link to a map in GeoNode master: https://master.demo.geonode.org/catalogue/#/map/610

We want to switch to v4 ASAP so we do not need to have this developed for v3.3.x at all. The semantic change from 'layer' to dataset in v4 is good and double down on that concept in the way described by you @giohappy. Datasets should have a default style and nothing more. Additional styles should be provided as part of a map, which will provide render options (=styles) for the dataset. The dataset will show the map anyway (or has that behaviour changed?).

Nonetheless, the current master implementation needs still to many clicks to switch styles. As said the terria.io implementation does work very well in our tests.

[t-book]

@giohappy In addition. The abbility to download a style by one click has been removed was well, right?

[MarkusKonk]

fyi: We will work on this issue in cooperation with @gannebamm.

[gannebamm]

We have put this development on hold for the moment. We still need to figure out how this works well in terms of usability and interoperability.

This is a common example of complex scientific data: https://atlas.thuenen.de/layers/geonode_data_ingest:geonode:emissionen_lawi_1990_2021_luftschadstoffe

As you can see, this dataset uses lots of styles.

The v4 approach would be to create one map with eight layers. These eight layers would have their SLDs. The current vanilla geonode v4 will make it hard to navigate the eight layers since you need to switch them on/off manually. Thünen-Institute has developed a mapstore client feature with mutually exclusive layers (see https://github.com/GeoNode/geonode-mapstore-client/issues/1265). With this feature, we can show those eight styled layers in a good way in terms of usability.

But this will not relate those SLDs properly with the dataset, right? Our portal will be harvested by, e.g. GeoNetwork or other catalogue instances and should behave appropriately. Without the direct connection from SLD to the dataset, those will not show up on their side, AFAIK. This is an issue.

We currently do not have a definitive answer on how to solve this issue. We will work further on this later this year.

[giohappy]

@gannebamm I agree that things must be improved on this side. One thing we were considering was extending the style management for a map layer to support multiple styles. At the moment a map layer can have only one custom style, but this is only an implementation limit, not a technical one. This would pave the road to a quick style switch/selector for the single layer.

The client uses the extra_params JSON field from the MapLayer model to store the (optional) custom style. If empty the default style for the dataset is used. This field was already modeled to store an array of styles (see image below), although at the moment only one custom style can be set. This information gives us a link from the Dataset to the styles associated with it inside maps: Dataset 1->N MapLayer -> extra_params -> styles. This information could be exposed to harvesters the way we prefer.

We don't have plans to implement this multi-style and style selector feature soon, but we're available to discuss it.