Include driver data?

[florianhartig]

My PhD student Johannes is just working on a 3PG calibration across Europe, and I discussed with him that, in principle, all driver data is freely available, so if we have a place where the data is stored, with https://github.com/trotsiuk/r3PG/issues/57 it would be possible to create

• A function that allows to run r3PG on a arbitrary location
• Possibly even a small shiny app

What do you guys think about this? I might even have someone that could do this (more via email)

[trotsiuk]

I would personally go against it. From my expectation, it is a lot of work with no particular output. It would be nice function for the test purpose, but people who would really want to work with the 3-PG they would like to use their own data. Furthermore, this is not only climatic driver data, but also the site conditions (soil, etc), which are even more difficult to access.

To name some reasons:

• there is large variety of climatic driver data, sources, resolution, coverage, etc. We would have to decide which one to use, and for which continents. They are also under constant development, would you consider updating them on regular basis.
• Storage and availability might be still an issue, if we want to cover few continents.
• There are already many tools to extract the climatic data (e.g. climate, rnoaa, etc...)
• As mentioned above, the soil data will be more tricky one.

I could envision that we create a function, which call external package to get the data. But even then, I would be very careful in including many dependencies to the r3PG, as maintenance on the long term is difficult.

I would rather suggest writing a vignette, which show how to get the external forcing data for the mode.

[florianhartig]

OK, we can discuss this - I had a lot of dependency issues lately with other packages but for the same reason I have also learned how to circumvent them better, I'm pretty confident that this can be done at least without creating CRAN problems (of course, it might still happen that the code doesn't run).

I'm not so sure about the "people want to do their own stuff" argument - I think people are quite happy to be given a reasonable solution, and if none is provided, there is a good chance that an inexperienced user is making mistakes in preparing the data. Given that people still can use whatever data they want, an (optional) default seems like a plus to me.

[trotsiuk]

Hi @florianhartig I still consider given the time limitation and above mentioned points NOT to include the driver data into the package. So for now I will close this issue and will be glad to re-open it once we have a bit more clear idea.