.NETDC_REQUEST is necessary to identify the mail
document as a request intended for NetDC. This must always be
the first line of the request.
.NAME indicates the name of the user. This is needed
to identify the request and allows for the grouping of multiple
requests by the same user.
.INST lists the institution that the user belongs to.
This can be a company name or educational institution. This
assists in establishing contact with the user should it be necessary
for servicing the request.
.MAIL indicates the postal address of the institution,
should it be necessary to send physical media containing the
requested data product.
.EMAIL is the email address of the requesting user.
This entry is mandatory since the majority of user contact will
be through email.
.PHONE lists the user’s contact phone number.
.FAX indicates the fax machine number that the user
has access to.
.LABEL is a user-assigned label for the request, which
will appear in data files shipped to the user. If a label is
not specified, a default value will be assigned.
.MEDIA specifies the preferred media of delivery of
the data. Normally the media type will be predetermined by the
type and size of the data being shipped. Options are currently
FTP, EMAIL, EXABYTE TAPE, DAT TAPE, DLT TAPE, and possibly others.
.ALTERNATE MEDIA specifies a backup media option should
the first not be available.
.FORMAT_WAVEFORM indicates the format for the waveform
data to be shipped. Initially, the only option will be "SEED".
SEED will also be the default format if this line is not provided.
.FORMAT_WAVEFORM SEED
.FORMAT_RESPONSE indicates the format for response
information when it is requested. The current default is "SEED
ASCII", which is a specific text output format for displaying
response data known as "RESP" format. RESP files can
easily be produced by a program called "rdseed".
.FORMAT_RESPONSE SEED_ASCII
.MERGE_DATA requires a YES or NO entry, specifying
whether the data products should be combined at the hub data
center before shipment to the user or if each data center should
send their shipment to the user. In the case of a YES entry,
a number of days should be entered which equates to the wait
time in days. After that point, the hub data center will
ship what it is able to provide and any late shipments will
be redirected to the user. Here is an example of how the user
would specify product merging with a two-day time window.
.MERGE_DATA YES 2
.DISPOSITION is an optional field for specifying
how to transfer data through FTP to the user. It will be followed
by one of two directives: PUSH or PULL. The PUSH
case directs the data center performing the shipment to open
an FTP dialogue with the user's host machine and put the data
on the user's machine. The PUSH directive is followed
by the host name and the anonymous FTP directory into which
the data is placed.:
.DISPOSITION PUSH myhost.seismology.edu /pub/dropoff
The PULL directive specifies that the user will
get the data through FTP manually once notified that it is available.
There is no need to specify a host name or directory here:
.DISPOSITION PULL
.END is a mandatory entry that signals the end of
the request header. What follows the .END tag is one to many
data request lines, which list specifically what data
the user wants to receive. There is no set upper limit to the
number of data request lines a user can enter, but each line
must be a separate record with white space separators for each
of the fields.
The data request lines come in three flavors: .DATA,
.RESP, and .INV. .DATA lines request waveform
data, .RESP lines ask for response information, and .INV
queries a site for an inventory of data holdings. All
of these request types follow the same general format, even
though the response to each will differ.
The format of a data request line is laid out in a logical
order, reflecting the one-to-many relationship between successive
fields. Each field in the request line is a text string with
the first field containing a leading period. UNIX-style wildcards
‘?’ and ‘*’ can be used in
many of the field strings, which say "match to any one
character" and "any number of characters", respectively.
The field layout of a data request line is as follows:
.<DATA_TYPE> <DATA_CENTER> <NETWORK>
<STATION> <LOCATION> <CHANNELS> <START_TIME>
<END_TIME>
To elaborate:
DATA_TYPE specifies what data is desired. This field
must always have a leading period, making the possible choices
".DATA", ".RESP", and ".INV". Note that
more data types may become available in the future.
DATA_CENTER is a unique string identifier representing
a specific data center in the group of networked data centers.
The proper data center code name must be used here in order
to match to the proper data center. Except for inventory requests,
this field will generally be wildcarded with a single ‘*’.
However, if the user insists that data comes from a specific
data center, then putting an identifier in this field would
force the request line to be sent to that site.
NETWORK is the FDSN network code for the data requested,
consisting of one or two characters. This field may be wildcarded.
Network code examples can be found at http: //www.iris.washington.edu/stations/networks.txt.
STATION is a station name up to five characters
in length. This name refers to a geographic location, so occasionally
another network will have the same station name for their instrument
placed nearby. This is equivalent to the station identifier
in SEED format.
LOCATION is a field that allows users to request
data from specific data streams on the instrument at the specified
network and station. This is in the form of a one or two character
string, referring to the location identifier in SEED format.
This field may be wildcarded.
CHANNELS is a string describing the channels to
be retrieved. Channel names are up to three characters in length
and follow SEED channel-naming conventions. The number of channel
names can vary from one to any number of space-separated elements.
Each channel entry may be wildcarded. When two or more channels
are specified, they need to be enclosed in double-quotes. An
example channel string would be:
"BHE LH? E*"
START_TIME is a six-field set of numbers specifying
the time and date for the beginning of the time window desired.
The format is:
"YYYY MM DD hh mm ss.ffff"
where YYYY = year (0000-9999), MM = month
(01-12), DD = day of month (01-31), hh = hour
(00-23), mm = minute (00-59), ss = second (00-59),
ffff = fraction of second (0000-9999 ten-thousandths).
Take note that the ss field can drop the decimal point
if the fraction of a second is equal to zero. Since this is
a space-separated set of characters, the time string must
be contained within double-quotes. Wildcards are not allowed.
An example start time could be:
"1995 06 22 04 00 23.4522"
END_TIME has the same format as START_TIME, and
pertains to the end of the time window for the data desired.
Armed with this information, the following example of a
DATA request line makes sense:
.DATA * AA ORCA * "BHE LH? E*" "1995
06 22 04 00 23.4522" "1995 06 22 05 30 00"
This asks for data from station ORCA of network AA from
June 22nd 1995, 0400 hours and 23.4522 seconds to 0530 hours.
The channels returned will be BHE, all LH orientations, and
any extremely short period (E) channels. If the user
instead wanted response information, the line would read:
.RESP * AA ORCA * "BHE LH? E*" "1995
06 22 04 00 23.4522" "1995 06 22 05 30 00"
More information on these types of requests will be provided
in later chapters.
