jlstevens
commented
8 years ago Having ranges declared on iris Cubes would indeed be helpful and I think this is information we would want to use whenever it is available.
Given that cubes may not always have this metadata, it is worth considering other ways that explicit ranges could easily be supplied. In the issue referenced above, I propose a library of Dimension presets which could allow quick defining of a suitable normalization range by selecting an appropriate dimension. This would be another way of avoiding the automatic computation of ranges over the entire dataset.
It is worth thinking about the pros and cons of these two proposals and figuring out the tradeoffs. I think defining ranges on the cubes themselves would be ideal as long as the specified ranges change between cubes. If the ranges tend to be shared between cubes as the ranges are a function of the type of measurement (rather than a feature of the data values themselves) then perhaps an appropriate dimension preset would be more suitable.
marqh
HoloViews provides a general system to normalize the ranges of dimensions across multiple frames and axes. These ranges are usually computed either directly from the data but if an explicit range has been declared on the dimension this is skipped. Computing the range for dataset can be very expensive however and domain knowledge and an understanding of the dataset is required to set an appropriate explicit range.
In a recent meeting we discussed an alternative, instead of requiring the user to set an explicit range there could be an official API to declare the dimension ranges directly on an iris cube such that the HoloCube interface can just look it up in the constructor. This would be a lot less expensive than computing the ranges dynamically and avoid manual and error-prone input by the user but would require deciding on an official way to declare the ranges on an iris Cube.