Layer change feature for tour, sidecar and automated playbook

[srijitcoder]

@silvester-pari @lubojr @santilland I would like to discuss how I plan to implement the Layer change feature. I would appreciate your opinion on these implementation details.

My approach involves passing a 3D array containing a list of layers to be made visible by specifying their layer IDs. For example - , let's assume we have layers labeled as L1, L2, L3, L4, and L5 on our map layers. We will utilize a parameter called tourLayers to control these layers, structured as follows:

[tourLayers]:[["L1", "L2", "L3"], ["L2", "L3"], ["L4", "L5", "L6"]]

The Z-index of the layers will determine their stacking order, with the first element being the topmost and the last element being the bottommost.

Each set of arrays indicates layer control for a specific tour section. For instance, in the array ["L1", "L2", "L3"], the first tour section will have "L1" as the topmost layer and "L3" as the bottommost layer, while the rest of the layers, "L4" and "L5" will remain hidden.

I would appreciate hearing your thoughts on this implementation.

[silvester-pari]

Thanks for the proposal Srijit! My concern is that this way we would create an additional way of defining a map. We already have a way to define everything using a config object (layers and view), maybe we can just have this config change for each "step". Although I agree that the entire json is probably too large and complex to be repeated every step. Then, on the other hand, if the story creator does not need to type this by hand but it is generated automatically, it could be feasible.

[silvester-pari]

Just to add an example, instead of

<eox-map .layers=[{... L1 ...},{... L2 ...},{... L3 ...},{... L4 ...},{... L5 ...},{... L6 ...},]></eox-map>
[tourLayers]:[["L1", "L2", "L3"], ["L2", "L3"], ["L4", "L5", "L6"]]

something more like

[eoxMapTour]:[
{layers=[{... L1 ...},{... L2 ...},{... L3 ...}]},
{layers=[{... L2 ...},{... L3 ...}]},
{layers=[{... L4 ...},{... L5 ...},{... L6 ...}]}
]

this would also allow setting the entire config like

[eoxMapTour]:[
{
  layers=[{... L1 ...},{... L2 ...},{... L3 ...}],
  view: {
    center: [0, 0],
    zoom: 0
  }
},
{
  layers=[{... L2 ...},{... L3 ...}],
  view: {
    center: [15, 48],
    zoom: 7
  }
},
{
  layers=[{... L4 ...},{... L5 ...},{... L6 ...}],
  view: {
    center: [10, 20],
    zoom: 4
  }
}
]

This would re-use the current api for the eox-map. This would of course need to be generated and not written manually...

[silvester-pari]

On the other hand, this would lock us into only supporting eox-map, whereas with the suggested structure proposed by you we could also support other map modules theoretically...

[srijitcoder]

Interesting! That's a clever approach to create a different config for each tour. While this method certainly works, it's worth considering that users might need to deal with large JSON structures. Additionally, what happens when the same layers are used in multiple tours? In such cases, users would have to write redundant JSON layer code.

@silvester-pari, perhaps for our MVP, we can simplify control it using Arrays of layer IDs? We could explore the more complex approach mentioned by you when we have a more robust drag-and-drop feature in place and can provide users with form fields for input.

[santilland]

i was considering the option, if we assume we have all data within the stac catalog, that we could use stac identifiers, then we would need a wrapper that extracts the correct stac element (item/collection) based on the identifier and "generates" the configuration that is passed to the eox-map.

**edit: as the idea is to work tightly with the dashboard we could make use of indicator codes, these should in theory always correspond to a specific map configuration

[lubojr]

On the other hand, this would lock us into only supporting eox-map, whereas with the suggested structure proposed by you we could also support other map modules theoretically...

I think we can lock ourselves in into supporting EOX Map directly and only. I assume (expect) that there will be a requirement coming from this or that project in "nearby" future to also develop a 3D viewer for our EOx Map, so we could build a unified "EOX" API for example on top of a Cesium library in the same way we now did for OpenLayers which would mean it would be directly supported for usage in Storytelling component.

Interesting! That's a clever approach to create a different config for each tour. While this method certainly works, it's worth considering that users might need to deal with large JSON structures. Additionally, what happens when the same layers are used in multiple tours? In such cases, users would have to write redundant JSON layer code.

@silvester-pari, perhaps for our MVP, we can simplify control it using Arrays of layer IDs? We could explore the more complex approach mentioned by you when we have a more robust drag-and-drop feature in place and can provide users with form fields for input.

In the previous storytelling in eodash, we were able to preset and therefore control for example map time or different base layers than are defined normally for that indicator, but I agree that we should keep these functionalities outside of the scope of the MVP when we have curated form fields for input of predefined parameters of the map/layers rather than storytelling authors having to write the JSON config of the EOXMap config.