We need to update a WMS layer with a CUSTOM color map or pixel values based on the values supplied on the client end.
My understanding is that this can be done from the client end by providing the “edited” evalscript within the WMS request (base64 encoded), which SH will use to return the updated WMS layer.
The challenge is that by doing this we would “expose” a confidential equation/values within the evalscript which could easily be decoded.
What is the best way to change the colour map/scheme of a layer without exposing the entire evalscript internals to the client side?
I would like to make sure I understand your requirements clearly: you would like to setup a WMS layer that contains an Evalscript that stays hidden to your users/clients, but at the same time where they can modify the colormap to fit a specific range (possibly through your front-end platform)?
Thank you for your response. Okay maybe I can break the question up into two parts.
The stats of the AOI will inform the visualization of the pixel data on the map. E.g. I would like to scale the color scheme of the layer (e.g. NDVI) based on the values based on the statistics of a selected AOI or that are either supplied by the user (frontend client feature). How is this best done?
The client would like to apply a specific formula to a layer (e.g. SPECIAL_BAND_RATIO* <client_input_value> / <client_input_value>), and then visualize it further on the map. These <client_input_values> are confidential to the user (inserted through frontend platform), and the SPECIAL_BAND_RATIO is confidential to us, and therefore we would not want it made public. How is this best done?
We are currently using WMS to view layers set us in the configurator, what is the best practice to manipulate the layers (and its color scheme) with inputs from the front-end platform.
Hey,
thanks for the reply, this is more clear now.
If it is enough to prevent adversaries from intercepting the requests, then you can safely use WMS with the evalscript parameter or Processing API (where the evalscript is provided in the body of a POST http request).
HTTPS URLs are encrypted (except for the domain name), so the evalscript parameter can’t be seen by sniffing the network.
This way would still allow tech-literate users to get the evalscript from the requests that can be observed in the network tab in devtools of the web browsers.
If there is a need to also prevent that, then this can be solved in several different ways with a small backend which would have your SPECIAL_BAND_RATIO and would generate evalscript based on the users’ input values.
Option 1: Backend would serve as a way to update evalscript on Sentinel Hub
This is easier to do and more suitable for interactive maps (e.g. Leaflet.js - no change to WMS Layer).
Downside is that every user would change the “global” evalscript for a layer that is used by every “instance” of the frontend (for every user).
user provides values and confirms (button with “submit” / “apply” / “update”)
Thank you Ziga for the response, and apologies about the delayed response.
I appreciate the options suggested. Unfortunately option would result in global changes of the layer used and therefore changing the styling for other users. I will try option 2, it may be a challenge, but will see if I can make this work.