fix: categorical legend

[hanbyul-here]

Related Ticket: #1456

Description of Changes

Categorical legend often doesn't have a colormap name but custom colormap values. This PR makes colormap&&rescale combination valid sourceParam. I think I would still like to run it with back-end team re: what makes sourceParams valid.

Notes & Questions About Changes

We need to consolidate where we are subbing colormap and rescale value. The current dataflow seems to be scattered, making it difficult to pin down where the source of the data is. IMO, it should happen while reconciling the render data.

Also it is interesting... that GeoGLAM dataset has been displayed just fine - which is another categorical dataset with colormap value. It just didn't get caught in any of our error Logic - which probably means that we can do better 😬

Validation / Testing

Check campfire nlcd data from the preview of NASA-IMPACT/veda-config#669
direct url: https://deploy-preview-669--visex.netlify.app/exploration?datasets=%5B%7B%22id%22%3A%22campfire-nlcd%22%2C%22settings%22%3A%7B%22isVisible%22%3Atrue%2C%22opacity%22%3A100%2C%22analysisMetrics%22%3A%5B%7B%22id%22%3A%22mean%22%2C%22label%22%3A%22Average%22%2C%22chartLabel%22%3A%22Average%22%2C%22themeColor%22%3A%22infographicB%22%7D%2C%7B%22id%22%3A%22std%22%2C%22label%22%3A%22St+Deviation%22%2C%22chartLabel%22%3A%22St+Deviation%22%2C%22themeColor%22%3A%22infographicD%22%7D%5D%7D%7D%5D&taxonomy=%7B%7D&search=&date=2019-01-01T05%3A00%3A00.000Z

[netlify]

✅ Deploy Preview for veda-ui ready!

Name	Link
🔨 Latest commit	215c593
🔍 Latest deploy log	https://app.netlify.com/sites/veda-ui/deploys/67bf852f6ad4a0000856490c
😎 Deploy Preview	https://deploy-preview-1462--veda-ui.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[anayeaye]

I am curious about cases where

• there are no sourceParams (and none are needed) such as the planet data that is displayed with blue tarp detections https://github.com/NASA-IMPACT/veda-config/blob/develop/datasets/ps_blue_tarp_detections.ej.data.mdx?plain=1#L49
• there are valid sourceParams that have a colormap_name but no rescale (adding rescale would not work) such as soil-texture https://github.com/NASA-IMPACT/veda-config/blob/develop/datasets/soil-texture.data.mdx?plain=1#L28

[hanbyul-here]

@anayeaye
Regarding Blue Tarp, this dataset has source param from render extension - https://openveda.cloud/api/stac/collections/blue-tarp-detection

      "rescale": [
        [0, 400]
      ],
      "resampling": "cubic_spline",
      "colormap_name": "reds"

But if the mdx configuration and render extension are both empty, the dashboard will make requests without any sourceParams.

Re: soil texture data - I think this is the same with geoglam data - it should have thrown an error since it doesn't have a valid sourceparams (at least for the dashboard) - but we have a bug that we are not throwing an error with some specific combination- user configured source param is not valid + render param exists + render param is not valid. This is a bug, but factoring all these cases, there doesn't seem to be any definite rule that we can tell whether the source is valid or not. We can skip any validation process if that reflects the actual rendering of the dataset more correctly?

[hanbyul-here]

Not directly related but kind of related - do all the datasetes have dashboard namespace now? (Can we expect dashboard namespace for all the datasets on VEDA?) Asking since we had to depend on user-configured data to retrieve render data ex. https://earth.gov/ghgcenter/api/stac/collections/micasa-carbonflux-monthgrid-v1 If I remember correctly, this dataset render extension did not have dashboard namespace before but now it does!

[hanbyul-here]

Based on the discussion with @anayeaye @smohiudd and @dzole0311 I made several more changes

• Removed validation of source parameters
• Changed the precedence of resolving sourceParams. The order is like this:
  // 1. if the layer requires specific asset,
  // 1-1. If so, check if renderExtension has that asset as a name space.
  // 1-1-1. If so, use the renderExtension data.
  // 1-1-2. If not, fallback to user-defined source parameters
  // 2. if renderExtension data exists
  // 2-1. If so, use the render Extension
  // 3. return user defined source parameters (which can be undefined)

@dzole0311 I will appreciate if you can review this one more time 🙇

[anayeaye]

// 1-1. If so, check if renderExtension has that asset as a name space.

I think it could be problematic to mix item asset keys with the renders namespace visualization object keys because renders could include multiple assets in source parameters. Can we make a 1:1 mapping of <dataset-name>.data.mdx layer.id (example) to the renders object keys?

In this case the logic might be

1. if layer.id in renders keys, use renders[layer.id],
2. else if renders["dashboard"] exists, use that
3. else use mdx sourceParams

@hanbyul-here @smohiudd @dzole0311