Continuous overlay range

[moontrip]

Making a new PR at web-monorepo. Detailed discussions were made at VEuPathDB/web-eda#1696.

[moontrip]

Following your request, I made a PR at web-monorepo, @bobular

[moontrip]

Hi @bobular I have updated this PR based on our discussions and your suggestions at VEuPathDB/web-components#454.

[bobular]

I'll need to do some more testing tomorrow (and we should probably have some unit tests for complex functions like this) but can't we also get rid of this line

        ? defaults.displayRangeMin != null && defaults.displayRangeMax != null

and the whole block here?

web-monorepo/packages/libs/eda/src/lib/core/utils/default-axis-range.ts

Lines 45 to 53 in dfa763c

	: {
	min: logScale
	? (observedMinPos as number)
	: (min([
	isNonZeroBaseline ? undefined : 0,
	defaults.rangeMin,
	observedMin as number,
	]) as number),
	max: max([defaults.rangeMax, observedMax]) as number,

If displayRangeMin/Max are undefined, they should be fine in the lodash min/max.

There's just one defaults.displayRangeMin <= 0 to take care of.

[bobular]

nice

[bobular]

maybe also leave a comment saying that lodash.min is being used because it is tolerant of undefined values

[moontrip]

@bobular Thank you for your comments! 👍 I think that you are right. Perhaps that part, ? defaults.displayRangeMin != null && defaults.displayRangeMax != null may not be necessary. I will try to check it out carefully. Will also add a comment about lodash.min/.max

[moontrip]

@bobular I have tried your suggestions and didn't notice specific issue. So, a commit is made to remove that part & add a comment concerning lodash.min/.max

[bobular]

This is looking great. Nearly there!

We just need to tweak the drawing of the legend gradient bar.

In the following GEMS1 screenshot, you can see that the two "Weight-for-length or -height z-score *" variables are basically the same thing:

This is useful, and it means we can basically overlay with the same variable as one of the main axes:

What this shows is that the zero values are being correctly coloured in the neutral "white" colour. This is because the code is correctly normalising between +/- maxAbs

// L2366 (!) of ScatterplotVisualization.tsx
const normalize = scaleLinear();
// ...
normalize.domain([-maxAbsOverlay, maxAbsOverlay]).range([-1, 1]);

However, the legend needs to be drawn so that the zero values are also white(ish).

[bobular]

I noticed a type

            } else if (gradientColorscaleType === 'sequntial reverse') {

This would be avoided by typing gradientColorscaleType with the allowed values.

[bobular]

Haha, a typo in my comment. Should have been "typo"!

[moontrip]

Thank you for your detailed reviews and tests @bobular 👍 - Didn't have time to reply earlier due to map stuff we worked together 😄

I will change the type (typo haha). Also will try to adjust the legend.
By the way, here is one question concerning the legend you suggested. Do we need to use legend for the calculated range or for the absolute max based range? I think that your intention is the former but want to make sure of it.

[bobular]

Hi @moontrip - I'm not sure I understand the question but here is my understanding of how the legend needs to be drawn:

The min and max values displayed on the legend (e.g. -30 and +20 in my screenshot above) are correctly sourced, I think.

The transform applied to generate the colours in the legend needs to be the same as used in the viz component, e.g. -maxAbs to +maxAbs. Maybe pass the normalize object to the legend if possible? This would avoid having to code the logic twice.

[bobular]

I looked at the PlotGradientLegend implementation.
Currently the whole colour scale is rendered as an SVG linearGradient.
I think we need to pass in to PlotGradientLegend the xxxxColorScaleMap and the normalizer, and use those to generate the gradient stop point colours from "raw" input values legendMin to legendMax

[moontrip]

@bobular Thank you for sharing your insights 👍 I will think of it next week. Have a great weekend!

[moontrip]

Hi @bobular I have implemented new colormap based on range for divergent, sequential, and sequential reversed. For your better understanding when reviewing, I summarized how to resolve this in the following.

a) at ScatterplotVisualization, RGB values for overlayMin and overlayMax via gradientDivergingColorscaleMap(normalize(overlayMin/Max)) are passed to PlotLegend/plotGradientLegend.
b) at PlotGradientLegend, computing a kind of bins, which depends gradient type (e.g., divergent, sequential, etc.), range used for normalize function, and the number of gradient colors, and then find an array index with a criterion - this also depends on gradient type (either overlayMin or overlayMax). It is because sorting RGB colors is very difficult.
c) the array index is utilized to determine 1) trimming down pre-existing gradient colors and 2) where to place overlayMin's RGB or overlayMax's RGB in the trimmed gradient colors.

Here are screenshots to show current Live site and new divergent colormap (GEMS1 data): I think sequential-related colormaps would also work fine with the logic I implemented but couldn't find appropriate example to demo (mostly starting from 0 or 1).
Note that displayRangeMin/Max = (-30, 20) and rangeMin/Max=(-15.3, 273.91) from the variable's metadata, thus final range becomes (-30, 273.91).

a) current Live site: incorrect range as you initiated in the ticket

b) new divergent colormap: as you can see, the color of the min does not start from dark blue

[moontrip]

@bobular After checking the cases of the sequential and sequential reversed, I don't think we need to use my logic for them. So, I simplified the logic and changed accordingly. Now we only use the logic for the divergent case.

[bobular]

Converting to draft as I'm not sure of the status of this branch.
Currently reviewing #44

[moontrip]

@bobular yes you are right I will close this PR 👍 #44 will take over instead of this.