I see a possible source of confusion in the way kernels are used, this was also discussed with @J535D165 .
For a non-expert user, creating their own kernel is not a possibility. Therefore, the package should offer an easy-to-understand implementation of the basic aggregation functions such as mean(), median(), min(), max(), count(), , quantile(), furthest(), closer(), fastest(), slowest(), [...]. I believe these functions would cover the large majority of the enrichment needs and would make the retrieval of distances/durations actually useful.
If these functions would go under kernels, then the naming of kernels would have to change. Otherwise, kernels might be left untouched for expert users (and NULL by default), while these functions would have their own summarisation = X variable.
As discussed with @J535D165, this implementation would be also a start for moving towards the direction of a tidyverse-like syntax. However, the I will write a more formalized issue later on the syntax topic.
I see a possible source of confusion in the way
kernelsare used, this was also discussed with @J535D165 .For a non-expert user, creating their own kernel is not a possibility. Therefore, the package should offer an easy-to-understand implementation of the basic aggregation functions such as
mean(),median(),min(),max(),count(), ,quantile(),furthest(),closer(),fastest(),slowest(), [...]. I believe these functions would cover the large majority of the enrichment needs and would make the retrieval of distances/durations actually useful.If these functions would go under
kernels, then the naming ofkernelswould have to change. Otherwise, kernels might be left untouched for expert users (andNULLby default), while these functions would have their ownsummarisation = Xvariable.As discussed with @J535D165, this implementation would be also a start for moving towards the direction of a tidyverse-like syntax. However, the I will write a more formalized issue later on the syntax topic.