Francisco Rodriguez-Sanchez

Thanks Julen. I apologise because that approach was proposed early and I didn't object. I think I didn't understand the implications then. But now I'm quite convinced we should step...

Thanks Vero Yes, we would have to recalculate the rasters. What I meant is that we probably don't need to calculate monthly values from daily rasters again, but instead just...

Excellent, thank you both!

Hi, I agree from an ideal point of view we should store all data versions for the sake of reproducibility. Last time we talked about this we discarded the idea...

Sounds good to me! When you say "only create a new version if there are substantial changes", if we "update the whole time series every year", that means we will...

But those lon/lat columns are used a few lines below (https://github.com/VeruGHub/easyclimate/blob/bc102832ce749a3aae7083c83d3a8ffeda7efeb5/R/get_daily_climate_single.R#L318) so I don't think they can be removed?

Ah, I see. Probably can be removed then? Please check that wouldn't break anything

Dear Kun Thanks for the suggestion. We're currently discussing it cc @VeruGHub @cpucher Meanwhile, I'm unclear if you have tried the approach outlined here: https://verughub.github.io/easyclimate/articles/climatic-indices.html#average-climatic-values-per-site-or-time-period. That is, you may not...

The function would produce data from a single dataset, which you can choose using a 'source' argument, for example: get_daily_climate(coords, "tmin", period = "2010-01-01", source = "CHELSA") This function would...

Great thread! A common bottleneck for many, I think. For some time I thought that using Authorea or Overleaf, which can be easily synced to GitHub (e.g. see [here](https://support.authorea.com/en-us/article/syncing-articles-to-github-zubain/) &...