The HARRY_READ_ME.txt file

Part 31

31. And so.. to DTR! First time for generation I think.

Wrote 'makedtr.for' to tackle the thorny problem of the tmin and tmax databases not
being kept in step. Sounds familiar, if worrying. am I the first person to attempt
to get the CRU databases in working order?!! The program pulls no punches. I had
already found that tmx.0702091313.dtb had seven more stations than tmn.0702091313.dtb,
but that hadn't prepared me for the grisly truth:


crua6[/cru/cruts/version_3_0/db/dtr] ./makedtr

MAKEDTR - Produce a DTR database

This program takes as its input a database of
of minimum temperatures and another of maximum
temperatures, and produces a database of diurnal
temperatures. If the input databases are found
to be out of synchronisation, the option is also
given to save synchronised versions.

So, may I please have the tmin database? tmn.0702091139.dtb

May I please now have the tmax database? tmx.0702091313.dtb

The output database will now be called: dtr.0705152339.dtb

IMPORTANT: PLEASE READ! (it's good for you)

The databases you gave are NOT synchronised!

tmn.0702091139.dtb has 42 'extra' stations

tmx.0702091313.dtb has 49 'extra' stations
You have the choice of quitting, or of allowing
me to create two new synchronised databases,
which will be saved and used to create the dtr db

Enter Q to Quit, S to Synchronise: S
New tmin database is: tmn.0705152339.dtb
Discarded tmin stations here: tmn.0702091139.dtb.del
New tmax database is: tmx.0705152339.dtb
Discarded tmax stations here: tmx.0702091313.dtb.del
Number of stations to process: 14267


Yes, the difference is a lot more than seven! And the program helpfully dumps a listing
of the surplus stations to the log file. Not a pretty sight.

Unfortunately, it hadn't worked either. It turns out that there are 3518 stations in
each database with a WMO Code of ' 0'. So, as the makedtr program indexes on the
WMO Code.. you get the picture. *cries*

Rewrote as makedtr2, which uses the first 20 characters of the header to match:


MAKEDTR2 - Produce a DTR database

This program takes as its input a database of
of minimum temperatures and another of maximum
temperatures, and produces a database of diurnal
temperatures. If the input databases are found
to be out of synchronisation, the option is also
given to save synchronised versions.

So, may I please have the tmin database? tmn.0702091139.dtb

May I please now have the tmax database? tmx.0702091313.dtb

The output database will now be called: dtr.0705162028.dtb

IMPORTANT: PLEASE READ! (it's good for you)

The databases you gave are NOT synchronised!

tmn.0702091139.dtb has 203 'extra' stations

tmx.0702091313.dtb has 209 'extra' stations
You have the choice of quitting, or of allowing
me to create two new synchronised databases,
which will be saved and used to create the dtr db

Enter Q to Quit, S to Synchronise: S
New tmin database is: tmn.0705162028.dtb
Discarded tmin stations here: tmn.0702091139.dtb.del
New tmax database is: tmx.0705162028.dtb
Discarded tmax stations here: tmx.0702091313.dtb.del


The big jump in the number of 'surplus' stations is because we are no longer automatically
matching stations with WMO=0.

Here's what happened to the tmin and tmax databases, and the new dtr database:

Old tmin: tmn.0702091139.dtb Total Records Read: 14309
New tmin: tmn.0705162028.dtb Total Records Read: 14106
Del tmin: tmn.0702091139.dtb.del Total Records Read: 203

Old tmax: tmx.0702091313.dtb Total Records Read: 14315
New tmax: tmx.0705162028.dtb Total Records Read: 14106
Del tmax: tmx.0702091313.dtb.del Total Records Read: 209

New dtr: dtr.0705162028.dtb Total Records Read: 14107

*sigh* - one record out! Also three header problems:

BLANKS (expected at 8,14,21,26,47,61,66,71,78)
position missed
8 1
14 1
21 0
26 0
47 1
61 0
66 0
71 0
78 0

Why?!! Well the sad answer is.. because we've got a date wrong. All three 'header' problems
relate to this line:

6190 94 95 98 100 101 101 102 103 102 97 94 94

..and as we know, this is not a conventional header. Oh bum. But, but.. how? I know we do
muck around with the header and start/end years, but still..

Wrote filtertmm.for, which simply steps through one database (usually tmin) and
looks for a 'perfect' match in another database (usually tmax). 'Perfect' here
means a match of WMO Code, Lat, Lon, Start-Year and End-Year. If a match is
found, both stations are copied to new databases:


crua6[/cru/cruts/version_3_0/db/dtr] ./filtertmm

FILTERTMM - Create GOOD tmin/max databases

Please enter the tmin database: tmn.0702091139.dtb

Please enter the tmax database: tmx.0702091313.dtb

working..

Old tmin database: tmn.0702091139.dtb had 14309 stations
New tmin database: tmn.0705182204.dtb has 13016 stations
Old tmax database: tmx.0702091313.dtb had 14315 stations
New tmax database: tmx.0705182204.dtb has 13016 stations


I am going to *assume* that worked! So now.. to incorporate the Australian
monthly data packs. Ow. Most future-proof strategy is probably to write a
converter that takes one or more of the packs and creates CRU-format databases
of them. Edit: nope, thought some more and the *best* strategy is a program
that takes *pairs* of Aus packs and updates the actual databases. Bearing in
mind that these are trusted updates and won't be used in any other context.

From Dave L - who incorporated the initial Australian dump - for the tmin/tmax bulletins,
he used a threshold of 26 days/month or greater for inclusion.

Obtained two files from Dave - an email that explains some of the Australian
bulletin data/formatting, and a list of Austraian headers matched with their
internal codes (the latter being generated by Dave).

Actually.. although I was going to assume that filtertmm had done the synching job OK, a
brief look at the Australian stations in the databases showed me otherwise. For instance,
I pulled all the headers with 'AUSTRALIA' out of the two 0705182204 databases. Now because
these were produced by filtertmm, we know that the codes (if present), lats, lons and dates
will all match. Any differences will be in altitude and/or name. And so they were:

crua6[/cru/cruts/version_3_0/db/dtr] diff tmn.0705182204.dtb.oz tmx.0705182204.dtb.oz | wc -l
336

..so roughly 100 don't match. They are mostly altitude discrepancies, though there are an
alarming number of name mismatches too. Examples of both:

74c74
< 0 -3800 14450 11 AVALON AIRPORT AUSTRALIA 2000 2006 -999 -999.00
---
> 0 -3800 14450 8 AVALON AIRPORT AUSTRALIA 2000 2006 -999 -999.00

16c16
< 0 -4230 14650 585 TARRALEAH VILLAGE AUSTRALIA 2000 2006 -999 -999.00
---
> 0 -4230 14650 595 TARRALEAH CHALET AUSTRALIA 2000 2006 -999 -999.00

Examples of the second kind (name mismatch) are most concerning as they may well be
different stations. Looked for all occurences in all tmin/tmax databases:

crua6[/cru/cruts/version_3_0/db/dtr] grep 'TARRALEAH' *dtb
tmn.0702091139.dtb: 0 -4230 14650 585 TARRALEAH VILLAGE AUSTRALIA 2000 2006 -999 -999.00
tmn.0702091139.dtb:9597000 -4230 14645 595 TARRALEAH CHALET AUSTRALIA 1991 2000 -999 -999.00
tmn.0705182204.dtb: 0 -4230 14650 585 TARRALEAH VILLAGE AUSTRALIA 2000 2006 -999 -999.00
tmn.0705182204.dtb:9597000 -4230 14645 595 TARRALEAH CHALET AUSTRALIA 1991 2000 -999 -999.00
tmx.0702091313.dtb: 0 -4230 14650 595 TARRALEAH CHALET AUSTRALIA 2000 2006 -999 -999.00
tmx.0702091313.dtb:9597000 -4230 14645 595 TARRALEAH CHALET AUSTRALIA 1991 2000 -999 -999.00
tmx.0705182204.dtb: 0 -4230 14650 595 TARRALEAH CHALET AUSTRALIA 2000 2006 -999 -999.00
tmx.0705182204.dtb:9597000 -4230 14645 595 TARRALEAH CHALET AUSTRALIA 1991 2000 -999 -999.00

This takes a little sorting out. Well first, recognise that we are dealing with four files: tmin
and tmax, early and late (before and after filtertmm.for). We see there are two TARRALEAH entries
in each of the four files. We see that 'TARRALEAH VILLAGE' only appears in the tmin file. We see,
most importantly perhaps, that they are temporally contiguous - that is, each pair could join with
minimal overlap, as one is 1991-2000 and the other 2000-2006. Also, we note that the 'early' one
of each pair has a slightly different longitude and altitude (the former being the thing that
distinguished the stations in filtertmm.for).

Finally, this, from the tmax.2005120120051231.txt bulletin:

95018, 051201051231, -42.30, 146.45, 18.0, 00, 31, 31, 585, TARRALEAH VILLAGE

So we can resolve this case - a single station called TARRALEAH VILLAGE, running from 1991 to 2006.

But what about the others?! There are close to 1000 incoming stations in the bulletins, must
every one be identified in this way?!! Oh God. There's nothing for it - I'll have to write a prog
to find matches for the incoming Australian bulletin stations in the main databases. I'll have to
use the databases from before the filtertmm application, so *0705182204.dtb. And it will only
need the Australian headers, so I used grep to create *0705182204.dtb.auhead files. The other
input is the list of stations taken from the monthly bulletins. Now these have a different number
of stations each month, so the prog will build an array of all possible stations based on the
files we have. Oh boy. And the program shall be called, 'auminmaxmatch.for'.

Assembled some information:

crua6[/cru/cruts/version_3_0/db] wc -l *auhead
1518 glseries_tmn_final_merged.auhead
1518 tmn.0611301516.dat.auhead
1518 tmn.0612081255.dat.auhead
1518 tmn.0702091139.dtb.auhead
1518 tmn.0705152339.dtb.auhead
1426 tmn.0705182204.dtb.auhead

(the 'auhead' files were created with )

Actually, stopped work on that. Trying to match over 800 'bulletin' stations against over 3,000
database stations *in two unsynchronised files* was just hurting my brain. The files have to be
properly synchronised first, with a more lenient and interactive version of filtertmm. Or...
could I use mergedb?! Pretend to merge tmin into tmax and see what pairings it managed? No
roll through obviously. Well it's worth a play.

..unfortunately, not. Because when I tried, I got a lot of odd errors followed by a crash. The
reason, I eventually deduced, was that I didn't build mergedb with the idea that WMO codes might
be zero (many of the australian stations have wmo=0). This means that primary matching on WMO
code is impossible. This just gets worse and worse: now it looks as though I'll have to find WMO
Codes (or pseudo-codes) for the *3521* stations in the tmin file that don't have one!!!

OK.. let's break the problem down. Firstly, a lot of stations are going to need WMO codes, if
available. It shouldn't be too hard to find any matches with the existing WMO coded stations in
the other databases (precip, temperature). Secondly, we need to exclude stations that aren't
synchronised between the two databases (tmin/tmax). So can mergedb be modified to treat WMO codes
of 0 as 'missing'? Had a look, and it does check that the code isn't -999 OR 0.. but not when
preallocating flags in subroutine 'countscnd'. Fixed that and tried running it again.. exactly
the same result (crash). I can't see anything odd about the station it crashes on:

0 -2810 11790 407 MOUNT MAGNET AERO AUSTRALIA 2000 2006 -999 -999.00
6190-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999
2000 339 344 280 252 214 202 189 196 262 291 316 377
2001 371 311 310 300 235 212 201 217 249 262 314 333
2002-9999-9999 339 297 258 209 205 212 246 299 341 358
2003 365 367 336 296 249 195 193 200 238 287 325 368
2004 395 374 321 284 219 214 173 188 239 309 305 370
2005 389 396 358 315 251 182 189 201 233 267 332 341
2006 366 331 314 246 240-9999-9999-9999-9999-9999-9999-9999

.. it's very similar to preceding (and following) stations, and the station before has even
less real data (the one before that has none at all and is auto-deleted). The nature of the
crash is 'forrtl: error (65): floating invalid' - so a type mismatch possibly. The station has
a match in the tmin database (tmn.0702091139.dtb) but the longitude is different:

tmn.0702091139.dtb:
0 -2810 11780 407 MOUNT MAGNET AERO AUSTRALIA 2000 2006 -999 -999.00
tmx.0702091313.dtb:
0 -2810 11790 407 MOUNT MAGNET AERO AUSTRALIA 2000 2006 -999 -999.00

It also appears in the tmin/tmax bulletins, eg:
7600, 070401070430, -28.12, 117.84, 16.0, 00, 30, 30, 407, MOUNT MAGNET AERO

Note that the altitude matches (as distinct from the station below).

Naturally, there is a further 'MOUNT MAGNET' station, but it's probably distinct:

tmn.0702091139.dtb:
9442800 -2807 11785 427 MOUNT MAGNET (MOUNT AUSTRALIA 1956 1992 -999 -999.00
tmx.0702091313.dtb:
9442800 -2807 11785 427 MOUNT MAGNET (MOUNT AUSTRALIA 1957 1992 -999 -999.00

I am at a bit of a loss. It will take a very long time to resolve each of these 'rogue'
stations. Time I do not have. The only pragmatic thing to do is to dump any stations that are
too recent to have normals. They will not, after all, be contributing to the output. So I
knocked out 'goodnorm.for', which simply uses the presence of a valid normals line to sort.
The results were pretty scary:


crua6[/cru/cruts/version_3_0/db/dtr] ./goodnorm

GOODNORM: Extract stations with non-missing normals

Please enter the input database name: tmn.0702091139.dtb
The output database will be called: tmn.0705281724.dtb

(removed stations will be placed in: tmn.0705281724.del)

FINISHED.

Stations retained: 5026
Stations removed: 9283

crua6[/cru/cruts/version_3_0/db/dtr] ./goodnorm

GOODNORM: Extract stations with non-missing normals

Please enter the input database name: tmx.0702091313.dtb
The output database will be called: tmx.0705281724.dtb

(removed stations will be placed in: tmx.0705281724.del)

FINISHED.

Stations retained: 4997
Stations removed: 9318



Essentially, two thirds of the stations have no normals! Of course, this still leaves us with
a lot more stations than we had for tmean (goodnorm reported 3316 saved, 1749 deleted) though
still far behind precipitation (goodnorm reported 7910 saved, 8027 deleted).

I suspect the high percentage lost reflects the influx of modern Australian data. Indeed, nearly
3,000 of the 3,500-odd stations with missing WMO codes were excluded by this operation. This means
that, for tmn.0702091139.dtb, 1240 Australian stations were lost, leaving only 278.

This is just silly. I can't dump these stations, they are needed to potentially match with the
bulletin stations. I am now going to try the following:

1. Attempt to pair bulletin stations with existing in the tmin database. Mark pairings in the
database headers and in a new 'Australian Mappings' file. Program auminmatch.for.

2. Run an enhanced filtertmm to synchronise the tmin and tmax databases, but prioritising the
'paired' stations from step 1 (so they are not lost). Mark the same pairings in the tmax
headers too, and update the 'Australian Mappings' file.

3. Add the bulletins to the databases.


OK.. step 1. Modified auminmaxmatch.for to produce auminmatch.for. Hit a semi-philosophical
problem: what to do with a positive match between a bulletin station and a zero-wmo database
station? The station must have a real WMO code or it'll be rather hard to describe the match!

Got a list of around 12,000 wmo codes and stations from Dave L; unfortunately there was a problem
with its formatting that I just couldn't resolve.

So.. current thinking is that, if I find a pairing between a bulletin station and a zero-coded
Australain station in the CRU database, I'll give the CRU database station the Australian local
(bulletin) code twice: once at the end of the header, and once as the WMO code *multiplied by -1*
to avoid implying that it's legitimate. Then if a 'proper' code is found or allocated later, the
mapping to the bulletin code will still be there at the end of the header. Of course, an initial
check will ensure that a match can't be found, within the CRU database, between the zero-coded
station and a properly-coded one.

Debated header formats with David. I think we're going to go with (i8,a8) at the end of the header,
though really it's (2x,i6,a8) as I remember the Anders code being i2 and the real start year being
i4 (both from the tmean database). This will mean post-processing existing databases of course,
but that's not a priority.

A brief (hopefully) diversion to get station counts sorted. David needs them so might as well sort
the procedure. In the upside-down world of Mark and Tim, the numbers of stations contributing to
each cell during the gridding operation are calculated not in the IDL gridding program - oh, no! -
but in anomdtb! Yes, the program which reads station data and writes station data has a second,
almost-entirely unrelated function of assessing gridcell contributions. So, to begin with it runs
in the usual way:

crua6[/cru/cruts/version_3_0/primaries/precip] ./anomdtb

> ***** AnomDTB: converts .dtb to anom .txt for gridding *****

> Enter the suffix of the variable required:
.pre
> Will calculate percentage anomalies.
> Select the .cts or .dtb file to load:
pre.0612181221.dtb

> Specify the start,end of the normals period:
1961,1990
> Specify the missing percentage permitted:
25
> Data required for a normal: 23
> Specify the no. of stdevs at which to reject data:
4

But then, we choose a different output, and it all shifts focus and has to ask all the IDL
questions!!

> Select outputs (1=.cts,2=.ann,3=.txt,4=.stn):
4
> Check for duplicate stns after anomalising? (0=no,>0=km range)
0
> Select the .stn file to save:
pre.stn
> Enter the correlation decay distance:
450
> Submit a grim that contains the appropriate grid.
> Enter the grim filepath:
clim.6190.lan.pre

> Grid dimensions and domain size: 720 360 67420
> Select the first,last years AD to save:
1901,2006
> Operating...

> NORMALS MEAN percent STDEV percent
> .dtb 7315040 73.8
> .cts 299359 3.0 7613600 76.8
> PROCESS DECISION percent %of-chk
> no lat/lon 17911 0.2 0.2
> no normal 2355275 23.8 23.8
> out-of-range 13253 0.1 0.2
> accepted 7521013 75.9
> Calculating station coverages...

And then.. it unhelpfully crashes:

> ##### WithinRange: Alloc: DataB #####
forrtl: severe (174): SIGSEGV, segmentation fault occurred

Ho hum. I did try this last year which is why I'm not tearing my hair out. The plan is to use the
outputs from the regular anomdtb runs - ie, the monthly files of valid stations. After all we need
to know the station counts on a per month basis. We can use the lat and lon, along with the
correlation decay distance.. shouldn't be too awful. Just even more programming and work. So before
I commit to that, a quick look at the IDL gridding prog to see if it can dump the figures instead:
after all, this is where the actual 'station count' information is assembled and used!!

..well that was, erhhh.. 'interesting'. The IDL gridding program calculates whether or not a
station contributes to a cell, using.. graphics. Yes, it plots the station sphere of influence then
checks for the colour white in the output. So there is no guarantee that the station number files,
which are produced *independently* by anomdtb, will reflect what actually happened!!

Well I've just spent 24 hours trying to get Great Circle Distance calculations working in Fortran,
with precisely no success. I've tried the simple method (as used in Tim O's geodist.pro, and the
more complex and accurate method found elsewhere (wiki and other places). Neither give me results
that are anything near reality. FFS.

Worked out an algorithm from scratch. It seems to give better answers than the others, so we'll go
with that. Also decided that the approach I was taking (pick a gridline of latitude and reverse-
engineer the GCD algorithm so the unknown is the second lon) was overcomplicated, when we don't
need to know where it hits, just that it does. Since for any cell the nearest point to the station
will be a vertex, we can test candidate cells for the distance from the appropriate vertex to the
station. Program is stncounts.for, but is causing immense problems.

The problem is, really, the huge numbers of cells potentially involved in one station, particularly
at high latitudes. Working out the possible bounding box when you're within cdd of a pole (ie, for
tmean with a cdd of 1200, the N-S extent is over 20 cells (10 degs) in each direction. Maybe not a
serious problem for the current datasets but an example of the complexity. Also, deciding on the
potential bounding box is nontrivial, because of cell 'width' changes at high latitudes (at 61 degs
North, the half-degree cells are only 27km wide! With a precip cdd of 450 km this means the
bounding box is dozens of cells wide - and will be wider at the Northern edge!

Clearly a large number of cells are being marked as covered by each station. So in densely-stationed
areas there will be considerable smoothing, and in sparsely-stationed (or empty) areas, there will be
possibly untypical data. I might suggest two station counts - one of actual stations contributing from
within the cell, one for stations contributing from within the cdd. The former being a subset of the
latter, so the latter could be used as the previous release was used.

Well, got stncounts.for working, finally. And, out of malicious interest, I dumped the first station's
coverage to a text file and counted up how many cells it 'influenced'. The station was at 10.6E, 61.0N.
The total number of cells covered was a staggering 476! Or, if you prefer, 475 indirect and one direct.

Ran for the first month (01/1901). Compared the resulting grid with that from CRU TS 2.1. Seems to
compare fine, some higher, some lower. Example:

2.10: 139 142 146 154 156 157 165 170
3.00: 141 148 154 153 153 159 163 168

(data are on latitude #265 and longitudes #163-170)

Wrote 'makelsmask.for' to, well, make a land-sea mask. It'll work with any gridded
data file that uses -999 for sea. The mask is called 'lsmask.halfdeg.dat'. Adapted
stncounts.for to read it and use it to mask the output files.

Still a bit disturbed by the large number of cells marked as 'influenced' by a single station. IDL
seems to use the inbuilt 'TRIGRID' function to interpolate the grid, so there's no way of getting
the station count for a particular cell that way anyway. Not that it would mean much, since there
is bound to be some kind of weighting (it's not clear what that weighting is, though, from the IDL
website). So the figures in the station count files are really rather loose. What might be useful
as a companion dataset would be the ACTUAL station counts. Counts for cells with stations actually
INSIDE them. Of course, that might be rather sensitive information..

Managed a full run of stncounts. It took over five and a half hours, which is a bit much!

Back to the gridding. I am seriously worried that our flagship gridded data product is produced by
Delaunay triangulation - apparently linear as well. As far as I can see, this renders the station
counts totally meaningless. It also means that we cannot say exactly how the gridded data is arrived
at from a statistical perspective - since we're using an off-the-shelf product that isn't documented
sufficiently to say that. Why this wasn't coded up in Fortran I don't know - time pressures perhaps?
Was too much effort expended on homogenisation, that there wasn't enough time to write a gridding
procedure? Of course, it's too late for me to fix it too. Meh.

Well, it's been a real day of revelations, never mind the week. This morning I
discovered that proper angular weighted interpolation was coded into the IDL
routine, but that its use was discouraged because it was slow! Aaarrrgghh.
There is even an option to tri-grid at 0.1 degree resolution and then 'rebin'
to 720x360 - also deprecated! And now, just before midnight (so it counts!),
having gone back to the tmin/tmax work, I've found that most if not all of the
Australian bulletin stations have been unceremoniously dumped into the files
without the briefest check for existing stations. A classic example would be
these 'two' stations:

0 -1570 12870 31 KIMBERLEY RES.STATIO AUSTRALIA 2000 2006 -999 -999.00
6190-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999
2000 245 243 243 232 184 143 138 155 193 231 249 249
2001 245 247 241 216 156 167 163 129 201 238 246 247
2002 244 246 230 208 167 122 92 119 202 217 248 259
2003 253 249 222 220 169 151 144 158 203 216 248 250
2004 252 247 244 209 202 135 129 140 176 230 248 257
2005 245 246 237-9999-9999-9999-9999-9999-9999-9999-9999-9999
2006-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999

0 -1565 12871 31 KIMBERLEY RES.STATIO AUSTRALIA 1971 2000 -999 -999.00
6190-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999
1971 254 249 239 218 166 147 142 169 214 246 253 241
1972 246 244 226 198 175 158 126 182 200 222 244 259
1973 255 259 252 232 215 186 171 189 216 240 256 246
1974 247 243 240 217 183 144 134 171 216 247 248 246
1975 239 239 237 216 180 157 168 171 223 233 243 246
1976 235 244 227 190 148 142 142 144 177 236 252 250
1977 253 249 245 218 177 135 130 137 187 226 250 248
1978 247 244 239 199 218 174 162 186 195 233 245 253
1979 247 246 238 217 205 166 147 178 216 234 248 254
1980 249 245 240 221 186 161 141 171 192 241 249 252
1981-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999
1982-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999
1983-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999
1984-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999
1985-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999
1986-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999
1987-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999
1988-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999
1989-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999
1990-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999
1991 248 244 234 224 169 160 160 140 210 225 252 260
1992 253 251 247 239 206-9999 141 173 218 237 246 260
1993 247-9999 242 225 207 172 149 170 204 237 249 258
1994 253-9999 214 196 171 140 130 141 171 222 248 247
1995 245 249 234 205 186 155 148 151 198 217 245 244
1996 245 238 220 208 159 166 136 161 179 225 233 247
1997 245 243 217 195 186 149 138 156 195 230 242 247
1998 248 250 245 229 188 167 177 158 200 247 253 250
1999 250 245 242 216 144 150 123-9999 188 239 240 251
2000 245 243 243 232 184 143 138 154 194 231 249 249

Now, I admit the lats and lons aren't spot on. But c'mon, what are the chances
of them being different? The two year 2000s are almost identical. What about:

0 -1550 12450 12 KURI BAY AUSTRALIA 2000 2006 -999 -999.00
9420800 -1548 12452 29 KURI BAY AUSTRALIA 1965 1992 -999 -999.00

Or:

0 -1550 12810 11 WYNDHAM AUSTRALIA 2000 2006 -999 -999.00
0 -1550 12820 4 WYNDHAM AERO AUSTRALIA 2000 2006 -999 -999.00
9421400 -1549 12812 11 WYNDHAM POST OFFICE AUSTRALIA 1968 2000 -999 -999.00
9421401 -1547 12810 20 WYNDHAM (WYNDHAM POR AUSTRALIA 1898 1966 -999 -999.00

Come On!! This is one station isn't it.

I'd be content to leave it - but I have to match the bulletins! And I can match
to the long, stable series or to the loose, flapping ones put in for the
purpose! Meh II.

So.. in the end I matched to the 2000-2006 stations, where they actually did match.
Unfortunately the huge bulk of the bulletins still had to have new entries created for
them, which is a shame, and begs the question of why the Australian update bulletins
don't match the original 'catch-up' block they sent us.

For some reason, the auminmatch program is causing no end of grief. I thought I'd
managed a complete run, and it did produce a good-looking tmin database with lots of
new station stubs tacked on the end:

-1009 -6628 11054 12 KURI BAY AUSTRALIA 2007 2007 -999 1009
6190-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999
2006-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999
-1019 -6628 11054 23 KALUMBURU AUSTRALIA 2007 2007 -999 1019
6190-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999
2006-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999
-1020 -6628 11054 51 TRUSCOTT AUSTRALIA 2007 2007 -999 1020
6190-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999
2006-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999-9999

However, it doesn't seem to have put the bulletin codes on the (a8) header field, for
some of the matches only!

Not sure why this is yet.. but have found also that there are cases of duplicated lat/lon pairs,
so multiple matches are being made.. argh.. will have to further augment auminmatch. Not happy.

An interesting aside.. David was looking at the v3.00 precip to help National Geographic with
an enquiry. I produced a second 'station' file with the 'honest' counts (see above) and he used
that to mask out cells with a 0 count (ie that only had indirect data from 'nearby' stations).
There were some odd results.. with certain months havign data, and others being missing. After
considerable debate and investigation, it was understood that anomdtb calculates normals on a
monthly basis. So, where there are 7 or 8 missing values in each month (1961-1990), a station
may end up contributing only in certain months of the year, throughout its entire run! This was
noticed in the Seychelles, where only October has real data (the remaining months being relaxed
to the climatology but excluded by David using the 'tight' station mask). There is no easy
solution, because essentially it's an honest result: only October has sufficient values to form
a normal, so only October gets anomalised. It's an unfortunate concidence that it's the only
station in the cell, but it's not the only one. A 'solution' could be for anomdtb to get a bit
more involved in the gridding, to check that if a cell only has one station (for one or more
years) then it's all-or-nothing. Maybe if only one month has a normal then it's dumped and the
whole reverts to climatology. Maybe if 4 or more months have normals.. maybe if >0 months have
normals and the rest can be brought in with a minor relaxation of the '75% rule'.. who knows.

Back to auminmatch.for, and a (philosophical) breakthrough. Built a loop to find 'fuzzy'
matches and group them together. The user then processes one group at a time, pairing up
matches until the potential for further matches is zero (or the user decides it is). Uses a
FSM to work out each chain (all db matches for a bulletin, then all bulletins that match
each of those db stations, then.. etc). To understand it, either read the code (especially
the comments) or just look at this mind-boggling example from the first run of it:

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
User Match Decision(s) Please!
Bulletin stations: 8
1. 9021 -3193 11598 15 PERTH AIRPORT
2. 9225 -3192 11587 25 PERTH METRO
3. 9106 -3205 11598 10 GOSNELLS CITY
4. 9240 -3201 11614 384 BICKLEY
5. 9172 -3210 11588 30 JANDAKOT AERO
6. 9215 -3196 11576 41 SWANBOURNE
7. 9194 -3222 11581 14 MEDINA RESEARCH CENT
8. 9256 -3224 11568 6 GARDEN ISLAND HSF
Database stations: 18
1. 0 -3190 11590 25 PERTH METRO 2000 2006
2. 0 -3190 11600 15 PERTH AIRPORT 2000 2006
3. 9461000 -3190 11600 20 PERTH AIRPORT COMPAR 1944 2006
4. 9461001 -3190 11600 18 PERTH AIRPORT 1944 2004
5. 9461501 -3198 11607 210 KALAMUNDA (KALAMUNDA 1908 1992
6. 0 -3200 11580 41 SWANBOURNE 2000 2006
7. 0 -3200 11580 20 SUBIACO TREATMENT PL 2000 2006
8. 0 -3196 11579 20 SUBIACO TREATMENT PL 1991 1999
9. 9460800 -3195 11587 19 PERTH (PERTH REGIONA 1897 1992
10. 9460801 -3195 11587 19 PERTH-(PERTH-REGIONA 1897 1992
11. 0 -3210 11590 30 JANDAKOT AERO 2000 2006
12. 0 -3210 11600 10 GOSNELLS CITY 2000 2006
13. 0 -3200 11610 384 BICKLEY 2000 2006
14. 0 -3220 11580 14 MEDINA RESEARCH CENT 2000 2006
15. 0 -3220 11580 4 KWINANA BP REFINERY 2000 2006
16. 0 -3223 11576 4 KWINANA BP REFINERY 1961 2000
17. 9560800 -3222 11581 14 MEDINA RESEARCH CENT 1991 2000
18. 0 -3220 11570 6 GARDEN ISLAND HSF 2000 2006

Enter a matching pair, (bulletin,database) or 'n' to end: 1,2
Bulletin stations: 7
2. 9225 -3192 11587 25 PERTH METRO
3. 9106 -3205 11598 10 GOSNELLS CITY
4. 9240 -3201 11614 384 BICKLEY
5. 9172 -3210 11588 30 JANDAKOT AERO
6. 9215 -3196 11576 41 SWANBOURNE
7. 9194 -3222 11581 14 MEDINA RESEARCH CENT
8. 9256 -3224 11568 6 GARDEN ISLAND HSF
Database stations: 17
1. 0 -3190 11590 25 PERTH METRO 2000 2006
3. 9461000 -3190 11600 20 PERTH AIRPORT COMPAR 1944 2006
4. 9461001 -3190 11600 18 PERTH AIRPORT 1944 2004
5. 9461501 -3198 11607 210 KALAMUNDA (KALAMUNDA 1908 1992
6. 0 -3200 11580 41 SWANBOURNE 2000 2006
7. 0 -3200 11580 20 SUBIACO TREATMENT PL 2000 2006
8. 0 -3196 11579 20 SUBIACO TREATMENT PL 1991 1999
9. 9460800 -3195 11587 19 PERTH (PERTH REGIONA 1897 1992
10. 9460801 -3195 11587 19 PERTH-(PERTH-REGIONA 1897 1992
11. 0 -3210 11590 30 JANDAKOT AERO 2000 2006
12. 0 -3210 11600 10 GOSNELLS CITY 2000 2006
13. 0 -3200 11610 384 BICKLEY 2000 2006
14. 0 -3220 11580 14 MEDINA RESEARCH CENT 2000 2006
15. 0 -3220 11580 4 KWINANA BP REFINERY 2000 2006
16. 0 -3223 11576 4 KWINANA BP REFINERY 1961 2000
17. 9560800 -3222 11581 14 MEDINA RESEARCH CENT 1991 2000
18. 0 -3220 11570 6 GARDEN ISLAND HSF 2000 2006

Enter a matching pair, (bulletin,database) or 'n' to end: 2,1
Bulletin stations: 6
3. 9106 -3205 11598 10 GOSNELLS CITY
4. 9240 -3201 11614 384 BICKLEY
5. 9172 -3210 11588 30 JANDAKOT AERO
6. 9215 -3196 11576 41 SWANBOURNE
7. 9194 -3222 11581 14 MEDINA RESEARCH CENT
8. 9256 -3224 11568 6 GARDEN ISLAND HSF
Database stations: 16
3. 9461000 -3190 11600 20 PERTH AIRPORT COMPAR 1944 2006
4. 9461001 -3190 11600 18 PERTH AIRPORT 1944 2004
5. 9461501 -3198 11607 210 KALAMUNDA (KALAMUNDA 1908 1992
6. 0 -3200 11580 41 SWANBOURNE 2000 2006
7. 0 -3200 11580 20 SUBIACO TREATMENT PL 2000 2006
8. 0 -3196 11579 20 SUBIACO TREATMENT PL 1991 1999
9. 9460800 -3195 11587 19 PERTH (PERTH REGIONA 1897 1992
10. 9460801 -3195 11587 19 PERTH-(PERTH-REGIONA 1897 1992
11. 0 -3210 11590 30 JANDAKOT AERO 2000 2006
12. 0 -3210 11600 10 GOSNELLS CITY 2000 2006
13. 0 -3200 11610 384 BICKLEY 2000 2006
14. 0 -3220 11580 14 MEDINA RESEARCH CENT 2000 2006
15. 0 -3220 11580 4 KWINANA BP REFINERY 2000 2006
16. 0 -3223 11576 4 KWINANA BP REFINERY 1961 2000
17. 9560800 -3222 11581 14 MEDINA RESEARCH CENT 1991 2000
18. 0 -3220 11570 6 GARDEN ISLAND HSF 2000 2006

Enter a matching pair, (bulletin,database) or 'n' to end: 3,12
Bulletin stations: 5
4. 9240 -3201 11614 384 BICKLEY
5. 9172 -3210 11588 30 JANDAKOT AERO
6. 9215 -3196 11576 41 SWANBOURNE
7. 9194 -3222 11581 14 MEDINA RESEARCH CENT
8. 9256 -3224 11568 6 GARDEN ISLAND HSF
Database stations: 15
3. 9461000 -3190 11600 20 PERTH AIRPORT COMPAR 1944 2006
4. 9461001 -3190 11600 18 PERTH AIRPORT 1944 2004
5. 9461501 -3198 11607 210 KALAMUNDA (KALAMUNDA 1908 1992
6. 0 -3200 11580 41 SWANBOURNE 2000 2006
7. 0 -3200 11580 20 SUBIACO TREATMENT PL 2000 2006
8. 0 -3196 11579 20 SUBIACO TREATMENT PL 1991 1999
9. 9460800 -3195 11587 19 PERTH (PERTH REGIONA 1897 1992
10. 9460801 -3195 11587 19 PERTH-(PERTH-REGIONA 1897 1992
11. 0 -3210 11590 30 JANDAKOT AERO 2000 2006
13. 0 -3200 11610 384 BICKLEY 2000 2006
14. 0 -3220 11580 14 MEDINA RESEARCH CENT 2000 2006
15. 0 -3220 11580 4 KWINANA BP REFINERY 2000 2006
16. 0 -3223 11576 4 KWINANA BP REFINERY 1961 2000
17. 9560800 -3222 11581 14 MEDINA RESEARCH CENT 1991 2000
18. 0 -3220 11570 6 GARDEN ISLAND HSF 2000 2006

Enter a matching pair, (bulletin,database) or 'n' to end: 4,13
Bulletin stations: 4
5. 9172 -3210 11588 30 JANDAKOT AERO
6. 9215 -3196 11576 41 SWANBOURNE
7. 9194 -3222 11581 14 MEDINA RESEARCH CENT
8. 9256 -3224 11568 6 GARDEN ISLAND HSF
Database stations: 14
3. 9461000 -3190 11600 20 PERTH AIRPORT COMPAR 1944 2006
4. 9461001 -3190 11600 18 PERTH AIRPORT 1944 2004
5. 9461501 -3198 11607 210 KALAMUNDA (KALAMUNDA 1908 1992
6. 0 -3200 11580 41 SWANBOURNE 2000 2006
7. 0 -3200 11580 20 SUBIACO TREATMENT PL 2000 2006
8. 0 -3196 11579 20 SUBIACO TREATMENT PL 1991 1999
9. 9460800 -3195 11587 19 PERTH (PERTH REGIONA 1897 1992
10. 9460801 -3195 11587 19 PERTH-(PERTH-REGIONA 1897 1992
11. 0 -3210 11590 30 JANDAKOT AERO 2000 2006
14. 0 -3220 11580 14 MEDINA RESEARCH CENT 2000 2006
15. 0 -3220 11580 4 KWINANA BP REFINERY 2000 2006
16. 0 -3223 11576 4 KWINANA BP REFINERY 1961 2000
17. 9560800 -3222 11581 14 MEDINA RESEARCH CENT 1991 2000
18. 0 -3220 11570 6 GARDEN ISLAND HSF 2000 2006

Enter a matching pair, (bulletin,database) or 'n' to end: 5,11
Bulletin stations: 3
6. 9215 -3196 11576 41 SWANBOURNE
7. 9194 -3222 11581 14 MEDINA RESEARCH CENT
8. 9256 -3224 11568 6 GARDEN ISLAND HSF
Database stations: 13
3. 9461000 -3190 11600 20 PERTH AIRPORT COMPAR 1944 2006
4. 9461001 -3190 11600 18 PERTH AIRPORT 1944 2004
5. 9461501 -3198 11607 210 KALAMUNDA (KALAMUNDA 1908 1992
6. 0 -3200 11580 41 SWANBOURNE 2000 2006
7. 0 -3200 11580 20 SUBIACO TREATMENT PL 2000 2006
8. 0 -3196 11579 20 SUBIACO TREATMENT PL 1991 1999
9. 9460800 -3195 11587 19 PERTH (PERTH REGIONA 1897 1992
10. 9460801 -3195 11587 19 PERTH-(PERTH-REGIONA 1897 1992
14. 0 -3220 11580 14 MEDINA RESEARCH CENT 2000 2006
15. 0 -3220 11580 4 KWINANA BP REFINERY 2000 2006
16. 0 -3223 11576 4 KWINANA BP REFINERY 1961 2000
17. 9560800 -3222 11581 14 MEDINA RESEARCH CENT 1991 2000
18. 0 -3220 11570 6 GARDEN ISLAND HSF 2000 2006

Enter a matching pair, (bulletin,database) or 'n' to end: 6,6
Bulletin stations: 2
7. 9194 -3222 11581 14 MEDINA RESEARCH CENT
8. 9256 -3224 11568 6 GARDEN ISLAND HSF
Database stations: 12
3. 9461000 -3190 11600 20 PERTH AIRPORT COMPAR 1944 2006
4. 9461001 -3190 11600 18 PERTH AIRPORT 1944 2004
5. 9461501 -3198 11607 210 KALAMUNDA (KALAMUNDA 1908 1992
7. 0 -3200 11580 20 SUBIACO TREATMENT PL 2000 2006
8. 0 -3196 11579 20 SUBIACO TREATMENT PL 1991 1999
9. 9460800 -3195 11587 19 PERTH (PERTH REGIONA 1897 1992
10. 9460801 -3195 11587 19 PERTH-(PERTH-REGIONA 1897 1992
14. 0 -3220 11580 14 MEDINA RESEARCH CENT 2000 2006
15. 0 -3220 11580 4 KWINANA BP REFINERY 2000 2006
16. 0 -3223 11576 4 KWINANA BP REFINERY 1961 2000
17. 9560800 -3222 11581 14 MEDINA RESEARCH CENT 1991 2000
18. 0 -3220 11570 6 GARDEN ISLAND HSF 2000 2006

Enter a matching pair, (bulletin,database) or 'n' to end: 7,14
Bulletin stations: 1
8. 9256 -3224 11568 6 GARDEN ISLAND HSF
Database stations: 11
3. 9461000 -3190 11600 20 PERTH AIRPORT COMPAR 1944 2006
4. 9461001 -3190 11600 18 PERTH AIRPORT 1944 2004
5. 9461501 -3198 11607 210 KALAMUNDA (KALAMUNDA 1908 1992
7. 0 -3200 11580 20 SUBIACO TREATMENT PL 2000 2006
8. 0 -3196 11579 20 SUBIACO TREATMENT PL 1991 1999
9. 9460800 -3195 11587 19 PERTH (PERTH REGIONA 1897 1992
10. 9460801 -3195 11587 19 PERTH-(PERTH-REGIONA 1897 1992
15. 0 -3220 11580 4 KWINANA BP REFINERY 2000 2006
16. 0 -3223 11576 4 KWINANA BP REFINERY 1961 2000
17. 9560800 -3222 11581 14 MEDINA RESEARCH CENT 1991 2000
18. 0 -3220 11570 6 GARDEN ISLAND HSF 2000 2006

Enter a matching pair, (bulletin,database) or 'n' to end: 8,18
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Amazing, huh? Most are actually more like this:

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
User Match Decision(s) Please!
Bulletin stations: 1
1. 9053 -3167 11602 40 PEARCE RAAF
Database stations: 2
1. 0 -3170 11600 40 PEARCE RAAF 2000 2006
2. 9461200 -3167 11602 49 BULLSBROOK (PEARCE A 1940 1992

Enter a matching pair, (bulletin,database) or 'n' to end: 1,1
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

However.. still teething troubles, with previously-paired stations reappearing
for a second chance sometimes! So more debugging.. fixed. Also added a test
before the user gets a chain, to anticipate what the user (er, I) would do. For
instance, I generally match to a 200-2006, WMO=0 database station if the names
match, as they're the ones David L put in from the Aus update files. I, er, the
user then gets ambiguities and nearby but unconnected stations. Fine, until you
get a nasty surprise like this one:

User Match Decision(s) Please!
Bulletin stations: 2
1. 58009 -2864 15364 95 BYRON BAY (CAPE BYRO
2. 58216 -2864 15364 95 BYRON BAY (CAPE BYRO
Database stations: 3
1. 0 -2860 15360 95 BYRON BAY (CAPE BYRO 2000 2006
2. 0 -2860 15360 95 BYRON BAY (CAPE BYRO 2000 2006
3. 9459500 -2863 15363 98 CAPE BYRON 1974 1992

Looking in the files I see that Bulletin 58009 is 'BYRON BAY (CAPE BYRON LIGHTHOUSE)',
and 58216 is 'BYRON BAY (CAPE BYRON AWS)'. But the database stubs that have been
entered have not been intelligently named, just truncated - so I have no way of
knowing which is which! CRU NEEDS A DATA MANAGER. In this case I had to assume that
the updates were processed in .au code order, so 1-1 and 2-2. Argh. A few doubles
found, too:

Bulletin stations: 1
1. 33106 -2037 14895 59 HAMILTON ISLAND AIRP
Database stations: 3
1. 0 -2040 14900 23 HAMILTON ISLAND AIRP 2000 2006
2. 0 -2040 14900 59 HAMILTON ISLAND AIRP 2000 2006
3. 9436800 -2035 14895 23 HAMILTON ISLAND AIRP 1991 2000

Bulletin stations: 1
1. 90186 -3829 14245 71 WARRNAMBOOL AIRPORT
Database stations: 4
1. 0 -3830 14250 71 WARRNAMBOOL AIRPORT 2000 2006
2. 0 -3830 14240 75 WARRNAMBOOL AIRPORT 2000 2006
3. 0 -3840 14248 21 WARRNAMBOOL (POST OF 1961 1980
4. 0 -3828 14243 76 WARRNAMBOOL A 1983 1999

And the results? Strictly average, I thought.. but I'd forgotten to count the extra
'anticipated match' routine achievements! So I grepped the match-by-match file,
matches.0706281447.dat, and got:

crua6[/cru/cruts/version_3_0/db/dtr] grep 'AUTO\:' matches.0706281447.dat |wc -l
232
crua6[/cru/cruts/version_3_0/db/dtr] grep 'AUTO FROM CHAIN' matches.0706281447.dat | wc -l
514
crua6[/cru/cruts/version_3_0/db/dtr] grep 'MANUAL' matches.0706281447.dat | wc -l
12

In other words, all that sweat was worth it - 746 stations matched automatically, and
a further 12 manually! Only (797-758=) 39 bulletins unmatched! Wheeee! And here they are:

-6072 -2303 11504 111 EMU CREEK STATION AUSTRALIA 2007 2007 -999 6072
-12044 -3355 12070 220 MUNGLINUP WEST AUSTRALIA 2007 2007 -999 12044
-12241 -2888 12132 370 LEONORA AERO AUSTRALIA 2007 2007 -999 12241
-17031 -2965 13806 50 MARREE COMPARISON AUSTRALIA 2007 2007 -999 17031
-21118 -3323 13800 10 PORT PIRIE AERODROME AUSTRALIA 2007 2007 -999 21118
-22801 -3575 13659 143 CAPE BORDA COMPARISO AUSTRALIA 2007 2007 -999 22801
-23122 -3451 13868 65 ROSEWORTHY AWS AUSTRALIA 2007 2007 -999 23122
-24521 -3512 13926 33 MURRAY BRIDGE COMPAR AUSTRALIA 2007 2007 -999 24521
-25509 -3533 14052 99 LAMEROO COMPARISON AUSTRALIA 2007 2007 -999 25509
-26026 -3716 13976 3 ROBE COMPARISON AUSTRALIA 2007 2007 -999 26026
-32004 -1826 14602 5 CARDWELL MARINE PDE AUSTRALIA 2007 2007 -999 32004
-35019 -2282 14764 260 CLERMONT SIRIUS ST AUSTRALIA 2007 2007 -999 35019
-48243 -2943 14797 154 LIGHTNING RIDGE VISI AUSTRALIA 2007 2007 -999 48243
-55024 -3103 15027 307 GUNNEDAH RESOURCE CE AUSTRALIA 2007 2007 -999 55024
-56037 -3053 15167 987 ARMIDALE (TREE GROUP AUSTRALIA 2007 2007 -999 56037
-60013 -3218 15251 4 FORSTER - TUNCURRY R AUSTRALIA 2007 2007 -999 60013
-63039 -3371 15031 1015 KATOOMBA (MURRI ST) AUSTRALIA 2007 2007 -999 63039
-63226 -3348 15013 900 LITHGOW (COOERWULL) AUSTRALIA 2007 2007 -999 63226
-68257 -3406 15077 112 CAMPBELLTOWN (MOUNT AUSTRALIA 2007 2007 -999 68257
-70263 -3475 14970 670 GOULBURN TAFE AUSTRALIA 2007 2007 -999 70263
-82170 -3655 14600 171 BENALLA AIRPORT AUSTRALIA 2007 2007 -999 82170
-84150 -3787 14801 4 LAKES ENTRANCE (EAST AUSTRALIA 2007 2007 -999 84150
-85099 -3863 14581 3 POUND CREEK AUSTRALIA 2007 2007 -999 85099
-88023 -3723 14591 230 LAKE EILDON AUSTRALIA 2007 2007 -999 88023
-200001 -2166 15027 209 MIDDLE PERCY ISLAND AUSTRALIA 2007 2007 -999 200001
-200100 -2066 11558 24 VARANUS ISLAND AUSTRALIA 2007 2007 -999 200100
-200212 -1061 12598 -999 NORTHERN ENDEAVOUR AUSTRALIA 2007 2007 -999 200212
-200283 -1629 14997 8 WILLIS ISLAND AUSTRALIA 2007 2007 -999 200283
-200288 -2904 16794 112 NORFOLK ISLAND AERO AUSTRALIA 2007 2007 -999 200288
-200731 -1176 13003 7 POINT FAWCETT AUSTRALIA 2007 2007 -999 200731
-200783 -1772 14845 3 FLINDERS REEF AUSTRALIA 2007 2007 -999 200783
-200790 -1045 10569 261 CHRISTMAS ISLAND AER AUSTRALIA 2007 2007 -999 200790
-200824 -1753 21040 2 PAPEETE AUSTRALIA 2007 2007 -999 200824
-200838 -3922 14698 116 HOGAN ISLAND AUSTRALIA 2007 2007 -999 200838
-200851 -52 16692 7 NAURU ARCS-2 AUSTRALIA 2007 2007 -999 200851
-200852 -206 14743 4 MANUS ARCS-1 AUSTRALIA 2007 2007 -999 200852
-300000 -6858 7797 18 DAVIS AUSTRALIA 2007 2007 -999 300000
-300001 -6760 6287 10 MAWSON AUSTRALIA 2007 2007 -999 300001
-300017 -6628 11054 40 CASEY AUSTRALIA 2007 2007 -999 300017

Resultant database: tmn.0707021605.dtb

[edit: found another fault, had to re-run. Headers weren't being modded if the WMO code was
already there]


Go on to part 32, back to index or Email search