zVariables are identical to rVariables in all but one respect. The dimensionality of a zVariable may be different from that of the rVariables (and other zVariables). This allows variables that do not ``fit'' into the dimensionality of the rVariables to be included in the same CDF. Using only rVariables to store certain data sets could result in wasted disk space or a CDF with rVariables whose dimensionality is not consistent with some of the data in the data set. zVariables are intended to solve these problems. Note that a CDF may also contain just zVariables.
Consider a data set that consists of some number of images, each containing 1024 by 1024 pixels. The data set also contains a palette that is used to map pixel values to the actual color/shade to be displayed. Palettes are also referred to as lookup tables or color lookup tables. For this example assume that each image pixel is stored in an 8-bit byte and the palette is a 1-dimensional array of 256 colors/shades. Indexing into the palette array with a pixel value gives the appropriate color/shade to use.
Attempting to store the images and the palette using only rVariables would result in one of two undesirable situations. If the CDF's rVariables are 2-dimensional with sizes [1024,1024] (to store the images), the palette would have to be stored in a 1024 by 1024 array that does not make sense logically and would waste disk space regardless of how the dimension variances are set. If the CDF's rVariables are 3-dimensional with sizes [1024,1024,256], the images could be stored in an rVariable having dimension variances [TRUE,TRUE,false] and the palette could be stored in an rVariable having dimension variances [false,false,TRUE]. This would not waste any disk space but is not the intuitive way to store the data --- nothing in the data set is 3-dimensional.
Using zVariables to store the images and palette would solve both problems. The images would be stored in a 2-dimensional zVariable with sizes [1024,1024] (and dimension variances [TRUE,TRUE]) and the palette would be stored in a zVariable defined to be 1-dimensional with a size of [256] (and dimension variance of [TRUE]). This would waste no disk space and logically makes sense.
The use of zVariables is recommended because of this added flexibility. Note that zVariables can always be used instead of rVariables. In the previous example involving the storage of temperature values, the zVariables defined in Table 1.5 could have been used instead. To some users this approach may be more logical. When using zVariables in this way, it becomes more important to use attributes to store the metadata needed to understand the data. In this example, attributes would be used to describe how the latitude/longitude zVariables relate to the dimensions of the temperature zVariable.
zVariables | Dimensionality | Variances |
Time | 0:[] | T/ |
Latitude | 1:[2] | F/T |
Longitude | 1:[2] | F/T |
Temperature | 2:[2,2] | T/TT |
[.]The notation used is <num-dims>:[<dim-sizes>] where <num-dims> is the number of dimensions and <dim-sizes> is zero or more dimension sizes separated by commas.
[.]The notation used is <rec-vary>/<dim-varys> where <rec-vary> is the record variance (T or F) and <dim-varys> is zero or more dimension variances.