ISPAQ uses ObsPy to read in the miniSEED files, which was also reading the data into the stream object out of chronological order. When this happens, the ObsPy object indicates that there are 2217 traces - which is the num_gaps plus num_overlaps reported (plus 1). This indicated a probable source of the erroneous metric values.
To test whether this ordering was causing the problem, I tested out using the .sort() method on the ObsPy stream object after reading in the data. After adding the sorting, the availability metrics seem more reasonable:
We found that when the miniSEED segments are out of order, the availability values (e.g. num_gaps, num_overlaps, percent_availability) are inaccurate.
This was observed using local files for QW.BCV11 which has many segments in a single day file:
Of note, the data within the day file are out of order. For example:
ISPAQ was calculating unexpectedly high values for the gaps and overlaps metrics, and reporting 0% availability:
ISPAQ uses ObsPy to read in the miniSEED files, which was also reading the data into the stream object out of chronological order. When this happens, the ObsPy object indicates that there are 2217 traces - which is the num_gaps plus num_overlaps reported (plus 1). This indicated a probable source of the erroneous metric values.
To test whether this ordering was causing the problem, I tested out using the .sort() method on the ObsPy stream object after reading in the data. After adding the sorting, the availability metrics seem more reasonable: