Add initial support for alternate servers or URLs supported by obspy

[timgunter]

This change allows users to sonify data from networks like the raspberryshake network.

[liamtoney]

Thanks for this improvement, Tim. ObsPy actually implements a wrapper around the "IRIS Federator" routing client. This routes data requests to the applicable server. I haven't gotten around to implementing this in sonify, but the change would be simply importing the RoutingClient via

from obspy.clients.fdsn import RoutingClient

and then changing the client definition on line 125 to

client = RoutingClient('iris-federator')

In theory this should accomplish the same thing as allowing users to supply their own server via Client(server). I've tested this on the RASPISHAKE server. Can you test this solution and see if it fits your needs? I'd prefer it over adding another user option.

[timgunter]

When I use the RoutingClient, I get issues with the call to get_waveforms():

  File "/home/tgunter/.local/bin/sonify", line 33, in <module>
    sys.exit(load_entry_point('sonify===4668e9b', 'console_scripts', 'sonify')())
  File "/home/tgunter/.local/lib/python3.10/site-packages/sonify/sonify.py", line 728, in main
    sonify(
  File "/home/tgunter/.local/lib/python3.10/site-packages/sonify/sonify.py", line 132, in sonify
    st = client.get_waveforms(
TypeError: BaseRoutingClient.get_waveforms() takes 3 positional arguments but 7 were given

I tried changing the args to get_waveforms() to kwargs, but got issues with the attach_response arg. I tried a few other things, and received other issues.

  File "/home/tgunter/.local/bin/sonify", line 33, in <module>
    sys.exit(load_entry_point('sonify===4668e9b', 'console_scripts', 'sonify')())
  File "/home/tgunter/.local/lib/python3.10/site-packages/sonify/sonify.py", line 728, in main
    sonify(
  File "/home/tgunter/.local/lib/python3.10/site-packages/sonify/sonify.py", line 132, in sonify
    st = client.get_waveforms(
  File "<decorator-gen-54>", line 2, in get_waveforms
  File "/home/tgunter/.local/lib/python3.10/site-packages/obspy/clients/fdsn/routing/routing_client.py", line 78, in _assert_filename_not_in_kwargs
    return f(*args, **kwargs)
  File "<decorator-gen-53>", line 2, in get_waveforms
  File "/home/tgunter/.local/lib/python3.10/site-packages/obspy/clients/fdsn/routing/routing_client.py", line 84, in _assert_attach_response_not_in_kwargs
    raise ValueError("The `attach_response` argument is not supported")
ValueError: The `attach_response` argument is not supported

[liamtoney]

Ah, I see it here, in the docs for FederatorRoutingClient.get_waveforms():

The filename and attach_response parameters of the single provider FDSN client are not supported.

I didn't think to check that. That's unfortunate — otherwise, with the kwargs change you noted, this would have worked.

It's possible to grab the response information via FederatorRoutingClient.get_stations(), I'll look into that briefly. If that doesn't work or adds too much complexity, I think we can move forward w/ this PR's approach.

[liamtoney]

Okay, I've implemented the changes w/ a response retrieval fix in a new branch routing-client. @timgunter could you please give that branch a spin and let me know how it works for you?

NOTE: Currently the ObsPy routing client does not work for the RASPISHAKE data center. I actually discovered this while testing the sonify modification. I've made an issue, https://github.com/obspy/obspy/issues/3126, for this. In the meantime, if you'd like to try RASPISHAKE stations, you'll need to modify this line from

            if "http://" in line:

to

            if "http" in line:

On the routing-client branch, with the above ObsPy fix made, I was able to run sonify for a Raspberry Shake station:

sonify AM RAF63 EHZ 2022-05-04T23:10 2022-05-05T00:00 --freqmin 1 --freqmax 23 --speed_up_factor 200 --fps 1 --spec_win_dur 8

[liamtoney]

I've made an issue, obspy/obspy#3126, for this.

Now I've made a PR: https://github.com/obspy/obspy/pull/3127

[liamtoney]

Now I've made a PR: obspy/obspy#3127

PR is now merged

[liamtoney]

Now I've made a PR: obspy/obspy#3127

ObsPy 1.3.1 is now out. Re-building the conda environment (so as to get the new ObsPy) and running the example from RAF63 works as expected.

[liamtoney]

Hi @timgunter — as you can see I've gone ahead and made a PR for the alternative approach I proposed in the routing-client branch. Once I merge that PR (soon) this one will be closed.

Please give the updated code a try and if you encounter any issues with data access, we can re-open this. Thanks for this suggestion!