Open jschaeff opened 1 month ago
Concerning stations RUSF and ASEAF, there are censors more distant than the recommandation. But it is a well known situation there will not be any fix for this metadata.
Concerning the stations in G, the metadata producers have been reached in order to see if they need to fix something.
This is the RESIF part of issues reportes in #166 and #167
I present the results from detailed tests of formal consistency of the StationXML files, see https://github.com/PetrColinSky/DataQuality/tree/master/ludekvecsey for description and result tables. The tests are a part of data and metadata quality tests prepared by participants of the AdriaArray Seismology group jointly with the ORFEUS User Advisory Group, see the summary of tests and the first issue opened by @PetrColinSky.
The metadata tests include validating the FDSN StationXML format, a set of controls from IRIS StationXML Validator and other tests, including checking station response, corner periods, band codes. The metadata files for this test were downloaded from EIDA on June 7, 2024 (thus some issues can already be fixed).
The station/network operators can find the maximum severity level on each station in the report file QC_AdA_severity_levels_240607.csv. The report consists of three columns: station; max severity in 2022+ epoch; max severity over all epochs. Severity levels are -1 (the station was checked and everything was ok), 0 (not important, notification about input or output units given in the wrong upper/lower case), 1 (other not important notifications), 2-3 (warnings), and 4-5 (errors). The detailed report of all issues of levels 1-5 is found in QC_AdA_metadata_issues.xlsx, see the sheet named 240607. If you would like more descriptions and remarks, please take a look at the Legend sheet.
The following part shows only the worst issues (levels 4-5). Go to QC_AdA_metadata_issues.xlsx for a complete list of issues. A header for columns shown bellow is: STATION;VALID_FROM;VALID_TO;ISSUE_ID;ISSUE_SEVERITY_LVL;ISSUE_DESCRIPTION;COMMENTS
Station and Channel Latitudes/Longitudes/Elevations differ too much:
Invalid InputUnits for given Instrument code:
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