Slow processing times with `fill_na_values = TRUE`

[robe2037]

Setting fill_na_values = TRUE causes align_move() to take significantly longer than if the argument is set to FALSE. Here is the benchmark comparison for a move2 object with 3 tracks lasting an average of 228 days and a simple feature collection with 6539 features and 11 fields:

Unit: milliseconds
                                                                                            expr        min         lq      mean     median         uq        max neval
                         align_move(m = d, res = units::set_units(24, "hours"), verbose = FALSE) 19735.0677 20677.9392 21672.959 21513.5055 22356.7081 24811.1658   100
 align_move(m = d, res = units::set_units(24, "hours"), fill_na_values = FALSE, verbose = FALSE)   115.1227   122.3369   137.918   134.2175   139.0747   583.3093   100

fill_na_values may be necessary for any animations that want to adjust aesthetics based on an event-level attribute value (e.g. coloring by behavioral segment), but in many cases the interpolated values are likely to be unnecessary for a future animation.

Considering how much slower it is to fill attributes at interpolated times, it may be worth having fill_na_values default to FALSE and documenting the cases in which a user might need to opt-in by explicitly setting fill_na_values = TRUE. In these cases users can also limit the processing time increase by removing any unnecessary columns prior to calling align_move() (e.g., with move2::select_track_data() or dplyr::select()). Alternatively, fill_na_values could be modified to target specific columns that should have their values retained at interpolated times, while other columns would be ignored.

[annescharf]

Hi @16EAGLE, when downloading data from Movebank using the move2 library, all available attributes are downloaded by default (these can be over 100). One can control which attributes associated to the locations are downloaded, but those attributes that are associated to the tracks (i.e track data table) will be always downloaded, and there are usually several dozens of these attributes to. I expect that the normal use case will be a move2 object with a ton of attributes.