Tucson format: Difference between revisions
| Line 46: | Line 46: | ||
NM002 1632 90 92 91 174 84 45 185 111 | NM002 1632 90 92 91 174 84 45 185 111 | ||
NM002 1640 116 72 91 49 85 146 125 126 136 131</pre> | NM002 1640 116 72 91 49 85 146 125 126 136 131</pre> | ||
''The usual ending and start of samples ( | ''The usual ending and start of samples (0.01 mm units resolution)'' | ||
| Line 61: | Line 61: | ||
''This snappet from brit045.rwl<ref>{{itrdb|brit045|europe}}</ref> looks very much normal, but ends with two Asciichar(13) characters which will not be trimmed away by the VB Trim function.'' | ''This snappet from brit045.rwl<ref>{{itrdb|brit045|europe}}</ref> looks very much normal, but ends with two Asciichar(13) characters which will not be trimmed away by the VB Trim function.'' | ||
Revision as of 17:53, 9 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.
Basics of the Tucson format for ring width data
A Tucson file usually consists of three lines of meta data followed by an undefined number of data lines. Ring width data is written as integers either in units of 0.01 mm or in units of 0.001 mm 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) followed by ring width data, up to ten rings per line. Except for the first and last lines of each core, there are always measurements for one full decade per line.
After the youngest ring there is a stop marker as an extra value. The stop marker depends on the resolution used:
- When using 0.01 mm as the unit of measure, the stop marker is "999"
- When using 0.001 mm as the unit of measure, the stop marker is "-9999"
I.e. the stop marker is used to show not only the end of the series but also the units of measurement used (0.01 mm or 0.001 mm)!
The missing data mark is actually not defined, though usually the mark "-999" is used within 0.01 mm files, and "0" in 0.001 mm files.
Note 1: The consequence of using the value 999 as a stop marker is that a measurement of 9.99 mm, in 0.01 mm units, has to be changed
into 9.98 mm (written value=998) or 10.00 mm (1000)! To avoid fooling any other software, it is probably best never to write the value "999" as measurement data also for files with 0.001 mm units!
Note 2: If 5 digits are needed for the year number, i.e. a core older than -999, the identity cannot be more than 7 alphanumeric characters.
Note 3: An ITRDB specification of the Tucson format is found here: [1] though that specification cannot be
fully trusted. E.g. it currently (2009-07-09) specifies the missing data mark to be 999, which value in reality is used as the stop marker.
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 sample saved in 0.01 mm units, 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.
PMkr12b 1781 1200 870 690 1220 1080 850 1250 1140 770 PMkr12b 1790 1340 1310 1140 970 1170 490 690 1000 1230 890 PMkr12b 1800 1370 890 0 790 440 380 620 990 680 260 PMkr12b 1810 270 430 510 570 360 -9999
The same sample written in 0.001 mm units. Note the missing data mark which is here "0".
Examples
The Tucson format standard is sometimes interpreted in ways that will make the programming a bit hard. The following examples are taken from files in ITRDB but also from other sources.
- 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 (0.01 mm units 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[1] 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[2] looks very much normal, but ends with two Asciichar(13) characters which will not be trimmed away by the VB Trim function.
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.[3] 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[4] 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.[5] 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"
OMA0851A1623 232 126 216 213 157 258 263 . . . OMA0851A1630 246 182 174 187 240 175 169 173 149 150 ... OMA0851A1810 29 33 30 31 30 41 38 32 52 65 OMA0851A1820 47 57 55 40 999 . . . . . OMA0851B1623 216 142 209 181 207 273 265 . . . OMA0851B1630 189 172 162 153 155 145 147 150 157 155 OMA0851B1640 166 138 132 105 99 107 129 69 78 86 OMA0851B1650 140 156 60 47 35 75 26 41 50 37 ... OMA0851B1840 14 15 15 12 12 11 13 10 11 11 OMA0851B1850 6 8 999 . . . . . . . OMA0852A1692 140 161 151 144 97 122 149 160 . . OMA0852A1700 222 237 251 153 185 191 234 293 189 159 OMA0852A1710 213 182 174 213 114 136 143 129 170 130 ...
Example from the Finnish Tree ring data bank of Saima With this layout each "unused position" is marked with a dot (.).
CDendro interpretation
Using comments
When various dendrochronology programs are described, it is often noted that lines that cannot be interpreted as ring width data lines are considered as comments. That feature is used by CDendro. Comments may then be bound both to the .rwl file (the sample collection) itself and to individual members (samples) of the collection.
SN 1 Saltsjobaden PISY SN 2 SWEDEN Scots pine 5917N1818E 1696 2005 SN 3 Lars-Ake Larsson SN #### Samples taken from living or fallen trees except the group SNKBxx, which are poles of an old pier SN #### (Kolbryggan) in the bay Palnasviken, which have been standing in clay for a 110 years. SN #### The sample SNSU01 is taken from the Skutudden cottage. SN001A 1923 341 374 369 298 500 382 396 SN001A 1930 332 297 421 250 290 288 317 320 256 215 SN001A 1940 111 183 229 183 159 157 163 134 105 111 SN001A 1950 81 62 89 138 164 180 138 157 170 130 SN001A 1960 108 184 137 148 124 164 80 98 105 67 SN001A 1970 57 89 126 101 114 100 83 76 71 57 SN001A 1980 114 87 79 85 56 49 61 79 81 70 SN001A 1990 99 139 132 161 132 118 999 SN001A #### You may store comments for a sample too SN001A #### and it may extend over several lines. SN001B 1923 329 375 319 299 435 366 384 SN001B 1930 287 258 392 280 251 293 296 278 200 181 SN001B 1940 114 154 224 160 138 106 127 126 97 96 SN001B 1950 68 65 83 114 168 176 91 163 189 146
Example of .rwl file with comments created with CDendro
Meta data
Meta data that is collect from e.g. a Heidelberg file can be written by CDendro to a .rwl file:
... 1AD0046A1500 54 64 64 67 64 54 61 71 78 81 1AD0046A1510 84 94 105 84 108 108 115 88 135 108 1AD0046A1520 111 98 121 94 138 118 111 94 108 105 1AD0046A1530 999 1AD0046A#### Location=Stockholm; Species=PISY; TreeNo=0; 1AD0046A#### CoreNo=0; Project=123;
Naming standard
Limitations of the Tucson format
- The amount of meta data is limited to what is specified for the three first lines of a .rwl file. Then we should also be aware that the syntax of that meta data is not very specified, i.e. in practice it will be almost free text.
- If meta data is stored as comments with a special syntax, then we have to recognize that there is no common specification for how that meta data should be named and specified.
- There is no specification on how Latewood and Earlywood should be stored within the same .rwl file.
- There is no specification on e.g. a naming standard to allow for keeping radii from the same stem together, though see also CDendro naming standard