-
Notifications
You must be signed in to change notification settings - Fork 12
Open Design Decisions
This wiki page collects together all issues involving general design decisions that should be considered during the code sprint, including various naming issues. Each bullet point links to the relevant issue and includes a brief description of the decision that needs to be made.
Naming this project (#41)
Currently, we are using the following names: Cube Browser (organization), Cube Explorer (repository name), HoloCube (package name)
The details of where these names are used is discussed in the issue and the issue lists five things that need naming (the project, organization, repository, import package and pip/conda package names). What names are chosen should depends on both the current status of the library and its expected future direction.
- Defining plotting normalization behavior for large datasets (#20)
This issue discusses the desired default normalization behaviour. One suggestion to consider by @marqh and @pelson is to add a 10% margin on the normalization range based on the values in the first frame.
- Units and dimensions (#35)
This issue suggests a library of dimension presets with standardized names, units and ranges defined. This could offer a way to easily define normalization ranges. In addition, the user might be able to define their own set of dimension presets at the top of each notebook.
-
An additional proposal Consider adding dimension ranges to iris Cube metadata was rejected based on input from the Iris developers.
-
Guessing bounds
Our example notebooks currently call guess_bounds(), but it seems odd to have to explicitly call something to make a guess. Should it automatically guess, if no bounds were specified (printing a notice that it's guessing, perhaps?)? Or should we be trying to make the cubes have sufficient metadata to avoid guessing?
Supporting slicing and indexing semantics (#12)
This issue is marked as an enhancement and the decision needs to be made whether __getitem__ should be supported in a way that fits in well with the semantics used in HoloViews.
The example notebooks currently have code like surface_temperature.to.image(['longitude', 'latitude']), which can be confusing because it's not clear what the resulting type is. Because HoloViews organizes options by type, it's important to know whether this returns hv.Image, hc.Image, or some other type. [Actually, how do we distinguish options for two Element classes that happen to have the same name but come from different packages? -- Jim] We can also write
surface_temperature.to(hc.Image, ['longitude', 'latitude']), which is more explicit, though it's also slightly misleading because it's actually a HoloMap of Image objects that is returned. It would be nice to have a more succinct way to specify ['longitude','latitude']`, as well -- are there cases where that information can be declared on the cube itself, so that when we make an Image it will automatically be mapped onto those dimensions? Tricky!
Suggestions of this type may require substantial user input and discussion as the appeal of these proposals may vary according to personal taste, coding style and so on.
-
Tab-completable cube collections. A typical notebook is expected to handle a number of different cubes and it would be desirable to have easy access to them through some sort of indexing object. A simple and well-understood approach would be to collect the cubes into a Python dictionary, perhaps with a handle
cubes. Using a dictionary is simple and understandable, but is less easy to use dictionaries in notebooks than to use an object with tab-completion support. HoloViews offersLayoutcontainers with easy tab-access and it is easy to build other containers with tab-completion facilities, but these won't be as familiar to new users as dictionaries are. Whether the tab-completion and other features of aLayoutare worth the cognitive cost to learn about them is a decision that will need the opinions of many notebook users who work with cubes on a regular basis.