[obspy-users] iris web services client - anyone see this problme recently?

Lion Krischer krischer at geophysik.uni-muenchen.de
Wed Jul 8 23:05:44 CEST 2015

Hi all,

> The obspy team shouldn't write interfaces to all IRIS services, but
> keeping a web services client like obspy.iris that at least partially
> integrates with obspy is a good idea. Many users appreciate access to
> the non-fdsn IRIS services. At some point use of the MUSTANG services is
> going to catch on (if it hasn't already).

Talking about Mustang: Like a year ago I wrote an `obspy.mustang` module but got stuck because I could not find a way to properly specify constraints when requesting multiple metrics at once.

For example here I would like to request the `max_stalta` metric with values larger then 10 and the `clock_locked` metric with values larger than 4000. In my tries it always applies the constrains to all requested metrics simultaneously.


Is the recommended procedure in these cases then to submit multiple requests or is there a way I am missing?

> I imagine there are two parts to a client - building requests and
> unpacking the responses. I have not followed all the code of an obspy
> client through. Is it possible to open up the part of obspy.iris that
> builds a web-service request? That's tedious coding (if you add urllibs,
> error checking and reporting, etc.) that is already robustly complete in
> obspy.
> You can leave the unpacking of non-fdsn services to the user. With a
> generic WS interface available, a user can acquire the raw server
> response using the client argument "filename=io.BytesIO()" and pull
> apart the xml, etc. That's what I usually do with stations and channels
> now anyway. Then I can construct dictionaries with exactly the
> information I need, not what obspy unpacks.
> I guess that I am thinking of something like:
> irisClient = obspy.iris.Client()
> myOutput = irisClient(service="mustang/measurements",metric="Sample
> RMS", ...,format=json,filname=io.BytesIO())

As Elliot already stated we have no intention of removing the still working parts of obspy.iris. Nonetheless what you intend to do here is just much simpler to do with a specialized package like this one: http://docs.python-requests.org

The advantage one gains by using ObsPy to do it is that we parse it to our internal representations which in the case of Station XML and QuakeML are fairly involved operations. Our internal objects don’t loose any information and its possible to round trip between file and object.

Out of curiosity: In what cases is it simpler to parse the XML files by yourself to create a dictionary instead of using the ObsPy classes and creating the dictionaries from them? We are always willing to make ObsPy easier to use :-)



More information about the obspy-users mailing list