From the CDB user webinar Q&A:

Q: Not all TIFF libraries support TIFF images with channels with different data types. Has this been considered with the new Elevation Datasets?

A: The TIFF format supports different data types per channel. Where we recognize that this type of TIFF file may not be supported by all libraries, the benefits of having all the data in a single file is significant. Using the same data type for all channels was considered but not suitable for the mix of data to represent (Elevation, mesh type and offsets) and the file size would have been impacted significantly. Users are encouraged to use CDB API to leverage the required level of TIFF support.

I can see why you want to use different channels with different bit depths, it preserves the same raster height and width. I wish it could have been as multiple images within a single TIFF file so it wouldn't break libraries like libtiff.

Onto a question, since we have to change our tiff library for 3.2, can the Raster Material dataset be changed in a future spec version to combine the material index and mixture layers together? That would almost halve the number of files we need to read in this dataset.

Hi Ryan,

You have a good point on the Raster Material dataset which would also benefit from a multi-channel tiff file. This is an additional improvement in the spec that would improve client performance.

Do you have suggestion on the best way to implement this in the spec while preserving backward compatibility with 3.0 (i.e. a 3.0 client still has access to material data).

Herm

I'm not sure what you mean by preserving backwards compatibility. In my opinion, there are several things in CDB 3.2 that are not backwards compatible with current runtime publishers, and require changes to support the new specification. For example, the multiple bands added to elevation TIFF files, or the suggested location of attributes in feature shapefiles.

One easy way to detect the new format would be if all the mixture layers were missing, they must be in the material index TIFF files (just look to see if mixture layer 0 is missing, if more than one material raster exists). That wouldn't be too different than detecting the mixture raster element (float in CDB 3.0, float or 8-bit binary in CDB 3.2)

Hi Ryan,

You are correct in saying that there are some changes in spec 3.2 which a 3.0 client would need code changes to support the 3.0 subset of a 3.2 database. This should remain minimal changes in the case of the spec changes in 3.2.

One option to limit the impact on 3.0 clients is to generate a CDB 3.2 in a "maximize 3.0 compatibility mode". In such a mode, decisions to leverage 3.2 constructs can be made to maximize compatibility. Shapefile attributes are a good example where spec 3.2 gives flexibility on the level of the attribute (class, instance, extended). A content tool publishing a 3.2 CDB can select the attributes levels as per 3.0 to limit the impact. Same goes for deprecated attributes which remains "legal" in 3.2 even if 3.2 client should not rely on them.

This mechanism can facilitate support for mixed runtime components (3.0 and 3.2) but is only delaying a proper support for CDB 3.2 in a client.

The primary objective remains to allow 3.2 client to load 3.0 databases in order to re-use existing database assets. The 3.0 client loading 3.2 assets is beneficial for a smoother migration but not an end goal.

Herm