The page is not automatically updated, since the trends are at least two decades. However, the previous page was made in 2012, so a data update was needed. And it makes sense to use the new MoyGLV2.1 WebGL facility. I had been slow to update the old data partly because I had used a rather neat, but hard to debug, mesh compression scheme, described here. Each period needs a separate mesh, so that helps. However, downloads are now generally quicker than in 2012, so the full 3 Mb of data does not seem so forbidding. So I have sadly let that go. However, for this post I have put the WebGL below the jump, as it still may take quite a few seconds for some.
I also updated the computing method to correct a source of noise in the previous page. I think the issue is instructive, and in 2012, I hadn't done the thinking explained in some of my many pages on averaging, eg here. I have frequently explained why anomalies are used in spatial averaging, to overcome inhomogeneities. But I had not thought they were needed for a trend at a single station. But they are - seasonal variation is a big source of inhomogeneity, and should be subtracted out. It shows itself in two ways:
- If missing values cluster in a cold or hot time, especially biased toward one end of the period, then it introduces a spurious trend, and
- you can even get a spurious trend with all data present. Sin(x) between 0 and 360° has a trend, rising almost the full amplitude. Taking 30 cycles reduces this by a factor of 30, but with seasonal range of say 20C, that can still be serious. Fortunately a calendar year is nore like cos, which doesn't have a trend over that period, but not all data runs a full calendar year at the end.
The remedy is to, for each station, calculate the mean observed seasonal cycle,, and subtract that out. I did that, to good effect. So, below the jump, or on the revised page, you can check ot trends from the last two decades to century plus. The radio buttons let you look at unadjusted or adjusted GHCN (prefixes un_ and ad_). One thing I found useful is to compare (swap button) two trends for the same period, one adjusted, one not. It is clear that homogenisation clears up all kinds of aberration, without greatly affecting the main trend pattern, which except for aberrations is quite smooth in space.
So below the jump is the revised map. There are some operating instructions on the page, or more detail on the WebGL page or post.
Appendix - V2.1
I'll just record here something I added to V2.1 (not yet released, but used here) for the multiple data (radios). It is a common situation where there are several sets of links (meshes) but just one master set of nodes. One could gives multiple sets of nodes too, but that is bulky. The logic goes:
The same logic may be needed when there are multiple objects which draw on a common set of nodes.
- there are properties associated with nodes that are common to all data - coords and tags. These can be pointed to by the links.
- there may be properties that vary, specifically vals. Here you want to give just values that will appear on the current plot. V2 did not handle this.
The same logic may be needed when there are multiple objects which draw on a common set of nodes.
Another addition - the match button. Pressing this makes it go red and ensure that all alternative datasets (radio buttons) will use the color scaling that is currently showing. Press again to cancel (button reverts color).
Another addition - if you click on the various buttons with Ctrl key down, there is no action, but some explanation of its function pops up.
It is a great interface but by changing net colour scale between periods it is difficult to see any gradual changes in trend. Maybe it is better to fix a long term scale (fixed color_palette) so that all half decades show relative warming.
ReplyDeleteClive,
DeleteYes, I said I would do something about that, and haven't yet. I'll add a dutton ("Match") which let's you force the color scale of one to match any other, or if you wish, forces all to match any particular one.
The Match button is working - described in an appendix above.
Delete