HDFCOMPASS(1) | HDF Compass | HDFCOMPASS(1) |
hdfcompass - HDF Compass Documentation
This document provide information about the HDF Compass application.
HDF Compass is an experimental viewer program for HDF5 and related formats, designed to complement other more complex applications like HDFView. Strong emphasis is placed on clean minimal design, and maximum extensibility through a plugin system for new formats.
HDF Compass is written in Python, but ships as a native application on Windows, OS X, and Linux, by using PyInstaller and Py2App to package the app.
TBD
Copyright Notice and License Terms for HDF Compass - Viewer for HDF5 and other file formats
----
HDF Compass Copyright 2014-2016 by The HDF Group.
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted for any purpose (including commercial purposes) provided that the following conditions are met:
DISCLAIMER: THIS SOFTWARE IS PROVIDED BY THE HDF GROUP AND THE CONTRIBUTORS "AS IS" WITH NO WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED. In no event shall The HDF Group or the Contributors be liable for any damages suffered by the users arising out of the use of this software, even if advised of the possibility of such damage.
Copyright and license terms for the following software can be found in the adjacent subdirectory Additional_Legal/. This information was obtained from sources provided by each software package provider at the location specified under "Original source:" and was current as of 19 December 2014.
HDF Compass uses selected icons from the following icon sets:
Pre-built HDF Compass binaries include the following software. None of this software is present in whole or in part in the HDF Compass source code.
TBD
TBD
TBD
This document describes the publically accessible data model package which is used by HDFCompass to display objects in a file, OpenDAP server or other resource.
The data model is implemented as a collection of classes in a top-level Python package, compass_model, which is completely independent of the GUI code. It has no dependencies beyond the Python standard library. This makes it possible to develop and test new plugins independently of GUI development; in particular, the automated Python unit-testing framework can be used, which is impossible for code that depends on the GUI.
The classes in compass_model are abstract, and define a standard interface for objects like containers, regular multidimensional arrays, images, and key/value stores. "Plug-ins" consist of concrete implementations which satisfy this interface. For example, the built-in HDF5 plugin which ships with HDFCompass implements a Group class which inherits from compass_model.Container, and a Dataset class which inherits from compass_model.Array.
The GUI has a collection of viewers which can display any object following the interfaces defined in compass_model. For example, compass_model.Container implementations are displayed in a browser-style view, with list, icon, and tree displays possible. Likewise, compass_model.Array implementations are displayed in a spreadsheet-like view, with facilities for plotting data.
Multiple concrete classes can handle the same object in a file. For example, an HDF5 image is implemented as a dataset with special attributes. Three classes in the HDF5 plugin are capable of handling such an object, which inherit respectively from compass_model.Image, compass_model.Array, and compass_model.KeyValue; the last represents HDF5 attributes.
When an icon in the GUI is double-clicked, the default (last-registered) class is used to open to object in the file. The other classes are made available in a context menu, for example, if the user wants to open an image with the Array viewer or see the HDF5 attributes.
Numeric types (integers, floats, multidimensional data) are handled with the NumPy type model, which can represent nearly all formats. Python strings (byte and Unicode) are also supported.
Objects may be retrieved using the __getitem__ syntax (obj = store[key]). The retrieved object is a Node instance. The exact class depends on the order in which Node handlers were registered; see the push method below.
Typically, a model will implement several classes based on the compass_model abstract classes such as Container or Array. This rasises the question: when an object is retrieved from the data store, which class should be used?
The answer is that each Node subclass you write should be "registered" with your Store subclass, and have a static method called canhandle. When an object is opened, by default the most recently registered class which reports it can understand the object is used.
All registered subclasses may be retrieved via the gethandlers function, which an optionally request that only subclasses capable of handling key be returned. This is the basis for the right-click "Open As" menu in the GUI.
A "node" is any object which lives in the data store. The Node class defined below is the base class for more interesting abstract classes like containers and arrays. It defines much of the interface.
You generally shouldn't inherit from Node directly, but from one of the more useful Node subclasses in this file. Direct Node subclasses can't do anything interesting in the GUI; all they do is show up in the browser.
Implementations will be displayed in a spreadsheet-style viewer with controls for subsetting and plotting.
Implementations are displayed in an image viewer.
One public function is defined in compass_model:
The following files need to be update for each new release:
For the HDFCompass.1file.spec file, you need to verify that the following parameters are passed to the EXE() function:
TBD
The HDF Group
2020, The HDF Group
March 22, 2020 | 0.7 |