Thursday, 7 November 2013

ISTI/Benchmarking talk at Reading University Meteorology Department lunchtime seminar

I was invited to present the work of the ISTI at Reading University Meteorology Department.

The talk covered the aims and workings of the ISTI: to facilitate robust climate analysis of land surface temperature.

1) Provide a version controlled, comprehensive, traceable to known origin, openly shared databank of surface temperature data with digitally attached metadata.

2) Set up an international standard for benchmark testing homogenisation algorithms and other methodological choices for building climate data-products to help quantify homogenisation and methodological uncertainty and aid product selection and methodological advancement.

3) Provide a portal for all ISTI related products with user tools to help inform choice of product, visualisation and intercomparison of products.

I then focussed on the benchmarking side of things to explain why this is needed and how we are going about it.

The slides for the talk are available here: The ISTI: Dragging the land surface temperature data kicking and screaming into the 21st Century

A few of the interesting questions that I remember:

Will the ISTI databank include non-standard station data?
Yes, there are plans to incorporate data from amateur stations. This will be flagged and prioritised appropriately.

How do you deal with uncertainties between the true shaded air temperature verses the biases created by poor ventilation or insolation issues in screen temperatures?
This is a big problem as we need to quantify changes/impacts on the smaller, more local scale. By making as much data available as possible, in addition to metadata, the ISTI can help address this problem. Having a higher density of stations increases the statistical power in detection of errors. Making it easier to build surface temperature products enables more people to tackle the problem and apply a wider spread of methodological choices. This may help to constrain the uncertainty to come extent.

Can you provide a list of stations used to make up each gridbox in gridded products?
This is something that we would encourage anyone building data-products to do. Ideally they would list the stations and which stage and version they come from. The data-portal will have to be able to cope with hosting ancillary information pertaining to the data-products in an easily searchable and usable manner.

Can other people make their own error worlds/synthetic data?
Yes - all of our code will be written in R and published on the website. The idea is that others can use the code and tweak various parameters to make their own clean synthetic stations and add errors as they wish.

No comments: