GIStemp a slice of Pisa

Hohenpeissenberg Observatory - 1000m up the Alps

Hohenpeissenberg Observatory - 1000m up the Alps; Like Pisa How?

Original image from the LIDAR working group at Hohenpeissenberg including a closer view of the observatory.

PApars.f logs, and a Slice of Pisa

In wandering through the PApars.f program in STEP2 (a key early program in the zones / anomaly / grid box process) I figured out what one of the log files was good for.

It’s good for answering the question “What ‘rural’ Station was used to adjust this Urban station history?”.

That file is named PApars.GHCN.CL.1000.20.log and it is typically found in the work_files directory at the end of a run. The first 5000 or so lines are not very interesting, mostly being just a list of stations and a count:

 rural station: 1  id: 200460003  #ok 44
 rural station: 2  id: 200690003  #ok 58
 rural station: 3  id: 202740000  #ok 29

But it’s the later bit that is interesting. It includes the specifics as to which of these rural stations was used to “correct” what urban station.

I’ll be using it from time to time to look at particular stations and what they did / do / had done to them. In particular, on my ToDo list, is to answer the question from Ellie on the “Airports as UHI correction” thread about what stations were being modified by 2 airports on the edges of Iceland.

For now, though, we are going to look at what stations modified Pisa, Italy. Over on WattsUpWithThat, there was a posting that looked at Italy and various stations there, with “blink comparisons” of before and after GIStemp “correction”. For Pisa, the very early data drop by about 1.75C. Way beyond anything that is reasonable. The nagging question is “Why?”. It is very hard to find “where” and harder to get “why” out of it; but at this point I’m fairly certain the “where” is in PApars.f and the “why” is the choice of “Reference Stations” and the method by which they are applied.

We are mostly going to look at the issue of Which Stations in this posting today. I’ll come back to it in a few days with an update on the method issue (friends over for dinner in an hour, so I’ll have to complete this tonight / tomorrow.)

OK, so what do we have now?

Who “Corrects” Pisa? Would you believe Switzerland?

This is the correction log for Pisa Italy. I won’t go into what the PApars.f and related bits of code do at this time (back later), but I will describe what this log says. The first record says that the URBAN station is “161580004″ and that is Pisa. It uses a comparison radius of 500 km, so it is one of the better behaved ones (you get either 1000 km or half that if there are lots of reference stations). I’ve added the names for the reference stations, along with their country codes. You can see the years of that station and the overlap.

Now, one Really Interesting Thing. See that overlap of 129 years for Hohenpeissenb and 126 years for SAENTIS? How do you get 126 years of “overlap” from a Pisa record that starts in 1949? Yes, this matters to how the code chooses to apply stations for “corrections”. This is one Giant Dig Here! One hopes that it is just mis-printing the length of the SAENTIS record as “overlap” and not really treating it as an overlap, but the code does say that it looks at ‘overlap’ to decide who gets top billing (and top billing is also greatest impact. The first records averaged in to a reference average sets the “tone”; all subsequent records get ‘adjusted’ such that they do not move this mean, then get averaged in: so they can change the “tilt” but not the “mean”. I think this is a source of error, but need to Dig Here to show it.).

This might also explain the inordinate attention paid to Hohenpeissenberg in the STEP0 process, complete with getting a special copy of the data that is ‘more complete’. Might this make it “overlap” with more stations and thus use a cold German site in more “adjustments”? And rank it in the more influential “first position” more often? Pure speculation, but worth a good Dig Here!

Notice also that stations in Switzerland, Germany, Italy, and France are used to “correct” Pisa. Gotta think there is a bit of weather variation between those places…

So we have a Sea Coast moderated record from Pisa that is being adjusted by records from inland Switzerland and the Aviano Military Air base. OK, that has to do something, but Lord Only Knows what… And since things like the jet stream and AMO can shift historic relations between the areas that far apart, having a 20 year overlap that you use to set a “baseline” then judging any delta from that to be UHI confounds UHI with normal climate oscillators. Another Dig Here.

I added an A to the country code for sites that are airports. Supposedly pristine rural locations…) Notice that Pisa is adjusted by a couple of airports, too. My favorite being the Aviano record. IIRC that is a major military Air Base for Italy. Nice “rural” station /sarcoff>. This picture gives a nice idea what goes on there and I like the way the rain water is kicking up off the runway…
http://www.jetphotos.net/viewphoto.php?id=41156

For Comparison:

For comparison, you can look at the more or less “raw” Pisa GHCN graph here:

http://www.unur.com/climate/ghcn-v2/623/16158.html

and compare the before and after adjustment (and much closer scale) here:

http://wattsupwiththat.files.wordpress.com/2009/01/paolo-figure14.png

That is a figure from the WUWT posting about Italy.

Notice that the start of the graph gets about 1.75C nocked out of it… So somewhere in this adjustment process, the 60 years of Pisa history gets a 1.75C added tilt just from that process. 2C per century. Rather a lot, and not in the “raw” data.

Pisa from PApars.GHCN.CL.1000.20


*** urb stnID: 161580004 # rur:   31 ranges:  1949 2008 Radius:      500.
LONGEST rur range: 1880-2008   129 109620002 617 HOHENPEISSENB
add stn    2 range: 1883-2008   126  066800003 646 SAENTIS 
 data added:  126  overlap: 126  years
add stn    3 range: 1880-1985   106  067190010 646 ST. BERNARD SWITZERLA  
 data added:  106  overlap: 106  years
add stn    4 range: 1887-2008   102 111460002 603 SONNBLICK 
 data added:  102  overlap: 102  years
add stn    5 range: 1880-1960    81  067530010 603 ST. GOTTHARD SWITZERLA
 data added:  81  overlap: 81  years
add stn    6 range: 1880-1980    69 144470000 609 HVAR   
 data added:  69  overlap: 69  years
add stn    7 range: 1880-1943    64 112340010 603 OBIR       AUSTRIA
 data added:  64  overlap: 64  years
add stn    8 range: 1951-2008    58 109610003 617 ZUGSPITZE 
 data added:  58  overlap: 58  years
add stn    9 range: 1933-1985    53  067300000 646 JUNGFRAUJOCH 
 data added:  53  overlap: 53  years
add stn   10 range: 1951-2007    32 162800000 623A PONZA
 data added:  32  overlap: 32  years
add stn   11 range: 1951-1981    31 160660000 623A MILANO/MALPEN
 data added:  31  overlap: 31  years
add stn   12 range: 1951-1980    30 161460000 623 PUNTA MARINA
 data added:  30  overlap: 30  years
add stn   13 range: 1951-1980    30 160400000 623 TARVISIO
 data added:  30  overlap: 30  years
add stn   14 range: 1951-1980    29 165060000 623 GUARDIAVECCHI 
 data added:  29  overlap: 29  years
add stn   15 range: 1954-2007    29 161790000 623 FRONTONE 
 data added:  29  overlap: 29  years
add stn   16 range: 1951-1980    29 161420010 623 RIFREDO MUGELLO
 data added:  29  overlap: 29  years
add stn   17 range: 1951-1979    29 161290000 623 ISOLA DI PALM 
 data added:  29  overlap: 29  years
add stn   18 range: 1951-1979    29 161190010 623 PASSO DEI GIOVI  
 data added:  29  overlap: 29  years
add stn   19 range: 1955-2007    28 162240000 623 VIGNA DI VALL 
 data added:  28  overlap: 28  years
add stn   20 range: 1951-1978    27 161970020 623 ISOLA DI PIANOSA 
 data added:  27  overlap: 27  years
add stn   21 range: 1953-1980    27 161160010 623 GOVONE 
 data added:  27  overlap: 27  years
add stn   22 range: 1952-1977    24 165380010 625 MACOMER 
 data added:  24  overlap: 24  years
add stn   23 range: 1951-1974    24 165200020 623 ISOLA ASINARA
 data added:  24  overlap: 24  years
add stn   24 range: 1954-1977    24 162800010 623A TORRE OLEVOLA AERO
 data added:  24  overlap: 24  years
add stn   25 range: 1954-1976    23 162940010 623 CAPRI
 data added:  23  overlap: 23  years
add stn   26 range: 1960-2007    23 162450000 623A PRATICA DI MA 
 data added:  23  overlap: 23  years
add stn   27 range: 1951-1975    23 161490010 623 SASSO FELTRIO 
 data added:  23  overlap: 23  years
add stn   28 range: 1951-1973    23 160360010 623A AVIANO 
 data added:  23  overlap: 23  years
add stn   29 range: 1951-1974    21 161970010 623 ISOLA GORGONA
 data added:  21  overlap: 21  years
add stn   30 range: 1961-1980    20 162340000 623 GUIDONIA 
 data added:  20  overlap: 20  years
add stn   31 range: 1949-1968    20  075860010 615 MONT VENTOUX FRANCE     
 data added:  20  overlap: 20  years

So there they are. These are the stations that are used to “modify” Pisa and the years during which they have data that overlap Pisa. By looking at each overlap period, and the average of the records that overlap in that period, we ought to be able to figure out which stations caused the Pisa data points to move. It will also likely take some “code time” looking at what the different parts of PApars.f do to the data in that averaging. That’s what I’ll be looking at about 1am to 4am tonight when everyone else is sleeping and I can “have a bit of a think” about it…

If you want to “get ahead of me” in the chase, feel free. You have the pointers above, the log file, and here is the source code…

http://chiefio.wordpress.com/2009/03/08/gistemp-step2_PApars/

UPDATE: 1 Sept 2009

This update has to do with a particular thing that PApars.f does that I think may be bogus and part of the cause for the large temperature shifts in the early years for some sites, like Pisa.

First, the “human readable” form, then the “computer language support”.

The program claims to “remove the station bias” by taking the interval of overlap of a new station, relative to the average of prior adjusted stations, and finding the average distance from that average, then moving the new data such that this “mean” will not change. Basically, you have a bunch of “rural” stations and you don’t want to shift that mean when you “add one”, you just want it’s “tilt” to have an impact. That is, if an old year is cold, it will pull an old year down, but some newer year will have to pull a newer year up to keep the mean stable.

Sounds sort of OK… but I do wonder about all these averaging of averages of offsetterized averages of anomalies… (the data we are dealing with here are “anomalies” not actual temperatures, which adds is own degree of indirection and confusion).

So I go looking at the code for a basic “sanity check” and want to pay particular attention to the “edge case” of the first record. Just HOW is it “de-biased” to be put into this “average rural anomaly reference” record? What I found is that, as near as I can tell, it isn’t.

That’s right, the “first station” IS the “Average” at the start of the series.

ALL subsequent “added station” data are ‘adjusted’ to ‘remove bias’ by referencing them to a ‘mean’ based initially on a single station that was not ‘unbiased’.

A disclaimer: I’m still working through this particular bit of code, and I’ve been ‘short slept’ a few nights; so I might have missed something here. That is why I’m putting this update here. I’d like to get “more eyes” on it (and some with less caffeine and more sleep ;-) Basically, I’d like someone else to “sanity check” this assertion and maybe even point out some bits I might have missed.

With that said: If this observation stands up to scrutiny, it means that every single “first ‘rural’ station” in every single ‘urban adjustment’ is a cherry picked bias. Not Good. The implications of this are why I’m rushing this point to “public” scrutiny rather than stewing on it for a few days (weeks?) as I sort it out.

Since Hohenpeissenberg is a very long record in Europe, it would bias a great number of other stations (the ‘first record’ slot goes automatically to the ‘longest lived’ record within the 1000 km radius (or 500 km if lots of stations qualify). And that might explain the extraordinary effort put into getting a longer Hohenpeissenburg record. Nothing like a little Cold German edge of Swiss Alps cold to make the past colder, yet be “averaged out” in newer records as a bolus of new thermometers move the recent data a bit higher… but the “mean” stays the same.

OK, The Code:

C**** Start with the station with the longest time record
      IS=ISOFI(1)
      IOFF=MFSR(IS)-I1SR(IS)
      nuseid(is)=nuseid(is)+1
C**** First update of full data and weight arrays
      DO 160 M=I1SR(IS),ILSR(IS)
c     if(M+IOFF.gt.IYRM0) stop 244
      AVG(M+IOFF)=RDATA(M)
      IF(RDATA(M).LT.XBAD) WT(M+IOFF)=WTI(1)
      IF(RDATA(M).LT.XBAD) IWT(M+IOFF)=1
  160 CONTINUE

The line right after “DO 160″ is a commented out “if” statement that does nothing now that it’s been turned into a comment with the leading “c”. We set a couple of variables and increment the “number used” counter then start a “DO” loop from first to last year of the adjustment average.

Notice that AVG(M+IOFF) = RDATA(M)

We just stuff the present record anomaly data into the AVG bucket. No adjustment of any kind. Rather than keeping the two arrays in sync, one is offset via “IOFF”. The WT , WTI, IWT and other hard to read variants are various buckets for holding weighting flags. The weighting is adjusted by radius. This posting is not looking at weighting here, though, we’re talking about BIAS.

And it sure looks to me like the first station is just accepted as RIGHT without addressing the issue of “is Hohenpeissenberg anomaly colder than or biased relative to Pisa?”

Then we go off to “add in the new stations”:

      C**** Add in the remaining stations
      DO 190 I=2,IS0
      IS=ISOFI(I)
      IOFF=MFSR(IS)-I1SR(IS)
      write(*,'(a,i5,a,i5,a,i4,i6,i10)')'add stn',i,' range:',
     *   MFSR(IS)+IYOFF,'-',ILSR(IS)+ioff+IYOFF,LENis(i),idr(is)

We DO the 2nd to the limit of ‘nearby rural’ stations (IS0) writing out their log entry on the way.

C**** Extend the new data into a full series
      DO 170 M=1,IYRM
  170 DNEW(M)=XBAD

Pre-stuff the NEW Data array with bad flags, to be overwritten only where we have a good data item.

      DO 180 M=I1SR(IS),ILSR(IS)
c     if(M+IOFF.gt.IYRM0) stop 259
  180 DNEW(M+IOFF)=RDATA(M)

I prefer to use a NNN Continue to end a loop, but if you end on a statement, it does execute that statement, so the “commented out” if statement inside the loop does nothing, but the target at 180 does. For those records inside the limits of the average range, it stuffs the RDATA item for that station into the DNEW array for that year position).

      NF1=MFSR(IS)
      NL1=ILSR(IS)+IOFF
C**** Shift new data, then combine them with current mean
      CALL CMBINE (AVG(1),WT,IWT, DNEW,NF1,NL1,WTI(I),
     *  IDR(IS),NSM,NCOM)
      write(*,*) 'data added: ',nsm,' overlap:',ncom,' years'
      IF(NSM.EQ.0) GO TO 190
      nuseid(is)=nuseid(is)+1
  190 CONTINUE

For some reason, the folks who wrote this code love to change the names of things mid stream. So the variables NF1 AND NL1 (that I think means First and Last) are stuffed from other variables, then handed to the CALL CMBINE (along with the New Data array and weighting factors). When we return, we print out a record that says we added that station to the average and increment the number of used IDs by one nuseid(is)=nuseids(is)+1 (And here you can see the mixing of f77 ALL CAPS code with newer F90 lower case… clearly an ‘update’ happened at some point).

So what does CMBINE do? It is a subroutine that combines the two records by “removing the bias” from the new data relative to the existing average. But on the first call, the average is only the initial station, unadjusted for “bias”, all future additions must conform to the “mean” it sets. What happens if it is biased?

      SUBROUTINE CMBINE (AVG,WT,IWT, DNEW,NF1,NL1,WT1,ID,NSM,
NCOM)
C****
C**** Bias of new data is removed by subtracting the difference
C**** over the common domain. Then the new data are averaged in.

and a bit further down:

      DO 10 N=NF1,NL1
      IF(AVG(N).GE.XBAD.OR.DNEW(N).GE.XBAD) GO TO 10
      NCOM=NCOM+1
      SUM=SUM+AVG(N)
      SUMN=SUMN+DNEW(N)
   10 CONTINUE

If either the “average” or the “new” data are a bad flag, just skip it and jump to 10, the end of the DO loop. Otherwise, increment the number of items counter NCOM by one and add the Average for each year to a sum of the averages (first pass through, this will be ONLY the first rural station record, unadjusted!) and add the New data to a new data sum.

      IF(NCOM.LT.NLAP) RETURN
      BIAS=(SUM-SUMN)/FLOAT(NCOM)

If we don’t have enough overlap (count greater than 20) give up and return. Otherwise, compute the BIAS that is simply the difference of the two summed series divided by the count. The new data are referenced to the AVERAGE to measure bias, but the very first record IS the “benchmark” on the first pass. It is not adjusted for “bias”, it sets the bias benchmark. So the 2nd record will be adjusted to conform to the mean of that bias, then that average becomes the standard for the next record (with both the 1st record, and the 2nd one adjusted to the first one) reflecting any “bias” present in the first record).

C**** Update period of valid data, averages and weights
      DO 20 N=NF1,NL1
      IF(DNEW(N).GE.XBAD) GO TO 20
      WTNEW=WT(N)+WT1
      AVG(N)=(WT(N)*AVG(N)+WT1*(DNEW(N)+BIAS))/WTNEW
      WT(N)=WTNEW
      IWT(N)=IWT(N)+1
      NSM=NSM+1
   20 CONTINUE

Then, for each of the years, IFF the NEW data is not a missing / bad data flag, we adjust the weighting factors (that are based on the distance of the station from the Urban station), and compute a “new” AVG with the DNEW record ‘adjusted to remove bias’ but the AVG left alone (it, presumably, already being free of bias from prior passes through here; but in fact carrying forward an accumulating bias). Except in the case of the first record. THAT record was accepted As Is.

We then increment some counters and return the result

OK, this is rather crufty and someone complicated code, written in a painful style, with lots of I i 1 L l confusions possible and lots of 0Oo confusions possible and COMMON blocks that might be changing things somewhere else a bit unseen and….

So I’m asking for some help. I’m asking for a ‘sanity check’ on what I think is going on and what I suspect I’ve found. I’m not ready to shout Eureka! until I’ve been “desk checked” by someone else to make sure this isn’t just too much coffee and not enough sleep talking…

But sure looks like a “Eureka!” moment is right around the corner to me…

About these ads

About E.M.Smith

A technical managerial sort interested in things from Stonehenge to computer science. My present "hot buttons' are the mythology of Climate Change and ancient metrology; but things change...
This entry was posted in AGW GIStemp Specific, Favorites and tagged , , , , , . Bookmark the permalink.

35 Responses to GIStemp a slice of Pisa

  1. Murray says:

    St. Bernard, Gotthard, and JungfrauJoch are =>2000 meters above sea level higher than Pisa. They should cool the history more than somewhat. Murray

  2. E.M.Smith says:

    @Murray

    2000 Meters! Yikes! So we have Alps glacial in the mix. Time to ‘run the numbers’ through the code by hand and see what it does to them…

  3. Ellie in Belfast says:

    Oops – never occurred to me to mention alpine altitudes when the St Gottard/St Bernard passes came up prevously. After some checking:
    Hohenpeißenberg – 985m
    Saentis – 2500m,
    Grand-Saint-Bernard – 2479 m,
    Sonnblick – 3105m,
    St Gotthard – 2115m (pass height; hospice at pass reported as historical weather station) http://www.worldwidepanorama.org/worldwidepanorama/wwp608/html/RolfRis.html
    “Weather division. Often in Europe (and more locally in Switzerland) we have two different weather conditions.
    When there is rainy weather north of St. Gotthard, it is then mostly that we have warm and sunny conditions in the south.”
    Hvar – island off Split (Croatia) – Adriatic(Mediterranian) Sea
    Obir – 2044m,
    Zugspitze – 2962m,
    Jungfraujoch – 3572 m,
    Ponza – airport, 184m,
    MONT VENTOUX FRANCE – 1907m,

    CAP CARBON – interesting, but if you try to Google it there are too many references to ‘cap carbon’ dioxide!

    Even if this type of comparison should be done, this is complete overkill. Europe has many microclimates and this has completely ignored gross geography never mind microclimates.

    For future ref (and you may already have found/know this)
    Re Brightness index – more to it than B: A/B/C= dark/dim/bright
    There is a good discussion in comments here:
    http://atmoz.org/blog/2008/02/16/giss-adjustments-to-miles-city-ushcn245690/
    starting with comment by steven mosher on 17 Feb 2008 at 8:24 am and several further down

    The actual list with values is here:
    http://data.giss.nasa.gov/gistemp/station_data/station_list.txt
    This may help figure out some of the what stations/why are used as rural references.

  4. E.M.Smith says:

    @Ellie:

    Thanks!

    No, I didn’t know about the details of the Brightness Index. All I really knew is that it existed, somewhere, in some form. One of the “loose ends” I’d not chased down yet. I only got sucked into this whole climate science thing as a consequence of too many What The?!? moments about 2 years ago. Before that, I happily thought “Maybe there IS a problem”. Then I decided to look…

    The rest, as they say, is history…

    Now, it would seem, I’m in the middle of becoming the world expert on the GIStemp code. I’m sure I’ve had more “face time” with it than Hansen has had in the last few years…

    Jungfraujoch – 3572 m

    Per these folks:

    http://www.esrl.noaa.gov/gmd/obop/mlo/

    Mauna Loa Observatory is at 3397 m

    Yet MLO is tossed out of the record for being at an “atypical altitude” while Jungfraujoch is kept in as a Rural Reference Station?!

    I’m sorry, I smell cooked books being scorched… and they want us to believe kicking out MLO had nothing to do with the long, stable, non-warming temperature record from the site…

    (Young Lady Ridge / Yoke? Sounds like an, um, interesting story somewhere… )

    FWIW, I’m slowly reaching the opinion that the major issues in GIStemp et. al. are, roughly in order of magnitude of the bogosity:

    1) Does not adequately filter The March Of The Thermometers, partly due to the following items.

    2) The whole UHI unadjust / readjust process is bogus. It does nothing but corrupt the data. Start with GHCN Adjusted, instead, and just skip the GIStemp adjustments. (A future A/B compare project, now added to my list…) The lookaside to places like Jungfrauyoch and Aviano Air Base is just so broken it is beyond words, and the Pisa A/B chart shows why.

    3) They simply use too coarse a granularity. Why is an interesting question, but the impact is clear.

    Zones that are too large blend Siberia and Italy and hide the southern movement of thermometers. 6 zones, with 2 of them polar (Of equal latitude so very UNequal AREA) put Way To Many thermometers in “the same zone type” of Equator +30 and Equator -30 that accounts for most of the planet surface and neatly captures most of the land area in one zone type (of two zones). The choice also masks the near absence of data in the Southern Cold latitudes. Then the poles are handled as special cases further reducing their truths. (i.e. Arctic temps are guessed from ice extent guesses…) The end result is hiding The March Of The Thermometers. (Future project, re-do benchmark with equal AREA bands, not latitude bands…)

    Reference Station Ranges that are WAY too large. The 1000 km in one step, 1200 km in another, etc. Results in junk like we see in PApars.f for Pisa. IIRC it reaches out 1500 km in the SST box Reference Station Method blending. (Future test: Make RSM limit 100 km and re-run A/B.)

    4) Recursive application of that which is not shown to be valid beyond one application. (i.e. that reference station in STEP2 might well be applying fabricated data from STEP1 that might itself have used fabricated data from STEP0…) Exacerbated by the RSM ranges above. (Future test: Add “fabricated data” flag to prevent recursive use of RSM.)

    5) A general lack of honesty in asking the data what it has to say; that is, agenda driven coding and design. It could be accidental (folks do deceive themselves) or not; but it is there. This has many small effects, that add up. Such as not using the “airstn” flag to filter airports out of the “rural” group. Removing MLO, but leaving in Jungfraujoch. 1001 small decisions where the bias (perhaps subconscious) adds up. (Future test: put in “don’t use airstn flag” test and re-run A/B.)

    6) Code “oopsies” like the F to C conversion that warms the temperature record by 1/1000 C in one line of code.

    7) Crappy data. The airstn flag is often wrong, and not kept ‘by year’ only ‘by station’ so changes in an airport over time are not caught / kept (and it ought to be ‘sized’ with different values for grass field, small private, regional, commercial jet, major international, etc.). That’s just one example…

    8) They ignore altitude, distance from the ocean, and in general micro climate type, when choosing Reference Stations for data change / fabrication actions.

    That understanding will guide my testing plan.

  5. Peter O'Neill says:

    CAP CARBON in the log above is not correct. This should be TARVISIO (623160400000). The Gistemp log unfortunately omits the country code and so makes it more difficult to correctly identify the appropriate stations. I have remedied this in my Gistemp port, and added the station name and the weight given to each station in the log (and added a station lookup for all this information in the GUI). I’m posting the log for Pisa below, and will post the logs for the stations adjusted using the Icelandic airports in another comment shortly.

    623 16158000 [PISA/S. GIUST] 31208

    lat 43.68 elevs 6 pop U topo FL stloc CO
    lon 10.38 elevg 4 ipop 91 stveg xx iloc 9
    airstn A itowndis 3 grveg: COASTAL EDGES

    PApars.GHCN.CL.1000.20.log
    ==========================

    number of rural/urban stations 2501 3788

    urb stnID:623161580004 # rur: 32 ranges: 1949 2008 500.
    longest rur range: 1880-2008 129 [wgt: 0.083] 617109620002 [HOHENPEISSENB]
    add stn 2 range: 1883-2008 126 [wgt: 0.184] 646066800003 [SAENTIS]
    data added: 126 overlap: 126 years
    add stn 3 range: 1880-1985 106 [wgt: 0.29] 646067190010 [ST. BERNARD SWITZERLA]
    data added: 106 overlap: 106 years
    add stn 4 range: 1887-2008 102 [wgt: 0.142] 603111460002 [SONNBLICK]
    data added: 102 overlap: 102 years
    add stn 5 range: 1880-1960 81 [wgt: 0.336] 646067530010 [ST. GOTTHARD SWITZERLA]
    data added: 81 overlap: 81 years
    add stn 6 range: 1880-1980 69 [wgt: 0.009] 609144470000 [HVAR]
    data added: 69 overlap: 69 years
    add stn 7 range: 1880-1943 64 [wgt: 0.104] 603112340010 [OBIR AUSTRIA]
    data added: 64 overlap: 64 years
    add stn 8 range: 1951-2008 58 [wgt: 0.172] 617109610003 [ZUGSPITZE]
    data added: 58 overlap: 58 years
    add stn 9 range: 1933-1985 53 [wgt: 0.253] 646067300000 [JUNGFRAUJOCH]
    data added: 53 overlap: 53 years
    add stn 10 range: 1951-2007 32 [wgt: 0.244] 623162800000 [PONZA]
    data added: 32 overlap: 32 years
    add stn 11 range: 1951-1981 31 [wgt: 0.499] 623160660000 [MILANO/MALPEN]
    data added: 31 overlap: 31 years
    add stn 12 range: 1951-1980 30 [wgt: 0.648] 623161460000 [PUNTA MARINA]
    data added: 30 overlap: 30 years
    add stn 13 range: 1951-1980 30 [wgt: 0.2] 623160400000 [TARVISIO]
    data added: 30 overlap: 30 years
    add stn 14 range: 1951-1980 29 [wgt: 0.42] 623165060000 [GUARDIAVECCHI]
    data added: 29 overlap: 29 years
    add stn 15 range: 1954-2007 29 [wgt: 0.627] 623161790000 [FRONTONE]
    data added: 29 overlap: 29 years
    add stn 16 range: 1951-1980 29 [wgt: 0.817] 623161420010 [RIFREDO MUGELLO]
    data added: 29 overlap: 29 years
    add stn 17 range: 1951-1979 29 [wgt: 0.883] 623161290000 [ISOLA DI PALM]
    data added: 29 overlap: 29 years
    add stn 18 range: 1951-1979 29 [wgt: 0.688] 623161190010 [PASSO DEI GIOVI]
    data added: 29 overlap: 29 years
    add stn 19 range: 1954-1981 28 [wgt: 0.129] 646066100000 [PAYERNE]
    data added: 28 overlap: 28 years
    add stn 20 range: 1955-2007 28 [wgt: 0.539] 623162240000 [VIGNA DI VALL]
    data added: 28 overlap: 28 years
    add stn 21 range: 1951-1978 27 [wgt: 0.75] 623161970020 [ISOLA DI PIANOSA]
    data added: 27 overlap: 27 years
    add stn 22 range: 1953-1980 27 [wgt: 0.559] 623161160010 [GOVONE]
    data added: 27 overlap: 27 years
    add stn 23 range: 1952-1977 24 [wgt: 0.199] 623165380010 [MACOMER]
    data added: 24 overlap: 24 years
    add stn 24 range: 1951-1974 24 [wgt: 0.326] 623165200020 [ISOLA ASINARA]
    data added: 24 overlap: 24 years
    add stn 25 range: 1954-1977 24 [wgt: 0.289] 623162800010 [TORRE OLEVOLA AERO]
    data added: 24 overlap: 24 years
    add stn 26 range: 1954-1976 23 [wgt: 0.057] 623162940010 [CAPRI]
    data added: 23 overlap: 23 years
    add stn 27 range: 1960-2007 23 [wgt: 0.438] 623162450000 [PRATICA DI MA]
    data added: 23 overlap: 23 years
    add stn 28 range: 1951-1975 23 [wgt: 0.66] 623161490010 [SASSO FELTRIO]
    data added: 23 overlap: 23 years
    add stn 29 range: 1951-1973 23 [wgt: 0.382] 623160360010 [AVIANO]
    data added: 23 overlap: 23 years
    add stn 30 range: 1951-1974 21 [wgt: 0.7] 623161970010 [ISOLA GORGONA]
    data added: 21 overlap: 21 years
    add stn 31 range: 1961-1980 20 [wgt: 0.467] 623162340000 [GUIDONIA]
    data added: 20 overlap: 20 years
    add stn 32 range: 1949-1968 20 [wgt: 0.162] 615075860010 [MONT VENTOUX FRANCE]
    data added: 20 overlap: 20 years
    possible range increase 27 58 60

  6. Peter O'Neill says:

    For Ellie in Belfast:

    KEFLAVIKURFLU is used to adjust REYKJAVIK and AKUREYRI.
    VESTMANNAEYJA is also used to adjust REYKJAVIK and AKUREYRI.
    GRIMSEY is also used to adjust REYKJAVIK and AKUREYRI.
    None of these are used to adjust any station outside Iceland. I’ve pasted the logs for Reykjavik and Akureyri below. When considering adjustment using Vestmannaeyja it might be a good idea to bear in mind the volcanic history of the island of Heimaey, where the airstrip is located: “the Eldfell eruption of January 1973 which created a 700-foot-high mountain where a meadow had been, and caused the island’s 5000 inhabitants to be temporarily evacuated to the mainland” (http://en.wikipedia.org/wiki/Vestmannaeyjar). When I visited Heimaey in 1980 it was only necessary to brush aside the top 15 cm or so of ash to feel the heat below near that airstrip.

    620 04030000 [REYKJAVIK] 37101

    lat 64.13 elevs 53 pop U topo HI stloc CO
    lon -21.90 elevg 54 ipop 98 stveg xx iloc 1
    airstn A itowndis 1 grveg: COOL GRASS/SHRUB

    PApars.GHCN.CL.1000.20.log
    ==========================

    number of rural/urban stations 2501 3788

    urb stnID:620040300000 # rur: 6 ranges: 1901 2008 500.
    longest rur range: 1880-1980 101 [wgt: 0.765] 620040130000 [STYKKISHOLMUR]
    add stn 2 range: 1884-1981 98 [wgt: 0.779] 620040480000 [VESTMANNAEYJA]
    data added: 98 overlap: 97 years
    add stn 3 range: 1884-1970 87 [wgt: 0.258] 620040920000 [TEIGARHORN]
    data added: 87 overlap: 87 years
    add stn 4 range: 1880-1970 79 [wgt: 0.355] 620040650000 [GRIMSEY]
    data added: 79 overlap: 79 years
    add stn 5 range: 1949-2008 60 [wgt: 0.928] 620040180005 [KEFLAVIKURFLU]
    data added: 60 overlap: 33 years
    add stn 6 range: 1951-2008 58 [wgt: 0.35] 620040820000 [HOFN I HORNAFIRDI/HOLAR IC]
    data added: 58 overlap: 58 years
    possible range increase 41 81 81

    620 04063000 [AKUREYRI] 41401

    lat 65.68 elevs 27 pop S topo MV stloc CO
    lon -18.08 elevg 101 ipop 11 stveg xx iloc 1
    airstn x itowndis -9 grveg: TUNDRA

    PApars.GHCN.CL.1000.20.log
    ==========================

    number of rural/urban stations 2501 3788

    urb stnID:620040630003 # rur: 6 ranges: 1882 2008 500.
    longest rur range: 1880-1980 101 [wgt: 0.554] 620040130000 [STYKKISHOLMUR]
    add stn 2 range: 1884-1981 98 [wgt: 0.447] 620040480000 [VESTMANNAEYJA]
    data added: 98 overlap: 97 years
    add stn 3 range: 1884-1970 87 [wgt: 0.581] 620040920000 [TEIGARHORN]
    data added: 87 overlap: 87 years
    add stn 4 range: 1880-1970 79 [wgt: 0.822] 620040650000 [GRIMSEY]
    data added: 79 overlap: 79 years
    add stn 5 range: 1949-2008 60 [wgt: 0.431] 620040180005 [KEFLAVIKURFLU]
    data added: 60 overlap: 33 years
    add stn 6 range: 1951-2008 58 [wgt: 0.586] 620040820000 [HOFN I HORNAFIRDI/HOLAR IC]
    data added: 58 overlap: 58 years
    possible range increase 49 98 98

  7. May I simply offer my congratulations for doing some Digging. There’s nothing worse than OPC (Other People’s Code) and my admiration for your persistence and diligence increases with every visit to your site.

    This is Good, Important work.

    Well done (and please, as the actress said to the bishop, don’t stop just yet.)

  8. Peter O'Neill says:

    As regards source code: WordPress still seems to have swallowed up some of this. I don’t know if this applies to STEP2 PApars, but I am currently working on STEP3 to.SBBXgrid.f and I noticed that http://chiefio.wordpress.com/2009/03/07/gistemp-step345_tosbbxgrid/ loses some of lines 249 through 275 which should be (hoping now that these appear correctly when pasted in! Otherwise please refer to the original source code to see these lines):

    DO 120 M=I1S(IS),I1S(IS+1)-1
    C?LIM IF(RDATA(M) >RMAX or <RMIN) RDATA(M)=XBAD
    IF(RDATA(M).EQ.XBAD) GO TO 120
    LEN(IS)=LEN(IS)+1
    C?*** Change data if necessary (e.g. trace flag for precip)
    C?PRC IF(RDATA(M).EQ.TRACE) RDATA(M)=0.
    C?LIM IF(RDATA(M).GT.RMAX or 1′ below in the orig code
    IF(CSDBYR.LE.CSCRIT) THEN

    but appear instead as:

    DO 120 M=I1S(IS),I1S(IS+1)-1
    C?LIM IF(RDATA(M) >RMAX or 1′ below in the orig code
    IF(CSDBYR.LE.CSCRIT) THEN

    REPLY: Fixed. The comments had a LESSTHAN character in them that
    caused WordPress to steal them as an HTML tag (up to the next GTtag).

  9. Peter O'Neill says:

    Follow up to my last comment: I pasted 27 lines, but WordPress has lost some of these, leaving only 8! Not as extreme as the mangled code which appears on http://chiefio.wordpress.com/2009/03/07/gistemp-step345_tosbbxgrid/ instead of the original 27 source code lines, but still very different from the original source code!

    All the source code lines on the web page before and after these mangled lines match the original source code perfectly.

  10. rob r says:

    I have looked at your results for quartiles from a few posts back.

    The number of very long records (>103 yrs) in GISSTEMP appears to be relatively stable until very recently.

    Decade 1870-79 (445 long records) 77% of total
    Decade 1900-09 (1315) 51.8%
    Decade 1930-39 (1320) 33.1%
    Decade 1950-59 (1337) 20.4%
    Decade 1980-89 (1198) 15.1%
    Decade 1990-99 (898) 32.6%
    Decade 2000-09 (80) 5.2%

    The question is: what happened to all the long-lived stations after the late 1990′s?

    Surely 91% of these stations were not all suddenly closed down about 10 years ago. What would happen to the global average temp if a significant number of these stations could be rediscovered and if the missing station temp data was added back into the GISSTEMP stewpot?

    I recall either at climate audit or WUWT about 1 year ago that via a massive team effort they managed to rediscover the location of Wellington and the temp record for Wellington (Capital city of NZ) which had dropped out of GISSTEMP. The station was never closed and the NZ Met Service and NIWA had the data all along.

    A substantial part of the degradation of the GISSTEMP data base probably relates to NOAA losing track of 100′s of stations that are still continuously operational. If NOAA stops collecting and supplying certain station data to GISS it appears that James Hansen does not go looking for it.

    By the way you are doing great work here.

  11. E.M.Smith says:

    Peter O’Neill
    Follow up to my last comment: I pasted 27 lines, but WordPress has lost some of these,

    If any line has a LESSTHAN in it, WordPress takes that as the start of an HTML tag and strips to the next GREATERTHAN sign. It may do something similar with some other characters.

    The only solution is to spot all the places where this will happen and put in the metacharacters for the LESSTHAN (i.e. AMPERSAND L T SEMICOLON).

    I tried using the PREFORMATED tag of LESSTHAN PRE GTHAN but it still seems to reach inside and steal some times…

    Oh the joys of layers of reserved words and characters and meta characters and markup languages…

    Thanks for the pointer to the spot I missed, I’ll patch it shortly.

    And thanks for the pointer on the country code issue.

    Oh, and glad to hear someone else has a copy of GIStemp running. I was beginning to wonder if I was the only one…

  12. E.M.Smith says:

    rob r
    I have looked at your results for quartiles from a few posts back.

    The number of very long records (>103 yrs) in GISSTEMP appears to be relatively stable until very recently.

    Remember that this is long lived Station Records. The thermometer might still be there, and still be reporting, but have a different “modification flag” and so is a new “record”.

    So there are many reasons a thermometer record might drop out of the long lived set, some being closure of the site, some being changed equipment leading to a new record, and some being a change of “modification history”. I’ve not gone into depth about exactly which is the primary cause of the recent drop out (though I suspect some combination of equipment change and modification change. USHCN is, I believe, deprecated in some way in favor of the GHCN record of the same thermometers. This can account for some of it.)

    As soon as I hit upon the Airport connection, what happened to thermometers in the last decade fell in importance in my queue. (It’s still there, but the Airport thing “jumped queue” ;-)

    Anyone “with clue” is welcome to pitch in.

  13. E.M.Smith says:

    Peter O’Neill
    CAP CARBON in the log above is not correct. This should be TARVISIO (623160400000). The Gistemp log unfortunately omits the country code and so makes it more difficult to correctly identify the appropriate stations. I have remedied this in my Gistemp port, and added the station name and the weight given to each station in the log (and added a station lookup for all this information in the GUI).

    OK, I’ve verified that I had done a “grep” that hit a record with the right number text in it, but off by one (used the last country code digit as the first digit of station ID). The perils of trying to patch by hand deficiencies in the program output. Oh Well.

    At this point I’ve corrected the posting and removed that error.

    I’ve been torn between two goals:

    1) Keep the code as close to original as possible to be able to prove that I’ve not introduced a change causing the output of broken values (i.e. I can toss rocks at bogus output with pretty fair odds that I didn’t change the code.)

    2) Fix broken things and improve clear deficiencies (like your log file enhancements, that are very nice, BTW).

    I’ve tended toward #1, but that can have issues like this one (where trying to manually make up for a deficiency of the log – too much brevity, an error is made). So I’m thinking maybe a bit more #2, but keeping an “original” version available for validation…

    More complicated, but might work better overall.

    In working through PApars.f, for example, there are a bunch of variables that contain various combinations of I i 1 l and L with 0 o and O. Like the use of both ILSR and I1SR as variables (and with a subscript of IS, no less). Trying to sort out ILSR(IS) from I1SR(IS) is painful, at best. I’ve resisted the urge to “fix it” for readability (to be able to say “it is the original code with minimal changes”)… on the other hand, it would be a lot easier to read if the names were sorted out better…

    Sidebar on Style: The general FORTRAN style guides advise to avoid using i l L I 1 or o O 0 Q in variable names if possible, and never mixing a couple of them in the same code if at all possible. (a leading I is common for Integer variables, and O is often on the end for “old”, but ought not be mixed with things that would confuse or mislead). GIStemp ignores this rule greatly (and in fact, seems to revel in making some parts highly unreadable and error prone).

    For example, among the variables in PApars.f with close names: One is ILSR, the other is I1SR. They are even used together in one DO loop as loop limits (AND with the subscript IS):

    DO 180 M=I1SR(IS),ILSR(IS)

    There is one statement set particularly hard to read:
    I1SR(ISR)=I1Snow
    ILSR(ISR)=I1Snow+LENGTH+1

    You really have to go out of your way to get that many I, 1, and L in that little space. Unfortunately, the rest of the code is not much better…

    So I’ve been holding myself back from “improving it”, but your example with the log file catching an error is convincing me to “go for it” (but keep an intact “audit copy” for validation runs).

    Oh, and there is this ‘gem’ of obfuscated coding in the annav subroutine in toANNanom.f where a variable “seasis” is used along with one “seas” that is an array, used with a variable “is” so that we have:

    if(nms.gt.1) seas(is)=seasis/nms

    someone had to go out of their way to make that “pun” with
    seas(is) = seasis …

    The same “style” in the log files (obscurity) and in confusing use (station ID is sometimes 5 characters long, sometimes 8, sometimes 9 with modification flag and sometimes has the country code, sometimes not) leads to this kind of issue.

    OK, enough griping, back to dancing in the GIStemp mine field…

  14. Dennis Elliott says:

    A couple of weeks ago I suggested that the original temp records were produced for a wholly different purpose than trying to establish a global warming signature

    Out of curiosity, was GIStemp also set up originally to serve a different (and maybe not especially important) purpose and that’s why the code is so seemingly amateurish? That is, could it have been a “quickie” setup to test a few theories about temperature for some othe purpose? It would be interesting to know the who and why of that.

    E.M.. I’m not suggesting that I expect you to chase this down, but I thought maybe someone else might have an answer.

  15. Ellie in Belfast says:

    @Peter O’Neill

    re Iceland – that makes sense. Thank you. I do remember the eruption of Heimaey. How facinating to have visited it!

    A week ago it wasn’t clear to me how many stations were in the area or what rules were being applied. I’ve since spent some time looking at the GIStemp station data and got a feel for the numbers/stations a bit more.

  16. E.M.Smith says:

    @Dennis:

    It looks to me like the code started out as one chunk, then bits were “glued on” over time. Like it was a small project (I would guess for Mr. Hansen) who maybe did the STEP1 bit of glueing records together (that I suspect was later re-written into C and Python, but that is rampant speculation) then added STEP2 making anomaly maps, then using them to adjust “nearby” historical data with PApars.f making the OMG warming signal in places like Pisa. At that point, it looks like STEP0 was added to pull in more data (It even states that the name STEP0 was due to STEP1 already being in use). To “glue on” the antarctic stations and do a few special data sets, like a longer series for Hohenpeissenberg. At that point, we jump back to STEP3 (where the code looks like a slightly newer era of FORTRAN) and do the Grid / Box thing and we’re “all done”… Until sea temperatures pop up as a problem and “STEP4_5″ gets glued on to the end to merge a Sea Surface Temperature anomaly map SBBX.HadR2 from Hadley (no temperatures need apply in this step / these steps…) with a very FORTRAN90 feel.

    It is possible some of those might be out of order by one (it’s all “guess work” based on the “era” of the coding style and step numbers). For example, I could see STEP3 being completed before STEP0 was glued on, but then having some enhancements done that erased that history and made it look newer. (Isn’t code archaeology fun! 8-} But STEP3 has a “kinship” with STEP4_5. They share some code, the style is FORTAN90. It is also the case that “updates” were not very careful to preserve coding style. Lower case is blended into old f77 UPERCASE and f90 isms are sometimes found creeping into f77 code. (So we have invnt.f where you can choose which compiler nags you about what conflicting style piece, with each not liking part of the other era standard ;-) This argues that a complete re-write to F90 “style” is very unlikely to have happened in STEP3, the original (whatever it was).

    The general impression from the code is that it started life as a “research hand tool”. Somebody looking for a paper to publish and trying things to see what “looked good”.

    There are a lot of places where parameters are used so they can be “tweaked” to “see what happens” and maybe make a paper (IMHO). Not the kind of thing that would be needed in a production bit of code. Like “Zone” number being a parameter. They had not settled on “6″ as the magic number at the time the code was written. (Yes, I think 6 is a “cherry pick” to make something “interesting” happen or to allow a bit of code to run at all – any larger number blowing up on too few thermometers in some zone… and if it blows up, no paper this publishing cycle…)

    There are also bits of dreck left over that make it clear folks were playing with the bounds until they found something they liked. Typical “hand tool” and “R and D” type behaviours. An example? In PApars.f there is a bit of code, that, after I’ve sorted out exactly what it does, and postulated “why”, I’m pondering an article called:

    “The Curious Case of 1950.”

    Here is the teaser:

    There is a line, buried WAY down in the code that simply says:

    X0=1950.

    About 5 pages in. In the middle of a major DO loop. Just above “130 Continue”.

    A very odd place to do an initialization of a variable not used in that part of the code. One is left to wonder: Why?

    (And is reminded: “Why? Don’t ask why. Down that path lies insanity and ruin. – emsmith” … so we explore why…)

    About 3 pages further on, it is used (above 195 continue) in the line:

    X(NXY)=YR(NXY-X0)

    and one page further on (just above 200 Continue) in
    the “write” statement that dumps out a lot of stuff called “adjustment parameters”.

    So far, I’ve not found it anywhere else in PApars.f.

    It looks for all the world like someone would like to have had it be a variable, but made it a “plug number” during some run or other, and just left it as a fixed parameter.

    The “Common block” does pass it through to t2fit.f that has the line:

    xmin=Xknee+X0

    in the subroutine “getfit”.

    (That is called about 15 lines above the “write adjustment parameters” line. Yes, that simple “CALL GETFIT(15)” means that all the stuff in the COMMON block may have been changed somewhere else… Isn’t FORTRAN fun! /sarcoff> )

    So as a GUESS I’d say it looks like some kind of cherry pick limit on how resent the “knee” can be for tilting temperatures. That is, any “bogus” jumps like -1.75 C in a record are not allowed to get too close to the present where folks might notice and call “Bull Shit!” …

    But at this point, that’s just a guess. I need to worm my way through all the code and see just exactly what it does, and then make assertions about why. For now, it can only be a suspicion. (Anyone else who want’s to, can, of course DIG HERE!)

    The way it is used in the PApars.f code, though, just shouts at a failed attempt to make it a variable, swapped into making it a “plug number” instead, and just left “for the future”… Typical hand tool behavior.

  17. Murray says:

    In the entire Alpine region, averaging stations separated by as little as 10 km can be questionable. The Alps are a mass of microclimates. Cold grotty days in Chamonix coexist with lovely sunny days in Italy, the length of the Mont Blanc tunnel away. It can be lovely in Zermatt and raining a gully-washer in Saas Fe. Even Davos and Klosters, as close as they are can have very different weather on any given day. On larger scale, the north side of the Alps is just totally different from the south side climate-wise. What can these guys be thinking? Murray

  18. E.M.Smith says:

    @Murry:

    Thinking? You expect them to be thinking? How could you!
    8-)

  19. tty says:

    There is a large airfield at Guidonia. The weather data are almost certainly from there. The “Airfield” designation is very often missing in the GHCN data. Out of 19 sites in Sweden 6 are indicated as airfields. The actual figure is 11.

  20. E.M.Smith says:

    @tty

    Wow. I knew the data were “off” but didn’t realize they were off by that much. A 50% or so error rate is rather spectacular.

    I really am coming to believe that AGW is real, it’s just Airport Global Warming…

  21. Jeff Alberts says:

    What about the lukewarmers like Steve Mosher who agree that there are multiple independent lines of evidence supporting AGW? Do you think there are such things?

  22. E.M.Smith says:

    @Jeff

    I don’t know Mosher’s views. I can speak to mine, though.

    Yes, I think there are multiple lines of evidence, I just think we are completely missing any sizing on the lines of “causality” and some of them are mistaken. Oh, and the causality is confounded. Some things are considered causal of other things when they are not, and some things with a non AGW causality are attributed to AGW.

    So, for example, we have glaciers receding. Fine. But we’ve had 30 years of PDO in the warm phase. And we’re “long in the tooth” on the present Bond Event cycle. It’s a line of evidence, but the causality runs to ocean currents and natural cycles, not CO2.

    So lets break it down and size the impact of each thing… oh, we don’t have the data needed… So we have to speculate. IMHO, a lot of that shows up in papers of the form “Given these conclusions what assumptions can we draw?”

    But looking at the data you can see the impact of the code itself (the benchmark data are changed by the code by an amount) so an eyeball of it looks like about 1/2C to me. That much is attributable to GIStemp. The anomaly steps are shaping up to look like they add some too. Call it another 1/2 C, at least until I can construct a real benchmark for those phases and measure it. That will be about 1C from the code itself. (Or about .66 C per century). Until I “ran the numbers” through GIStemp and measured against that benchmark, this was not known. An outside observer would have had to conclude there was 2/3C per century of warming to account for somewhere and gone looking for cause. Perfectly rational, but wrong. That 2/3 C is from the programming. Very few people know that yet (especially given that I still have not finished all the “anomaly” steps analysis).

    The data themselves show some warming, but it is focused in adding thermometers to tropical places and airports. Maybe there is a little in it in the last 30 years of the PDO cycle but the longer term shows little trend in the stable thermometer set. Maybe 1 C at most? But that depends strongly on what year you start with and the early thermometer counts are way too sparse to be meaningful. So at this point I’d guess the real change in the data are about 0.25C to 0.5 C / century. But that can be confounded in that we are not paying attention to known cyclical processes of longer cycle (including the cycle of Bond Events with 1470 year cyclicality) so we might be measuring a real rise, from natural causes in a natural long lived cycle. But wait, the trend in thermometers by latitude was only made visible here a week or two ago. Not exactly a lot of time for the idea to spread and “catch hold”. And the degree to which “UHI” is “corrected” by using airports was also just shown. (And even that is slightly flakey to the low side, since a lot of airports do not have the airstn flag set in the data…)

    Then a lot of the other “lines of evidence” can be simply catching that 1/4C to 1/2 C per Century from normal long cycle events and either getting a scaling factor wrong or attributing the causality wrong (i.e. to CO2 caused warming). So take tree rings. They can easily show recent warming from added growth ring size… unfortunately the added CO2 can cause more growth and larger growth rings even with NO increase in temperature. Confounded growth causality… but there are still ‘multiple lines of evidence’… just the scale is gotten wrong and the reason confounded (heat vs CO2 fertilization directly).

    So at the end of the day I look at the “science” and it is just horridly sloppy and broken. I fear we handed out way too many diplomas from our schools and not enough discipline. Where, in the past, we had the 1 in 1,000,000 who where truly gifted get a Ph.D. we now have them handed out by the train load. These folks

    http://nces.ed.gov/das/library/tables_listings/show_nedrc.asp?rt=p&tableID=2046

    Say in one year alone we handed out
    83,041 “professional Degrees” things like DD, LLD and MD
    48,378 “Doctors Degrees” so that’s Ph.D land
    558,940 “Masters” degrees.

    Now think about that for a minute. In 10 years, that’s pushing 1/2 million Ph.D.s many of whom need to publish or perish. Over a 40 year professional life, that will add up to 2 million of them. From the USA alone. Don’t even get me started thinking about all those Masters holders working on papers…

    With a 200 M adult population (being very liberal…) that’s on the order of 1% of the population.

    Now I’m sure being in the 99th percentile is a big deal, but I’m also sure that it isn’t all that smart… and certainly not all of those who are smart will be diligent, careful, honest, etc. (FWIW, I’m above 99th percentile and I know how often I mess up and how dumb I can be, so it is not a great leap to think others “like me” can be pretty dumb some times.)

    The point? We’re cranking out more “mediocre and junk science” because we have a more mediocre average Ph.D. from handing them out to so many folks. And these folks are the ones who have to publish something to ‘make a name’. What happens when most of the basic truths have been found in, say, Pine Tree Biology. You need a paper. What will you do… Oh, LOOK! AGW is new and trendy, lets make an “AGW Pine Tree Biology” paper! Bet there isn’t much published on that!

    So, IMHO, folks “create the paper” but not the honest science. And they don’t see the difference because they were not really steeped in the traditions of excellence and history of science; they just went through the mill to get the degree and a good interesting job. They are not on a quest, searching for the truth, they are searching for the “published paper” and a cost of living raise.

    Back to AGW. What’s the impact?

    So at a minimum we can say that the warming from the code is roughly the same as that IN the data, and a lot of that in the data might just be from putting more thermometers in warm places and at airports.

    That is over a 150 year span. But a lot of the “lines of evidence” have a 30 to 40 year history. They show more warming “per century” because they project the 30 year warm PDO phase over 150 years as a straight line instead of realizing it’s a cycle.

    You can keep on going through that kind of thing and you end up with a lot of “lines of evidence” but also a big mess of confounded causalities, mistaken linear projections, broken code, biased data… A fair amount of it due to a bunch of folks “making the paper” but not pondering the meaning in depth nor integrating across the whole topic area.

    And at the end of it, I’m left to conclude that we really can not make many decent conclusions from most of the stuff that’s being passed off as science these days. The volume of dead trees turned into papers has gone up, but the volume of accurate and original thoughts, careful and discerning work, and insight has not; because the number of truly brilliant and gifted folks has not (and in fact, they are an ever smaller percentage of the published pool.) Many (or most) of the Ph.D.s are not a Newton or a Galileo concerned about their legacy, they have a job and a boss and a performance review committee… While at the same time, fewer of them are really looking for truth for its own sake.

    It is hard to find what you do not seek.

    So I’m not going to fault someone for looking at the mass of printed stuff and saying “Some of this must have some truth in it.” It’s very hard to look at that large a volume in enough depth and detail to sort it all out; and it’s very hard to assert it all is wrong without looking.

    At the end of the day, I expect us to find that there is some microscopic impact from warming. I also expect we’ll have more error found than fact. I’d guess it will be about 1/2 thermometer placement and quality, 1/4 bad code design, 1/8 normal climate cycles, 1/16 UHI, and maybe 1/16 or less some real human induced warming via environmental changes (though even there I suspect it will be more to do with cutting down trees than with burning oil.) But that is all just rampant speculation.

    What is clear is that folks do not like multi causal proportional impact explanations (and exactly what Journal do you publish THAT in? It is easier to publish in the focused journal in “your field”.). They want the “one answer” causality. Yet that is most often wrong. Nature works in a mesh, not a line. So the truth will be pushed away as “messy” and “not inspiring” or “not in the field of your expertise”; and a fantasy will take it’s place. A host of True Believers pushing “The One True Answer”… and almost by definition they will be wrong. At a minimum by “degree”.

  23. Jeff Alberts says:

    Thanks for the synopsis, EM.

    Pretty much what I was thinking, just not quite so clearly as you’ve put it. They have multiple lines of evidence, but evidence of what is not at all clear.

  24. Peter O'Neill says:

    A little more on Pisa and Hohenpeissenberg:

    A question first – the maximum difference I find between the GISS raw and GISS adjusted data for Pisa is -1.4 C in 1949 (using http://data.giss.nasa.gov/gistemp/station_data/). When does the -1.75 C appear, and comparing which data sets?

    I’ve run PApars using rural stations in order of proximity to Pisa instead of the GISS order of length of record, and found that the cooling of the past was reduced by only 0.1 C. As Hohenpeissenberg has a small weight, including it as the first adjusting station does not seem to make much difference.

    This sample (of one station) may confirm Hansen and Lebedeff (1987): “One potential disadvantage of the method we have described for combining station records is that the results, in principle, depend on the ordering of the station records. However, we have tested the effect of other choices for Station ordering, for example, by beginning with the station closest to the subbox center, rather than the station of longest record. The differences between the results for alternative choices were found to be very small, about 2 orders of magnitude less than the typical long-term temperature trend.”

    However, I’m still working on STEP 3, and have not yet systematically investigated the effects of variations such as this ordering issue which I have built in as options in my code.

    I have however already found that implementation dependent tie-breaking in get_longest_overlap in the Python code in STEP1 can give rise to differences of 0.8 C in the combined temperature records, depending on the order in which such ties are broken (and possibly even greater differences may exist: 0.8 C was the largest difference I noticed arising from differences in tie-breaking between my code and the GISS code, but I have yet to go back to explore alternative tie-breaking for cases where my code resolved ties in the same order as the GISS code). I notified GISS of this last May, and even suggested a possible tie-breaking rule for some of these cases, but have not yet received a response on this.

    This also illustrates one of the frustrations of porting the GISS code. To validate my code by producing the same output from the same inputs, I had to build up a table of 80+ tie-breaking case rules for this Python routine. I have also had to build up extensive tables to match GISS rounding of “xxx.5″ values, where 4 byte real arithmetic in the GISS implementation leads to imprecise values which round in an unexpected direction. Using such tables (for validation only – they can be dropped later) I have been able to reproduce the GISS STEP0 and STEP1 output value for value, and STEP2 is already nearly value for value, and I expect will also match exactly when the rounding case tables are completed – as STEP2 involves rounding in more than one place without intermediate output some trial and error is involved in completing the rounding tables, so I have moved on to STEP3 in parallel with table completion.

    Hohenpeissenberg is by no means the “greatest” rural adjusting station. that honour goes to BRADFORD/FAA AIRPORT in the USA which is used to adjust 251 urban stations, whereas Hohenpeissenberg is only used to adjust 97 urban stations, a number exceeded by 258 other rural stations/airports. Looking at my log (now with distance added as well as weight) for Hohenpeissenberg I was surprised to see one of my local warming stations VALENTIA OBSE appear alongside it adjusting some northern french urban stations, and the eclectic company they keep in doing so, as for example:

    urb stnID:615070390020 # rur: 44 ranges: 1967 1990 1000. [CHERBOURG-MAUPERTUS]
    longest rur range: 1880-2008 129 [wgt: 0.342 658.4 km] 621039530005 [VALENTIA OBSE]
    add stn 2 range: 1880-2008 129 [wgt: 0.061 939.9 km] 617109620002 [HOHENPEISSENB]
    add stn 3 range: 1883-2008 126 [wgt: 0.155 845.9 km] 646066800003 [SAENTIS]
    add stn 4 range: 1880-1985 106 [wgt: 0.231 769.8 km] 646067190010 [ST. BERNARD SWITZERLA]
    add stn 5 range: 1880-1975 96 [wgt: 0.743 256.7 km] 651035210010 [ROSS-ON-WYE UK]
    add stn 6 range: 1880-1974 95 [wgt: 0.115 885.2 km] 651030680010 [GORDON CASTLE UK]
    add stn 7 range: 1880-1969 90 [wgt: 0.179 821.9 km] 651030720010 [BRAEMAR UK]
    add stn 8 range: 1880-1969 88 [wgt: 0.539 461.3 km] 651033290010 [STONYHURST UK]
    add stn 9 range: 1880-1969 85 [wgt: 0.039 961.7 km] 612060660010 [TARM DENMARK]
    add stn 10 range: 1880-1960 81 [wgt: 0.165 835.2 km] 646067530010 [ST. GOTTHARD SWITZERLA]
    add stn 11 range: 1931-2008 78 [wgt: 0.549 451.1 km] 651033020001 [VALLEY]
    add stn 12 range: 1931-2008 78 [wgt: 0.367 633.6 km] 651031620003 [ESKDALEMUIR]
    add stn 13 range: 1931-2008 78 [wgt: 0.163 837.6 km] 651031000001 [TIREE]
    add stn 14 range: 1931-2008 78 [wgt: 0.005 996.0 km] 651030260001 [STORNOWAY]
    add stn 15 range: 1898-1968 71 [wgt: 0.388 612.0 km] 651032410010 [COCKLE PARK UK]
    add stn 16 range: 1948-2008 61 [wgt: 0.386 614.0 km] 621039620005 [SHANNON AIRPO]
    add stn 17 range: 1951-2008 58 [wgt: 0.047 954.3 km] 617109610003 [ZUGSPITZE]
    add stn 18 range: 1933-1985 53 [wgt: 0.216 784.3 km] 646067300000 [JUNGFRAUJOCH]
    add stn 19 range: 1956-2008 53 [wgt: 0.255 745.2 km] 621039800004 [MALIN HEAD]
    add stn 20 range: 1961-2008 48 [wgt: 0.233 767.5 km] 621039760004 [BELMULLET]
    add stn 21 range: 1941-1987 46 [wgt: 0.069 931.9 km] 643081840010 [MONTSENY SPAIN]
    add stn 22 range: 1949-2007 46 [wgt: 0.267 733.5 km] 615075600000 [MONT AIGOUAL]
    add stn 23 range: 1950-1990 41 [wgt: 0.365 634.8 km] 621039740000 [CLONES]
    add stn 24 range: 1950-1990 41 [wgt: 0.413 587.0 km] 621039710000 [MULLINGAR]
    add stn 25 range: 1950-1990 41 [wgt: 0.319 681.7 km] 621039700000 [CLAREMORRIS]
    add stn 26 range: 1951-1991 41 [wgt: 0.318 681.9 km] 617106280000 [GEISENHEIM]
    add stn 27 range: 1971-2008 38 [wgt: 0.488 511.8 km] 651032570001 [LEEMING]
    add stn 28 range: 1880-1948 37 [wgt: 0.086 914.3 km] 643081710010 [SORIA SPAIN]
    add stn 29 range: 1955-1990 36 [wgt: 0.417 583.1 km] 621039650000 [BIRR]
    add stn 30 range: 1949-1984 36 [wgt: 0.234 766.5 km] 615076210010 [PIC DU MIDI FRANCE]
    add stn 31 range: 1956-1990 35 [wgt: 0.474 526.1 km] 621039520000 [ROCHES POINT]
    add stn 32 range: 1951-1981 31 [wgt: 0.112 889.2 km] 623160660000 [MILANO/MALPEN]
    add stn 33 range: 1951-1981 31 [wgt: 0.456 544.4 km] 615074600010 [LE PUY DE DOME FRANCE]
    add stn 34 range: 1931-1960 30 [wgt: 0.832 168.2 km] 651037430000 [LARKHILL]
    add stn 35 range: 1961-1990 30 [wgt: 0.557 443.3 km] 621039570000 [ROSSLARE]
    add stn 36 range: 1951-1979 29 [wgt: 0.032 968.8 km] 623161190010 [PASSO DEI GIOVI]
    add stn 37 range: 1954-1981 28 [wgt: 0.293 707.0 km] 646066100000 [PAYERNE]
    add stn 38 range: 1953-1980 27 [wgt: 0.095 906.0 km] 623161160010 [GOVONE]
    add stn 39 range: 1951-1981 27 [wgt: 0.119 882.1 km] 617104530000 [BROCKEN]
    add stn 40 range: 1880-1900 21 [wgt: 0.877 123.2 km] 651038740010 [OSBORNE UK]
    add stn 41 range: 1961-1981 21 [wgt: 0.034 966.7 km] 636085750000 [BRAGANCA]
    add stn 42 range: 1884-1903 20 [wgt: 0.175 825.2 km] 651030380010 [BEN NEVIS UK]
    add stn 43 range: 1884-1903 20 [wgt: 0.175 825.2 km] 651030380000 [FORT WILLIAM]
    add stn 44 range: 1949-1968 20 [wgt: 0.196 804.1 km] 615075860010 [MONT VENTOUX FRANCE]

    Valentia on the west coast of Ireland may have something in common with Cherbourg in Brittany, and perhaps even Ben Nevis near the west coast of Scotland, but Milan/Malpensa, St. Gotthard, St. Bernard, Zugspitze … ?

  25. E.M.Smith says:

    Peter O’Neill
    A little more on Pisa and Hohenpeissenberg:

    A question first – the maximum difference I find between the GISS raw and GISS adjusted data for Pisa is -1.4 C in 1949 (using http://data.giss.nasa.gov/gistemp/station_data/). When does the -1.75 C appear, and comparing which data sets?

    It is just an estimate (guess?) from eyeballing this chart:

    http://wattsupwiththat.files.wordpress.com/2009/01/paolo-figure14.png

    The first few years. I could easily be off 0.25 C ‘by eye’ on a dinky laptop screen (about 12 in diagonal). I’ve not gotten to the “instrument and benchmark” step for STEP2 yet. I’m still doing “code review”. It looks like you are a bit ahead of me on that part.

    Do you have a blog up with your results? It would be helpful to know what’s already done so I don’t have to reinvent something that was already found to be fine, or demonstrated to have a known issue.

    I’ve run PApars using rural stations in order of proximity to Pisa instead of the GISS order of length of record, and found that the cooling of the past was reduced by only 0.1 C. As Hohenpeissenberg has a small weight, including it as the first adjusting station does not seem to make much difference.

    Well, since we’re supposed to get all excited about changes in the 0.1 C position, I find it fascinating that you can get that much just from a change of ordering…

    Could you do a run with the Alpine and German stations left out all together and test sensitivity to latitude? That is, leave in the Italy stations, but take out the cold northern and alpine stations. That’s on my ToDo list, but ‘life events’ have slowed me down a bit lately. (My spouse is just now recovered, we hope, from early pneumonia as a consequence of what we suspect was Swine Flu. The Dr. did not do an antigen test to confirm it, but we had H1N1 outbreaks in some of the schools here and she is a teacher. So I’ve been “doing more” at home…)

    I also find it interesting that Hansen knew he had a sensitivity here…

    However, I’m still working on STEP 3, and have not yet systematically investigated the effects of variations such as this ordering issue which I have built in as options in my code.

    I have however already found that implementation dependent tie-breaking in get_longest_overlap in the Python code in STEP1 can give rise to differences of 0.8 C in the combined temperature record

    Is your version a “straight port” or a re-write of parts?

    It isn’t clear to me if you are saying the order of tie-breaking is a random event in the original GIStemp, or if it is language suite dependent or if it is sensitive to the nature of a rewrite.

    (That kind of question is why I’ve been reluctant to rewrite anything, any variations in my port are solely due to GIStemp design; so I can focus on ‘what does it do’ rather than ‘what did I do’. I would presume that if your port is a ‘straight port’ you are saying some aspect of the implementation – hardware register size, compilers, etc. – can cause the tie breaking to wander different directions. Yes?)

    Ah yes, rounding wars…

    One of those things experienced programmer types watch out for, where other folks just blow by with ‘well, it was rounded, so who cares?’ That, and all this serial averaging of averages of averages of average or… Really makes me wonder what’s happening to the low order bits. What I’ve seen so far leads me to believe everything in the 1/10s place is corrupted to some extent. Heck, the F to C makes the 1/10 C position suspect – warming 1/100 of the records by 1/10C, then we average a bunch, then you found in STEP2 has a 1/10C variation based on order of application of reference stations, and STEP1 tie-breaking can move records 8/10 C (though I would expect not many).

    And how many more of these ‘little details’ are we going to dig up? I’ve got 3 more “STEP”s to go, and I’ve not done a record by record sensitivity test, I’m just doing a gross bulk benchmark at this point.

    So take those several places where the record moves in the tenths position. At least one of them is always to the warmer. Depending on how these interact, we could get significant swings in individual records and perhaps the whole bulk product. (I know, I need to actually measure it first. But as you have demonstrated, that can be a very long process…)

    Hohenpeissenberg is by no means the “greatest” rural adjusting station.

    My suspicion is that it was “filled out” to make it a longer lived station so that it would be used early in more places, not so much that it was THE greatest. But it is well positioned to influence a large radius of Europe. It is equally possible it was just ‘filled out’ because they could. But I’m left wondering about all the other stations that did not get such individual care in STEP0…

    that honour goes to BRADFORD/FAA AIRPORT in the USA which is used to adjust 251 urban stations

    Ah the joys of another “Rural” Airport. Looks like it has grown over the years.

    http://www.smethporthistory.org/lafayettetownship/bradfordairport/planeonrunway.html

    Wonder if that dark “thing on a pole” on top of the building is the temperature sensor? Nah, it couldn’t be..

    http://www.smethporthistory.org/lafayettetownship/bradfordairport/2007airportfront2.html

    http://www.smethporthistory.org/lafayettetownship/bradfordairport/2007cornerview.html

  26. Peter O'Neill says:

    E.M.Smith
    Do you have a blog up with your results? It would be helpful to know what’s already done so I don’t have to reinvent something that was already found to be fine, or demonstrated to have a known issue.

    I don’t have a blog, but I will put up some web pages once I have started to explore more systematically. Up to now I have been instrumenting my port as I work my way through the steps with this in mind, but just checking that this instrumentation is working rather than using it to explore.

    Could you do a run with the Alpine and German stations left out all together and test sensitivity to latitude?

    Yes. I am just completing the code to allow inclusion or exclusion of adjusting stations for a selected urban station, and will post the result of the test you suggest Sunday or Monday.

    Is your version a “straight port” or a re-write of parts?

    A re-write in the sense that I have translated the FORTRAN/Python/C/scripts to C#, and put everything into one application with a GUI (including a check for updates to input files and to the GIStemp source code archive). A “straight port” in the sense that this translation has remained (painfully) close to the original code “structure” even though readability suffers as a result. I have tried to limit structural changes to the elimination of GOTOs, introduction of while loops to replace the IF/ENDIFs with GOTOs back before these blocks used in the original, and splitting up long sections of code into further procedures.

    It isn’t clear to me if you are saying the order of tie-breaking is a random event in the original GIStemp, or if it is language suite dependent or if it is sensitive to the nature of a rewrite.

    Language suite dependent, and so in particular sensitive to the change from Python to C# (incidentally, I rewrote the Python code replacing the C add-ins by pure Python when working through STEP1. Very little recoding needed for a vast improvement in readability!). Here is what I sent GISS last May (minus the plot, which was for PALMA DE MALL[ORCA] 64308306000:

    The order in which station records are combined in get_longest_overlap (comb_records.py and comb_pieces.py) and get_longest (comb_pieces.py) is effectively implementation-dependent where ties occur. In get_longest_overlap in comb_records.py :

    for rec_id, record in records.items():

    will enumerate the records in an order which is determined by the Python interpreter, and:

    if wgt < overlap:
    continue
    overlap = wgt

    will resolve any tie by choosing the last record encountered among the ties. A new inplementation of the Python interpreter might store and return the records in a different order, and my C# implementation, unless overridden with a table of 80+ choices matching the Python implementation, does in fact resolve these ties differently. As you can see from the example below, where I have plotted the difference between the two combined records, this difference can be quite substantial. I have not yet experimented to see whether even larger differences may occur, as I have moved on to implement STEP2 before looking again at this issue. 0.8 degrees difference was the largest I noticed when I compared the “unconstrained” C# choices with the Python output. Larger differences might perhaps be found by trying more orderings, which would be possible here for example as the remaining three station records all tie for longest overlap at the highlighted point (I’ve added a count of ties to the comb.log I generate to facilitate later experimentation). The only reference to record ordering I found was in Hansen and Lebedeff (1987):

    One potential disadvantage of the method we have
    described for combining station records is that the results,
    in principle, depend on the ordering of the station records.
    However, we have tested the effect of other choices for
    Station ordering, for example, by beginning with the station
    closest to the subbox center, rather than the station of
    longest record. The differences between the results for
    alternative choices were found to be very small, about 2
    orders of magnitude less than the typical long-term temperature
    trend.

    Although the station ordering referred to here is the STEP2 rather than STEP1 ordering. Hansen et al. 1999 and 2001 do not seem to touch on this issue, nor for that matter the use of MCDW, SUMOFDAY and USHCN in get_best, which could also arise here, although it does not arise with the current data.

    My immediate thoughts on this issue are obviously that the “implementation dependency” should be corrected, and the possibility that when get_best selects a “MCDW” record get_longest_overlap could possibly select an “UNKNOWN” record ahead of a “USHCN” or “SUMOFDAY” record if a tie occurs. I checked all ties to confirm that this does not occur at present, but without tie-breaking code to handle such a case the possibility presumably remains that this might occur at some stage in the future. Without further thought and experimentation I would not have any definitive thoughts on how other ties should be handled, but choosing the longest record or the one giving the smallest difference would seem to be possible choices for consideration.

    The 2001 paper does indicate that:

    This single record is not necessarily appropriate for local studies, and
    we recommend that users interested in a local analysis return to the raw GHCN data and examine all
    of the individual records for that location, if more than one is available.

    but it can be assumed that the station data from the GISTEMP server will be downloaded without this qualification being noticed, and so the best combined station record possible would be desirable.

    I mentioned that this tie issue arises also in comb_pieces.py, (and I had to add a similar but shorter choice override table in my C# implementation to match the Python output), but there are far fewer ties, and I have not yet examined code and output to check whether this has any effect on the final output.

    64308306000
    643083060005 1880 2009 – MCDW —— Python
    643083060002 1961 1991 0.00138068175997
    643083060001 1901 1970 -0.760331012442
    643083060000 1880 1991 -0.526370366246
    643083060003 1961 1981 -0.34442429337

    64308306000
    643083060005 1880 2009 – MCDW ——– C# without override table
    643083060002 1961 1991 0.00138
    643083060000 1880 1991 0.09256 ties: 3
    643083060001 1901 1970 -0.14628
    643083060003 1961 1981 0.13071

  27. E.M.Smith says:

    @Peter O’Neill

    If you want to put anything up here, let me know, I can give you “guest poster” or just start a thread for comments.

    I’m glad to hear you are doing a C# port. Means I can take “do a C something port” off my “ToDo” list! What a relief!

    The whole “tie breaking” issue is one I had not looked at. It is fascinating that you get 0.8 degree C in some records out of tie breaking changes. Very dramatically illustrates the impact the coding decisions (even as to what language is used) can have on the final numbers.

    With so many places that have 1/1000 C, 1/100C, and sometimes even 1/10 C impacts on the data; I really wonder how much of the GIStemp product is actually in the data and how much is random chance. I think the whole degrees C are valid, but …

  28. Peter O'Neill says:

    @E.M.Smith
    Could you do a run with the Alpine and German stations left out all together and test sensitivity to latitude? That is, leave in the Italy stations, but take out the cold northern and alpine stations.

    Using just the Italian rural stations Pisa becomes a “no adjustment” station, as shown in the log extracts below. I will try to change this outcome by progressively adding more stations until an adjustment takes place, but this will be a trial and error operation which I do not have time for now. For now I will send the three full log listings (default order, weight order and Italian only) for Pisa to your AOL address as these are about 30K each, too large to post in full here.

    PApars.noadj.stations.list
    ==========================

    623161580004 drop early years 1880-1959
    623161580004 drop early years 1880-1973
    623161580004 good years: 0 total years: 1 too little rural-neighbors-overlap – drop station 9999

    PApars.GHCN.CL.1000.20.log
    ==========================

    number of rural/urban stations 2501 3788

    urb stnID:623161580004 # rur: 32 ranges: 1949 2008 500.
    longest rur range: 1951-2007 129 [wgt: 0.083 377.9 km] 623162800000 [PONZA]
    add stn 2 range: 1951-1981 126 [wgt: 0.184 250.6 km] 623160660000 [MILANO/MALPEN]
    data added: 31 overlap: 31 years
    add stn 3 range: 1951-1980 106 [wgt: 0.290 176.0 km] 623161460000 [PUNTA MARINA]
    data added: 30 overlap: 30 years
    add stn 4 range: 1951-1980 102 [wgt: 0.142 400.2 km] 623160400000 [TARVISIO]
    data added: 30 overlap: 30 years
    add stn 5 range: 1951-1980 81 [wgt: 0.336 290.0 km] 623165060000 [GUARDIAVECCHI]
    data added: 29 overlap: 29 years
    add stn 6 range: 1954-2007 69 [wgt: 0.009 186.6 km] 623161790000 [FRONTONE]
    data added: 29 overlap: 28 years
    add stn 7 range: 1951-1980 64 [wgt: 0.104 91.7 km] 623161420010 [RIFREDO MUGELLO]
    data added: 29 overlap: 29 years
    add stn 8 range: 1951-1979 58 [wgt: 0.172 58.6 km] 623161290000 [ISOLA DI PALM]
    data added: 29 overlap: 29 years
    add stn 9 range: 1951-1979 53 [wgt: 0.253 156.1 km] 623161190010 [PASSO DEI GIOVI]
    data added: 29 overlap: 29 years
    add stn 11 range: 1955-2007 31 [wgt: 0.499 230.7 km] 623162240000 [VIGNA DI VALL]
    data added: 28 overlap: 28 years
    add stn 12 range: 1951-1978 30 [wgt: 0.648 124.8 km] 623161970020 [ISOLA DI PIANOSA]
    data added: 27 overlap: 27 years
    add stn 13 range: 1953-1980 30 [wgt: 0.200 220.4 km] 623161160010 [GOVONE]
    data added: 27 overlap: 27 years
    add stn 14 range: 1952-1977 29 [wgt: 0.420 400.7 km] 623165380010 [MACOMER]
    data added: 24 overlap: 24 years
    add stn 15 range: 1951-1974 29 [wgt: 0.627 336.8 km] 623165200020 [ISOLA ASINARA]
    data added: 24 overlap: 24 years
    add stn 16 range: 1954-1977 29 [wgt: 0.817 355.6 km] 623162800010 [TORRE OLEVOLA AERO]
    data added: 24 overlap: 24 years
    add stn 17 range: 1954-1976 29 [wgt: 0.883 471.6 km] 623162940010 [CAPRI]
    data added: 23 overlap: 23 years
    add stn 18 range: 1960-2007 29 [wgt: 0.688 281.1 km] 623162450000 [PRATICA DI MA]
    data added: 23 overlap: 23 years
    add stn 19 range: 1951-1975 28 [wgt: 0.129 170.1 km] 623161490010 [SASSO FELTRIO]
    data added: 23 overlap: 23 years
    add stn 20 range: 1951-1973 28 [wgt: 0.539 309.2 km] 623160360010 [AVIANO]
    data added: 23 overlap: 23 years
    add stn 21 range: 1951-1974 27 [wgt: 0.750 150.2 km] 623161970010 [ISOLA GORGONA]
    data added: 21 overlap: 21 years
    add stn 22 range: 1961-1980 27 [wgt: 0.559 266.4 km] 623162340000 [GUIDONIA]
    data added: 20 overlap: 20 years
    trying full radius 1000.000000

    urb stnID:623161580004 # rur: 65 ranges: 1949 2008 1000.
    longest rur range: 1968-2008 129 [wgt: 0.542 650.2 km] 623163250001 [MARINA DI GIN]
    add stn 9 range: 1951-2007 69 [wgt: 0.504 874.9 km] 623164800000 [COZZO SPADARO]
    data added: 0 overlap: 15 years
    add stn 10 range: 1951-2007 64 [wgt: 0.552 377.9 km] 623162800000 [PONZA]
    data added: 0 overlap: 15 years
    add stn 11 range: 1951-1981 58 [wgt: 0.586 603.6 km] 623164000000 [USTICA]
    data added: 0 overlap: 14 years
    add stn 12 range: 1951-1981 55 [wgt: 0.016 578.1 km] 623163100000 [CAPO PALINURO]
    data added: 0 overlap: 14 years
    add stn 13 range: 1951-1981 53 [wgt: 0.626 250.6 km] 623160660000 [MILANO/MALPEN]
    data added: 0 overlap: 14 years
    add stn 16 range: 1951-1980 46 [wgt: 0.321 176.0 km] 623161460000 [PUNTA MARINA]
    data added: 0 overlap: 13 years
    add stn 17 range: 1951-1980 46 [wgt: 0.453 400.2 km] 623160400000 [TARVISIO]
    data added: 0 overlap: 13 years
    add stn 19 range: 1951-1980 41 [wgt: 0.276 290.0 km] 623165060000 [GUARDIAVECCHI]
    data added: 0 overlap: 12 years
    add stn 20 range: 1954-2007 39 [wgt: 0.045 186.6 km] 623161790000 [FRONTONE]
    data added: 0 overlap: 15 years
    add stn 21 range: 1951-1980 39 [wgt: 0.125 91.7 km] 623161420010 [RIFREDO MUGELLO]
    data added: 0 overlap: 12 years
    add stn 22 range: 1951-1979 37 [wgt: 0.216 58.6 km] 623161290000 [ISOLA DI PALM]
    data added: 0 overlap: 12 years
    add stn 23 range: 1951-1979 36 [wgt: 0.162 156.1 km] 623161190010 [PASSO DEI GIOVI]
    data added: 0 overlap: 12 years
    add stn 25 range: 1953-1980 33 [wgt: 0.208 612.5 km] 623163160000 [LATRONICO]
    data added: 0 overlap: 13 years
    add stn 26 range: 1955-2007 32 [wgt: 0.126 230.7 km] 623162240000 [VIGNA DI VALL]
    data added: 0 overlap: 15 years
    add stn 28 range: 1951-1978 31 [wgt: 0.397 124.8 km] 623161970020 [ISOLA DI PIANOSA]
    data added: 0 overlap: 10 years
    add stn 29 range: 1953-1980 31 [wgt: 0.422 220.4 km] 623161160010 [GOVONE]
    data added: 0 overlap: 13 years
    add stn 31 range: 1951-1980 31 [wgt: 0.364 517.3 km] 623165640000 [CAPO CARBONAR]
    data added: 0 overlap: 13 years
    add stn 32 range: 1952-1977 30 [wgt: 0.262 780.8 km] 623163320010 [PALASCIA AERO]
    data added: 0 overlap: 10 years
    add stn 33 range: 1952-1977 30 [wgt: 0.824 400.7 km] 623165380010 [MACOMER]
    data added: 0 overlap: 9 years
    add stn 34 range: 1951-1974 30 [wgt: 0.600 336.8 km] 623165200020 [ISOLA ASINARA]
    data added: 0 overlap: 7 years
    add stn 35 range: 1952-1977 30 [wgt: 0.470 700.5 km] 623163440010 [CALOPEZZATI]
    data added: 0 overlap: 9 years
    add stn 36 range: 1954-1977 29 [wgt: 0.710 355.6 km] 623162800010 [TORRE OLEVOLA AERO]
    data added: 0 overlap: 10 years
    add stn 37 range: 1954-1976 29 [wgt: 0.813 471.6 km] 623162940010 [CAPRI]
    data added: 0 overlap: 9 years
    add stn 38 range: 1952-1974 29 [wgt: 0.908 509.0 km] 623162630020 [CANDELA AERO]
    data added: 0 overlap: 7 years
    add stn 39 range: 1960-2007 29 [wgt: 0.941 281.1 km] 623162450000 [PRATICA DI MA]
    data added: 0 overlap: 15 years
    add stn 40 range: 1951-1975 29 [wgt: 0.844 170.1 km] 623161490010 [SASSO FELTRIO]
    data added: 0 overlap: 8 years
    add stn 41 range: 1951-1973 28 [wgt: 0.564 309.2 km] 623160360010 [AVIANO]
    data added: 0 overlap: 6 years
    add stn 43 range: 1960-1980 28 [wgt: 0.769 931.6 km] 623164900000 [LAMPEDUSA]
    data added: 0 overlap: 13 years
    add stn 44 range: 1951-1974 27 [wgt: 0.255 150.2 km] 623161970010 [ISOLA GORGONA]
    data added: 0 overlap: 7 years
    add stn 45 range: 1961-1980 27 [wgt: 0.875 645.6 km] 623163370000 [BONIFATI]
    data added: 0 overlap: 13 years
    add stn 46 range: 1961-1980 27 [wgt: 0.780 266.4 km] 623162340000 [GUIDONIA]
    data added: 0 overlap: 13 years
    add stn 48 range: 1953-1974 26 [wgt: 0.483 676.8 km] 623164150010 [ISOLA STROMBOLI]
    data added: 0 overlap: 7 years

  29. E.M.Smith says:

    Hmmm….

    That, in itself, is an interesting result.

    We must choose between NO adjustment, or adjustment via stations from a dramatically different climate regime, due to the sparsity of the data…

    This will get “more interesting” going forward now that we have even fewer thermometers in the data in recent years…

    And Europe is fairly heavy with thermometers compared to most of the world.

  30. Peter O'Neill says:

    @Peter O’Neill

    @E.M.Smith
    Could you do a run with the Alpine and German stations left out all together and test sensitivity to latitude? That is, leave in the Italy stations, but take out the cold northern and alpine stations.

    (Peter O’Neill) Using just the Italian rural stations Pisa becomes a “no adjustment” station, as shown in the log extracts below. I will try to change this outcome by progressively adding more stations until an adjustment takes place, but this will be a trial and error operation which I do not have time for now.

    To start this trial and error search, I’ve excluded stations above 900m, so excluding the alpine or high altitude stations (and added the information displayed to guide station selection to the instrumented station log), and now have an adjustment again. The “cooling of the past” is reduced from -1.4 C to -1.0 C when these high altitude stations are excluded. Interpret these results as an indication of the influence of the stations excluded – it may or may not be appropriate to exclude these stations.

    I noticed also that RIFREDO MUGELLO, one of the rural stations marked “airstn:x” appears to be an airport: see http://www.privejets.com/airport_directory/international_airport_city_list.php?city=Rifredo%20Mugello

    623 16158000 [PISA/S. GIUST] 50929

    lat 43.68 elevs 6 pop U topo FL stloc CO
    lon 10.38 elevg 4 ipop 91 stveg xx iloc 9
    airstn A itowndis 3 grveg: COASTAL EDGES

    Rural station choice override was used

    PApars.GHCN.CL.1000.20.log
    ==========================

    number of rural/urban stations 2501 3788

    urb stnID:623161580004 # rur: 32 ranges: 1949 2008 500.
    ignore: 1880-2008 129 [wgt: 0.083 458.6 km] 617109620002 [h: 986 airstn:x topo:HI stloc:x stveg:xx grveg:COOL CONIFER ][HOHENPEISSENB]
    ignore: 1883-2008 129 [wgt: 0.083 408.1 km] 646066800003 [h: 2500 airstn:x topo:MT stloc:x stveg:xx grveg:WARM CROPS ][SAENTIS]
    ignore: 1880-1985 129 [wgt: 0.083 355.1 km] 646067190010 [h: 2460 airstn:x topo:MT stloc:x stveg:xx grveg:WARM CROPS ][ST. BERNARD SWITZERLA]
    ignore: 1887-2008 129 [wgt: 0.083 429.3 km] 603111460002 [h: 3109 airstn:x topo:MT stloc:x stveg:xx grveg:TUNDRA ][SONNBLICK]
    ignore: 1880-1960 129 [wgt: 0.083 332.0 km] 646067530010 [h: 2095 airstn:x topo:MT stloc:x stveg:xx grveg:NORTH. TAIGA ][ST. GOTTHARD SWITZERLA]
    longest rur range: 1880-1980 129 [wgt: 0.083 495.7 km] 609144470000 [h: 25 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][HVAR]
    ignore: 2 range: 1880-1943 126 [wgt: 0.184 495.7 km] 603112340010 [h: 2044 airstn:x topo:MT stloc:x stveg:xx grveg:WARM CROPS ][OBIR AUSTRIA]
    ignore: 3 range: 1951-2008 106 [wgt: 0.290 495.7 km] 617109610003 [h: 2962 airstn:x topo:MT stloc:x stveg:xx grveg:NORTH. TAIGA ][ZUGSPITZE]
    ignore: 4 range: 1933-1985 102 [wgt: 0.142 495.7 km] 646067300000 [h: 3576 airstn:x topo:MT stloc:x stveg:xx grveg:TUNDRA ][JUNGFRAUJOCH]
    add stn 5 range: 1951-2007 81 [wgt: 0.336 377.9 km] 623162800000 [h: 185 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][PONZA]
    data added: 32 overlap: 30 years
    add stn 6 range: 1951-1981 69 [wgt: 0.009 250.6 km] 623160660000 [h: 211 airstn:A topo:HI stloc:A stveg:xx grveg:WARM FOR./FIELD ][MILANO/MALPEN]
    data added: 31 overlap: 31 years
    add stn 7 range: 1951-1980 64 [wgt: 0.104 176.0 km] 623161460000 [h: 6 airstn:x topo:FL stloc:x stveg:xx grveg:WARM CROPS ][PUNTA MARINA]
    data added: 30 overlap: 30 years
    add stn 8 range: 1951-1980 58 [wgt: 0.172 400.2 km] 623160400000 [h: 778 airstn:x topo:MV stloc:x stveg:xx grveg:WARM CROPS ][TARVISIO]
    data added: 30 overlap: 30 years
    add stn 9 range: 1951-1980 53 [wgt: 0.253 290.0 km] 623165060000 [h: 159 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][GUARDIAVECCHI]
    data added: 29 overlap: 29 years
    add stn 10 range: 1954-2007 32 [wgt: 0.244 186.6 km] 623161790000 [h: 574 airstn:x topo:MV stloc:x stveg:xx grveg:WARM CROPS ][FRONTONE]
    data added: 29 overlap: 28 years
    add stn 11 range: 1951-1980 31 [wgt: 0.499 91.7 km] 623161420010 [h: 887 airstn:x topo:MV stloc:x stveg:xx grveg:WARM MIXED ][RIFREDO MUGELLO]
    data added: 29 overlap: 29 years
    add stn 12 range: 1951-1979 30 [wgt: 0.648 58.6 km] 623161290000 [h: 191 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][ISOLA DI PALM]
    data added: 29 overlap: 29 years
    add stn 13 range: 1951-1979 30 [wgt: 0.200 156.1 km] 623161190010 [h: 475 airstn:x topo:MV stloc:x stveg:xx grveg:WARM FOR./FIELD ][PASSO DEI GIOVI]
    data added: 29 overlap: 29 years
    add stn 14 range: 1954-1981 29 [wgt: 0.420 435.7 km] 646066100000 [h: 491 airstn:x topo:HI stloc:x stveg:xx grveg:WARM FOR./FIELD ][PAYERNE]
    data added: 28 overlap: 28 years
    add stn 15 range: 1955-2007 29 [wgt: 0.627 230.7 km] 623162240000 [h: 266 airstn:x topo:HI stloc:x stveg:xx grveg:WARM FIELD WOODS][VIGNA DI VALL]
    data added: 28 overlap: 28 years
    add stn 16 range: 1951-1978 29 [wgt: 0.817 124.8 km] 623161970020 [h: 17 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][ISOLA DI PIANOSA]
    data added: 27 overlap: 27 years
    add stn 17 range: 1953-1980 29 [wgt: 0.883 220.4 km] 623161160010 [h: 315 airstn:x topo:HI stloc:x stveg:xx grveg:WARM CROPS ][GOVONE]
    data added: 27 overlap: 27 years
    add stn 18 range: 1952-1977 29 [wgt: 0.688 400.7 km] 623165380010 [h: 585 airstn:x topo:MV stloc:x stveg:xx grveg:WARM CROPS ][MACOMER]
    data added: 24 overlap: 24 years
    add stn 19 range: 1951-1974 28 [wgt: 0.129 336.8 km] 623165200020 [h: 118 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][ISOLA ASINARA]
    data added: 24 overlap: 24 years
    add stn 20 range: 1954-1977 28 [wgt: 0.539 355.6 km] 623162800010 [h: 4 airstn:A topo:FL stloc:A stveg:xx grveg:WATER ][TORRE OLEVOLA AERO]
    data added: 24 overlap: 24 years
    add stn 21 range: 1954-1976 27 [wgt: 0.750 471.6 km] 623162940010 [h: 269 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][CAPRI]
    data added: 23 overlap: 23 years
    add stn 22 range: 1960-2007 27 [wgt: 0.559 281.1 km] 623162450000 [h: 21 airstn:A topo:FL stloc:A stveg:xx grveg:WATER ][PRATICA DI MA]
    data added: 23 overlap: 23 years
    add stn 23 range: 1951-1975 24 [wgt: 0.199 170.1 km] 623161490010 [h: 468 airstn:x topo:HI stloc:x stveg:xx grveg:WARM CROPS ][SASSO FELTRIO]
    data added: 23 overlap: 23 years
    add stn 24 range: 1951-1973 24 [wgt: 0.326 309.2 km] 623160360010 [h: 128 airstn:A topo:MV stloc:A stveg:xx grveg:WARM CONIFER ][AVIANO]
    data added: 23 overlap: 23 years
    add stn 25 range: 1951-1974 24 [wgt: 0.289 150.2 km] 623161970010 [h: 254 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][ISOLA GORGONA]
    data added: 21 overlap: 21 years
    add stn 26 range: 1961-1980 23 [wgt: 0.057 266.4 km] 623162340000 [h: 89 airstn:A topo:MV stloc:A stveg:xx grveg:WARM FIELD WOODS][GUIDONIA]
    data added: 20 overlap: 20 years
    ignore: 27 range: 1949-1968 23 [wgt: 0.438 266.4 km] 615075860010 [h: 1912 airstn:x topo:MT stloc:x stveg:xx grveg:MED. GRAZING ][MONT VENTOUX FRANCE]
    trying full radius 1000.000000

    urb stnID:623161580004 # rur: 65 ranges: 1949 2008 1000.
    ignore: 1880-2008 129 [wgt: 0.542 458.6 km] 617109620002 [h: 986 airstn:x topo:HI stloc:x stveg:xx grveg:COOL CONIFER ][HOHENPEISSENB]
    ignore: 1883-2008 129 [wgt: 0.542 408.1 km] 646066800003 [h: 2500 airstn:x topo:MT stloc:x stveg:xx grveg:WARM CROPS ][SAENTIS]
    ignore: 1891-2008 129 [wgt: 0.542 771.0 km] 617105780000 [h: 1215 airstn:x topo:MT stloc:x stveg:xx grveg:COOL FOR./FIELD ][FICHTELBERG]
    ignore: 1880-1985 129 [wgt: 0.542 355.1 km] 646067190010 [h: 2460 airstn:x topo:MT stloc:x stveg:xx grveg:WARM CROPS ][ST. BERNARD SWITZERLA]
    ignore: 1887-2008 129 [wgt: 0.542 429.3 km] 603111460002 [h: 3109 airstn:x topo:MT stloc:x stveg:xx grveg:TUNDRA ][SONNBLICK]
    longest rur range: 1880-1980 129 [wgt: 0.542 567.1 km] 603110120000 [h: 389 airstn:x topo:HI stloc:x stveg:xx grveg:COOL CROPS ][KREMSMUENSTER]
    add stn 2 range: 1907-2007 126 [wgt: 0.592 811.9 km] 611114640000 [h: -999 airstn:x topo:MV stloc:x stveg:xx grveg:COOL CROPS ][MILESOVKA]
    data added: 92 overlap: 74 years
    ignore: 3 range: 1880-1960 111 [wgt: 0.230 811.9 km] 646067530010 [h: 2095 airstn:x topo:MT stloc:x stveg:xx grveg:NORTH. TAIGA ][ST. GOTTHARD SWITZERLA]
    add stn 4 range: 1880-1980 106 [wgt: 0.645 495.7 km] 609144470000 [h: 25 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][HVAR]
    data added: 69 overlap: 69 years
    ignore: 5 range: 1880-1943 102 [wgt: 0.571 495.7 km] 603112340010 [h: 2044 airstn:x topo:MT stloc:x stveg:xx grveg:WARM CROPS ][OBIR AUSTRIA]
    ignore: 6 range: 1951-2008 101 [wgt: 0.433 495.7 km] 617109610003 [h: 2962 airstn:x topo:MT stloc:x stveg:xx grveg:NORTH. TAIGA ][ZUGSPITZE]
    add stn 7 range: 1951-2008 92 [wgt: 0.189 984.8 km] 617103930000 [h: 104 airstn:x topo:FL stloc:x stveg:xx grveg:WARM MIXED ][LINDENBERG]
    data added: 55 overlap: 48 years
    ignore: 8 range: 1933-1985 81 [wgt: 0.668 984.8 km] 646067300000 [h: 3576 airstn:x topo:MT stloc:x stveg:xx grveg:TUNDRA ][JUNGFRAUJOCH]
    ignore: 9 range: 1883-1948 69 [wgt: 0.504 984.8 km] 101603950010 [h: 942 airstn:x topo:MV stloc:x stveg:DE grveg:WARM CROPS ][FT. NATIONAL]
    ignore: 10 range: 1941-1989 64 [wgt: 0.552 984.8 km] 641119300000 [h: 2635 airstn:x topo:MT stloc:x stveg:xx grveg:WARM FOR./FIELD ][LOMNICKY STIT]
    ignore: 11 range: 1941-1987 58 [wgt: 0.586 984.8 km] 643081840010 [h: 1708 airstn:x topo:MV stloc:x stveg:xx grveg:WARM CROPS ][MONTSENY SPAIN]
    ignore: 12 range: 1949-2007 55 [wgt: 0.016 984.8 km] 615075600000 [h: 1565 airstn:x topo:MT stloc:x stveg:xx grveg:MED. GRAZING ][MONT AIGOUAL]
    add stn 13 range: 1968-2008 53 [wgt: 0.626 650.2 km] 623163250001 [h: 12 airstn:x topo:FL stloc:x stveg:xx grveg:COOL FOR./FIELD ][MARINA DI GIN]
    data added: 41 overlap: 38 years
    add stn 14 range: 1951-1991 48 [wgt: 0.042 724.3 km] 617106280000 [h: 120 airstn:x topo:HI stloc:x stveg:xx grveg:COOL MIXED ][GEISENHEIM]
    data added: 41 overlap: 41 years
    ignore: 15 range: 1951-1989 47 [wgt: 0.033 724.3 km] 641126500000 [h: 1989 airstn:x topo:MT stloc:x stveg:xx grveg:COOL FOR./FIELD ][KASPROWY WIER]
    ignore: 16 range: 1951-1989 46 [wgt: 0.321 724.3 km] 635125100000 [h: 1613 airstn:x topo:MV stloc:x stveg:xx grveg:COOL CROPS ][SNIEZKA]
    ignore: 17 range: 1880-1948 46 [wgt: 0.453 724.3 km] 643081710010 [h: 1068 airstn:x topo:HI stloc:x stveg:FO grveg:MED. GRAZING ][SORIA SPAIN]
    ignore: 18 range: 1949-1984 41 [wgt: 0.350 724.3 km] 615076210010 [h: 2860 airstn:x topo:MT stloc:x stveg:xx grveg:TUNDRA ][PIC DU MIDI FRANCE]
    ignore: 19 range: 1956-1989 41 [wgt: 0.276 724.3 km] 641119160000 [h: 2012 airstn:x topo:MV stloc:x stveg:xx grveg:COOL FOR./FIELD ][CHOPOK]
    add stn 20 range: 1951-2007 39 [wgt: 0.045 792.7 km] 623163600000 [h: 112 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][S. MARIA DI L]
    data added: 33 overlap: 33 years
    add stn 21 range: 1951-2007 39 [wgt: 0.125 874.9 km] 623164800000 [h: 51 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][COZZO SPADARO]
    data added: 32 overlap: 32 years
    add stn 22 range: 1951-2007 37 [wgt: 0.216 377.9 km] 623162800000 [h: 185 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][PONZA]
    data added: 32 overlap: 32 years
    add stn 23 range: 1951-1981 36 [wgt: 0.162 603.6 km] 623164000000 [h: 251 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][USTICA]
    data added: 31 overlap: 31 years
    add stn 24 range: 1951-1981 34 [wgt: 0.082 578.1 km] 623163100000 [h: 185 airstn:x topo:MV stloc:x stveg:xx grveg:WATER ][CAPO PALINURO]
    data added: 31 overlap: 31 years
    add stn 25 range: 1951-1981 33 [wgt: 0.208 250.6 km] 623160660000 [h: 211 airstn:A topo:HI stloc:A stveg:xx grveg:WARM FOR./FIELD ][MILANO/MALPEN]
    data added: 31 overlap: 31 years
    ignore: 26 range: 1951-1981 32 [wgt: 0.126 250.6 km] 615074600010 [h: 1452 airstn:x topo:MT stloc:x stveg:xx grveg:WARM CROPS ][LE PUY DE DOME FRANCE]
    add stn 27 range: 1951-1980 32 [wgt: 0.622 738.0 km] 643083060010 [h: 2 airstn:x topo:HI stloc:x stveg:xx grveg:WARM CROPS ][POLLENSA/BALEARIC IS.]
    data added: 30 overlap: 30 years
    add stn 28 range: 1951-1980 31 [wgt: 0.397 176.0 km] 623161460000 [h: 6 airstn:x topo:FL stloc:x stveg:xx grveg:WARM CROPS ][PUNTA MARINA]
    data added: 30 overlap: 30 years
    add stn 29 range: 1951-1980 31 [wgt: 0.422 400.2 km] 623160400000 [h: 778 airstn:x topo:MV stloc:x stveg:xx grveg:WARM CROPS ][TARVISIO]
    data added: 30 overlap: 30 years
    add stn 30 range: 1951-1980 31 [wgt: 0.749 530.4 km] 607133400010 [h: 724 airstn:x topo:MV stloc:x stveg:xx grveg:WARM FOR./FIELD ][LIVNO FORMER]
    data added: 30 overlap: 30 years
    add stn 31 range: 1951-1980 31 [wgt: 0.364 290.0 km] 623165060000 [h: 159 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][GUARDIAVECCHI]
    data added: 29 overlap: 29 years
    add stn 32 range: 1954-2007 30 [wgt: 0.262 186.6 km] 623161790000 [h: 574 airstn:x topo:MV stloc:x stveg:xx grveg:WARM CROPS ][FRONTONE]
    data added: 29 overlap: 29 years
    add stn 33 range: 1951-1980 30 [wgt: 0.824 91.7 km] 623161420010 [h: 887 airstn:x topo:MV stloc:x stveg:xx grveg:WARM MIXED ][RIFREDO MUGELLO]
    data added: 29 overlap: 29 years
    add stn 34 range: 1951-1979 30 [wgt: 0.600 58.6 km] 623161290000 [h: 191 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][ISOLA DI PALM]
    data added: 29 overlap: 29 years
    add stn 35 range: 1951-1979 30 [wgt: 0.470 156.1 km] 623161190010 [h: 475 airstn:x topo:MV stloc:x stveg:xx grveg:WARM FOR./FIELD ][PASSO DEI GIOVI]
    data added: 29 overlap: 29 years
    add stn 36 range: 1954-1981 29 [wgt: 0.710 435.7 km] 646066100000 [h: 491 airstn:x topo:HI stloc:x stveg:xx grveg:WARM FOR./FIELD ][PAYERNE]
    data added: 28 overlap: 28 years
    add stn 37 range: 1953-1980 29 [wgt: 0.813 612.5 km] 623163160000 [h: 896 airstn:x topo:MV stloc:x stveg:xx grveg:MED. GRAZING ][LATRONICO]
    data added: 28 overlap: 28 years
    add stn 38 range: 1955-2007 29 [wgt: 0.908 230.7 km] 623162240000 [h: 266 airstn:x topo:HI stloc:x stveg:xx grveg:WARM FIELD WOODS][VIGNA DI VALL]
    data added: 28 overlap: 28 years
    add stn 39 range: 1952-1992 29 [wgt: 0.941 745.4 km] 632135620000 [h: 29 airstn:x topo:MV stloc:x stveg:xx grveg:WATER ][ULCINJ]
    data added: 27 overlap: 27 years
    add stn 40 range: 1951-1978 29 [wgt: 0.844 124.8 km] 623161970020 [h: 17 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][ISOLA DI PIANOSA]
    data added: 27 overlap: 27 years
    add stn 41 range: 1953-1980 28 [wgt: 0.564 220.4 km] 623161160010 [h: 315 airstn:x topo:HI stloc:x stveg:xx grveg:WARM CROPS ][GOVONE]
    data added: 27 overlap: 27 years
    ignore: 42 range: 1951-1981 28 [wgt: 0.388 220.4 km] 617104530000 [h: 1153 airstn:x topo:MT stloc:x stveg:xx grveg:COOL FOR./FIELD ][BROCKEN]
    add stn 43 range: 1951-1980 28 [wgt: 0.769 517.3 km] 623165640000 [h: 118 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][CAPO CARBONAR]
    data added: 26 overlap: 26 years
    add stn 44 range: 1952-1977 27 [wgt: 0.255 780.8 km] 623163320010 [h: 86 airstn:A topo:HI stloc:A stveg:xx grveg:WATER ][PALASCIA AERO]
    data added: 26 overlap: 26 years
    add stn 45 range: 1952-1977 27 [wgt: 0.875 400.7 km] 623165380010 [h: 585 airstn:x topo:MV stloc:x stveg:xx grveg:WARM CROPS ][MACOMER]
    data added: 24 overlap: 24 years
    add stn 46 range: 1951-1974 27 [wgt: 0.780 336.8 km] 623165200020 [h: 118 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][ISOLA ASINARA]
    data added: 24 overlap: 24 years
    add stn 47 range: 1952-1977 27 [wgt: 0.099 700.5 km] 623163440010 [h: 215 airstn:x topo:MV stloc:x stveg:xx grveg:WATER ][CALOPEZZATI]
    data added: 24 overlap: 24 years
    add stn 48 range: 1954-1977 26 [wgt: 0.483 355.6 km] 623162800010 [h: 4 airstn:A topo:FL stloc:A stveg:xx grveg:WATER ][TORRE OLEVOLA AERO]
    data added: 24 overlap: 24 years
    add stn 49 range: 1954-1976 26 [wgt: 0.220 471.6 km] 623162940010 [h: 269 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][CAPRI]
    data added: 23 overlap: 23 years
    add stn 50 range: 1952-1974 24 [wgt: 0.599 509.0 km] 623162630020 [h: 521 airstn:A topo:MV stloc:A stveg:xx grveg:WARM CROPS ][CANDELA AERO]
    data added: 23 overlap: 23 years
    add stn 51 range: 1960-2007 24 [wgt: 0.663 281.1 km] 623162450000 [h: 21 airstn:A topo:FL stloc:A stveg:xx grveg:WATER ][PRATICA DI MA]
    data added: 23 overlap: 23 years
    add stn 52 range: 1951-1975 24 [wgt: 0.300 170.1 km] 623161490010 [h: 468 airstn:x topo:HI stloc:x stveg:xx grveg:WARM CROPS ][SASSO FELTRIO]
    data added: 23 overlap: 23 years
    add stn 53 range: 1951-1973 24 [wgt: 0.644 309.2 km] 623160360010 [h: 128 airstn:A topo:MV stloc:A stveg:xx grveg:WARM CONIFER ][AVIANO]
    data added: 23 overlap: 23 years
    add stn 54 range: 1880-1900 23 [wgt: 0.529 922.4 km] 641119180010 [h: 501 airstn:x topo:MV stloc:x stveg:xx grveg:COOL FOR./FIELD ][ARVAVARALJA CZECH]
    data added: 21 overlap: 21 years
    add stn 55 range: 1960-1980 23 [wgt: 0.491 931.6 km] 623164900000 [h: 20 airstn:A topo:FL stloc:A stveg:xx grveg:WATER ][LAMPEDUSA]
    data added: 21 overlap: 21 years
    add stn 56 range: 1951-1974 23 [wgt: 0.719 150.2 km] 623161970010 [h: 254 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][ISOLA GORGONA]
    data added: 21 overlap: 21 years
    add stn 57 range: 1961-1980 23 [wgt: 0.830 645.6 km] 623163370000 [h: 485 airstn:x topo:HI stloc:x stveg:xx grveg:COASTAL EDGES ][BONIFATI]
    data added: 20 overlap: 20 years
    add stn 58 range: 1961-1980 23 [wgt: 0.691 266.4 km] 623162340000 [h: 89 airstn:A topo:MV stloc:A stveg:xx grveg:WARM FIELD WOODS][GUIDONIA]
    data added: 20 overlap: 20 years
    ignore: 59 range: 1949-1968 21 [wgt: 0.078 266.4 km] 615075860010 [h: 1912 airstn:x topo:MT stloc:x stveg:xx grveg:MED. GRAZING ][MONT VENTOUX FRANCE]
    add stn 60 range: 1953-1974 21 [wgt: 0.069 676.8 km] 623164150010 [h: 5 airstn:x topo:MV stloc:x stveg:xx grveg:WATER ][ISOLA STROMBOLI]
    data added: 0 overlap: 19 years
    possible range increase 17 49 57

    before adjustment:

    Ts.GHCN.CL.2 [GHCN V2 Temperatures (.1 C)]
    =================

    PISA/S. GIUST UC623 [161580004]

    Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
    1949: 103 92 90 148 170 207 9999 237 230 9999 128 9999
    1950: 79 9999 119 131 180 227 256 245 9999 176 9999 90
    1951: 95 99 100 132 158 206 230 229 219 148 122 76
    1952: 70 76 105 149 171 217 256 239 196 164 107 84

    after adjustment:

    Ts.GHCN.CL.PA.2 [GHCN V2 Temperatures (.1 C)]
    =================

    PISA/S. GIUST UC623 [161580004]

    Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
    1949: 93 82 80 138 160 197 9999 227 220 9999 118 9999
    1950: 69 9999 109 121 170 217 246 235 9999 166 9999 80
    1951: 85 89 90 122 148 196 220 219 209 138 112 66
    1952: 60 66 95 139 161 207 246 229 186 154 97 74

    compare the after adjustment values below where no adjusting rural stations are excluded:

    Ts.GHCN.CL.PA.2 [GHCN V2 Temperatures (.1 C)]
    =================

    PISA/S. GIUST UC623 [161580004]

    Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
    1949: 89 78 76 134 156 193 9999 223 216 9999 114 9999
    1950: 65 9999 105 117 166 213 242 231 9999 162 9999 76
    1951: 82 86 87 119 145 193 217 216 206 135 109 63
    1952: 58 64 93 137 159 205 244 227 184 152 95 72

    Note: For these tests the 2009_03 archived GISS files have been used rather than the latest files, as these are the files I have been using for validation. These tests have also used “GISS rounding” to integer values, rather than attempting to any “adjustment” which is simply an artefact of this method of calculation. I have seen such “adjustments” reach 0.2 C on occasions in a single step, as a result of multiple “roundings” and integer conversions in the step.

  31. E.M.Smith says:

    @Peter

    Fascinating.

    Not only do your results demonstrate that the results are significantly dependent on the particular stations used for ‘correction’ in the 1/10 C place; they also show that the nature of the rounding has influence on the 1/10 C place as well.

    My conclusion from that is: Until the entire corpus of “adjustment stations” and methodology can be demonstrated as valid and until the rounding method can be demonstrated as valid, no faith nor trust can be put in anything in the 1/10 C place since it may just be an artifact of those processes and choices.

    Further, since at least some stations have a perverse “UHI adjustment that makes it worse” (i.e. Pisa has the past get colder), the UHI methodology is demonstrated as having failures of “sign” in an unknown percentage of cases. That makes it very hard to convince me that it is working “right” in the aggregate.

    I think if you can document and demonstrate these test run results, you’ve got a “paper”.

    FWIW, in looking ahead into the STEP3 code, I don’t see where it can “undo” the warming done up through this stage.

  32. Peter O'Neill says:

    As a follow-up to my posting above, here are the results when the Alpine/High Altitude rural stations are used instead of the Italian/lower altitude rural stations:

    623 16158000 [PISA/S. GIUST] 32802

    lat 43.68 elevs 6 pop U topo FL stloc CO
    lon 10.38 elevg 4 ipop 91 stveg xx iloc 9
    airstn A itowndis 3 grveg: COASTAL EDGES

    Rural station choice override was used

    PApars.GHCN.CL.1000.20.log
    ==========================

    number of rural/urban stations 2501 3788

    urb stnID:623161580004 # rur: 32 ranges: 1949 2008 500.
    longest rur range: 1880-2008 129 [wgt: 0.083 458.6 km] 617109620002 [h: 986 airstn:x topo:HI stloc:x stveg:xx grveg:COOL CONIFER ][HOHENPEISSENB]
    add stn 2 range: 1883-2008 126 [wgt: 0.184 408.1 km] 646066800003 [h: 2500 airstn:x topo:MT stloc:x stveg:xx grveg:WARM CROPS ][SAENTIS]
    data added: 126 overlap: 126 years
    add stn 3 range: 1880-1985 106 [wgt: 0.290 355.1 km] 646067190010 [h: 2460 airstn:x topo:MT stloc:x stveg:xx grveg:WARM CROPS ][ST. BERNARD SWITZERLA]
    data added: 106 overlap: 106 years
    add stn 4 range: 1887-2008 102 [wgt: 0.142 429.3 km] 603111460002 [h: 3109 airstn:x topo:MT stloc:x stveg:xx grveg:TUNDRA ][SONNBLICK]
    data added: 102 overlap: 102 years
    add stn 5 range: 1880-1960 81 [wgt: 0.336 332.0 km] 646067530010 [h: 2095 airstn:x topo:MT stloc:x stveg:xx grveg:NORTH. TAIGA ][ST. GOTTHARD SWITZERLA]
    data added: 81 overlap: 81 years
    ignore: 6 range: 1880-1980 69 [wgt: 0.009 332.0 km] 609144470000 [h: 25 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][HVAR]
    add stn 7 range: 1880-1943 64 [wgt: 0.104 447.9 km] 603112340010 [h: 2044 airstn:x topo:MT stloc:x stveg:xx grveg:WARM CROPS ][OBIR AUSTRIA]
    data added: 64 overlap: 64 years
    add stn 8 range: 1951-2008 58 [wgt: 0.172 414.3 km] 617109610003 [h: 2962 airstn:x topo:MT stloc:x stveg:xx grveg:NORTH. TAIGA ][ZUGSPITZE]
    data added: 58 overlap: 58 years
    add stn 9 range: 1933-1985 53 [wgt: 0.253 373.6 km] 646067300000 [h: 3576 airstn:x topo:MT stloc:x stveg:xx grveg:TUNDRA ][JUNGFRAUJOCH]
    data added: 53 overlap: 53 years
    ignore: 10 range: 1951-2007 32 [wgt: 0.244 373.6 km] 623162800000 [h: 185 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][PONZA]
    ignore: 11 range: 1951-1981 31 [wgt: 0.499 373.6 km] 623160660000 [h: 211 airstn:A topo:HI stloc:A stveg:xx grveg:WARM FOR./FIELD ][MILANO/MALPEN]
    ignore: 12 range: 1951-1980 30 [wgt: 0.648 373.6 km] 623161460000 [h: 6 airstn:x topo:FL stloc:x stveg:xx grveg:WARM CROPS ][PUNTA MARINA]
    ignore: 13 range: 1951-1980 30 [wgt: 0.200 373.6 km] 623160400000 [h: 778 airstn:x topo:MV stloc:x stveg:xx grveg:WARM CROPS ][TARVISIO]
    ignore: 14 range: 1951-1980 29 [wgt: 0.420 373.6 km] 623165060000 [h: 159 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][GUARDIAVECCHI]
    ignore: 15 range: 1954-2007 29 [wgt: 0.627 373.6 km] 623161790000 [h: 574 airstn:x topo:MV stloc:x stveg:xx grveg:WARM CROPS ][FRONTONE]
    ignore: 16 range: 1951-1980 29 [wgt: 0.817 373.6 km] 623161420010 [h: 887 airstn:x topo:MV stloc:x stveg:xx grveg:WARM MIXED ][RIFREDO MUGELLO]
    ignore: 17 range: 1951-1979 29 [wgt: 0.883 373.6 km] 623161290000 [h: 191 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][ISOLA DI PALM]
    ignore: 18 range: 1951-1979 29 [wgt: 0.688 373.6 km] 623161190010 [h: 475 airstn:x topo:MV stloc:x stveg:xx grveg:WARM FOR./FIELD ][PASSO DEI GIOVI]
    ignore: 19 range: 1954-1981 28 [wgt: 0.129 373.6 km] 646066100000 [h: 491 airstn:x topo:HI stloc:x stveg:xx grveg:WARM FOR./FIELD ][PAYERNE]
    ignore: 20 range: 1955-2007 28 [wgt: 0.539 373.6 km] 623162240000 [h: 266 airstn:x topo:HI stloc:x stveg:xx grveg:WARM FIELD WOODS][VIGNA DI VALL]
    ignore: 21 range: 1951-1978 27 [wgt: 0.750 373.6 km] 623161970020 [h: 17 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][ISOLA DI PIANOSA]
    ignore: 22 range: 1953-1980 27 [wgt: 0.559 373.6 km] 623161160010 [h: 315 airstn:x topo:HI stloc:x stveg:xx grveg:WARM CROPS ][GOVONE]
    ignore: 23 range: 1952-1977 24 [wgt: 0.199 373.6 km] 623165380010 [h: 585 airstn:x topo:MV stloc:x stveg:xx grveg:WARM CROPS ][MACOMER]
    ignore: 24 range: 1951-1974 24 [wgt: 0.326 373.6 km] 623165200020 [h: 118 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][ISOLA ASINARA]
    ignore: 25 range: 1954-1977 24 [wgt: 0.289 373.6 km] 623162800010 [h: 4 airstn:A topo:FL stloc:A stveg:xx grveg:WATER ][TORRE OLEVOLA AERO]
    ignore: 26 range: 1954-1976 23 [wgt: 0.057 373.6 km] 623162940010 [h: 269 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][CAPRI]
    ignore: 27 range: 1960-2007 23 [wgt: 0.438 373.6 km] 623162450000 [h: 21 airstn:A topo:FL stloc:A stveg:xx grveg:WATER ][PRATICA DI MA]
    ignore: 28 range: 1951-1975 23 [wgt: 0.660 373.6 km] 623161490010 [h: 468 airstn:x topo:HI stloc:x stveg:xx grveg:WARM CROPS ][SASSO FELTRIO]
    ignore: 29 range: 1951-1973 23 [wgt: 0.382 373.6 km] 623160360010 [h: 128 airstn:A topo:MV stloc:A stveg:xx grveg:WARM CONIFER ][AVIANO]
    ignore: 30 range: 1951-1974 21 [wgt: 0.700 373.6 km] 623161970010 [h: 254 airstn:x topo:HI stloc:x stveg:xx grveg:WATER ][ISOLA GORGONA]
    ignore: 31 range: 1961-1980 20 [wgt: 0.467 373.6 km] 623162340000 [h: 89 airstn:A topo:MV stloc:A stveg:xx grveg:WARM FIELD WOODS][GUIDONIA]
    ignore: 32 range: 1949-1968 20 [wgt: 0.162 373.6 km] 615075860010 [h: 1912 airstn:x topo:MT stloc:x stveg:xx grveg:MED. GRAZING ][MONT VENTOUX FRANCE]
    possible range increase 27 58 60

    before adjustment (unchanged):

    Ts.GHCN.CL.2 [GHCN V2 Temperatures (.1 C)]
    =================

    PISA/S. GIUST UC623 [161580004]

    Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
    1949: 103 92 90 148 170 207 9999 237 230 9999 128 9999
    1950: 79 9999 119 131 180 227 256 245 9999 176 9999 90
    1951: 95 99 100 132 158 206 230 229 219 148 122 76
    1952: 70 76 105 149 171 217 256 239 196 164 107 84

    after adjustment:

    Ts.GHCN.CL.PA.2 [GHCN V2 Temperatures (.1 C)]
    =================

    PISA/S. GIUST UC623 [161580004]
    High Altitude
    Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
    1949: 88 77 75 133 155 192 9999 222 215 9999 113 9999
    1950: 65 9999 105 117 166 213 242 231 9999 162 9999 76
    1951: 81 85 86 118 144 192 216 215 205 134 108 62
    1952: 57 63 92 136 158 204 243 226 183 151 94 71
    Low Altitude (from previous posting)
    Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
    1949: 93 82 80 138 160 197 9999 227 220 9999 118 9999
    1950: 69 9999 109 121 170 217 246 235 9999 166 9999 80
    1951: 85 89 90 122 148 196 220 219 209 138 112 66
    1952: 60 66 95 139 161 207 246 229 186 154 97 74

    Both of these can be compared to the after adjustment values below where no adjusting rural stations are excluded:

    Ts.GHCN.CL.PA.2 [GHCN V2 Temperatures (.1 C)]
    =================

    PISA/S. GIUST UC623 [161580004]

    Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
    1949: 89 78 76 134 156 193 9999 223 216 9999 114 9999
    1950: 65 9999 105 117 166 213 242 231 9999 162 9999 76
    1951: 82 86 87 119 145 193 217 216 206 135 109 63
    1952: 58 64 93 137 159 205 244 227 184 152 95 72

    REPLY: Wow. That pretty much clinches it. PApars.f is sensitive to exactly what stations are used and I would speculate that it is sensitive to what station is first and order of application (and Hansen has said it is sensitive to order of application as well). Great work, Peter.

    FWIW, some folks over on Jennifer Marohasy’s blog had asserted that GIStemp would not be sensitive to adding nor removing thermometers. They seemed to think GIStemp code would be a perfect filter. Nothing like a dose of reality to clear things up, eh? ;-)

    http://jennifermarohasy.com/blog/2009/08/stop-averaging-global-temperatures-part-1/

    Thanks. -ems.

  33. Espen says:

    Interesting stuff! My guess was that Säntis would be used before Hohenpeissenberg because it’s slightly closer to Italy, but at least it’s #2. The Säntis (Saentis in GISS) temperature record shows a step change from appr. 1990. Interestingly, this coincides with an “urbanization” of this high mountain. Look at all that concrete: http://en.wikipedia.org/wiki/Säntis
    And the construction work for the “Säntis 2000″ buildings started in 1995… (http://www.swisscom.ch/NR/rdonlyres/1E16DA0D-555F-49AB-A179-A8B4F17C3D44/0/Saentis_d.pdf)

  34. E.M.Smith says:

    @espen:

    The code specifically chooses to use the longest lived record first. This was something of a “red flag” to me to raise the question as to just why Hohenpeissenberg gets such special treatment as to get a custom made record (glued in in STEP0). Someone went to a great deal of effort to make the Hohenpeissenberg record just a bit more complete and just a bit longer. Why?

    Perhaps because that gives it “pole position” as longest lived record for a 1000 km radius around it and lets it have “interesting” effects on all those stations it “corrects”.

    I may not have a “smoking gun” but it certainly is a big “Dig Here!” suspicious behaviour. “Probable Cause” if you will.

    The Saentis history has interesting implications as well.

  35. Espen says:

    Here’s a picture of the measuring field of the Hohenpeissenberg station. Looks a bit crowded to me:
    http://de.wikipedia.org/w/index.php?title=Datei:Hohenperißenberg_Observatorium_Messfeld_2.jpg&filetimestamp=20070709153620

Comments are closed.