Closed mnaguit closed 5 months ago
Thank you for your feedback, knowing the issues (be it event-based and/or metadata mismatch) helps a lot in identifying the next steps to improve the dataset.
Here are the relevant points that may touch on the issues you encountered:
The transition from triggered recordings to continuous streams:
The array dataset requires metadata enhancement to standardize the sensor-datalogger naming. The arrays are equipped with multiple sensors plugged into one datalogger. Whereas a typical seismic station would be equipped with either a stand-alone seismic recorder or one sensor attached to a datalogger.
XYZ
or 12Z
.Response sent to the data user.
From the data user:
There are some issues in the structural array data sets , per below:
1- Since for buildings sensors restrictedStatus = open, they can be accessible through our app. (We only use the responses at the foundation level, so the building information is not technically available to the public)
2- The raw data recorded by sensors at the instrumented buildings (Like CPXB and CPLB ) are in [g] not in [m/s/s]. It seems that the response information is not recorded properly for them.
For example: 2011.052.2351.42.CPXB.cmf.gz values on your database is correct. But when you read it through the raw data and python you can see that the values are wrong (since in raw data it has been mentioned they are measured in m/s/s, but they are in g).
3- The other important problem is the difference between the name of the channel codes being delivered by client.get_stations() and client.get_waveforms(), resulting in failure of reading and filtering records.
BN1 and HN1 --> BNX and HNX ? BN2 and HN2 --> BNX and HNY ?
For example, for CPLB station at the former BNZ building location:
In summary, IMO there should be some inconsistency and small errors in structural array data sets compared to the free land sensor datasets.
Is there a possibility that these issues will be resolved in the near future? 😊