EMO-5: a high-resolution multi-variable gridded meteorological dataset for Europe

Thiemig, Vera; Gomes, Goncalo N.; Skøien, Jon O.; Ziese, Markus; Rauthe-Schöch, Armin; Rustemeier, Elke; Rehfeldt, Kira; Walawender, Jakub P.; Kolbe, Christine; Pichon, Damien; Schweim, Christoph; Salamon, Peter

doi:https://doi.org/10.5194/essd-14-3249-2022

Articles | Volume 14, issue 7

https://doi.org/10.5194/essd-14-3249-2022

© Author(s) 2022. This work is distributed under
the Creative Commons Attribution 4.0 License.

https://doi.org/10.5194/essd-14-3249-2022

© Author(s) 2022. This work is distributed under
the Creative Commons Attribution 4.0 License.

Articles | Volume 14, issue 7

Data description paper

|

15 Jul 2022

Data description paper |

| 15 Jul 2022

EMO-5: a high-resolution multi-variable gridded meteorological dataset for Europe

Vera Thiemig, Goncalo N. Gomes, Jon O. Skøien, Markus Ziese, Armin Rauthe-Schöch, Elke Rustemeier, Kira Rehfeldt, Jakub P. Walawender, Christine Kolbe, Damien Pichon, Christoph Schweim, and Peter Salamon

Download

Final revised paper (published on 15 Jul 2022)
Preprint (discussion started on 29 Nov 2021)

Interactive discussion

Status: closed

CC1:
'Comment on essd-2021-339', Peter Burek, 17 Dec 2021

Very useful dataset. Just testing at the moment.
3.3.2 Aggregation of reference period is a bit unclear.
- All the other daily parameters such as wind speed, solar radiation and vapour pressure are averaged over 00:00 to 23:59:59 of the current day -> you state that the time stamp reference to the end of a period.
Daily vapor pressure starts wirh 2/1/1990 00:00 -> according to your first statement that is from 2/1/1990 00:00 to 2/1/1990 23:59:59, according to your second statement (time stamp at end of period that is 1/1/1990 00:00 to 1/1/1990 23:59:59.

In your figure 5, time stamp 00:00 of reference date is the begging of the period not the end.
- your daily dataset starts sometimes on the 2/1/1990 00:00 (pd,pr,rd,ws). I guess that 2/1/1990 00:00 is the period 1/1/1990 00:00 - 23:59:59, but in any automatic reading this would linked to the 2/1/1990 (because that is the date)
- some of your datasets are only 10956 days (ws) some are 10957 days and some are 10958 days
-- 6 hourly ta - 43828 timesteps
this start on 1/1/1990 00:00 and end on 31/12/2019 18:00 - I assume that the first data 1/1/1990 00:00 is the period
1/1/1990 00:00 - 1/1/1990 5:59 -> but than it is not what you stated in line 250

-- 6 hour pr - 43832 timesteps
start on 31/12/1989 at 12:00 and ends on 1/1/2020 6:00 -> here it seems 31/12/1989 at 12:00 is the period 31/12/1989 at 6:01-12:00
Maybe you can clarify this in 3.3.2
-----
- The dataset comes without any readme. maybe a shor readme with definition of variable, units, citation is useful
---
- the dataset is not using SI- Units. Fine with me, but a explanation why you use e.g. mm instead of kg m-2 might be useful.

Citation: https://doi.org/10.5194/essd-2021-339-CC1
- AC1:
  'Reply on CC1', Vera Thiemig, 03 Jan 2022
  Dear Peter Burek,
  first of all, we would like to thank you for reviewing our manuscript and for raising some points. We have gone through your comments carefully and addressed them as outlined below.
  Shall you have any further questions please don’t hesitate to add them.
  Greetings from the entire team!
  Vera Thiemig
  
  Reviewer comment 1: Inconsistencies in reference period (in text and files)
  Reply by Authors 1:
  Clarification:
  The netCDF files for the daily variables shall contain 10957 daily grids. The time-stamp of the first and last grid depends on the variable:
  For daily windspeed, solar radiation and vapour pressure: first "1990/01/02 00:00 UTC", last "2020/01/01 00:00 UTC".
  
  For daily minimum temperature: first "1990/01/01 06:00 UTC", last "2019/12/31 06:00 UTC"
  
  For daily maximum temperature: first "1990/01/01 18:00 UTC", last "2019/12/31 18:00 UTC"
  
  For daily precipitation: first "1990/01/02 06:00 UTC", last "2020/01/01 06:00 UTC".
  
  The netCDF files for the 6-hourly variables shall contain 43828 6-hourly grids, where the first time-stamp is "1990/01/01 12:00 UTC" and the last one "2020/01/01 06:00 UTC".
  
  Action:
  We corrected
  the textual information in Section “3.3.2 Aggregation or reference period” in accordance
  
  re-generated Figure 5 which had the daily precipitation shifted by a day
  
  re-generated the netCDF files were necessary (e.g. windspeed file had a missing time step) and updated the repository
  
  Reviewer comment 2: Suggestion of a README file
  Reply by Authors 2: README file has been created and uploaded to the dataset, see README.txt (https://jeodpp.jrc.ec.europa.eu/ftp/jrc-opendata/CEMS-EFAS/)
  
  Reviewer comment 3: Dataset is not using SI- Units
  Reply by Authors 3:
  We only partly agree with this comment, as we are certainly using SI units for precipitation as "mm" is a unit in the SI system. However we are not using the recommended/canonical unit for "precipitation_amount" from the CF Standard Name table which would indeed be "kg m-2". We consider "mm" as a better unit because the usual convention in meteorology of "mm" == "kg m-2" for precipitation is strictly speaking only true at a water density of 1.000000, i.e. only at the temperature of 4°C. Nevertheless, we agree that complying to the CF Convention also has its merits. However, EMO-5 has been created with the main purpose of driving a hydrological as well as an evapotranspiration model, hence the models requirements determined the units of the variables.
  
  Citation: https://doi.org/10.5194/essd-2021-339-AC1
RC1:
'Comment on essd-2021-339', Anonymous Referee #1, 03 Jan 2022

See attached

Citation: https://doi.org/10.5194/essd-2021-339-RC1
- AC2: 'Reply on RC1', Vera Thiemig, 21 Jan 2022
  
  The comment was uploaded in the form of a supplement: https://essd.copernicus.org/preprints/essd-2021-339/essd-2021-339-AC2-supplement.pdf
  
  Citation: https://doi.org/10.5194/essd-2021-339-AC2
RC2: 'Comment on essd-2021-339', Anonymous Referee #2, 07 Jan 2022

See the attached pdf.

Citation: https://doi.org/10.5194/essd-2021-339-RC2

Peer review completion

AR: Author's response | RR: Referee report | ED: Editor decision | EF: Editorial file upload

AR by Vera Thiemig on behalf of the Authors (18 Feb 2022) Author's response Author's tracked changes Manuscript

ED: Referee Nomination & Report Request started (26 Feb 2022) by Qingxiang Li

RR by Anonymous Referee #1 (17 Mar 2022)

ED: Reconsider after major revisions (18 Mar 2022) by Qingxiang Li

AR by Vera Thiemig on behalf of the Authors (13 Apr 2022) Author's response Author's tracked changes Manuscript

ED: Referee Nomination & Report Request started (14 Apr 2022) by Qingxiang Li

RR by Anonymous Referee #1 (15 Apr 2022)

Suggestions for revision or reasons for rejection

The authors have responded to the majority of outstanding issues. The paper is substantively approved and in my view suitable for publication after minor amendments. Other issues I had the authors have responded to and I see no value in persisting on these in general and do not wish to be 'that reviewer' in this regard.

I would remain of the view that the table of sources is of sufficient importance that it should reside in the main text and not in an annex and would invite the editor to make a decision on this.

I remain of the opinion that the data availability section is too short and does not provide the reader with sufficient detail as to the level of user support involved. I think the authors here are too close to their system and are effectively taking for granted that the reader will know the level of user support that is standing behind this product. My fear is that very many of them won't. Would it really hurt to add a paragraph that describes what being in the data catalogue of JRC means in terms of 24/7 user support, up time, help desk, long-term product support, version control, documentation etc? You want users to read this and go "that's a product I can use with certainty that it is well maintained, well supported, operationally available, and therefore I can be certain of being available today, tomorrow, next year and 5 years hence to support my application so i can build my application around it with confidence". I think the authors are doing themselves and their product a very substantial dis-service not documenting this better. It would only take an additional paragraph but might mean the difference between a reader deciding to use this product or not.

The reference in line 377 to 2019 is inconsistent with elsewhere where NRT is assured.

I will not insist for this paper but I would very strongly urge for future work moving all plotting etc. software as quickly as possible to use colour-blind friendly schema. This is a pervasive and insidious case of able-ism that disenfranchises a not inconsiderable proportion of the population and for which copious software and tools exist to assure outputs that are not inadvertently discriminatory. I fully accept that there is no intent involved. However, when the tools exist it is behoven on those of us who are not colour blind to duly consider accessibility to our products to those who are.

Hide

ED: Publish subject to minor revisions (review by editor) (05 May 2022) by Qingxiang Li

AR by Vera Thiemig on behalf of the Authors (11 May 2022) Author's response Author's tracked changes Manuscript

ED: Publish as is (30 May 2022) by Qingxiang Li

AR by Vera Thiemig on behalf of the Authors (09 Jun 2022) Manuscript

Short summary

EMO-5 is a free and open European high-resolution (5 km), sub-daily, multi-variable (precipitation, temperatures, wind speed, solar radiation, vapour pressure), multi-decadal meteorological dataset based on quality-controlled observations coming from almost 30 000 stations across Europe, and is produced in near real-time. EMO-5 (v1) covers the time period from 1990 to 2019. In this paper, we have provided insight into the source data, the applied methods, and the quality assessment of EMO-5.