I'm writing some code to retrieve data from IRIS, and have found that
while I can use the fdsn module to get the waveform data, I still need
to use the iris module to get response data and other station metadata
(resp() and sacpz()).
Whenever I import the iris module, I get a DeprecationWarning saying
that I should consider moving all of my code to use fdsn.
Question 1: Are there fdsn equivalents to iris.resp() and iris.sacpz()?
Question 2: If not, should I be getting a DeprecationWarning whose
advice I cannot yet take?
Question 1: Yes and no. For resp() you can instead rely on StationXML
(see bottom of the page Lion pointed to). For sacpz(), if you really
need that I do not think there is an equivalent using FDSNWS.
Question 2: Indeed, this general DeprecationWarning might be a bit too
harsh, as it seems that these few still operating "old" IRIS web
services are not going to be discontinued any time soon.. anyway, you
can use the following if the warning annoys you:
from obspy.iris import Client
import warnings
with warnings.catch_warnings(record=True):
client = Client()
When I use obspy.core.read to read this data file, no error is reported but the stream only contains 9 traces, whereas there are many more than that in the SEED file. I tried also using an Ubuntu machine (with obspy 0.8.3), but when I try reading it I get the error messages listed below.
I also used the antelope program miniseed2db, and that succcessfuly extracts 520 channels form the SEED file. Does anyone have any idea what might be wrong?
Thanks,
- Phil
(Canopy 64bit) pcummins@compute2:/scratch/compute2/phil/chile$ ipython
Python 2.7.3 | 64-bit | (default, Mar 25 2013, 15:55:17)
Type "copyright", "credits" or "license" for more information.
IPython 1.0.dev -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help -> Python's own help system.
object? -> Details about 'object', use 'object??' for extra details.
In [1]: from obspy.core import read
In [2]: st = read('2010-02-27_MW8.8_Near_Coast_Of_Central_Chile.420772.seed')
I also had a look. The problem is actually with the file. Some records just contain a random (or empty) sequence of bytes, nothing else. At this point we would have to make a guess when the next “proper” record starts. If we assume that each record has the same length, that would be possible in this particular case but not in general as each record can have a different size according to the standard. Furthermore I don’t think it is ObsPy’s responsibility to recover from erroneous files.
Where did you get the file? If it is something common, we might have to support it.
ObsPy actually did not report the errors it encountered. It is fixed now and will be part of the next release. To use it now you would have to update to our development version. It then prints nice error messages that can also be used to diagnose the file.
Thanks for having a look. It came straight from IRIS DMC. It tried transferring it a couple of times and checked the byte count. I will try again. I wouldn’t worry about it unless more SEED files show up like this. I will try just requesting the data again. Many thanks,