Home > Uncategorized > Middlesboro Kentucky: Pitch Black?

Middlesboro Kentucky: Pitch Black?

In his august draft of Hansen2010, Dr. Hansen makes the following claim:

“We present evidence here that the urban warming has little effect on our standard global

temperature analysis.  However, in the Appendix we carry out an even more rigorous test.

We show there that there are a sufficient number of stations located in “pitch black” regions,

i.e., regions with brightness below the satellite’s detectability limit (~1 µW/m2/sr/µm),

o allow global analysis with only the stations in pitch black regions defining long-term

trends.  The effect of this more stringent definition of rural areas on analyzed global

temperature change is immeasurably small (<0.01°C  per century).  The finding of a negligible

effect in this test (using only stations in pitch black areas) also addresses, to a substantial

degree, the question of whether movement of weather stations to airports has an important

effect on analyzed global temperature change.  The pitch black requirement eliminates not

only urban and peri-urban stations but also three-quarters of the stations in the more than

500 GHCN records that are identified as airports in the station name.  (The fact that

one-quarter of the airports are pitch black suggests that they are in extreme rural areas

and are shut down during the night.) Station location in the meteorological data records

is provided with a resolution of 0.01 degrees of latitude and longitude, corresponding to

a distance of about 1 km.  This resolution is useful for investigating urban effects on

regional atmospheric temperature.”

The are several claims here but I will only narrowly examine a few of them. I do not asses the claim about the role of UHI in the global record. That claim, in my mind cannot be assessed until the categorization of rural/urban is settled. So, my observations here have nothing to do with the effect of the issues that the case of Middlesboro will raise. In short, I still believe the world is warming and that man is the principle cause.  Instead on will focus on Dr. Hansen’s methodology. In particular, the assumption that the station locations are accurate to .01 degrees or 1 km ( at the equator) and his assumption that selecting “pitchblack stations” gives you a rural sample. Very simply, the station locations are not accurate to .01 degrees as we have seen repeatedly in this series.

To understand this problem in detail requires focusing on individual stations. That focus should neither convince people that the problem is widespread nor should it convince them that it is rare. What it should do is motivate those concerned to be more comprehensive and diligent in their work and their criticism. The conclusions I draw then are most narrow. First, station location data is too inaccurate to use with a simple look up into nightlights, second, a pitch black requirement does not eliminate the issue, and third nightlights is not a reliable indicator of the actual physical processes that cause UHI.

We will start with the GISS inventory data for this station: found here

42572326006 MIDDLESBORO 36.60 -83.73 358 469S 11HIxxno-9x-9COOL FOR./FIELD C2 0

decoding: the latitude is 36.60, longitude is -83.73. The “S” indicates it is a small town, 11 indicates a population of 11,000  and finally the last value  0, indicates that the station is pitch black by  nightlights. In H2010 this last value is apparently the one used to determine if a station is dark. Lets look  what our replicated inventory shows. it shows that Nightlights is 0, but it also indicates that there is a light with value 54 within 55km of the site. More importantly, the expanded inventory shows that within 3km of the station location there is a light with a value more than 35 DN. Simply, there are urban lights very close to the proported station location. Because I process all the pixels within a radius of every station I can locate these cases automatically. I merely sort for all the pitch dark stations and then sort for those with urban pixels within 3, 5, 10  20 km  all the way out to the 1degree cell boundary. Having identified this station as a possible issue the program then outputs the relevant google map with an overlay of nightlights contours. Like so: look at the pale blue cross. So, my algorithm works.

The program also outputs a kml file which then I can bring

up in Google earth and tour all the stations.

Not seeing anything that looks like a weather station at the location, perhaps at the airport?  Well, if  we check source data at NCDC we find the actual location(s)

And we can map all four which are all north of 36.60. In the bright zone

Checking close to the airport  36.61 -83.74 E


[1] 276750752

The Nightlights value  value at that location? not zero. its 33.

cellValues(hiResLights,cell=276750752)   33

To repeat. GISS have the station at  36.60,-83.73. The “lights at that location are Zero. But the actual station location is north of that in the bright zone .The lights at the airport are 33, which qualifies as Periurban, periurban type2. There are lights as high as 56 within the region. That qualifies as urban, urban type2 by Imhoff’s criteria.

The lights in the area near to the station suggest something btween periurban type2 or urban type 2. Urban type 1  is roughly 680  people per square km. The town in fact has 20 square km which translates into roughly 13K people. Checking back with the GISS inventory:

469S   11

11K people . You can check wikipedia. So Imhoffs nightlights did a good job of guessing the population, but if the station location is wrong you look up a dark pixel as opposed to the bright picels right next to them.

Hansen’s screen of pitch black stations is not adequate. A tighter screen, such as no dark pixels within the area of station location uncertainty would be better. We will work our way through that as we improve the tools here.

And in case you wondered about the temps?

Now there is one last thing I had to check. Hansen speaks of stations in pitch black “areas” Looking at his charts however it appears he picked stations at pitch black pixels. To check this the only think I can do is compare his view of USA stations  with my view. They match fairly well ( he shows fewer which may mean the stations drop for other reasons like short records), so I’ll assume  that he picked stations at pitch black “pixels”. As we have seen the value at the “pixel” of a station can be misleading because of very very minor location errors.

hansens graphic and then mine

For one final check, I produce a graphic of stations with periurban pixels within 3km ( marked by a cross) and those with periurban pixels within 5km of the site. Confirming the supposition that hansen has picked stations at pitch black pixels. he does not consider potential station location errors

Categories: Uncategorized
  1. Ironworx
    October 21, 2010 at 2:18 AM

    Hallo Mr. Mosher,
    i think, that the only solution for your problem is to obtain more precise real data for the station locations from a different catalog. I have tried several solutions to enhance the GHCN inventory, but started with the inventory from NCDC ISH/GSOD; it has many stations, which are also part of GHCN.

    It is named “ISH.HISTORY” and not only has one more digit after the decimal point, but also corrects many severe errors in GHCN. So it should be very simple to replace GHCN location data with that from ISH (GHCN has a reserved byte before the lat/lon columns, which can be used for the additional digit). But cave canem!

    . For a given station the WMO-ID and subindex (IMOD) are often not the same.
    . Station names differ in many cases, sometimes intentionally (e.g. in Antarctica) sometimes caused by sloppy data entry (uncorrected typing errors, cut-offs, etc.), sometimes caused by different conventions of the original data distributor (name of airport vs. name of the city), etc., etc.
    . ISH also can have multiple entries for the same station (WMO-ID/IMOD) with different location information.

    To overcome these problems, i wrote a little program, which selects a station from both inventories and checks if the station’s names are “the same”. If they are, and there is more than one entry in ISH, the entry with the minimum distance is selected from ISH.
    When comparing station names, i try to account for the various forms of sloppiness, as described above (i use “agrep” with some pre-modification of the names).
    If all looks OK, the location data in the GHCN inventory is overridden with the correspondig information from ISH.

    In this way, the precision of about 3000 entries in GHCN can be enhanced, but a handful get even worse :-(.

    The result looks like that:
    10160355000 SKIKDA 36.883 6.900 3
    10160360000 ANNABA 36.833 7.817 5
    10160390000 DAR-EL-BEIDA 36.683 3.217 25
    10160395001 FT. NATIONAL 36.520 4.180 942
    10160400001 CAP CARBON 36.800 5.100 230
    10160402000 BEJAIA 36.717 5.067 6
    10160403000 GUELMA 36.467 7.467 228
    10160419000 CONSTANTINE 36.283 6.617 690
    10160425000 CHLEF 36.217 1.333 141
    10160425001 ORLEANSVILLE 36.170 1.500 112

    10160581000 HASSI-MESSOUD 31.667 6.150 141

    If you are interested, just send a mail.

    Greetings (and sorry for my horrible English)

  2. Steven Mosher
    October 21, 2010 at 12:06 PM

    Hi Tony,

    i have been looking into the exact proceedure you describe, along with the master station list. Also, I have airport data that gives me exact data. The issue is which catalog is correct? WHAT does correct MEAN. there has to be ground truthing or one has to screen for location errors. Anyway, I’ll sned you mail

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: