You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the color legend widget, we use d3 scales with the nice() property to round to even values. We either need to expose a method to get this generated scale OR adjust the rendered colors in the scale, since this causes the displayed colors to not match the colors expected by the caller.
For instance, suppose we use a continuous color scale with a domain of [0.05, 0.95] and colors ['#000000', '#ffffff']. The caller expects that the scale will show 0.05 as black and 0.95 as white, but the nice values shift these to 0 and 1, so 0.05 maps to #0d0d0d and 0.95 to #f2f2f2.
Since the nice values are visually pleasing, it might be best to fix this by changing the rendered scale to have the end color values for values between the specified domain ends and the computed nice values. In the example above, [0,0.05] would all render as black and [0.95,1] would all render as white.
The text was updated successfully, but these errors were encountered:
Another option would be to allow the user to disable the nice() in instances where the user really wants to clamp max/min values. This perhaps should be the default since it is less surprising, and additional processing (nice()) would require an additional flag.
In visualizations, I have not seen the approach of clamping the range between the nice value and the data max/min. It seems misleading, with the user perhaps inferring that the range of the data is the nice values, since they are rendered at the "endpoint" colors. It seems best to have "messy" (non-nice) legends or "messy" (non-endpoint) colors, and not to try to accommodate both at the same time.
In the color legend widget, we use d3 scales with the
nice()
property to round to even values. We either need to expose a method to get this generated scale OR adjust the rendered colors in the scale, since this causes the displayed colors to not match the colors expected by the caller.For instance, suppose we use a continuous color scale with a domain of [0.05, 0.95] and colors ['#000000', '#ffffff']. The caller expects that the scale will show 0.05 as black and 0.95 as white, but the nice values shift these to 0 and 1, so 0.05 maps to #0d0d0d and 0.95 to #f2f2f2.
Since the
nice
values are visually pleasing, it might be best to fix this by changing the rendered scale to have the end color values for values between the specified domain ends and the computed nice values. In the example above, [0,0.05] would all render as black and [0.95,1] would all render as white.The text was updated successfully, but these errors were encountered: