Issues in structural array dataset

[mnaguit]

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:

t = UTCDateTime("2016-11-13T11:02:56.346094Z")
measuringStation = client.get_stations(station="CPLB", level="response", starttime = t-0, endtime = t + 300)
waveform = client.get_waveforms("NZ", "CPLB", "*", “*”, t-0, t + 300, attach_response=True)

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? 😊

[mnaguit]

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:

  • Continuous data are available since 2020 for arrays, which are accessible thru FDSN webservice in miniseed format, along with metadata like scale factors to convert the raw data to engineering units.
  • Prior to this, the triggered raw data files accessible from the GeoNet Data Site are in CSV/CMF formats, which contain 3-components of acceleration with unit of g.
  • The earlier recordings may have a different scale adjustment, the responses for early sites like CPXB may need checking. This may explain some of the discrepancy between these data, as you have observed (e.g., CMF records giving accurate numbers in g-unit).

• 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.

  • In addition, the channel naming needs to be addressed for arrays for consistency in channel codes. Currently, axial flag includes XYZ or 12Z.
  • FDSN query on the Z component returns the complete metadata including the response information. However, the query for horizontal components may return a response error when the data filename does not match the metadata.
  • In bulk processing that use FDSN webservice, you may hit errors connected to response error and/ data gaps for the triggered records.

[mnaguit]

Response sent to the data user.