FDSN webservices

The International Federation of Digital Seismograph Networks (FDSN) has defined web services for accessing waveform, station and event information. The FDSN specification defines THE defacto international standard allowing users to retrieve waveform data, response data, and station metadata through HTTP in a universally consistent format and language. AusPass is one of many data centres adopting FDSN webservices, with other notable examples being IRIS (USA), SCEDC (USA), ISC (UK), Orfeus (Europe), GEOFON (Germany), and Geonet (New Zealand), as well as many others. Other national networks not on that list, such as Geoscience Australia (GA), offload their data to IRIS for them to host.

How to access AusPass data


AusPass uses this address to support our FDSN archive service implementation: http://auspass.edu.au:8080 (or just :80 works too). If you are accessing via ObsPy, or any other software that interfaces with FDSN, that's the only address you'll have to enter and you'll be good to go.

From that address we provide following FDSN webservices:

Fundamentally, one can access all these services (except Event) by simply building a URL query that can be inserted into your web browser's address bar, with examples below. It's that easy! The links above provide convenience URL builders as well. More complicated and/or repeated requests can be easily scripted with utilities such as wget or curl, or preferrably via a client tool which is written expliclity with this task in mind (see our ObsPy tutorial).

Example

This example shows how to download the waveform data (in miniSEED format) recorded after the Samoa earthquake (29 September 2009 at 17h48) at BILBY stations in central Australia. In your browser, type:

http://auspass.edu.au:80/fdsnws/dataselect/1/query?net=6F&sta=*&cha=BHZ&start=2009-09-29T17:50:00&end=2009-09-29T18:50:00

Element of the data request Meaning
http://auspass.edu.au:8080/ Server name (AusPass website serving data on port 80/8080)
fdsnws/FSDN Web Services on that server
dataselect /1/Data retrieval services (use "station/1/" to retrieve station metadata and "event/1/" for event metadata)
queryA query!
? Marks the end of the website adress serving the data
&Separates the arguments to select AusPass data
net=6F Seismic network "6F" (BILBY)
sta=* Select all stations in BILBY array, central Australia
cha=BHZVertical broadband channel (also available: BHN and BHE, all broadband channels can be selected with cha=BH?)
start=2009-09-29T17:50:00.000Data start time using ISO standard date and time format
end=2009-09-29T18:50:00.000Data end time using ISO standard date and time format


Also need station metadata and response? Build a station query in the same way:
http://auspass.edu.au:8080/fdsnws/station/1/query?network=6F&level=response&nodata=404

Note that we've set "level" to "response" in order to include both station positions AND response information, for all sites in network 6F.

Another example... lets look at ALL the stations we have online, and have it presented in simple text!
http://auspass.edu.au:8080/fdsnws/station/1/query?network=*&level=channel&format=text&nodata=404

Note that we've now set the level to "channel" and format to "text". Channel provides a bit more information regarding equipment and individual channel info etc. The simplest level is "station" which is more fundamental. Try both out (e.g. change to: level=station) and see the difference yourself.

Wildcards can generally be used as well. Clobber * can be used to substitute any amount of characters, a question mark ? for a single character.

Recommendations


The AusPass team does its best to maintain fast and efficient webservices.

However, it is recommended not to request too much data in a single request. The larger the request, the longer it takes to complete. If a large request fails, it will have to be resubmitted. You can break a large request into smaller ones. Then, if a failure occurs, you will just have to resubmit the small request. Webservice connections can break if no data is transmitted after 5-10 minutes. Therefore, do not rely on requests that could take more than 5-10 minutes to begin returning data.

On the other hand, for performance reasons, do not to make lots of very small data requests. Be aware that every time a request is made, a new connection is established and the associated processing overhead will slow the response.

Best practice is to group requests by time period (one request for several stations, but one time period - see above example) or station (one request for several time periods, but one station).

Our sponsors:

AuScope and ANU logos