Hi Jens,

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.

1. 
   

   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?

   
   


2. 
   

   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.

Hope that makes better sense.

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”)


• frontend sends the values to the backend
  
  • backend
    
    • generates evalscript and saves it to Sentinel Hub (documentation for this)
    
    
    • responds to frontend to let it know that the evalscript is saved
    
    
  
  


• frontend requests new images from Sentinel Hub and displays them like normal images or on the map (e.g. with Leaflet.js).

Option 2: Backend would act like a proxy (“middle man”) for WMS / Processing API requests

This is not really suitable for use for interactive maps (e.g. would need to mimick WMS server behaviour) and might mean even more work.

• user provides values and confirms (button with “submit” / “apply” / “update”)


• frontend makes requests to the backend to get new images and provides the users’ values, area (bbox / geometry) and time
  
  • backend
    
    • generates the evalscript and makes a WMS (with evalscript parameter) or Processing API request to Sentinel Hub
    
    
    • returns results to the frontend
    
    
  
  

Hope you find a good solution with these ideas.

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.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.