|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|||||||
|
|
|
|
|
|||||||
|
|
|
|||||||||
|
|
|
|||||||||
|
|
|
|||||||||
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|||||||||
|
|||||||||||
| You are here: IRIS > Software and Manuals > NetDC |
NetDC manual [ back ] [ forward ]6.0 INVENTORY (.INV) REQUESTS Inventory requests ask for information regarding the data holdings of a particular data center. The information can generally be extracted from a database but the source of data may also be a flat file index or a filesystem directory tree. Inventory data is provided in a standard ASCII format and can generally be forwarded to the requesting user directly through email. Local processing begins with the "inventory.request" file being fed to the function "local_inventory()", where the data is queried and returned. The request file is laid out as a series of request lines, like the example below:
Looking at these sample inventory requests, you'll notice that some of the request lines have less than the total number of fields filled in. Some omit the start and end time, some exclude the channel and location, and still others leave out the station and network. What this illustrates is the inventory request's unique ability to accept a variable number of field entries which will determine how much information is returned. More will be explained in the output examples below. "process_inv", the inventory interface routine, is called from "local_inventory()" supplying the following parameters, followed by the contents of the file "inventory.request":
This header information allows NetDC to know how to deliver the output once it has been constructed. "process_inv" must take each request line and form a query to the local information base. As the query is passed, it should in some fashion extract the output and filter the information into the output format shown below:
The REQUEST LINE displays the inventory request line being processed. This helps associate the inventory output with the query that triggered it. The LIST CONTENT DESCRIPTION indicates what kind of list follows. This description can be one of the following:
Following this is the HEADER LINE, which can vary depending on the content listing. This is a standard text line that gives the user a quick reference to what the fields stand for, much like a table header. Each of the lines afterward contain the records that fit the query criteria. There can be zero lines, one line, or many lines of output, depending on the query and the matching elements. For each request line there can be many of these "content blocks" consisting of description, header, and data lines. The arrangement of these blocks is recursive in nature, meaning that a single category is exhaustively described down through all of its subcategories before going to the next category. In other words, when printing information on a network, the next block of information will be on the first station of the network and the block after will be on the first location or channel of that station, and so forth. This arrangement helps link subcategories to their parent categories. A given channel is unmistakably part of the previously listed station, which is a part of the previously listed network, etc. The following are examples showing what output a user could expect to see from various inventory requests. Carefully note the format of each request, since inventory requests can be made with a variable number of fields, depending on how much information is desired. In this first example, a query for available data centers comes back with a report with lines pulled directly out of the local routing table. The query is made by placing a wildcard in the DC_NAME field, with no other request fields specified. In the output, the fields are contained within double-quotes and space-separated. The field names are indicated just below the title. The <cr> pertains to where a carriage return would be. .INV *<cr> This next example shows a list of available networks. This occurs when the network field is filled with a wildcard or requested network code. In this case, the database at the PRIMARY site provides the data. Information on the data center from the routing table is not included in such a query. .INV * IU<cr> A list of available stations will show the station name and related information, including the effective time. Note that more than one entry can exist for a given station in the case of having more than one effective time, as illustrated in the example below (values may be hypothetical). It is conventional to represent an open-ended end time with a very large value, such as 2500,365,23:59:59.9999. .INV GEOSCOPE G *<cr> It is important to note that locations and channels are provided in the same line of output. Location identifiers are very closely tied in uniqueness to channel names, so it makes sense to include both on the same output line. It should be noted that a user wishing to see channel information needs to fill both the location identifier and channel field in the query, as shown in the example below. Also note the use of two channel strings contained in double-quotes in the query. .INV GEOSCOPE G * * "MH? LH?"<cr> The list of available waveform data will indicate the start and end times of the available data, the number of samples, and the number of bytes. By entering a start and end time, you not only get waveform information, but only the channels and stations that have effective times within the time window will be displayed. .INV IRIS_DMC CD WMQ * BHZ "1990 01 16 00 00 00" "1990
11 01 00 00 00"<cr> [AVAILABLE WAVEFORM DATA]<cr> The time strings in the above examples are in standard format of year, julian day, and time down to the ten-thousandth of a second. Precision at least down to the second is recommended. The format can be described in C-code syntax: "%04d,%03d,%02d:%02d:%07.4f",(int)year,(int)jday,(int)hour,(int)min,(float)sec Inventory data will typically be emailed back to the user. In the case of merging inventory data from different sites, the data will be concatenated with an identification header at the head of each data center's output. An identification header is always included with an inventory shipment and looks like this example: ***Inventory Shipment*** From: GEOFON For request ID: GEOFON:Feb_12,01:27:30:1874 Originally Requested by: Joe_Seismologist (jseis@quake.institute.edu) of: The Quake Institute Request Label: netdc_data_gather_1 If an inventory shipment is too large to be mailed to the user (this limit is set by the data center), it is instead diverted to FTP transfer. The user is notified of the shipment through email, but the data is made available through FTP. NetDC manual [ back ] [ forward ]
introduction
•• overall concept •• request
format •• request reception and delegation |
 |
|||
About
IRIS
| Members | Programs
| USArray | Seismic
Monitor | Earthquakes | SeismoArchives |
|||
Send comments to the |