Greg has come back. Apparently, it's not all profiles which have missing data in the BUFR,
only some. Having re-dumped all 62 of Gregs set of profiles there are indeed some with
missing lat_tp/lon_tp. My sampling clearly skipped over these, and thinking all lat/lon
values were claimed to be missing (and were shown not to be), problem not ours.
Re-encoding using v3.0 ropp2bufr with -p0 switch (suppress all thinning) 'solves' the missing
lat/lons. I suspect (but need to test) that any of the non-sample methods will work correctly,
and we have a regression bug in the default sampling-to-no-more-than-[375] code.
This Ticket re-opened to investigate this part of the thinner.
Meanwhile, Torsten should be advised re-encode TerraSAR-X data for NCEP using -p0 (or apply the log-247 thinner file)
Greg's email below:
Hi Dave,
You recall that I was trying to find out why I'm seeing missing latitude and longitude
values in various replication sequences of the sample TerraSAR-X BUFR data provided by GFZ,
whereas you and GFZ were not seeing any of these missing values. I'm finally getting
around to looking at the three output files (bufr01, bufr31, and bufr62) you provided in
your last message to me from December. I was wondering. Did the bufr01 file contain
everything in the entire message number 1 of the file dated 07/24/08 that I provided
or was it just the first subset of that message? The latitudes and longitudes (and e
verything else, even other parameters with missing values) match with what I got through
the end of the first subset. However, I see two more subsets after the first subset and
in the second subset under message number 1, I see in my file an initial latitude/longitude
of 69.37100/-29.13200, but then in all of the replications for that subset, the Lat/Lon
is missing. If you still have my sample BUFR file available, could you send an output
file (or several output files, depending on the size) of the other two subsets under
message number 1 at the beginning of that BUFR file, so that I can continue to compare
that message number? If you need another copy of my sample BUFR file, let me know, and
I will resend it to you.
I also noticed that the bufr31 output file is actually the first subset of message
number 11, while the bufr62 output file contains the first and only subset of message
number 1 from a different tank (11/03/08). It appears the data from these first
subsets all match. If we can just verify the subsequent subsets under message
number 1 of the tank from 07/24/08, we should be able to figure everything out soon.
Thanks in advance for continuing to help us in this matter, Greg Krasowski
