Tucson format

From Cybis Wiki
Revision as of 11:41, 4 July 2009 by Lars-Ake (Talk | contribs)
Jump to: navigation, search

Tucson format or decadal format or rwl format is one of the most common formats for storing ring width data. It is the standard format for ITRDB. It is a text file format. Different extensions are used, such as .rwl, .crn, .tuc and .dec. (.crn is used for derivate chronologies). The name comes from the city of Tucson in Arizona.

A Tucson file consists of three lines of meta data followed by an undefined number of data lines (and cores). A data line consist of the core identity (max 8 alphanumeric characters, i.e. letters or digits), the year of the oldest measurement of the line (4 digits)[1] ring width data, up to ten rings per line. Measurement data is either given with 3 or 4 digits according to resolution. Except for the first and last lines of each core there are measurements for one decade per line. After the youngest ring there is a "999" as a stop mark. Missing data mark is -999.

If the unit of measure of a series is 0.01 mm then the end of the series is marked with a last extra value of "999". If the unit of measure is 0.001 mm then the end of the series is marked with "-9999".
Note: The consequence of 999 being an end marker is that a measurement of 0.999 mm, in four digit resolution, has to be changed into 0.998 mm (998) or 1.000 mm (1000)!

PMkr12b 1781   120    87    69   122   108    85   125   114    77
PMkr12b 1790   134   131   114    97   117    49    69   100   123    89
PMkr12b 1800   137    89  -999    79    44    38    62    99    68    26
PMkr12b 1810    27    43    51    57    36   999

An example of a three digit resolution sample which covers the timespan AD 1781-1814, with a missing ring for AD 1802 (-999). The width of AD 1781 (the first year) annual ring is 1.20 mm and for 1782 AD 0.87 mm.

Contents

Examples

The tucson format standard is sometimes interpreted in some various ways, which will make the programming a bit harder. The following examples from files in ITRDB is taken from comments within the CDendro code. Best would be if we could have two sections with awkward data - one for each precision - that could be used for testing Tucson format reading capability of software.


Examples of variants of the decadal file format
6682    1980   143   231   154   145   150   201   130   156   245   137
6682    1990   141   202   120    96   999
NM002   1632    90    92    91   174    84    45   185   111
NM002   1640   116    72    91    49    85   146   125   126   136   131

The usual ending and start of samples (3 digit resolution)


SH387C  1170    14    16    14    19    22    22    26    16    23    23
SH387C  1180    17    11    14    12   999     0     0     0     0     0
SH387D  1078    48    48
SH387D  1080    50    42    46    62    49    53    41    28    17    31

An example from brit9.rwl[2] where the positions after the end mark are filled out with "0"


Q 9730   990    72    98   112   124   107   132   137   145   114    80

This snappet from brit045.rwl[3] looks very much normal, but ends with two Asciichar(13) characters which will not be trimmed away by the VB Trim function.


Start line
6682    1884   261   267   191   189   215   309
6682    1890   357   284   248   174   274   271   229   201   200   130

The normal start of a sample


WRU9    1190   190   192   218   213   204   259   206   150   178   149
WRU9    1200   198   232   151   199   175   196  9990  9990  9990  9990
WRU13   1075  9990  9990  9990  9990  9990   342   426   240   213   217

A snappet from brit5.rwl.[4] It both ends and start a sample with 9990 markers.


MWK964  1970    16    11    22    25     9    13    26    24    23    16        
MWK964  1980   999                                                              
MWK965   509    62     0     0     0     0     0     0     0     0     0        
MWK965   510    47    45    25    19    33    24    32    51    24    22        
...
MWK401 -3550    26    21    19    20    28    21    13    11    -0    11  

Example from ca535.rwl[5] where zeroes are filled into positions which are not in use and this with a -0 instead of 0 or -999 for missing rings.

606 13  1570    24    31    30    25    26    24    27    27    33    30
606 13  1580    20   999
606 13  1586    20    19    19    18
606 13  1590    27    20    20    25    22    22    23    23    10    15

Example from fran009.rwl.[6] I.e. two segments with a small gap of missing rings in between is written in the same way as two separate samples though here with the same identity.

Note, that there exist also .rwl files of the type above but with several other samples written between the segments. See e.g. Itrdb germ011.rwl where the identity 371241 starts the collection with a segment, then many other members follow and at last still a segment of 371241 ends the collection.

In CDendro these segments are handled as separate samples though they have the same identity within the .rwl file. The identity problem is then solved by giving them a temporary identity like "616 13:1" and "616 13:2"

CDendro interpretation

....
See also CDendro naming standard

Limitations of the Tucson format

Notes

  1. If 5 digits are needed for the year, i.e. older than -999, the identity cannot be more than 7 alphanumeric characters.
  2. ITRDB: brit9.rwl info
  3. ITRDB: brit045.rwl info
  4. ITRDB: brit5.rwl info
  5. ITRDB: ca535.rwl info
  6. ITRDB: fran009.rwl info
Personal tools