- Data and Services
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.
Limitations of the present beta version are:
- only non-restricted
waveform data may be downloaded.
- fdsn-station using the federator will
only distribute metadata from datacenters that export stationXML1.0 (presently
all datacenters, except RESIF)
The Federator is released in January 2020 as a beta version. Users are
encouraged to try it out and provide feedback to
using the Template specifically created for the Federator.
The following services are exposed:
When should I use the federator, rather than the individual EIDA nodes?
Use the federator, if you want to
explore the entire EIDA inventory (station) or access QC information
- explore and download (unrestricted) data from virtual networks
download unrestricted data that you know is distributed over multiple EIDA
(e.g. "all stations with HH* channels available in the greater alpine
download unrestricted data and you are not sure which node it is archived
Use an individual node, if you want to
- download restricted data (targeting each node separately)
download unrestricted data which you know is at a single EIDA node
(e.g. all waveforms of network GE are hosted at GFZ, thus with a request
for all waveforms recorded in the GE network during an event last Monday,
go to GFZ's dataselect service)
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 datacenters
direct support for virtual networks (though it does not
deliver restricted data): e.g
ideal for handling large data requests: it bypasses request
size limitations of the individual data centers, and includes 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 station data requests may be significantly
slower via federator than submitting individual queries to individual data
(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
does not support restricted datasets: the federator does
not support authentication by tokens, for these requests, the nodes must be
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
no support for different versions of stationXML: For
fdsnws/station the federator currently does not support stationXML 1.1 (text
and stationXML 1.0 only), nor data centers supporting stationXML in the 1.1
data is actualy passing from nodes through the federator to the
user:, even if the user sits next to the node. This is not optimal, we should
think about it knowing the environmental impact of data through the network.
If you experience any issues with requests to eida-federator.ethz.ch, you are
encouraged to file a bug report at [[https://github.com/EIDA/userfeedback/]] using the template named "Federator".
Point of Contact: Philipp Kästli