Tucson format: Difference between revisions
| Line 67: | Line 67: | ||
''Example from ca535.rwl<ref>{{itrdb|ca535|northamerica/usa}}</ref> where zeroes are filled into positions which are not in use and this with a -0 instead of 0 or -999 for missing rings.'' | ''Example from ca535.rwl<ref>{{itrdb|ca535|northamerica/usa}}</ref> where zeroes are filled into positions which are not in use and this with a -0 instead of 0 or -999 for missing rings.'' | ||
<pre> | <pre> | ||
606 13 1570 24 31 30 25 26 24 27 27 33 30 | 606 13 1570 24 31 30 25 26 24 27 27 33 30 | ||
| Line 77: | Line 76: | ||
Note, that there exist also .rwl files of the type above but with several other samples written between the segments. | Note, that there exist also .rwl files of the type above but with several other samples written between the segments. | ||
See e.g. [ftp://ftp.ncdc.noaa.gov/pub/data/paleo/treering/measurements/europe/germ011.rwl 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. | See e.g. [ftp://ftp.ncdc.noaa.gov/pub/data/paleo/treering/measurements/europe/germ011.rwl 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== | ==CDendro interpretation== | ||
Revision as of 11:41, 4 July 2009
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.
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