Data Q test summary and a list of XML issues

[PetrColinSky]

Dear network and station operators,
participants of the AdriaArray Seismology group together with the ORFEUS User Advisory Group prepared a summary of data and metadata quality tests. The summary sheet “Quality_control.ods”/“Quality_control.xlsx” is available here
https://github.com/PetrColinSky/DataQuality/tree/master/summary
There is a readme file explaining all the details and pointing you to the particular tests at other four sites. I would like to encourage all operators to check the summary table, mainly their networks/stations, to recognize the issues. The links in the readme file then point you to the detailed results of the particular test for which the station of your interest failed. If there are any questions, get back to me or directly to the authors of the other tests. These tests were performed just before the EGU in April 2024, and some of the issues are already fixed, thanks to everybody for the effort. We will repeat the tests soon and the summary table will be updated then.

Here, I am listing some stations with metadata issues, which are partly already included in the summary table, partly are found in addition. This list is not exhaustive and not necessarily systematic in a sense that I discovered these issues by processing the data for particular earthquakes for different time epochs and various regions. The best would be – if your station is mentioned here – that you check all your stations of the same network for the same issue. The problems are repeating mainly within a given network.

deconvolution gives zero multiplication/division for the 2015-2018 epoch
http://ws.icgc.cat/fdsnws/station/1/query?net=CA&station=CGAR&channel=???&level=response

missing PaZ for the 2001-2018 HH* epoch:
https://eida.bgr.de/fdsnws/station/1/query?net=HS&station=GWBE&channel=???&level=response

missing PaZ for the 2012-2018 HH* epoch:
https://eida.bgr.de/fdsnws/station/1/query?net=HS&station=GWBD&channel=???&level=response

missing PaZ for the 2002-2020 HH* epoch:
https://eida.bgr.de/fdsnws/station/1/query?net=HS&station=GWBF&channel=???&level=response

missing PaZ for the 2001-2021 HH* epoch:
https://eida.bgr.de/fdsnws/station/1/query?net=HS&station=GWBC&channel=???&level=response

missing PaZ for the 2011-2019 HH* epoch:
https://eida.bgr.de/fdsnws/station/1/query?net=HS&station=EBSD&channel=???&level=response

missing PaZ for the 2012-2020 HH* epoch:
https://eida.bgr.de/fdsnws/station/1/query?net=HS&station=GODD&channel=???&level=response

missing PaZ for the 2001-2021 HH* epoch:
https://eida.bgr.de/fdsnws/station/1/query?net=HS&station=WBA&channel=???&level=response

missing PaZ for the 2003-2020 HH* epoch:
https://eida.bgr.de/fdsnws/station/1/query?net=HS&station=WBB&channel=???&level=response

missing PaZ for the 2013-2021 HH* epoch:
https://eida.bgr.de/fdsnws/station/1/query?net=HS&station=WBFO&channel=???&level=response

missing PaZ for the 2006-2020 HH* epoch:
https://eida.bgr.de/fdsnws/station/1/query?net=HS&station=WBG&channel=???&level=response

missing InstrumentSensitivity in the 2011-2022 HH* epoch
http://eida.gein.noa.gr/fdsnws/station/1/query?net=HL&station=DION&channel=???&level=response

Dip is -90 for the HHE channel in 2015-2016 and 2016-2020 epochs, but should be rather 0
https://erde.geophysik.uni-muenchen.de/fdsnws/station/1/query?network=BW&station=GELB&channel=???&level=response

in the xml, there is a locationCode="00" given, but no location code is given in the data
http://www.orfeus-eu.org/fdsnws/station/1/query?net=GB&station=HMNX&channel=???&level=response

BHZ and HHZ channels have Dip = 0, but should be rather -90 or 90,
both *HE and *HN channels have the same Azimuth = 0, but E and N should be orthogonal
http://www.orfeus-eu.org/fdsnws/station/1/query?net=CR&station=HVAR&channel=???&level=response

the following stations are missing the older epochs before 2019 (the data is available, but metadata is not)
https://erde.geophysik.uni-muenchen.de/fdsnws/station/1/query?network=Z3&station=A260A&channel=???&level=response
https://erde.geophysik.uni-muenchen.de/fdsnws/station/1/query?network=Z3&station=A261A&channel=???&level=response
https://erde.geophysik.uni-muenchen.de/fdsnws/station/1/query?network=Z3&station=A262A&channel=???&level=response
https://erde.geophysik.uni-muenchen.de/fdsnws/station/1/query?network=Z3&station=A263A&channel=???&level=response
https://erde.geophysik.uni-muenchen.de/fdsnws/station/1/query?network=Z3&station=A264A&channel=???&level=response
https://erde.geophysik.uni-muenchen.de/fdsnws/station/1/query?network=Z3&station=A265A&channel=???&level=response
https://erde.geophysik.uni-muenchen.de/fdsnws/station/1/query?network=Z3&station=A266A&channel=???&level=response
https://erde.geophysik.uni-muenchen.de/fdsnws/station/1/query?network=Z3&station=A267A&channel=???&level=response
https://erde.geophysik.uni-muenchen.de/fdsnws/station/1/query?network=Z3&station=A271A&channel=???&level=response
https://erde.geophysik.uni-muenchen.de/fdsnws/station/1/query?network=Z3&station=A272A&channel=???&level=response
https://erde.geophysik.uni-muenchen.de/fdsnws/station/1/query?network=Z3&station=A273A&channel=???&level=response

These are stations, for which I had downloaded data in recent years, but the metadata is not available now
Z3.A268A
Z3.A269A
Z3.A270A
IV.T0110
CR.KIJV
CR.KALN
CR.NVLJ
CR.PLIT
CR.PTJ
CR.UDBI

Here it looks like the PaZ are agiven in HERTZ, but the units are given as RADIANS – this issue has already been discussed for IV.VINO, see #68. It affects the Guralp sensor epochs.
https://webservices.ingv.it/fdsnws/station/1/query?net=NI&station=VINO&channel=???&level=response
https://webservices.ingv.it/fdsnws/station/1/query?net=IV&station=EMAS&channel=???&level=response
https://webservices.ingv.it/fdsnws/station/1/query?net=IV&station=IPSM&channel=???&level=response
https://webservices.ingv.it/fdsnws/station/1/query?net=IV&station=EBDA&channel=???&level=response

Here all channels are closed the latest in 2017, but the Station has endDate= 2500, it is not wrong in principle, just a question if the station is still in place after not recording for 8 years?
http://ws.resif.fr/fdsnws/station/1/query?network=FR&station=CORF&channel=???&level=response
This is actually frequent issue, see e.g.
http://ws.resif.fr/fdsnws/station/1/query?network=FR&station=FLAF&channel=???&level=response

Here the same issues combines with a change of a network code, so then the two Station epochs overlap for the two networks as FR.ILLK has Station open till 2500 and FO.ILLK started in 2016 according to the Station element, and in 2021 according to the channel element
http://ws.resif.fr/fdsnws/station/1/query?network=FR&station=ILLK&channel=???&level=response
http://ws.resif.fr/fdsnws/station/1/query?network=FO&station=ILLK&channel=???&level=response
The same for FR.BETS and FO.BETS (where FR.BETS Station continues to 2500 and channels are closed to 2021 while FO.BETS Station starts in 2012 and channels start in 2021) and for FR.OPS and FO.OPS (FR channels closed in 2021, Stations continues to 2500 and FO channels started in 2021 and FO Station started in 2009). Shortly, the channel epoch are following each other OK, but the Station epochs overlap.
http://ws.resif.fr/fdsnws/station/1/query?network=FR&station=BETS&channel=???&level=response
http://ws.resif.fr/fdsnws/station/1/query?network=FO&station=BETS&channel=???&level=response
http://ws.resif.fr/fdsnws/station/1/query?network=FR&station=OPS&channel=???&level=response
http://ws.resif.fr/fdsnws/station/1/query?network=FO&station=OPS&channel=???&level=response

Here it is the opposite: Station is closed, but channels are open. This creates an issue, as such a station is then not listed in EIDA as open station, and is not listed in _ADARRAY virtual network, as the virtual network is based on the Station element, and HC.KOSP hence looks like closed.
http://eida.gein.noa.gr/fdsnws/station/1/query?net=HC&station=KOSP&channel=???&level=response

Streams with problems from GEOFON have been moved to #171
This station has similar issue. The are several Station elements. One of them is open, as are the channels in there, but there are other Station elements which have closed epochs. It is again maybe not wrong, but it is dangerous, as one needs to go through all the Station element to find out if one is still open. Having one Station element sounds like a safe solution.
http://geofon.gfz-potsdam.de/fdsnws/station/1/query/?net=HU&station=BEHE&channel=???&level=response

The channels are named BH* here, but the sensor looks like a short-period with a corner period below 10 s
https://geofon.gfz-potsdam.de/fdsnws/station/1/query/?net=SJ&station=SVIS&channel=???&level=response

Here there are only SP epochs included, but there is a BB sensor installed too (and hence the station is not listed in the _ADARRAY)
http://geofon.gfz-potsdam.de/fdsnws/station/1/query/?net=SK&station=LANS&channel=???&level=response

AC.LSK – epochs open since 2010, but there were some malfunctions and hence the epochs could be closed
https://webservices.ingv.it/fdsnws/station/1/query?net=AC&station=LSK&channel=???&level=response

Here the instrumentation was upgraded by temporary BB deployment, but epochs are not
https://webservices.ingv.it/fdsnws/station/1/query?net=AC&station=BERA&channel=???&level=response
https://webservices.ingv.it/fdsnws/station/1/query?net=AC&station=LACI&channel=???&level=response
https://webservices.ingv.it/fdsnws/station/1/query?net=AC&station=LSK&channel=???&level=response
https://webservices.ingv.it/fdsnws/station/1/query?net=AC&station=PHP&channel=???&level=response
https://webservices.ingv.it/fdsnws/station/1/query?net=AC&station=TPE&channel=???&level=response

These stations are not in EIDA yet
AC.SDA
Z6.DRME
Z6.KOME
Z6.ULC
Z6.GJIK
Z6.SMRK
Z6.ZATK
7B.7422
7B.7433
7B.7440
7B.7442
7B.7443
7B.7445
7B.7489
7B.7491
7B.7493
7B.7496
7B.7498
7B.7499
7B.7500
7B.7501
7B.7502

[megies]

is -90 for the HHE channel in 2015-2016 and 2016-2020 epochs, but should be rather 0
https://erde.geophysik.uni-muenchen.de/fdsnws/station/1/query?network=BW&station=GELB&channel=???&level=response

Thanks, fixed in our metadata, will get updated in our FDSNWS shortly

[aschloem]

Z3.A260-Z3.A267A and Z3.A271A-Z3.A273A:

In 2016 KRSO in Budapest occupied 11 AlpArray sites (A260A - A270A) in western Hungary and 3 AlpArray sites were occupied by ETH-Zurich (A271A - A273A).
In 2019, LMU replaced 8 KRSO stations (Z3.A260-Z3.A267A) and all 3 ETH-stations (A271A - A273A).
You can find the corresponding data and metadata on erde.geophysik.uni-muenchen.de since 2019.
Older metadata for ETH stations (A271A - A273A) are here (with missing end time):
https://eida.ethz.ch/fdsnws/station/1/query?&net=Z3&format=text&station=A27*
and for KRSO station(A260A - A270A):
https://orfeus-eu.org/fdsnws/station/1/query?&net=Z3&format=text&station=A2*

[PetrColinSky]

@megies Thanks, Tobias, sorry for my bad edit, you got the point, it was Dip = -90.
@aschloem Thanks, Antje. For some reason, I did not get the older epochs when downloading the xml with fdsn.get_stations some weeks ago, and today, I wrongly looked at only the LMU node. All works for me now.
A271A and A272A have a 1.5 yr gap between the epochs anyway, but maybe indeed these were not working meanwhile (?)
A271A at ETH has the epoch closed 2017-10-31
http://eida.ethz.ch/fdsnws/station/1/query?net=Z3&station=A271A&channel=???&level=response
and at LMU it starts 2019-05-08
https://erde.geophysik.uni-muenchen.de/fdsnws/station/1/query?network=Z3&station=A271A&channel=???&level=response
Similarly for A272A.
For A273A, and for A260A-A267A the epochs are following each other smoothly.

[aschloem]

Yes, the locations A271A and A272A were not equipped with instruments between 2017 and 2019.

[xrise75]

Metadata for HL.DION and HC.KOSP concerning EIDA@NOA are fixed.