The EIDA federator – a one-stop access to EIDA seismic data holdings

With the setup of EIDA (the European Integrated Data Archive https://www.orfeus-eu.org/data/eida/) in the framework of ORFEUS, and the implementation of FDSN-standardized web services, seismic waveform data and instrumentation metadata of most seismic networks and data centers in Europe became accessible in a homogeneous way. EIDA has augmented this with the WFcatalog service for waveform quality metadata, and a routing service to find out which data center offers data of which network, region, and type. However, while a distributed data archive has clear advantages for maintenance and quality control of the holdings, it complicates the life of researchers who wish to collect data archived across different data centers. To tackle this, EIDA has implemented the “federator” as a one-stop transparent gateway service to access the entire data holdings of EIDA.

To its users the federator acts just like a standard FDSN dataselect, station, or EIDA WFcatalog service, except for the fact that it can (due to a fully qualified internal routing cache) directly answer data requests on virtual networks.

Technically, the federator fulfills a user request by decomposing it into single stream epoch requests targeted at a single data center, collecting them, and re-assemble them to a single result.

This implementation has several technical advantages:

• It avoids response size limitations of EIDA member services, reducing limitations to those imposed by assembling cache space of the federator instance itself.
• It allows easy merging of partial responses using request sorting and concatenation, and reducing needs to interpret them. This reduces computational needs of the federator and allows high throughput of parallel user requests.
• It reduces the variability of requests to end member services. Thus, the federator can implement a reverse loopback cache and protect end node services from delivering redundant information and reducing their load.
• As partial results are quick, and delivered in small subunits, they can be streamed to the user more or less continuously, avoiding both service timeouts and throughput bottlenecks.

The advantage of having a one-stop data access for entire EIDA still comes with some limitations and shortcomings. Having requests which ultimately map to a single data center performed by the federator can be slower by that data center directly. FDSN-defined standard error codes sent by end member services have limited utility as they refer to a part of the request only. Finally, the federator currently does not provide access to restricted data.

Nevertheless, we believe that the one-stop data access compensates these shortcomings in many use cases.

Further documentation of the service is available with ORFEUS at http://www.orfeus-eu.org/data/eida/nodes/FEDERATOR/