Each dap is identified by a specific code from the list available in appendix C. The dap position as well as its length can vary. For example, the item dap would be located at h%gil%column_pointer(code_uvt_item), and it could be a Real(4) or Real(8) number depending on the value of h%gil%column_size(code_uvt_item).
A whole set of possible daps entities is defined below, and can be extended if needed. The daps element can be located either before the complex visibilities, or after, but not intermixed with them. Accordingly, there can be h%gil%nlead leading columns before the complex visibility values and h%gil%ntrail trailing columns after. Note that these number indicates the number of 32-bit columns, so if any of the dap is a 64-bit number (h%gil%column_size(code_uvt_dap) = 2), nlead+ntrail will be greater than the number of non-zero values in h%gil%column_size(:).
The existence of daps entities of different lengths raise a specific
issue when transposing a UV tables.
By default in GILDAS, transpositions are applied on the global data
type. For UV tables, this is fmt_r4, i.e. 32 bit entities.
Assume we start with a natural (UVT) order, with for example 
a 64
bit quantity. After transposition to TUV order, the first 32 bit of
are in the first column, and the last 32 bits in the second. This
is incoherent. Thus a second transposition is required on these
specific columns to establish the contiguity of the 64-bit
values. This is handled transparently by the GIO library, in
gdf_transpose as well as in gdf_read_gildas.