You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
dear all,
Luděk and me noticed that for temporary stations installed by our group in various countries, the PaZ stage is empty and some stages are missing when StationXML is downloaded from EIDA, while everything was correct when sending the metadata to EIDA. We have data and metadata stored at 3 EIDA nodes. At LMU everything is correct, at ODC and NIEP things are missing. From our side, all StationXMLs are treated the same way.
Here a documentation on examples of two stations:
Z3.A080A + Z6.A080A
Station A080A was recording as in the Z3 network and moved to Z6 network in 2022. With this change, also the EIDA node was changed from ODC to LMU.
Here is the original StationXML as sent to ODC (correct): Z3.A080A_orig.zip
Here is what you get when downloading the XML from ODC (things missing in there): Z3.A080A_ODC.zip
The same can be found here: https://www.orfeus-eu.org/fdsnws/station/1/query?net=Z3&station=A080A&channel=???&level=response
A report of the differences is here: Z3.A080A.pdf
To summarize the differences directly for Z3.A080A..HHZ response:
1.stage (sensor P&Z)
EIDA: no poles and zeros values!
2.stage (datalogger analogue filter)
missing in EIDA!
3.stage (ADC)
only different numbering, ok
4.stage (datalogger decimation)
different numbering
orig: with 10 numerators
EIDA: with 5 numerators and Symmetry=EVEN (I hope it has the same response as in the original stage)
The second example is about Y8.AVR stored at NIEP. This has no counterpart at other EIDA node, and the problem seems to be similar as in the ODC case above.
Here is the original StationXML sent to NIEP: Y8.AVR_orig.zip
Here follows the XML downloaded from NIEP - PaZs are missing in there and in addition to the ODC example, also one more stage is missing here: Y8.AVR_NIEP.zip
The same XML can be found here: https://eida-sc3.infp.ro/fdsnws/station/1//query?net=Y8&station=AVR&channel=???&level=response
A report of the differences follows: Y8.AVR.pdf
This problem here was discussed already with the respective persons at NIEP and ODC, so it should not come as a surprise. We set this issue here to document it properly. It concerns ALL the stations we have in ODC and NIEP, which is 22 stations in ODC and 18 in NIEP. LMU node is mentioned here only as a reference, there is no issue with LMU.
We think the problem is connected with how the original XML file is treated with SeisComP, or how then the request from the user is handled.
cheers
Luděk and Petr
IG CAS CZ
The text was updated successfully, but these errors were encountered:
Finally, we found out what had happened (thank @cristianneagoe for help). We were sending StationXML metadata to the EIDA with Zeros and Poles with no 'number' attributes. It is correct in FDSN StationXML but the 'number' attribute is mandatory in SeisComP StationXML! When we added this attribute to our metadata and sent this updated version of metadata to the EIDA, the issue with no zeros and poles disappeared.
It looks like a small trap for station operators - before sending metadata to the EIDA, we should validate our StationXML not only for the FDSN XML schema (XSD) but also for SeisComP one. As I do not have any experience with SeisComP, is possible to download SeisComP XSD anywhere? Or how to validate our metadata (without installing the whole SeisComP)?
dear all,
Luděk and me noticed that for temporary stations installed by our group in various countries, the PaZ stage is empty and some stages are missing when StationXML is downloaded from EIDA, while everything was correct when sending the metadata to EIDA. We have data and metadata stored at 3 EIDA nodes. At LMU everything is correct, at ODC and NIEP things are missing. From our side, all StationXMLs are treated the same way.
Here a documentation on examples of two stations:
Z3.A080A + Z6.A080A
Station A080A was recording as in the Z3 network and moved to Z6 network in 2022. With this change, also the EIDA node was changed from ODC to LMU.
Here is the original StationXML as sent to ODC (correct):
Z3.A080A_orig.zip
Here is what you get when downloading the XML from ODC (things missing in there):
Z3.A080A_ODC.zip
The same can be found here:
https://www.orfeus-eu.org/fdsnws/station/1/query?net=Z3&station=A080A&channel=???&level=response
A report of the differences is here:
Z3.A080A.pdf
To summarize the differences directly for Z3.A080A..HHZ response:
Almost the same StationXML was sent to LMU. It differs only by the epoch. The instrument is the same. Here is the original XML:
Z6.A080A_orig.zip
Here is the XML downloaded from LMU, everything is correct in there:
Z6.A080A_LMU.zip
The same XML can be found here:
https://erde.geophysik.uni-muenchen.de/fdsnws/station/1/query?network=Z6&station=A080A&channel=???&level=response
All PaZs are in there. There is still a small difference, which, however, does not affect the use of the XML. Detailed report is here:
Z6.A080A.pdf
The second example is about Y8.AVR stored at NIEP. This has no counterpart at other EIDA node, and the problem seems to be similar as in the ODC case above.
Here is the original StationXML sent to NIEP:
Y8.AVR_orig.zip
Here follows the XML downloaded from NIEP - PaZs are missing in there and in addition to the ODC example, also one more stage is missing here:
Y8.AVR_NIEP.zip
The same XML can be found here:
https://eida-sc3.infp.ro/fdsnws/station/1//query?net=Y8&station=AVR&channel=???&level=response
A report of the differences follows:
Y8.AVR.pdf
This problem here was discussed already with the respective persons at NIEP and ODC, so it should not come as a surprise. We set this issue here to document it properly. It concerns ALL the stations we have in ODC and NIEP, which is 22 stations in ODC and 18 in NIEP. LMU node is mentioned here only as a reference, there is no issue with LMU.
We think the problem is connected with how the original XML file is treated with SeisComP, or how then the request from the user is handled.
cheers
Luděk and Petr
IG CAS CZ
The text was updated successfully, but these errors were encountered: