The EIDA Federator provides a single, unified access point to the
waveform archives and the station and quality control information from the
entire EIDA data holdings, i.e. from all the datacenters in EIDA. Access is
through standard FDSN and EIDA web services.
A limitation of the present version is that only non-restricted waveform data
may be downloaded.
The following services are exposed:
When should I use the Federator instead of other approaches?
Although that there are smart clients supporting data access and discovery for
EIDA as a federation (e.g.
Obspy,
fdsnws_fetch),
some of the main benefits of using the Federator are that:
-
it is the only FDSN web service compliant entry point for all EIDA data
holdings,
- the user does not need to install any software package,
- it is available from any OS,
-
it is compatible with any tool supporting FDSN web service interoperability.
Use the Federator, if you want to
-
explore the entire EIDA inventory (fdsnws-station) or access QC information
(eidaws-wfcatalog),
- explore and download (unrestricted) data from virtual networks,
-
download unrestricted data that you know is distributed over multiple EIDA
nodes
(e.g. "all stations with HH* channels available in the greater alpine
area"),
-
download unrestricted data and you are not sure which node it is archived
at.
Advantages of using the Federator:
-
a one-stop-shop for all EIDA holdings: it returns all data
using a single request, independently of which datacenter is curating it,
and whether it is distributed over multiple data centres.
-
direct support for virtual networks (though it does not
deliver restricted data): e.g.
https://federator.orfeus-eu.org/fdsnws/station/1/query?network=_ALPARRAY&level=station&format=text.
-
ideal for handling large data requests: it has its own
maximum limits (quite high) for requests received and these will not be
limited by the ones configured at the endpoints, as the incoming requests
will be split in smaller pieces. Requests to the Federator also benefit from
caching, traffic shaping and load balancing across nodes.
Disadvantages of using the Federator
-
may be slower than direct access: a request that covers
multiple EIDA nodes is limited by the completion of the slowest contributing
node's subtask. Complex queries covering many data centers may take some
time to process. Especially large fdsnws-station data requests may be
significantly slower via the Federator than submitting individual queries to
individual data centers
(e.g. requesting the response information of all HHE and HHZ stations
operated in Europe at some random date of last year may take up to 3-8
minutes, depending on available caches and the background work load of the
national nodes:
https://federator.orfeus-eu.org/fdsnws/station/1/query?network=*&station=*&channel=HHE,HHZ&start=2019-03-09&end=2019-03-10&level=response&format=xml)
-
does not support access to restricted datasets: the
Federator does not support authentication by tokens, for these requests, the
recommended smart clients (e.g.
Obspy,
fdsnws_fetch) should be
used.
-
in certain cases, HTTP response codes may be misleading:
The error codes defined for FDSN web services are poor in describing the
result of a distributed task. The Federator follows a best effort paradigm,
it rather tries to partially fulfil a request than telling you that a
request partially failed.
(e.g. if somebody is asking for waveforms of the Lake Geneva region,
partly hosted by INGV, RESIF and SED, but the SED fdsnws-dataselect node
is down in that very moment, the Federator will return the INGV and RESIF
contributions with status code 200, silently dropping the issue with
SED)
-
data is actually passing from EIDA nodes through the Federator to the
user:
even if the user sits next to the node.
Bug reports
If you experience any issues with requests to
https://federator.orfeus-eu.org, you
are
encouraged to file a bug report at
https://github.com/EIDA/userfeedback/issues
using the template named "Federator" (preferred) or describe the issue in an
e-mail to
eida_maint@gfz-potsdam.de
(alternative).
Point of
Contact: Philipp Kästli