Extend JSONform in LayerControl to allow "combining parameters" into one with a configurable separator

[lubojr]

We would need to support following custom case of URL replacement in LayerControl via JSON Forms.

Following URL has style parameter composed of individual optional variables, for which we would like to change values via UI elements and they are separated by , character.

https://wmts.marine.copernicus.eu/teroWmts?service=WMTS&version=1.0.0&request=GetTile&tilematrixset=EPSG%3A3857%403x&tilematrix=0&tilerow=0&tilecol=0&layer=GLOBAL_ANALYSISFORECAST_PHY_001_024%2Fcmems_mod_glo_phy-thetao_anfc_0.083deg_PT6H-i_202211%2Fthetao&style=range:-1/10,noClamp,cmap:inferno

This is a template that will be passed and we want to update the style property to be able to:

1) set / unset noClamp (boolean flag) - because noClamp:true or noClamp:false is not supported by the server implementation, just existence or nonexistence of noClamp 2) change cmap values from a configured dropdown list - is already supported 3) change range values based on minmax slider 4) have a configurable separator of key/value inside the individual options - here : 5) have a configurable separator of individual keys - here , 6) combine all of keys/values into one "main" URL key - here styles

[silvester-pari]

How common is this format @lubojr? Is this a standardized thing or very specific to this one endpoint? I am wondering how deeply we should integrate this into the generic functionality.

Maybe instead of supporting all these special cases, we could offer a custom transform function, that lets you transform something like

{
  range: [-1, 10],
  noClamp: false,
  cmap: "inferno"
}

into the desired output format. Or even handling this on the parent app, like transforming the output string

[...]&rangeMin=-1&rangeMax=10&noClamp=false&cmap=inferno

into the desired format.

As a temporary workaround, you could set range:-1/10,noClamp,cmap:inferno as a string.

[lubojr]

@silvester-pari No, it is not a standardized thing as there is no standard for "non-standard parameters". For this concrete case of this server I think they did not do it well, as baking in together a STYLE (which is a standardized string, usually with a single value like for example viridis) will break a lot of potential clients.

However for custom non-standardized parameters (like our EOxServer dim_range - e.g. &dim_bands=nir,red,green&dim_range=1000 10000,1000 10000,1000 10000 you can define anything with anything and the UI elements should be able to mix/match it together.

From the experience, a part of the WMS/WMTS endpoints do a full custom parameter decomposition to leave just single value for a single parameter (e.g. key1=param1&key2=param2) and some do compositions (e.g. &key1=param1:val1,param2:val2&key2=...).

I agree with you that this is already outside of a simple JSON schema to define fields. I would be happy if I could define a JS function as a custom transformer that would accept this object and I would define how it is structured in the URL.

[silvester-pari]

I am wondering when to provide a custom function, before or after creating the form.

We have the example of custom inputs in the JSON form parsing, like https://github.com/EOX-A/EOxElements/blob/main/elements%2Fjsonform%2Fsrc%2Fcustom-inputs%2Fminmax.js

This allows to create any non-standardized input and produce a JSON output. But I feel like this is mostly suited for custom UI elements (double sliders, map inputs, etc.).

The requested feature in this issue here doesn't need additional UI elements, as it is very basic (dropdown, checkbox, double slider), so maybe it is best to either provide a "hook" after the form input, before the json output is created, or after the json was created.

[lubojr]

I agree that for this use case, we would just need a custom hook as we have all UI elements we need.

We can make configurable hooks for both, but I think I would prefer using the case "after the JSON object is created", as it leaves me in direct control of input -> output handling, right?

[lubojr]

This would be a really nice to have to simplify https://github.com/gtif-cerulean/assets/blob/a253a1df3a20f4db4cd0923bed706b5694ca1aa0/collections/Polaris_algorithm_dmi_demo/style.json by several thousands of lines once it is fully complete.