tidyverse verbs and tidyrgee

[zackarno]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.
• This discussion was specifically created as a board to compile ideas related to naming functions in tidyrgee

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[zackarno]

I think there have been a few naming discussions that have come up as issues. I will start compiling them here:

#31
#1

[joshualerickson]

I think #33 as well. Not necessarily a naming issue but more a package scope issue. I think it might be a good time to separate tidy as in tidyverse and tidy as in cleaning or abstracting away complexities from rgee. The former being what I think tidyrgee is doing (purpose) and latter being more abstraction from common rgee/gee complexities, e.g. ee_extract_tidy, ee_join_bands, ee_get_closest_distance_to_val, ee_reduce_regions, ee_timeseries, ee_visualise, etc. Let me know what you think but I'm more inclined to work on non-dplyr/tidyr named functions in something like easyrgee. I think this will help maintain scope creep and will make it easier to maintain but also communicate.

[joshualerickson]

It's all abstraction!... What I really meant was that tidyrgee to me means using dplyr/tidyr named functions for rgee.

[zackarno]

yeah i agree splitting the scope is the way to go. But I also think there is some room to expand beyond pure dplyr verbs in tidyrgee to minimize the risk of ending up with a partial package which is too "feature-incomplete" to be very useful to others.

dplyr-like functionality is a core concept, but I think we we should try to come up with a conceptual framework that more concretely defines the scope of tidyrgee beyond just pure dplyr-syntax (as long as it remains dplyr-like). Just off the top of my head something along the lines of "wrangling/manipulating RS data from GEE." This removes visualization and analysis from the scope, but can still ensure the package remain "feature-complete". A this point I would probably advocate for leaving ee_extract_tidy in and thinking of it as a core wrangling/manipulation procedure. If we look at other packages that take this idea of using dplyr/tidy syntax to other domains (i.e sf, srvyr), they do include new functions when there is not a clear one-to-one translation and i think this generally makes the packages easier to learn. The other functions you mentioned, yeah definitely agree for easyrgee .

regarding the inner_join vs ee_join_bands - yes perhaps leaving it as inner_join makes sense - we just might need to improve documentation and maybe even include a helpful message to help lower risk of confusion. I can see a potentially temptation for people not used to GEE to just see the vrt and not realize some of the implications of the functions on the ee_ob

[joshualerickson]

Just off the top of my head something along the lines of "wrangling/manipulating RS data from GEE." This removes visualization and analysis from the scope, but can still ensure the package remain "feature-complete".

This sounds good @zackarno! I wasn't thinking of it like sf but that makes sense now and also the direction you are looking at going with this!

I agree with the vrt stuff and will just need to keep it updated.

Next step CRAN and getting it out there :)

[zackarno]

well tbh I do not think that we should aim to make it anywhere as rich as sf and do agree fully that keeping it bare bones will be much better and easier for us to maintain, i'm just making the case for a little wiggle room on common spatial data manipulation operations.

What do you think about this: Let's get {easyrgee} going - we can throw anything that does not super obviously fit into {tidyrgee} there ... in addition to adding more functionality {easyrgee} can also serve as a temporary staging ground - if after some time an {easyrgee} function seems like an obvious candidate for many {tidyrgee} workflows we can consider migrating it?

and yes CRAN - let's do it!

[joshualerickson]

Yeah this sounds good to me for sure. Let's chat and get a list going for CRAN.