FDSN ws assumes trimmed data output

[jmsaurel]

Hello,

When using FDSN dataselect as data source, it seems the code is expecting data trimmed to the nearest sample. I noted that trying to perform orientationCheck and crossTalk metrics, where the calculation was not possible because of different stream length returned for each channel.

However, the FDSN 1.1 webservice specification states that the dataselect shoud return samples starting on or after the starttime, and ending on or before the endtime. http://www.fdsn.org/webservices/FDSN-WS-Specifications-1.1.pdf

Using Obspy get_waveform method instead of the R getDataselect, I was able to download the data, and trim them to the nearest common data section. However, I lost the data quality flags in the process.

Otherwise, very interesting and great tool !!

Jean-Marie.

[krischer]

Using Obspy get_waveform method instead of the R getDataselect, I was able to download the data, and trim them to the nearest common data section. However, I lost the data quality flags in the process.

Semi-related comment: Most record level mini-SEED information is lost when parsing to an ObsPy Stream/Trace object. But as soon as you remove some samples from a record that information is probably void in any case as its just not defined on a per-sample level. ObsPy's get_X() methods all take a filename argument which dumps the raw file received from the web services to disc without touching it.

[gillian-earthscope]

jmsaurel - Do you have a specific example I can look at where orientationCheck and crossTalk are failing when they shouldn't be because of different stream lengths?

[jmsaurel]

@gillian-iris I don't remember exactly which station I tested but you can test any station from the IPGP EIDA secondary node : http://eida.ipgp.fr/fdsnws/dataselect/1/ . For example, use the following preference file and select the station alias WI for 2016.

eida-ipgp.txt

Jean-Marie.

[gillian-earthscope]

This behavior should be fixed now with ISPAQ version 1.1.0. The fix requires an update to the R IRISSeismic package, and you should be able to install this from CRAN by running run_ispaq.py -U. Alternatively, the IRISSeismic_1.4.6.tar.gz file is included on Github. Thank you for informing me about the problem.

[jmsaurel]

Gillian,

Perfect, thanks. The update worked like a charm.

Regards.

Jean-Marie.

On 07/06/2017 12:20 AM, Gillian Sharer wrote:

This behavior should be fixed now with ISPAQ version 1.1.0. The fix requires an update to the R IRISSeismic package, and you should be able to install this from CRAN by running |run_ispaq.py -U|. Alternatively, the IRISSeismic_1.4.6.tar.gz file is included on Github. Thank you for informing me about the problem.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/iris-edu/ispaq/issues/2#issuecomment-313261324, or mute the thread https://github.com/notifications/unsubscribe-auth/AVQx9r8yl-9leZ1UCYe-czN73ncrDFoeks5sLCg0gaJpZM4M7rZh.

--

Institut de Physique du Globe de Paris Observatoires Volcanologiques 1 rue Jussieu 75238 Paris Cédex 05 +33(0)183957437 France