The Vitessce view config defines the datasets (and the URLs to the files they contain) and the individual visualization components that the data will be mapped onto. The view config also stores the coordination space and defines whether multiple views are linked to each other (and on which properties they are linked, if any).
The full view config JSON schema can be found here.
A name for the view config. This name may be displayed in the website
<title>, for example. Although this field is required, you are welcome to use the empty string.
The view config schema version.
|Support for the coordination space was added in this version. We recommend that you use this version.|
The coordination space initialization strategy. The initialization strategy determines how missing coordination objects and coordination scope mappings are initially filled in.
|Recommended. This strategy will allow you to omit some or all coordination scope mappings.|
|Use this strategy if you would like to define all coordination scope mappings yourself.|
If you find yourself following certain patterns when initializing coordination spaces manually, please let us know so that we may work with you to implement this pattern as a supported strategy.
The datasets array stores a list of dataset objects. Each dataset object must contain a unique ID
uid, a list of file objects
files, and an optional
A unique ID for the dataset. Required.
A human-readable name for the dataset. Optional.
The files array stores a list of file objects for a dataset. Each dataset may have one file of each
type. File objects must contain a
type ("data type") and
fileType ("file type"). All file types require a
url string, with the exception of
raster.json which may point to multiple image URLs via an
options object. We don't associate any semantics with URL strings.
For more information about data types and file types, please visit our Data Types and File Types documentation page.
The layout property defines which visualization (and controller) components will be rendered, how they will be arranged on the screen, and optionally how they will map onto coordination scopes. Each layout object represents one "component" or "view", and must contain a component name
w and height
h, and horizontal position
x and vertical position
y. Components are arranged in a grid with 12 columns and a dynamic number of rows. Optionally, each component may contain the properties
For more information about the components that are available, please visit the Visualization Components documentation page.
For more information about the coordination types that are available, please visit the Coordination Types documentation page.
The coordination space stores the values associated with each coordination object. It may be helpful to recall that the coordination space is analogous to computer memory which stores values of variables, and the coordination scope names are analogous to references to different locations in memory.
The keys of each object (at the first level) in the coordination space represent coordination types. The keys of each coordination type object represent coordination scope names. The types of values that each coordination scope can take can be as simple as a single number or as complex as an array or object, and depend on the types of values supported by its coordination type.
When the coordination space is entirely or partially omitted from the view config,
initStrategy determines how the missing parts will be initialized.
An optional description for the view config.