SITMUN Base layer concept not being itself

[RicardCots]

Describe the bug
In SITMUN 2 a base map can be made up of one or more layers. In SITMUN 3, if a background map is configured with several layers, the viewer interprets it as different background maps instead of joining the different layers that form it into a single one.

Let us explain it with an example: If we want to define a background map formed by a WMTS orthophoto layer and a toponym layer on top of it, this can be done in SITMUN 2 but not in SITMUN 3. The SITMUN 3 viewer will interpret each layer (the ortophoto and the toponym) defined as part of the same a background map as a separate background map.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'Capes de fons' in the SITMUN admin.
2. Configure a Base layer composed of diferents layers
3. Assign it to a viewer and see how the viewer interprets it.

Expected behavior
Every 'Capa de fons' (background map) defined and assigned to a SITMUN aplication is listed in the 'Capes de fons' Div in the SITMUN viewer.

If a background map is made up of multiple layers, the viewer displays a single background map which will be the sum of the different layers.
IMPORTANT: The name displayed in the viewer for a 'Mapa de Fons' has to be the one configured in the Mapes de fons form, not the name of the layers.

Screenshots

[fjlopez]

I think that this is a "feature" of API SITNA. @silmeUsil0001 , can you confirm this?

[RicardCots]

This issue implies a reevaluation of the background concept in SITMUN... we should discuss it.

[fjlopez]

Scenarios

If we maintain the background concept in SITMUN as a set of multiple layers, there are three main scenarios to consider:

1. Background with a single layer (as is): This is the simplest scenario and requires no changes. The viewer should display the first available background layer for the territory or user as is. Alternatively, an external WMS cascading service could also manage this process if needed.
2. Background with multiple layers from the same service (flattened): This can be efficiently handled by either the viewer or backend by combining multiple layers into a single request. However, advanced features (e.g., controlling layer opacity individually) may only be supported if handled by a proxy.
3. Background with multiple layers from different services (proxy handling): This is the most complex scenario. The proxy would need to fetch layers from different services, merge them, and generate the final composite image. This could result in performance degradation due to the additional overhead of handling multiple services simultaneously. To the best of my knowledge, no established WMS cascading service currently exists that can automate this process across multiple services.

Review

• Option 1: Straightforward and easy to implement. Minimal adjustments are necessary.
• Option 2: Feasible, but advanced features such as opacity control may require proxy involvement. Implementing these features through the viewer or backend is possible but with limited functionality. Full functionality requires proxy handling, which adds complexity.
• Option 3: Merging layers from different services presents significant challenges, as it requires custom proxy development. This approach lacks a direct, out-of-the-box solution and would require substantial custom work, making it the most challenging option.