The fdsnws-dataselect service provides access to time series data for specified channels and time ranges.
Data are selected using SEED time series identifiers (network, station, location & channel) in addition to time ranges. Data are returned in miniSEED format.
This service is an implementation of the FDSN web service specification version 1.
To retrieve raw waveform data in miniSEED format, submit a request by either of two methods:
This service is designed to handle very large data requests1 and can easily be used with command line programs such as wget, curl or similar utilities.
A data selection is composed of a list of network, station, location, channel, start time and end time entries. Channel codes follow the conventions documented in Appendix A of the SEED Manual. The IRIS DMC has reproduced the appendix for an accessible SEED channel naming refrence.
Optional parameters that may be specified:
An example selection, submitted using HTTP POST, might look like:
TA A25A -- BHZ 2010-03-25T00:00:00 2010-04-01T00:00:00 IU ANMO * BH? 2010-03-25T00:00:00 2010-04-01T00:00:00 IU ANMO 10 HHZ 2010-03-25T00:00:00 2010-04-01T00:00:00 II KURK 00 BHN 2010-03-25T00:00:00 2010-04-01T00:00:00
Requests can be made with a selection file and the wget
Unix command line utility.
$ cat waveform.request quality=B TA A25A -- BHZ 2010-03-25T00:00:00 2010-04-01T00:00:00 TA A25A -- BHE 2010-03-25T00:00:00 2010-04-01T00:00:00
$ wget --post-file=waveform.request -O TA.miniseed http://server.local:port/fdsnws/dataselect/1/query
The "server.local" and "port" should be adjusted to the location of the local service.
This will send the request to the server and save the results in a file name TA.miniseed
Requests can also be made with a selection file and the curl
Unix command line utility.
$ cat waveform.request quality=B TA A25A -- BHZ 2010-03-25T00:00:00 2010-04-01T00:00:00 TA A25A -- BHE 2010-03-25T00:00:00 2010-04-01T00:00:00
$ curl -L --data-binary @waveform.request -o TA.miniseed http://server.local:port/fdsnws/dataselect/1/query
The "server.local" and "port" should be adjusted to the location of the local service.
Here is the equivalent request using query parameters instead of a selection file…
$ curl -L -o TA.miniseed "http://server.local:port/fdsnws/dataselect/1/query?net=TA&sta=A25A&cha=BHZ,BHE&loc=--&starttime=2010-03-25&endtime=2010-04-01"
This will send the request to the server and save the results in a file name TA.miniseed
We recommend always using the -L
option to allow curl to follow HTTP redirections specified by our systems. The DMC uses HTTP redirection during maintenance to keep servicing requests.
You may wish to use the -f
option. This will cause curl to return an exit code of 22 if data is not found or the request is improperly formatted.
See http://curl.haxx.se/docs/manpage.html for more information.
A variety of software tools are available from the DMC to assist with organizing and viewing miniSEED data or converting it to another format. Detailed descriptions and usage examples for each piece of software can be found by clicking the links below.
mseed2sac – for converting miniSEED to SAC format
mseed2ascii – for converting miniSEED to ASCII formats
dataselect – for selecting and sorting miniSEED
miniSEED Inspector – for quickly parsing and summarizing miniSEED data
1 In general, it is preferable to not ask for too much data in a single request. Large requests take longer to complete. If a large request fails due to any networking issue, it will have to be resubmitted to be completed. This will cause the entire request to be completely reprocessed and re-transmitted. By breaking large requests into smaller requests, only the smaller pieces will need to be resubmitted and re-transmitted if there is a networking problem. Web service network connections will commonly time out and break after some number of minutes if no data is transmitted.
Conversly, it is less efficient to ask for too little data in each request. Each time a request is made, a network connection must be established and a request processing unit started. For performance reasons, it is better to group together selections from the same stations and place them in the same request. This is especially true of selections that cover the same time periods.