mc_prep_crop( ) cropping individual loggers with individual start/end

[manmatej]

Upgrade the function to enable cropping of individual localities, not only whole myClim object.

1. by providing the vector of locality ids, start, end of the same length as the locality ids. if there is vector of localiteas an single start/end then recycle

[hanzlan]

As a work around this is possible using mc_filter -> mc_prep_crop -> mc_prep_merge:

### Define filter string of different logger groups based on locality
loc.eb <- ft$locality_id[grep('eb.*', ft$locality_id)]
loc.eg <- ft$locality_id[grep('eg.*', ft$locality_id)]

### Filter logger groups based on string
tms.eb <- myClim::mc_filter(tms, localities = loc.eb)
tms.eg <- myClim::mc_filter(tms, localities = loc.eg)

### Define individual filter dates
start.eb <- as.POSIXct("2022-06-03", tz = "UTC")
start.eg <- as.POSIXct("2022-06-01", tz = "UTC")

### Crop logger groups based on individual filter dates
tms.eb   <- myClim::mc_prep_crop(tms.eb, start.eb)
tms.eg   <- myClim::mc_prep_crop(tms.eg, start.eg)

### Merge individually cropped logger groups
tms <- myClim::mc_prep_merge(list(tms.eb, tms.eg))

Is it possible to filter individual loggers and crop their dates instead of localities (e.g. when a new logger replaces an old logger at the same locality) to prepare for a smooth join of time series?

[manmatej]

Thank you for your input. In general, it is not a supported approach to pre-clean the data at the level of the myClim object. For your example situation—when a new logger replaces an old logger at the same locality—we recommend the following options:

i) Either solve this during interactive joining (mc_join), where the user can decide which part of the timeseries to use in overlapping sections.

ii) Back up your original logger files and manually edit the copy of selected loggers, for instance, in Excel.

In mc_filter, it is not possible to filter individual loggers. If you insist on editing the logger data within the myClim object directly, you would need to work around it similarly as you proposed for localities, but this time going sensor by sensor. This is because, unlike loggers, sensors can be filtered within myClim.