Introduction to the Inventory Scheme

Andres Heinloo, Jan Becker

September 20, 2010

Motivation

• When we started ArcLink development, we needed a maintainable station database and a mechanism for exchanging metadata and creating full SEED. • Instead of defining independent response for each channel, we wanted to refer to an instrument database, where the responses are defined.

Introduction to the Inventory Scheme 1 / 13

Influences

Our basis was SEED standard; in addition we borrowed some ideas from • “inst.db” format of copy seed and make dlsv; • “inventory” format of NetDC. • DHI object model;

Introduction to the Inventory Scheme 2 / 13

The first version of inventory scheme

The scheme was defined as a generic UML object model from where we derived: • Database scheme for MySQL, Postgres, etc.; • XML scheme; • Python/C++ object model;

Introduction to the Inventory Scheme 3 / 13

Interoperability

Thanks to the same UML object model, we could easily: • save metadata from database into an XML file; • load metadata from XML file into database; • work with the metadata using the same object-oriented API, regardless if the source is database or XML.

Introduction to the Inventory Scheme 4 / 13

XML queries

• Unlike NetDC, which has completely different format for inventory (in this case, station and channel lists) and response, our inventory model contains complete metadata. • It is, however, not necessary to transfer everything. For example, using ArcLink, it is possible to request just a list of networks (without stations).

Introduction to the Inventory Scheme 5 / 13

Problems When we incorporated the scheme into the Seiscomp Data Model (SCDM) and added “foreign” stations into the database, some problems emerged: • inability to describe sensors whose components have different responses; • inability to describe stations (arrays) whose sensors have different coordinates; • difficulties to describe non-seismic sensors (eg., barometers); • incompatibilities with other parts of SCDM.

Solving the above problems was the goal of the new inventory scheme.

Introduction to the Inventory Scheme 6 / 13

New inventory scheme: components with different response

• All three components of modern seismometers have the same response (poles and zeros), therefore in the first version of the inventory scheme, the response of all components was defined by the “SeisStream” element. It had child elements for each component, which only allowed to define different gain. • In the new version of the scheme, there is no “Component” element anymore–each component is an independent “Stream”.

Introduction to the Inventory Scheme 7 / 13

New inventory scheme: sensors with different coordinates

• In case of small arrays, the same station code is used for all array elements. In this case specifying different coordinates of sensors is needed. • In the new version of the scheme, a new element “SensorLocation”– child of “Station” and parent of “Stream” was added for this purpose.

Introduction to the Inventory Scheme 8 / 13

New inventory scheme: non-seismic sensors

• Non-seismic sensors could be previously defined using “AuxStream”. • The new version adds support for polynomial responses as defined by the SEED standard. In addition, “Seismometer” and “SeisStream” were replaced by more generic “Sensor” and “Stream”.

Introduction to the Inventory Scheme 9 / 13

New inventory scheme: unification with SCDM

• SCDM introduced “PublicID” as a globally unique ID of an object, which is also used for inter-object references. This methodology was adopted by the new inventory scheme; for example “Stream” refers to “Sensor” and “Datalogger” by PublicID instead of Name. • Also, element and attribute naming convention was changed to match other parts of SCDM.

Introduction to the Inventory Scheme 10 / 13

Database initialization in SC3

• We have a mechanism for loading an XML file into database, but usually we don’t have metadata in XML format to begin with. • Seiscomp has historically used so called “key files” as the source of station metadata. “Key files” refer to sensor and datalogger by name; if the response of these instruments is defined in the “inst.db” file, it is automatically added into the database when calling “seiscomp config”.

Introduction to the Inventory Scheme 11 / 13

Using SEED dataless as the source of metadata In many cases, it is desired to “import” metadata from SEED dataless volumes. This is problematic, because dataless does not identify sensor and datalogger; therefore it is incompatible with “key file” concept. In this case the user has to perform the following steps: • create “key files” using “import dlsv”; • run “seiscomp config”; • call “sync dlsv” to write full metadata into the database.

Introduction to the Inventory Scheme 12 / 13

XML-based configuration

In future Seiscomp 3 releases, it is planned to simplify configuration by replacing “key files” with XML files that follow the inventory scheme. A tool to convert SEED Dataless to inventory XML is already included in the current release.

Introduction to the Inventory Scheme 13 / 13