Open peterdesmet opened 2 years ago
@jimcasaer: I discussed this with @peterdesmet of course and I find a good idea as well. What do you think? I think this will give a very boost to the package (especially if combined with #92) as it will make things easier to understand and follow. Users will have to use explicitly the get_*
functions, I know, but they will get rid of the argument feature
in map_dep(). At least in the new approach they will be helped by autocompletion while writing the function name, while they are not while selecting the feature in map_dep()
.
This will also very clearly split the calculation and the visualization part. Good for both users and software quality.
Curious about your opinion.
@damianooldoni can we discuss this tomorrow before the coding club - drinking a coffee ?
We didn't speak about this issue during the camtraptor July 2023 coding sprint. However, I think we should tackle this aspect while working on #231.
Currently features are implemented in two ways:
get_n_obs(mica)
map_dep(mica, feature = "n_obs")
That might get complicated to explain and maintain. I think features should be functions only, and
map_dep()
should be a generic function that is always called afterget_
.E.g.:
That way, users call a
get_
function first (and can explore the data at that stage), but have the option to pipe it further to see that dataframe as a map.