Here’s a story about how one missing letter, an M, can wreck a whole month’s worth of climate data. It is one of the longest posts ever made on WUWT, I spent almost my entire Saturday on it. I think it might also be one of the most important because it demonstrates a serious weakness in surface data reporting.
In my last post, we talked about the a curious temperature anomaly that Jean S. found in the March GISS data and posted at Climate Audit:
The anomaly over Finland has an interesting signature to it, and the correction that GISS posted on their website confirms something I’ve been looking at for a few months.
The data shown between 4/13 and 4/15 were based on data downloaded on 4/12 and included some station reports from Finland in which the minus sign may have been dropped.
With some work I started back in late December and through January, and with GISS putting stamp of approval on “missing minus signs” I can now demonstrate that missing minus signs aren’t just an odd event, they happen with regularity, and the effect is quite pronounced when it does happen. This goes to the very heart of data gathering integrity and is rooted in simple human error. The fault lies not with GISS (though now they need a new quality control feature) but mostly with NOAA/NCDC who manages the GHCN and who also needs better quality control. The error originates at the airport, likely with a guy sitting in the control tower. Readers who are pilots will understand this when they see what I’m talking about.
I’ve seen this error happen all over the world. Please read on and be patient, there is a lot of minutiae that must be discussed to properly frame the issue. I have to start at the very bottom of the climate data food-chain and work upwards.
First, a discussion about the root of error and the differences between the surface and satellite dataset. I should mention that in the satellite image from NASA’s Earth Observations (NEO), we don’t see the same error as we see in the GISTEMP map above.
Why? Better sensors, maybe, but mostly it has to do with a different data gathering methodology. In the surface data sets, including land and ocean data, most every datapoint is touched by a human hand, even airport data that gets done by automated airport sensors sometimes gets transcribed manually (often in third world and technologically stunted countries). In the surface data, thousands of sensors are spread across the globe, many different designs, many different exposures, many different people with different standards of measurement and reporting. The precision, accuracy, and calibration of the vast surface network varies, especially when we have broad mix of instrumentation types.For example in the US Historical Climatological Network the equipment varies significantly.
In satellite data, the data is measured at a single point with one sensor type, the Microwave Sounder Unit on the satellite, calibrated to a precision source on-board. On-board redundant precision platinum resistance thermometers (PRTs) carried on the satellite radiometers. The PRT’s are individually calibrated in a laboratory before being installed in the instruments. The satellite data is automatically measured and transmitted. In contrast to the surface temperature record, no human hands touch the data gathering or data reporting process. Satellite data generation is far more homogeneous than the mish-mash of surface data.
I think it would be safe to say that the chances of human error in raw surface data are at least an order of magnitude greater (if not several) than error in raw satellite data. Post measurement processing is another issue, but for the purposes of this essay, I’m focusing only on raw data gathering and transmittal.
As mentioned in the recently updated compendium of issues with the surface temperature data by Joe D’Aleo and myself, there has been a move in the Global Historical Climatological Network (GHCN) to rely more and more on airports for climate data. This, in my opinion, is a huge mistake because in addition to those issues
E.M. Smith aka “Chiefio” reports that in GISS (which uses GHCN) worldwide, there has been a wholesale migration towards airport weather data as a climatic data source. In an email sent to me on Jan 20, 2010 he says that
Look at:
http://chiefio.wordpress.com/2009/08/26/agw-gistemp-measure-jet-age-airport-growth/
which as a fairly good descriptions of the problems in the data, we have a global report for GHCN as of that August data. There is more deail in the link, but I think you care about “now”:
Percentage of sites that are AIRPORTS NOW, by decade of record Year S.P S.C S.T S.W EQ. N.W N.T N.C N.P Total 1909 0.0 42.0 15.1 28.2 29.2 36.7 22.8 33.3 44.4 25.4 1919 0.0 36.4 12.8 23.5 25.1 37.7 20.9 35.0 39.8 24.1 1929 0.0 37.0 11.9 27.4 27.7 32.7 20.4 35.9 56.4 24.1 1939 0.0 43.9 17.6 32.0 33.8 29.1 20.2 36.2 51.0 25.1 1949 0.0 32.3 24.4 37.6 44.4 31.8 23.3 39.3 60.9 29.1 1959 0.0 24.0 35.0 50.0 59.4 39.4 30.9 41.0 62.9 37.3 1969 0.0 18.1 39.3 53.2 63.2 40.2 31.4 41.1 61.5 39.0 1979 0.0 17.9 39.1 52.0 64.2 40.7 28.8 41.1 62.3 37.7 1989 0.0 20.7 41.5 52.5 67.8 41.9 29.1 40.8 64.9 37.7 1999 0.0 21.0 53.5 57.4 68.0 53.0 32.6 49.0 59.0 41.6 2009 0.0 17.9 74.0 64.7 66.5 51.5 30.2 45.4 57.3 41.0
I do break outs by continent and by some countries. For the USA, I further do a specific with / without USHCN (the older version, not the USHCN.v2 put in 15Nov09) and findFor COUNTRY CODE: 425
LATpct: 2006 3.7 18.3 29.5 33.2 14.4 0.0 0.4 0.3 0.1 0.1 100.0 AIRpct: 1.3 4.0 6.3 6.7 3.2 0.0 0.4 0.3 0.1 0.1 22.4 LATpct: 2007 8.2 17.2 28.4 26.9 11.2 0.0 3.7 3.0 0.7 0.7 100.0 AIRpct: 8.2 15.7 27.6 23.1 9.0 0.0 3.7 3.0 0.7 0.7 91.8 LATpct: 2008 8.8 16.9 28.7 26.5 11.0 0.0 3.7 2.9 0.7 0.7 100.0 AIRpct: 8.8 15.4 27.9 22.8 8.8 0.0 3.7 2.9 0.7 0.7 91.9 LATpct: 2009 8.1 17.8 28.1 26.7 11.1 0.0 3.7 3.0 0.7 0.7 100.0 AIRpct: 8.1 16.3 27.4 23.0 8.9 0.0 3.7 3.0 0.7 0.7 91.9 DLaPct: 2009 4.3 18.4 29.5 32.5 13.6 0.0 0.7 0.9 0.2 0.1 100.0 DArPct: 2.1 5.7 8.8 8.9 3.7 0.0 0.6 0.8 0.2 0.1 30.7
That in the YEAR 2009 the USA has almost 92% airports in GHCN.
So clearly, airports make up a significant portion of the climate data.
On the issues of airports as climate station, obvious issues with siting, UHI, failing ASOS instrumentation, and conflicting missions (aviation safety -vs-climate) aside, I’m going to focus on one other thing unique to airports: METAR
What is METAR you ask? Well in my opinion, a government invented mess.
When I was a private pilot (which I had to give up due to worsening hearing loss – tower controllers talk like auctioneers on the radio and one day I got the active runway backwards and found myself head-on to traffic. I decided then I was a danger to myself and others.) I learned to read SA reports from airports all over the country. SA reports were manually coded teletype reports sent hourly worldwide so that pilots could know what the weather was in airport destinations. They were also used by the NWS to plot synoptic weather maps. Some readers may remember Alden Weatherfax maps hung up at FAA Flight service stations which were filled with hundreds of plotted airport station SA (surface aviation) reports.
The SA reports were easy to visually decode right off the teletype printout:
Note that in the example above, temperature and dewpoint are clearly delineated by slashes. Also, when a minus temperature occurs, such as -10 degrees Fahrenheit, it was reported as “-10”. Hang on to that, it is important.
The SA method originated with airmen and teletype machines in the 1920’s and lasted well into the 1990’s. But like anything these days, government stepped in and decided it could do it better. You can thank the United Nations, the French, and the World Meteorological Organization (WMO) for this one. SA reports were replaced by METAR in 1996.
From Wikipedia’s section on METAR
METAR reports typically come from airports or permanent weather observation stations. Reports are typically generated once an hour; if conditions change significantly, however, they can be updated in special reports called SPECIs. Some reports are encoded by automated airport weather stations located at airports, military bases, and other sites. Some locations still use augmented observations, which are recorded by digital sensors, encoded via software, and then reviewed by certified weather observers or forecasters prior to being transmitted. Observations may also be taken by trained observers or forecasters who manually observe and encode their observations prior to transmission.
History
The METAR format was introduced 1 January 1968 internationally and has been modified a number of times since. North American countries continued to use a Surface Aviation Observation (SAO) for current weather conditions until 1 June 1996, when this report was replaced with an approved variant of the METAR agreed upon in a 1989 Geneva agreement. The World Meteorological Organization‘s (WMO) publication No. 782 “Aerodrome Reports and Forecasts” contains the base METAR code as adopted by the WMO member countries.[1]
Naming
The name METAR is commonly believed to have its origins in the French phrase message d’observation météorologique pour l’aviation régulière (“Aviation routine weather observation message” or “report”) and would therefore be a contraction of MÉTéorologique Aviation Régulière. The United States Federal Aviation Administration (FAA) lays down the definition in its publication the Aeronautical Information Manual as aviation routine weather report[2] while the international authority for the code form, the WMO, holds the definition to be aerodrome routine meteorological report. The National Oceanic and Atmospheric Administration (part of the United States Department of Commerce) and the United Kingdom‘s Met Office both employ the definition used by the FAA. METAR is also known as Meteorological Terminal Aviation Routine Weather Report or Meteorological Aviation Report.
I’ve always thought METAR coding was a step backwards, for reasons I’ll discuss shortly.
But first, quick! Spot the temperature and dewpoint in this METAR report:
The following is an example METAR from Burgas Airport in Burgas, Bulgaria, and was taken on 4 February 2005 at 16:00 Coordinated Universal Time (UTC).
METAR LBBG 041600Z 12003MPS 310V290 1400 R04/P1500N R22/P1500U +SN BKN022 OVC050 M04/M07 Q1020 NOSIG 9949//91=
Could you read this and know what the weather is in Burgas? I can, only becuase I’ve looked at hundreds the past few months, but I still have to pick through the report to find it. The reason is that METAR is a variable field reporting format. Data isn’t always in the same position.
In the report above. The temperature and dewpoint is: M04/M07
M04/M07 indicates the temperature is −4 °C (25 °F) and the dewpoint is −7 °C (19 °F). An M in front of the number indicates that the temperature/dew point is below zero (0) Celsius.
Notice also that the entire METAR report is visually more complex. This is fine if you are having computers code it, but many METAR reports are still hand coded by technicians at airports, and thus begins the introduction of human error into the climate data process. Complexity is not a good thing when manual labor is involved as it increases the likelihood of error.
Here is where METAR coding departs from normal numeric convention. SA reports did not have this problem.
In the METAR report above, instead of using the normal way we treat and write negative numbers, some policy wonk decided that we’ll use the letter “M” to report a negative number. Only a bureaucrat could think like this.
So instead of a below zero Centigrade temperature and dewpoint looking like this:
-04/-07
in the “new and improved” METAR coding, it looks like this:
M04/M07
OK not a problem you say? Well I beg to differ, because it forces technicians who manually code METAR reports for transmission to do something they would not do anywhere else, and that’s write down an “M” instead of a minus sign. Using an M is totally counter-intuitive and against basic math training, and increases the likelihood of error.
It gets worse. Let’s say the technician makes a boo-boo and puts a minus sign instead of an “M” in front of the numbers for temperature/dewpoint. You’d think this would be alright, and the system would correctly interpret it, right?
Let’s put the METAR report from Burgas Airport into an online METAR decoder.
http://www.wx-now.com/Weather/MetarDecode.aspx
Here’s the report with the easy to make mistake, using minus sign instead of M for the temperature.
METAR LBBG 041600Z 12003MPS 310V290 1400 R04/P1500N R22/P1500U +SN BKN022 OVC050 -04/M07 Q1020 NOSIG 9949//91=
The output from the online METAR decoder reads:
Hey look at that, the temperature is 39°F (3.8°C). Minus signs are discarded from METAR decoding. Note that decoded METAR temperature also comes out the same if the “M” is missing in front of the 04/-07 or 04/M07
If it had been decoded correctly we would have gotten:
(-4) degrees Celsius = 24.8 degrees Fahrenheit
A whole 14.2 degrees F difference!
Reference for METAR decoding:
http://www.met.tamu.edu/class/METAR/quick-metar.html
Also note that METAR data has no year stamp component to the data, so the METAR decoder has no way of knowing this was a report from 2005, not 2010. Since each METAR report is essentially disposable within 24 hours, this presents no problem for pilots, they don’t care. But if you are tracking climate over years using METAR data, not having a year time stamp increases the likelihood of error.
Also the temperature error itself in this case has no bearing on a pilot’s decision to takeoff or land. Unless they are worried about density altitude on hot humid days, the temperature is a throwaway datum. They are mostly concerned about winds, sky conditions, and barometer (altimeter setting). In fact cool/cold days are far better for aviators; see AOPA’s Why Airplanes Like Cool Days Better.
My point here is this:
If a pilot or tower controller sees an erroneous METAR report like this:
METAR LBBG 041600Z 12003MPS 310V290 1400 R04/P1500N R22/P1500U +SN BKN022 OVC050 -04/M07 Q1020 NOSIG 9949//91=
Or this:
METAR LBBG 041600Z 12003MPS 310V290 1400 R04/P1500N R22/P1500U +SN BKN022 OVC050 04/M07 Q1020 NOSIG 9949//91=
Pilots/controllers/dispatchers aren’t likely to care, since current temperature and dewpoint are not important to them at these cooler temperatures. They also aren’t likely to call up the tower and holler at the technician to say “Hey, the temperature is wrong!”. Further, since the METAR report may be reissued sometime within the hour if somebody DOES spot the error, problem solved.
Point is that updates/corrections to METAR data may not be logged for climate purposes, since they are likely to be seen as duplicate reports because of the hourly timestamp.
So, in the case of M’s and minus signs, the propensity exists for erroneous METAR reports to not get corrected and to stay logged in the system, eventually finding their way into the climate database if that airport happens to be part of GISS, CRU, or GHCN datasets.
Maddeningly, even when egregious errors in aviation weather data are pointed out and even acknowledged by the reporting agency, NOAA keep them in the climate record as was demonstrated last year in Honolulu, HI International Airport when a string of new high temperature records were set by a faulty ASOS reporting station. NOAA declined to fix the issue in the records:
NOAA: FUBAR high temp/climate records from faulty sensor to remain in place at Honolulu
The key sentence from that story from KITV-TV:
The National Weather Service said that is not significant enough to throw out the data and recent records.
Hmmm, look at another nearby station and compare the differences. You be the judge.
Does NOAA consider this a climate reporting station? Yes according to NCDC MMS database, it is part of the “A” network, designated for climate:
Clearly, NOAA simply doesn’t seem to care that erroneous records finds their way into the climatic database.
OK back to the METAR issue.
The problem with METAR reporting errors is worldwide. I’ve found many examples easily in my spare time. Let’s take for example, a station in Mirnvy, Russia. It is in Siberia at 62.5° N 113.9° E and has an airport, is part of GHCN, and reports in METAR format.
Weather Underground logs and plots METAR reports worldwide, and these METAR reports are from their database on November 11th, 2009.
It shows a clear error in the 12:30PM (330Z) and 1 PM (400Z) METAR report for that day:
UERR 010330Z 22005G08MPS 9999 -SN 21/M23 Q1026 NOSIG RMK QFE738 24450245 UERR 010400Z 22005G08MPS 9999 -SN SCT100 OVC200 20/M22 Q1025 NOSIG RMK QFE737 24450245 UERR 010430Z 21005G08MPS 4000 -SN SCT100 OVC200 M20/M22 Q1024 NOSIG RMK QFE737 24450245 UERR 010430Z 21005G08MPS 4000 -SN SCT100 OVC200 M20/M22 Q1024 NOSIG RMK QFE737 24450245 UERR 010500Z 21005G08MPS 4000 -SN SCT100 OVC200 20/M22 Q1023 NOSIG RMK QFE736 24450245
Note the missing ” M” on the 12:30PM (330Z) and 1 PM (400Z). It happens again at 2PM (500Z). Of course it isn’t very noticeable looking at the METAR reports, but like the GISS plot of Finland, stands out like a sore thumb when plotted visually thanks to Weather Underground:
Mirnvy, Russia
The effect of the missing “M” is plotted above, which coincidentally looks like an “M”.
Put those METAR reports in this online METAR decoder: http://www.wx-now.com/Weather/MetarDecode.aspx and you get 70F for 12:30PM and 68F for 1PM
What do you think 70 degree F spike this will do to monthly averaged climate data in a place where the temperature stays mostly below freezing the entire month?
http://www.wunderground.com/history/airport/UERR/2009/11/1/MonthlyHistory.html?MR=1
Does NOAA log METAR data from Mirnvy Russia (ICAO code UERR)?
Yes, they do. Plus many other METAR reporting stations discussed here.
Does NCDC classify it as a climate station?
Yep, it is part of the “A” network. Which means it either directly reports climate data and/or is used to adjust data at other stations, such as GHCN stations.
List of GHCN stations:
http://www1.ncdc.noaa.gov/pub/data/ghcn/daily/ghcnd-stations.txt
It is not however, part of GHCN. But there are plenty stations that have this error that are part of GHCN. Yakutsk, Russia, also in Siberia is part of GHCN and has a METAR reporting error. Here’s an example what one off-coded hourly reading will do to the climate database.
The city of Yakutsk, one of the coldest cities on earth, reported a high of 79˚F on November 14th with a low of -23˚F.
Weather Underground seems to have done some quality control to the METAR reports, but the erroneous high temp remains in the daily and monthly report:
http://www.wunderground.com/history/station/24959/2009/11/14/DailyHistory.html
http://www.wunderground.com/history/station/24959/2009/11/14/MonthlyHistory.html
A month later, it happened again reporting a high of 93˚F on December 14th with a low of -34˚F
And the erroneous 93F high temp remains in both the daily and monthly reports, but has been removed from the METAR report, so I can’t show you the missing “M” I observed back in January. I wish I had made a page screen cap.
http://www.wunderground.com/history/station/24959/2009/12/14/DailyHistory.html
http://www.wunderground.com/history/station/24959/2009/12/14/MonthlyHistory.html
When the temperature data was calculated with that error then, this was found:
The average for the day, 30˚F, was some 67˚F above normal, pushing the anomaly for the month of December from 3.6˚F above normal to 5.9˚F above normal… quite a shift!
More examples:
Here’s an example of a properly coded METAR report from Nizhnevartovsk, Russia, for December 11, 2009, but the data is wrong. I’m thinking it was supposed to be M30 but came out M13. The dewpoint value M16 is also erroneous.
Nizhnevartovsk, Russia Dec 7, 2009
METAR USNN 111230Z 00000MPS P6000 SCT026 OVC066 M27/M29 Q1014 NOSIG RMK QFE755 SC062 METAR USNN 111300Z 12005G08MPS P6000 SCT066 OVC200 M13/M16 Q1035 NOSIG RMK QFE772 SC063 METAR USNN 111330Z 12005G08MPS P6000 SCT066 OVC200 M13/M16 Q1035 NOSIG RMK QFE772 SC063 METAR USNN 111400Z 00000MPS P6000 SCT020 OVC066 M28/M29 Q1014 NOSIG RMK QFE755 SC065
And it was not a one time occurrence, happening again on Dec 25th as shown in the Monthly graph:
Nizhnevartovsk, Russia, December 2009
http://www.wunderground.com/history/airport/USNN/2009/12/25/MonthlyHistory.html
The daily graph and METAR reports, notice it happened about the same time (1300Z) and in the same way (M27 then M13) , perhaps pointing to the same technician on duty making the same habitual mistake again. Maybe too much Vodka having to work the Xmas night shift?
Nizhnevartovsk, Russia Dec 25, 2009
METAR USNN 251230Z 11006MPS 2200 -SN SCT014 OVC066 M27/M30 Q1015 NOSIG RMK QFE757 SC055 METAR USNN 251300Z 35002MPS 6000 -SN SCT015 OVC066 M13/M15 Q1010 NOSIG RMK QFE752 SC03 METAR USNN 251330Z 12006MPS 4100 -SN SCT015 OVC066 M27/M29 Q1014 NOSIG RMK QFE756 SC055
http://www.wunderground.com/history/airport/USNN/2009/12/25/DailyHistory.html
It did not appear initially to be in the GHCN list or on the GISS list, but I’ve found that some of the names on Weather Underground are different from the place names in the GHCN and GISS lists. It turns out that if you search in Weather Underground for the station ALEKSANDROVSKOE it will point you to use the data from Nizhnevartovsk. ALEKSANDROVSKOE is a GHCN/GISS station.
I found other instance of METAR errors for that station, this one was quite pronounced on Jan 16th, 2009, lasting for 7 hours before it was corrected.
Nizhnevartovsk, Russia Jan 16, 2009
Here’s the METAR reports
METAR USNN 151800Z 23002MPS P6000 BKN066 OVC200 M22/M24 Q1009 NOSIG RMK QFE751 SC038 METAR USNN 151830Z 23002MPS 2900 -SHSN SCT020CB OVC066 22/M23 Q1009 NOSIG RMK QFE751 SC038 METAR USNN 151900Z 23002MPS 2100 -SHSN SCT019CB OVC066 21/M23 Q1009 NOSIG RMK QFE751 SC038 METAR USNN 152000Z 24001MPS 5000 -SHSN SCT022CB OVC066 21/M22 Q1009 NOSIG RMK QFE751 SC038 METAR USNN 152030Z 24002MPS 4300 -SHSN SCT020CB OVC066 21/M22 Q1009 NOSIG RMK QFE751 SC038 METAR USNN 152100Z 24002MPS 6000 -SHSN SCT018CB OVC066 20/M22 Q1009 NOSIG RMK QFE751 SC038 METAR USNN 152130Z 25002MPS P6000 SCT020CB OVC066 20/M22 Q1009 NOSIG RMK QFE751 SC038 METAR USNN 152200Z 28002MPS P6000 SCT022CB OVC066 20/M22 Q1009 NOSIG RMK QFE752 SC038 METAR USNN 152300Z 27003MPS P6000 -SHSN SCT016CB OVC066 M19/M21 Q1010 NOSIG RMK QFE752 SC038
http://www.wunderground.com/history/airport/USNN/2009/1/16/DailyHistory.html
The monthly report shows the event:
Nizhnevartovsk, Russia, January 2009
http://www.wunderground.com/history/airport/USNN/2009/1/16/MonthlyHistory.html
It happened twice on Feb 2nd, 2007, and with a space added between the M and 09 on the 0300Z report, it is a clear case of human error:
METAR USNN 020100Z 11010G15MPS 0500 R03/1200 +SN +BLSN VV002 M09/M11 Q1003 TEMPO 0400 +SN +BLSN VV002 RMK QFE748 QWW060 MOD ICE MOD TURB S METAR USNN 020200Z 12009G14MPS 0500 R03/1200 +SN +BLSN VV002 M09/M10 Q1001 TEMPO 0400 +SN +BLSN VV002 RMK QFE747 QWW060 MOD ICE MOD TURB S METAR USNN 020300Z 11008G13MPS 1100 R03/1200 SN +BLSN BKN004 OVC066 M 09/M10 Q1000 NOSIG RMK QFE745 QRD120 MOD ICE MOD TURB SC045 ... METAR USNN 021200Z 18009MPS P6000 -SHSN DRSN SCT017CB OVC066 M07/M09 Q0989 TEMPO 2000 SHSN RMK QFE736 MOD ICE MOD TURB SC042 METAR USNN 021300Z 16009MPS P6000 DRSN SCT016CB OVC066 08/M11 Q0989 NOSIG RMK QFE736 MOD ICE MOD TURB SC042 METAR USNN 021400Z 16008MPS P6000 DRSN SCT016CB OVC066 M08/M11 Q0989 NOSIG RMK QFE736 MOD ICE MOD TURB SC042
http://www.wunderground.com/history/airport/USNN/2007/2/2/DailyHistory.html
The monthly data shows the double peak:
http://www.wunderground.com/history/airport/USNN/2007/2/2/MonthlyHistory.html
I’m sure many more can be found, I invite readers to have a look for themselves by looking for such events at Weather Underground
It is not just Russia that has METAR reporting errors
Lest you think this a fault of Russia exclusively, it also happens in other northern hemisphere Arctic site and also in Antarctica.
Svalbard, Oct 2, 2008
METAR ENSB 020550Z 13012KT 6000 -SN FEW010 SCT015 BKN030 M04/M06 Q1013 TEMPO 4000 SN BKN012 METAR ENSB 020650Z 14013KT 9000 -SN FEW010 SCT018 BKN040 03/M06 Q1013 TEMPO 4000 SN BKN012 METAR ENSB 020750Z 15011KT 9999 -SN FEW015 SCT025 BKN040 M03/M07 Q1013 TEMPO 4000 SN BKN012
http://www.wunderground.com/history/airport/ENSB/2008/10/2/DailyHistory.html
Eureka, Northwest Territory, Canada March 3 2007
It hit 109.4 F (43C) there on March 3rd 2007 according to this METAR report. Eureka is the northernmost GHCN station remaining for Canada. It’s temperature gets interpolated into adjacent grid cells.
CWEU 031600Z 14004KT 15SM FEW065 BKN120 M43/M45 A2999 RMK ST1AS2 VIA YQD SLP150 CWEU 031700Z 15005KT 10SM FEW065 BKN012 43/46 A3000 RMK SF1AS1 VIA YQD SLP163 Decoded: 11:00 AM 109.4 °F 114.8 °F 100% 30.01 in 10.0 miles SSE 5.8 mph - Mostly Cloudy CWEU 031800Z 11003KT 15SM FEW050 FEW065 OVC130 M43/M46 A3001 RMK SF2SC1AS1 VIA YQD SLP164
http://www.wunderground.com/history/airport/CWEU/2007/3/3/DailyHistory.html
In these cases below for Antarctic stations Dome C and Nico, the METAR reports seem to have all sorts of format issues and I’m not even sure how where the error occurs, except that Weather Underground reports a spike just like we see in Russia.
Dome C station Dec 9, 2009
AAXX 0900/ 89828 46/// ///// 11255 36514 4//// 5//// 90010 AAXX 0901/ 89828 46/// ///// 10091 36514 4//// 5//// AAXX 09014 89828 46/// /1604 11225 36480 4//// 5//// 9014
http://www.wunderground.com/history/station/89828/2009/12/9/DailyHistory.html
Nico Station, University of Wisconsin Dec 9, 2009
AAXX 0920/ 89799 46/// ///// 11261 4//// 5//// 92030 AAXX 0920/ 89799 46/// ///// 11103 4//// 5//// 92040 AAXX 0921/ 89799 46/// ///// 11270 4//// 5////
http://www.wunderground.com/history/station/89799/2009/12/9/DailyHistory.html
Admusen Scott Station Jan 14th, 2003
Here’s generally properly formatted METAR data, but note where the technician coded the extra space, oops!
NZSP 131350Z GRID36007KT 9999 IC SCT020 BKN060 M31/ A2918 RMK SDG/HDG NZSP 131450Z GRID36007KT 9999 IC FEW010 FEW020 SCT035 SCT050 M3 1/ A2918 RM K SDG/HDG NZSP 131550Z GRID10008KT 9999 IC BCFG FEW010 SCT020 BKN050 M31/ A2919 RMK VIS E 2400 BCFG E SDG/HDG
http://www.wunderground.com/history/station/89009/2003/1/14/DailyHistory.html
And I’m sure there are many more METAR coding errors yet to be discovered. What you see above is just a sampling of a few likely candidates I looked at over a couple of hours.
Missing M’s – Instant Polar Amplification?
It has been said that the global warming signature will show up at the poles first. Polar Amplification is defined as:
“Polar amplification (greater temperature increases in the Arctic compared to the earth as a whole) is a result of the collective effect of these feedbacks and other processes.” It does not apply to the Antarctic, because the Southern Ocean acts as a heat sink. It is common to see it stated that “Climate models generally predict amplified warming in polar regions”, e.g. Doran et al. However, climate models predict amplified warming for the Arctic but only modest warming for Antarctica.
Interestingly, the METAR coding error has its greatest magnitude at the poles, becuase the differences in the missing minus sign become larger as the temperature grows colder. Eureka, NWT is a great example, going from -43°C to +43°C (-45.4°F to 109.4°F) with one missing “M”.
You wouldn’t notice METAR coding errors at the equator, because the temperature never gets below 0°C. Nobody would have to code it. In middle latitudes, you might see it happen, but it is much more seasonal and the difference is not that great.
For example:
M05/M08 to 05/M08 brings the temp from -5°C to +5°C, but in a place like Boston, Chicago, Denver, etc a plus 5C temperature could easily happen in any winter month a -5C temperature occurred. So the error slips into the noise of “weather”, likely never to be noticed. But it does bump up the temperature average a little bit for the month if uncorrected.
But in the Arctic and Antarctic, a missing M on a M20/M25 METAR report makes a 40°C difference when it becomes +20°C. And it doesn’t seem likely that we’d see a winter month in Siberia or Antarctica that would normally hit 20°C, so it does not get lost in the “weather” noise, but becomes a strong signal if uncorrected.
Confirmation bias, expecting to see polar amplification may be one reason why until now, nobody seems to have pointed it out. Plus, the organizations that present surface derived climate data, GISS, CRU, only seem to deal in monthly and yearly averages. Daily or hourly data is not presented that I am aware of, and so if errors occur at those time scales, they would not be noticed. Obviously GISS didn’t notice the recent Finland error, even though it was glaringly obvious once plotted.
With NASA GISS admitting that missing minus signs contributed to the hot anomaly over Finland in March, and with the many METAR coding error events I’ve demonstrated on opposite sides of the globe, it seems reasonable to conclude that our METAR data from cold places might very well be systemically corrupted with instances of coding errors.
The data shown between 4/13 and 4/15 were based on data downloaded on 4/12 and included some station reports from Finland in which the minus sign may have been dropped.
That darned missing M, or an extra space, or even writing “-” when you mean “M” (which is counterintuituve to basic math) all seem to have a factor in the human error contributing to data errors in our global surface temperature database. To determine just how much of a problem this is, a comprehensive bottom up review of all the data, from source to product is needed. This needs to start with NOAA/NCDC as they are ultimately responsible for data quality control.
It has been said that “humans cause global warming”. I think a more accurate statement would be “human error causes global warming”.
Note: In this post I’ve demonstrated the errors. In a later post, I hope to do some data analysis with the numbers provided to see how much effect these errors actually have. Of course anyone who wants to do this is welcome to leave links to graphics and tables. -Anthony
UERR 010330Z 22005G08MPS 9999 -SN 21/M23 Q1026 NOSIG RMK QFE738 24450245
UERR 010400Z 22005G08MPS 9999 -SN SCT100 OVC200 20/M22 Q1025 NOSIG RMK QFE737 24450245
UERR 010430Z 21005G08MPS 4000 -SN SCT100 OVC200 M20/M22 Q1024 NOSIG RMK QFE737 24450245
Sponsored IT training links:
Ultimate VCP-410 practice files formulated by top experts to help you pass 220-702 and 640-822 exam in easy and fast way.
Discover more from Watts Up With That?
Subscribe to get the latest posts sent to your email.
Sorry, by way of a supplementary question, is there any way to get to the METAR data for the most recent week / month and see / download the data in it’s raw form? Or are individual records collated with some sort of back-end process that has no public interface?
what is also disturbing about climate data is how often the very place names are misspelled.
it’s not ‘Mirnvy’ – Russian Мирный, usually transliterated as Mirniy, sometimes as Mirnij, Mirnyy or Mirnyj – but in no way there’s v in it. (the meaning of it is ‘peaceful’ or ‘peace-loving’ – several Soviet-era settlements carry this name)
Wren (20:46:49) : Perhaps the answer to addressing this systematic error is simply to require a sign, plus or minus, in front of each recorded value
Anthony’s post notes one of the issues as follows “conflicting missions (aviation safety -vs-climate)”.
METAR is designed and operated by the aviation industry, with no other use in mind. Without doubt, climatologists will be free to use publicly available data if they want, but the terms of the transaction will be “strictly as seen”.
These ownership and mission issues get things off to a poor start for objectives such as quality, accuracy and precision of climate trends.
And if I were to use the word “disgrace” it would be in the sense that GISS use this data, and then appear to have failed to identify sich a flaw. Is it not fair to consider it disgraceful that WUWT and CA appear to have become part of the QC/QA machinery of funded projects?
There should now be a detailed investigation of this issue. GISS has the most to gain and lose from this issue, so the onus falls to GISS to use some of its funding to get the matter sorted out.
For a quick indication of the magnitude of the problem, my suggestion would be examine the most recent data first. Assess the magnitude of the error at individual locatons and consider whether averaging reduces the error (averaging doesn’t necessarily reduce systematic error, and it is necessary to take into account extrapolation to neighbouring grids).
If this is combined with existing error analysis (which we assume does not account for any METAR error), the confidence interval of the GISS global data set would expand. The expansion would come into play around 1996 (introduction of METAR) and there would be continuing expansion with the increased use of airport data.
At that point Wren, GISS will have put you in a position where your could examine the lower bound of the confidence interval to see whether there is any reason to argue for a significant trend.
We are hoping this posting stays up Numero 1 for at least 48 hours! (or stories directly related to it) VIP! (Very important Posting)
Why are there sign errors in hourly buoy data – aren’t they automatically transmitting data electronically?
Thanks
JK
Why anyone still uses the Global Historical Climatological Network when better and more accurate satelite measurements exist is beyond belief. These people are a bunch of incompetents!
A.W. You say
“In middle latitudes, you might see it (coding error) happen, but it is much more seasonal and the difference is not that great.”
True, but for that very reason, surely coding errors are more likely to slip through unnoticed. Conceivably, an operator then would be more likely to continue the habit, oblivious to the serial errors. The “difference is not that great”, but it can be significant if unchecked, especially in the context of just 0.6degC global warming in 30 years.
I am amazed.
Even unimportant factory records do basic confidence data checks when historizing process/production data. Normally we won’t acept data that is outside sane data-point to dat-point delta.
How on earth can this data be useful for anything ?
What sort of idiot/ignorant numptie doesn’t
do basic confidence checks ?
These people /claim/ to be scientists ? They demonstrate such an appalling lack of basic knowledge they shouldn’t be allowed near a keyboard, never mind a science based job.
Well done again Mr Watts,
Another problem ( which would never occur to either the French or English speakers )
In how many languages does the word for ‘minus’ start with ‘M’ ? ……..
Theo Goodwin (23:03:40) :
I have a complaint about climate scientists’ use of the word “anomaly.”
Maybe using “Absolute” and “Relative” would be better?
Outstanding work!
The more you look at this, the more you realise it’s impossible to do what they’re doing.
I cannot understand why one would base one’s life work on this. It cannot be done.
Possibly with sat data, we’ll start to get a handle on it, but as it stands now, the whole thing is rubbish.
Here is bit newer and sharper giff picture from that scandinavian error, was still having distinct error in it and almost half of europe.
Here in Finland we wheren´t sure should we laugh or go angry, because its been many degrees colder than normally in this winter and spring.
http://i756.photobucket.com/albums/xx206/MWPeriod/agw/GHCN_GISS_HR2SST_1200km_Anom03_2010.gif
Anthony, I have no idea how you have time to do all this analysis and work. I barely get the kids to bed without falling asleep reading to them. Whatever your secret, thank goodness you keep at it. It must be exhausting, but I hope the exhilaration and other benefits are enough to keep you at it. You are making a positive difference in the world.
A more enlightened NASA or NOAA or NWS would hire you as a full time gadfly. Wouldn’t that be something? The government hires Inspectors General, offices to manage Equal Opportunity, has full time ethics agencies, all sort of checks and balances folks, but no gadflies. Just someone to say, “yeah, but what if…..”. Think of the time, effort and money to be saved if someone like you were there to simply ask something like, “but what if the data is wrong?”
Excellent post Anthony. This explains so much of the GISS deviation from what is observed. Great piece of work.
Wren, if you have a data set of 150 years, of which the last 16 are biased high, please explain how this does not affect the trend!
<>
Anthony is clearly IDENTIFYING the problem here, and then talks about ANALYZING its extent and impact later. Well, duh, Nick! You can’t analyze the extent and impact of a problem until you have identified it. What scientist ever reverses this order? (“Hey guys, I’m gonna analyze the extent and impact of a problem even though I don’t know whether it exists.”)
Your scorn is clearly not scientific (it is based on an anti-scientific procedural error). So, I think I have fairly identified your problem. What remains to be analyzed is the extent and impact that your scorn has had in the development of your AGW paradigm. Your brief comment about the world’s glaciers and Anthony’s “US surface stations project” suggests that it is quite extensive.
The previous comment by Chad Woodburn first quoted Nick’s comment, but I put the quote in angle brackets, not realizing that that would eliminate them from the post.
“Nick (19:21:26) :
That’s right,Anthony,accusations and extrapolation first,then ’some data analysis’ later. “
Anthony, this is a most important subject, well explained and documented. Congratulations.
The big unknown, of course, is whether the dropping of a negative sign happens enough times to swing the country or global data, or whether some countries have QQ that detects it. The Antarctic would seem particularly at risk.
In looking at data from one of the Australian Antarctic stations, Mawson WMO 94997, there was not enough metadata available to me to address the same points that you raise. However, the first look shows in essence that the extreme temperatures are somewhat ragged at the edges. (For the record, Mawson has an airstrip. Australia changed to decimal in Feb 1966, but as a scientific base, the records were possibly in C from the start in 1954). The data are from the Australian Bureau of Meteorology, duly acknowledged.
An initial look is presented now in the form of three spreadsheet portions and a graph plus a comment on each. I stress that we might be looking at different mechanisms, but what I present does not preclude errors of the type that you describe with METAR.
Overall, the data set had 19,419 days, with Tmax and Tmin. There were 87 days of missing Tmax and 22 days of missing Tmin, reason for missing unknown.
The mean of all Tmax values is -8.38 deg C. The mean of all Tmin is -14.27. The mean difference is 5.87 deg. Condider the sign dropping exercise with these figures, first with the Tmax going from -8.38 to +8.38, causing the Tmean to change from -11.33 to -2.93. If the sign was dropped from Tmin, the two Tmean would change from -11.33 to +2.93. As this shows, the dropping of sign on the minimum is a bigger problem than dropping the sign on the maximum, as you noted.
Mawson1 is a small part of the Mawson daily maximum temperatures sorted from highest down, for the first few weeks.
http://i260.photobucket.com/albums/ii14/sherro_2008/2010/Mawson1.jpg?t=1271577750
If there was a sign error for Tmax, because its average is close to -8 Deg C, there are 2 consequences. Where Tmax is already above zero, in about 20% of the cases, we are not subjected to missing a negative since there are none. Where Tmax is below zero and the negative sign is dropped, this leads to an apparent warming that can report in 80% of the data. Tmax can be as low as -32 deg C, so dropping the sign gives a healthy wrong warming.
Mawson2 is for the minimum temperatures sorted from the highest down.
http://i260.photobucket.com/albums/ii14/sherro_2008/2010/Mawson2.jpg
This spreadsheet partially shows that only a few days had Tmin above zero. The vast majority have a negative sign and dropping the negative sign would cause a strong warming impression. It is also more probable an error than with Tmax. The average of all readings is -14.2, the coldest reading is -36 deg C with a potential for a daily Tmean error of 36 deg C.
Mawson3 shows the difference between Tmax and Tmin.
http://i260.photobucket.com/albums/ii14/sherro_2008/2010/Mawson3.jpg?t=1271577538
The largest difference is 32 degrees. If there were large mistakes made from occasional sign dropping, there would be occasional large values that did not seem to be part of a smooth distribution. However, it is plausible that such “unlikely” figures would be culled by the hand of man, making this detective work less relevant.
Then there is a daily graph showing the differences calculated in Mawson3.
http://i260.photobucket.com/albums/ii14/sherro_2008/2010/MAWSONGRAPH.jpg?t=1271577707
It is apparent that the hand of man has been at work, because one can see distinct artefacts in the graph of the differences. See the group of parallel values around day 10,000. Of course, this graph must have no points below the zero X axis because this would mean that Tmin exceeded Tmax, creating a terminological problem.
At this stage, further work is not warranted because too many assumptions need to be made. Primarily, evidence of numerical reworking exists but the cause(s) is unknown. It is noted that Tmax-Tmin was rising from about 1965 to 1980, then there is the 10,000 day gap, then the difference mainly fell between 1986 and 2000, then levelled. What this means in Nature I know not.
With further work not reported here, there are possible indications from several outliers that dropping of a negative sign could have happened, but there is no definite evidence that it did happen. The day-to day variation of temperatures at these latitudes is large and there is a lack of rigour in plausible reconstructions to explain outliers.
Just thinking….
Willis shows the deviation from “average” toward more warming occurs in the winter at night. http://wattsupwiththat.com/2010/04/16/wheres-the-climate-beef/
Anthony now show an error that can cause the deviation from “average” toward more warming when the temperature are below freezing.
The temperature are below freezing most often in the winter at night.
Human error is more apt to occur at night especially in a rotating shift type situation or when the shifts are longer than 8 hours.
A minus sign error has the most impact on data as you approach the poles. Not only does the sign switch cause a major deviation from the true value in the individual data point but the area around the poles is more likely to have sparse data causing the impact to be even greater and the incorrect data to be “smeared” to adjoining grids.
Definitely an area that needs more investigation.
Guys you have to realise that Nick, David X Benson et al are serious disciples of the RealClimate Church. They see only what their high priest tells them to see.
Sad very sad.
Those antarctic stations are not reporting in METAR format. That is called “ship synoptic” code. It has it’s own problems. The biggest being that it is done by quartermasters that have never been properly trained. I have seen them put a sling psychrometer into a bowl of water and read the temperature and dewpoint off of it from there.
You did a very good job here. I don’t think this is as big of a problem on land in the United States as this article makes it seem tho. For a couple of reasons. One is that we all talk to each other. If I am observing in Pax River and I see that Dover made a mistake I call them and tell them to send out a correction. Two is that we have a second group for temperatures. The “T” group, which you can see here. METAR KDOV 180855Z AUTO 30008KT 10SM CLR 05/01 A2991 RMK AO2 SLP130 T00520007 55002 $ This uses a 1 or 0 to denote positive and negative temperatures. Third is that when we go to insert this in the computer it checks it for us. Fourth, those online decoders do not work the same way that the NWS decoders do. Those are written in FORTRAN and pick up on some of that stuff, and always use the T group when available.
I do not mean to discount this work tho. You are pointing out a problem that is very real. Overall great job!
Thank you for taking the time and making the effort to publish this detailed analysis. Excellent; and IMO qualifies as another ”smoking gun”.
But I almost dispair at finding a practical solution to one huge problem; i.e.:
How do we ever get even a concise summary of important information like this considered by the MSM, let alone the average citizen; who has NO IDEA what is actually involved in gathering and adjusting all the data used to (at least theoretically) come up with statements like ”this was the warmest month on record in Oz”, etcetera ??
Take just two key statement from thread start:
”. . . . the chances of human error in raw surface data are at least an order of magnitude greater (if not several) than error in raw satellite data.”
and:
”. . . . there has been a wholesale migration towards airport weather data as a climatic data source.”
If even 1 out of 1000 people in North America have any idea that last two above are true let alone why and impact of same, I’d be surprised. But without at least a basic grasp of these and other key facts laid out in this post, citizens (and Members of Congress) are unable to make informed judgements on key issues; and remain vulnerable to self-appointed ”leaders” who contine to demagogue on the ”urgent need” to address CAGW regardless of cost and other priorities.
I guess as long as the WUWT hit counter continues to grow there is hope that objective science will prevail. Jury is still out, I suppose. . . .
I would agree with a previous comment that satellite data should now be the primary source of information as the other sources are compromised. This would make CRU and GISS redundant, so they could be terminated.
The NOAA/NCDC should continue to collect raw station data purely to make it available to researchers in an online database, with their remit just to make it as accurate as possible, but not to interpret it themselves. In addition they should be charged with trying to recover all historical data, and fully document any homogenisation.
Source data you can actually trust is paramount.
————
[Note : I would regard ‘raw’ data as being like that shown in the article – a variety of formats. I would regard ‘source’ data as being after the raw data has been formatted in to a standard record. If the source data needs a correction as per the article then the original data should be stored in the same record so that any correction is flagged and is reversible. I would want any adjustments [say, from homogenisation] in separate fields so the source data is always left intact, and, again, it is flagged and reversible.]
Ken Smith (18:56:17) asks-‘Is it plausible that UHI might be increased by a _local_ greenhouse effect?’ I don’t know about that Ken but I’d suggest UHI may well be an increasing culprit for another reason, if as Anthony suggests the surface temp record is increasingly reliant on airport records. He points out the METAR conundrum but that raises another issue with airports, if like my local airport in Adelaide (State capital of South Australia), advancing aircraft technology instrumentation and flight control are having another specific impact on airports like mine. How so? You might like to ask yourself if development at your local airport in recent years matches that of mine. Let me describe Adelaide Airport which you might like to check out on Google maps for yourself as a useful exercise. Basically it sits close to the coast (St Vincents Gulf) between the city and the sea. Its western boundary was always Tapleys Hill Rd and for much of my life it consisted of 2 crossed runways amid a very large grassy plain with a smallish State terminal vis a vis Melbourne and Sydney international airports. Furthermore the land between Tapleys Hill Rd and the coast was also used for playing fields, golf course, horse agistment and largely undeveloped. I can tell you as a keen motorcyclist for many years, particularly on winter nights, you braced yourself for a significantly cooler ride along Taps as you left the built up suburbs either side of this natural plain, albeit a pleasant and welcome cool change in summer. Noticeably warmer nowadays with an airport that’s been privatised, an international terminal added and everything from a Harbourtown shopping centre with large bitumen carparks to logistics warehouses and even old folks home being built ever closer to the runways. That would have been unheard of for pilots in the past on safety grounds. Clearly better navigation and flight control has been the catalyst for a shrinking safety area around the runways and with it a rapidly increasing UHI effect over the last decade or so. Presumably Adelaide Airport is not alone due to such a technology factor?
It’s amazing what objectivity does for science. Oh wait, isn’t all science supposed to be objective, unbiased, seek the truth?
Sounds like some modern software design could help alot.
Interesting. I am certainly convinced that such errors exist, and will bias the station temperature data upwards.
However, a critical question is – ‘How prevalent are these errors?’. It is possible that they have a minor effect – we cannot tell unless, at vast expense, we redo ALL the collected data from scratch. I believe we should do this, but no warmist does…