Open axelboc opened 1 year ago
Early thoughts when reading this:
RgbVis
should indeed follow the behaviour of HeatmapVis
, now that it supports custom axes valuesisIndexAxis
could be renamed to restrictToIntegers
or something similar to be more explicitIf we decide to bring proper support for discrete ticks (i.e. not limited to integers), then we need more info than just a boolean: either the tick values (bad for perf), the tick count (purpose might be unclear for consumers) or the tick step (my preference). So if we go down this route, I'd recommend replacing isIndexAxis
with a prop called step
, or tickStep
maybe (might as well be explicit).
For context, the renderTooltip
function currently receives the continuous coordinates (x
, y
). It is then up to the consumer to decide whether to show the continuous coordinates directly or instead compute the discrete coordinates. Computing the discrete coordinates is currently done in the viewer by first generating an array of axis values and then converting the continuous coordinates to indices with a threshold scale. Not great... Knowing tickStep
and the axis domain, we can avoid generating an array of axis values, we can remove the need for a threshold scale, and we can hide the continuous-to-discrete conversion logic inside TooltipMesh
.
Perhaps we can make the tooltip behaviour consistent with the ticks by default and save the consumer a bunch of work by returning the discrete coordinates directly when tickStep
is provided. Then, if we want to the consumer to keep the ability to have discrete tips but show continuous coordinates in the tooltip, then we could add a prop to TooltipMesh
to opt out or opt in (e.g. forceContinuousCoords
, or forceDiscreteCoords
) of the default behaviour.
The concept of tickStep
looks promising to me too. I am curious to see if it can remove the need for generation of axis values and/or threshold scales.
As for the tooltip, I wouldn't change much for now and iterate over the changes brought by tickStep
in a second time.
We've received a couple of emails requesting the ability to use text strings and formatted timestamps (date/time) as axis labels. In both cases, I think this would require support for discrete axes. For timestamps, the email referred to the NetCDF Climate and Forecast convention, which talks about discrete axes
Ticks
The axis configs we pass to
VisCanvas
may include a flag calledisIndexAxis
. This property has one goal: to prevent ticks from appearing between axis values - i.e. typically between image pixels on the heatmap:isIndexAxis: true
isIndexAxis: false
We set
isIndexAxis
totrue
when we know the axes show pixel indices, that is:HeatmapVis
, when custom abscissa/ordinate values are not providedLineVis
, when custom abscissa values are not providedRgbVis
, always for both axes (arguably this should follow the same behaviour asHeatmapVis
now that we support custom axis values)The assumption here is that when custom axis values are available, the axis is meant to be continuous.
When
isIndexAxis
istrue
, theAxis
component callsgetIntegerTicks
instead of the axis' D3 scale'sticks()
method, which cannot guarantee the generation of a specific number of ticks (i.e.scale.ticks(3)
can actually generate more than 3 ticks...) This works great when dealing with indices ([0 ... cols]
), but it doesn't work at all with custom axis values (e.g.getIntegerTicks([0.001, 0.004], 4)
returns an empty array and the axis disappears...)Of course, we can work around this problem easily in the viewer by setting
isIndexAxis
tofalse
inRgbVis
when custom absicssa/ordinate values are provided.However, this does not prevent misuse of
isIndexAxis
by consumers of@h5web/lib
.Note also that
getIntegerTicks
does not prevent ticks from appearing outside of the bounds of the heatmap:Tooltips
The other way in which the viewer currently supports discrete axes is in the tooltips of
HeatmapVis
andLineVis
. In fact we always consider that the axes are discrete regardless ofisIndexAxis
: the tooltip'sx
andy
values are always taken either from the axes' indices or from the custom values if provided:In other words, there is an inconsistency between the way the ticks are generated and the way the tooltip computes the coordinates of the value under the cursor. This is not great.
In Daiquiri, for the tomography visualizations, where
isIndexAxis
is left asfalse
, the tooltips show continuousx
andy
values (in mm) as expected:Question
So the question this issue raises is: should we add proper support for discrete axes? Is this something that would be useful to some scientific fields, either in the viewer (via a toolbar toggle, or always enabled), or in the lib? By proper support, I mean:
Proper support is not trivial, since, for instance, axes would need more info than just a domain to generate discrete ticks: either the axis values, the number of values (i.e. number of pixels + 1), or the step between the values. Obviously, it would be better if axis values never had to be generated in the viewer, as this is a (minor) performance issue at the moment, so the number of values or the step feel like better solutions.