Archiving file types
As mentioned in File types (whilst creating, working with, and processing data), there are a great many data formats in use within the dendrochronological community. However, with the exception of the Tree Ring Data Standard, none provide the mechanism for recording rich standardised metadata. Wherever possible we strongly recommend using TRiDaS format files to store both your data and metadata.
If the tools being used for the dendrochronological analyses do not support TRiDaS, then one option is to maintain your data within the legacy format supported by the software, and the metadata in a TRiDaS-enabled database like TRiDaBASE (Jansma et al. 2012b). The DCCD repository supports the submission of TRiDaS plus a variety of legacy formats, whereas the ITRDB supports the submission of Tucson and TRiDaS files.
The managing of the legacy data files in a hybrid TRiDaS/legacy system is definitely the weakest link in this approach. With no software to provide error checking, it is all too easy to mislabel, rename, move and delete files – especially in a multi-user environment. The utmost care must be taken at all times to be as strict as possible. Write access to the files should be limited to only essential personnel. Folders containing site data files should be made read-only as soon as work on a site has been completed.
If one decides to follow this method it is important to ensure that the legacy data format that is used stores the ring-width data in an unambiguous manner. Where ambiguities exist, these should be clarified in the TRiDaS metadata. A list of formats, along with some of the potential issues they may have, is available in table 2. Further details are available in Brewer et al. (2011).
One issue shared by many of the legacy data formats is the ambiguity of the calendar used for dates. To reduce the programming complexity, many formats use what is known as the astronomical rather than the Gregorian calendar. The astronomical calendar includes a year zero and denotes BC dates as negative integers. This means that prior to the AD/BC transition the year numbers are offset by one (e.g. 1AD = 1; 1BC = 0; 2BC=-1; etc.). This can cause complications for researchers both outside and within the dendrochronological community. It is not uncommon to find legacy data files with BC data where the offset has been removed.
|Format||Suitable for TRiDaS co-archival||Potential issues|
|Belfast Apple||With caveats||Format cannot store missing ring information|
|Belfast Archive||With caveats||Format cannot store missing ring information|
|Besancon||With caveats||The format should strictly only contain data values are in 1/100th mm, however, some users store micron resolution data instead. There is no standard way to discern the difference|
|CATRAS||No||Closed source proprietary binary format. There is some support for reading/writing CATRAS files in the TRiCYCLE library but the closed nature of the format means this is not comprehensive|
|Cracow Binary format||No||Simple binary format storing just ring-widths and sapwood markers. Although this is a very simple format, the fact it is binary means accessing the data is not trivial|
|Corina||No||File format with very limited software support|
|DendroDB||No||An export format used by the discontinued DendroDB database. No known software implementations generate this format.|
|FHX2||No||Dendro format for recording fire history event data. Does not support ring-width data|
|Generic spreadsheet formats||No||Various spreadsheet-style formats (including CSV, MS Excel, ODF etc) are used by some to store and transfer ring-width data. The flexible nature of spreadsheets means that data can be stored in a wide variety of ways makes it unsuitable for long term storage of data.|
|Heidelberg||Yes||Native format for the widely used TSAP software. Has extensive support for metadata fields, but the contents of these fields are not standardised|
|KINSYS-KS||With caveats||Format specific to the software of the same name produced by the Finnish Forest Research Institute although not widely used elsewhere. Stores ring-width data effectively but the lack of support in software means it is not ideal for long term storage|
|Nottingham||No||A format with no known documentation or extant reference implementation|
|Oxford||With caveats||Does not store data: prior to 1AD; ring-widths >=1mm|
|PAST4||No||Files can be in either astronomical or Gregorian calendar which can introduce ambiguities.|
|Sheffield||With caveats||Format cannot store missing ring information|
|Topham||With caveats||Very simplistic format which should only be used for raw ring-width data|
|TRIMS||With caveats||Format cannot store missing ring information|
|Tucson||With caveats||There are many undocumented alterations to this format. Check files with TRiCYCLE or COFECHA to ensure readability before archiving|
|Tucson compact||No||Rather complicated format that is not widely supported|
|VFormat||No||Highly encoded metadata makes this format not very accessible|
|WinDENDRO||No||Proprietary delimited text format|
 TRiDaBASE – http://www.tridas.org/tridabase/