Multiclient for making waveform requests to an arbitrary amount of clients based on a config and the requested SEED ID #3304
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
The motivation for this PR is automated workflows that work with waveform data from a changing set of stations with data being available through a variety of different means.
For data center hosted data, things like EIDA routing client or the IRIS FDSN Federator in many cases are sufficient to pull together data. However, often enough a mix of locally stored data (usually in SDS structures or similar well ordered directory trees) and also non public FDSN services (e.g. provided by non-public SeisComP instances) has to be queried to get all data combined in a certain automated analysis task.
The idea to make this task easy is for the user to specify all details once in a config file and then any obspy based workflow can simply rely on
MultiClient
with the given config file to handle all details of where from and how to fetch the data. In the configuration file an arbitrary amount of clients (currently of type FDSN, seedlink, SDS filesystem, but fully extensible in user code) can be specified, each one with their own set of initialization parameters (varying FDSN URLs, varying SDS directory trees) in combination with lookup information that maps SEED IDs to a certain specific client. The lookup can be based on simply the network code, or on station level (which can be useful e.g. if certain stations are not part of public servers and have to be pulled from file system).Still needs some minor tweaking, work on docs and adding some tests.
Example config:
Example usage
Why was it initiated? Any relevant Issues?
I have done this in one of my workflows for quite a while and recently when working on a new workflow decided to extract the concept and propose to put it into obspy properly to reduce code duplication and duplicated work.
PR Checklist
master
for new features,maintenance_...
for bug fixesno_ci
label can be added to skip CI buildsJust add the
build_docs
tag to this PR.Docs will be served at docs.obspy.org/pr/{branch_name} (do not use master branch).
Please post a link to the relevant piece of documentation.
clients.fdsn
) should be tested for the PR,just add the
test_network
tag to this PR.CHANGELOG.txt
.CONTRIBUTORS.txt
.from all the CI builds look correct. Add the "upload_plots" tag so that plotting
outputs are attached as artifacts.
CODEOWNERS
with your github handleready for review
label when you are ready for the PR to be reviewed.