Hi Lion,
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 will let Chad Trabant or someone from IRIS handle that - it's a good question and sounds like it may be a bug or design issue.
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
Thanks for pointing our the request package. I have used request, but was unaware that it handles the parameters so conveniently with a dictionary. Not as convenient as putting them into a call like the obspy clients, but certainly usable.
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.
I agree.
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
Simpler? No. Actually, I wrote it years ago, when your internal objects did ignore information in the XML (or at least I thought that they did). I can't remember when exactly, but below is an example of pulling apart some xml to show what I did (and do). Tedious, selective, and not the most robust code, but the result is a simple list-dictionary structure. The input is the XML from an fdsn.station request at a particular time (one station epoch is returned).
At some point python will change and this will break and I will not revise, but repackage from obspy objects as you suggest. I like to control my own data structures and keep them light-weight to simplify other parts of a workflow. I certainly don't do this kind of thing when I am working in a python notebook testing ideas. But when I write a script to run for days or weeks, I like to control things. And finally, this approach is not really dependent on obspy, I could make my own request and just call this to get my dictionary.
As to QuakeML - I have selectively parsed that in Objective-C and have no desire to wade into that monstrous schema, so I've always used obspy's event objects. I am not really a fan of XML.
Thanks for the response and the reminder about the request package.
def parse_stations_and_channels_from_xml(theXML):