Expansion and convention of the channel code

[krischer]

Assuming the FDSN identifiers will be used in the new data format (please discuss this in #4) how should the channel code be expanded (or not) and what conventions should be adopated (if any)?

[chad-earthscope]

As one idea described in an draft of new identifiers, posted to #4, the location code could be enhanced in the following ways:

• Allow both 3 and 4 Uppercase [A-Z] and/or Numeric [0-9] characters.
• With each character describing one aspect of the instrumentation and its digitization as follows:

First      - Band code, identifying the general sample rate and response band of instrument
Second     - First instrumentation code, identify the family to which the sensor belongs
Third      - Not always present.  Second instrument code, extended sensor identification
Last       - Orientation code, indicate the directionality of the sensor measurement

The first code in the sequence is always the band code, the second is always the first instrumentation code and the last is always the orientation code.

The 3-character channel codes are equivalent to the SEED 2.4 channels, as documented in the SEED manual and the IRIS FDSN Identifiers draft of 2018-1-3. Essentially, this scheme adds an optional character to define further instruments. These additional "instruments" could include derived time series, etc.

The scientific users of SEED data are relatively comfortable with the nomenclature of channel naming. I think it is very important to recognize that any change to any identifiers, but especially the channel code given how much information is packed into it, is potentially disruptive to users of the data.

[krischer]

Proposal by @tim-iris (#4 (comment)):

I think there should be some discussion related to the Channel field since it is really trying to specify three different attributes of a channel in a single field. Would it make sense to break out the current three fields separately into BandCode, Instrument code, and orientation. It would give greater flexibility than keeping them together as one. Users could still specify things such as BHZ but the interfaces would map those into B_H_Z for instance for query processing. Users might not be impacted but data generators could have greater flexibility and capability.

[krischer]

Regarding the proposal from @chad-iris above:

One change I would like to see is to move the identifier for synthetic data (currently an X in the instrument code in SEED 2.4) to the band code. The band limit/sampling rate of synthetic data is also not that meaningful in many cases. Then the instrument code can be used to specify the type of data (synthetic rotational data, synthetic strains, ...).

[chad-earthscope]

One change I would like to see is to move the identifier for synthetic data (currently an X in the instrument code in SEED 2.4) to the band code. The band limit/sampling rate of synthetic data is also not that meaningful in many cases. Then the instrument code can be used to specify the type of data (synthetic rotational data, synthetic strains, ...).

Currently 18 of 36 possible (26 letters + 10 digits) are allocated, so there are characters available to identify a synthetic or even derived time series in the "band" code.

So you are thinking something like "XHZ" for a synthetic, broadband seismic trace? That would even be backwards compatible with mseed2. The same could be done for derived data, e.g. "YGDZ", where the "Y" means derived, the "GD" is for geodetic (if we adopt 2-character instrument codes) and the "Z" is orientation. This seems OK. It definitely distorts the meaning of the band code, but may be worth it.

One user-level issue is that seleting, for example, "*HZ" to get broadband seismic data, would match synthetic data too.

[crotwell]

The channel code currently seems to have more information packed into it than the other 3 (net, sta loc) and as such maybe it should expand to 8 chars as well. Perhaps with some limitation that 3 or 4 char codes be restricted to follow the fdsn channel naming convention, but 5-8 length codes, maybe combined with the X,Y,Z additional band codes above, are open for synthetic/derived/processed data uses?

Also allow the dash char like in the station and loc codes?

There is value in having station, location and channel codes all be the same length and based on the same character set.

[krischer]

We could also adapt the convention that as soon as there are dashes in the "channel" code then its either derived or synthetic data. There is also value in having more than one value for the orientation - generic derivatives of the wavefields for example would require two orientation components.

[jmsaurel]

If we modify/expand the channel code to better identify derived or synthetic data while retaining information about the instrument (like XHZ or X_BHZ), then an expansion of the quality flag #10 to indicate synthetic/derived data is no more necessary.

[jsaul]

One might as well leave the 3-character channel naming convention as it is now in order to maintain compatibility with miniSEED. Either the current band code or the current instrumentation code could be used to flag synthetic data without introducing conflicts with the current channel naming.

The flagging of derived or synthetic data only requires 1 bit each. Too little to justify an incompatible change to the current channel naming.

On a side note, the miniSEED data quality indicator may also be used to flag both derived or synthetic data. There would be no conflict with the currently defined quality indicators.

[crotwell]

The primary reason for expanding the channel code is that (almost) all of the instrument codes have been used up. As a revision like this only happens after decades, leaving the channel code at 3 chars would be a mistake I believe.

I prefer the longer 8 char limit, but we should do at least 4 chars to allow additional instrument codes. So much the better if we can also handle synthetic/derived/processed within the channel code as well.

[jsaul]

The current SEED 2.4 specification lists as instrument codes:

Seismometers: H, L, G, M, N
Tilt Meter: A
Creep Meter: B
Calibration Input: C
Pressure: D
Electronic Test Point: E
Magnetometer: F
Humidity: I
Rotational Sensor: J
Temperature: K
Water Current: O
Geophone: P
Electric Potential: Q
Rainfall: R
Linear Strain: S
Tide: T
Bolometer: U
Volumetric Strain: V
Wind: W
Derived or Generated Channel: X
Non-specific Instruments: Y
Synthesized Beams: Z

That's a lot and I agree that there are not many left. But it's also a huge coverage of instrument types. What additional instrument types are on the agenda to be added to the scheme?

[crotwell]

Given the disruption of changing the net, station and loc codes, why not take to opportunity to give more room to the channel code? Rather than asking what additional types are needed, the question really should be are we positive that no new types will be needed over the lifetime of the format. If there is even a chance of new instrument types, then the expansion is worth it I feel.

[jmsaurel]

As it was suggested for network and station, maybe we could have room for new sensors or instrument type, but keep the actual ones for any new data corresponding to the existing instruments.

The only problem I see with the actual list is the identification of derived or synthetized data.
Because they concern an instrument, we loose the information as to which data they correspond to.
For example, according to SEED2.4, a vertical stream at 1Hz derived from a tilt-meter would be LXZ.
A vertical stream at 1Hz derived from a broadband sensor would be also LXZ.
That's confusing.

I think either an extension of the quality code #10 or of the channel code is needed, at least for that.
For the first solution, we would have, for example LAZ.{R,D,Q,M} for the tiltmeter raw data and LAZ.X for the tiltmeter derived data, LHZ.{R,D,Q,M} for the seismometer and LHZ.X for the seismometer derived data.
For the second, we would have, LAZ for the tiltmeter raw data and X_LAZ for the tiltmeter derived data, LHZ for the seismometer and X_LHZ for the seismometer derived data.
The drawback of the second solution is that it breaks compatibility with miniSEED.

[jsaul]

why not take to opportunity to give more room to the channel code

Agreed, but giving more room doesn't necessarily require a change in the channel naming at this stage.

Or, if you are really keen to change the channel naming, why not take the opportunity to split the band, instrument and orientation codes into truly separate 1-or-more-character fields? I hate the idea of having to follow rules like "if the channel code consists of more than 4 characters and the second character is a dash followed by a digit then...." etcpp. If more instrument codes are needed than available now, why not allocate 2 characters in a dedicated instrument code field?

[tim-iris]

I agree with Phillip’s observation, Also the channel naming is currently just an FDSN convention that does not preclude other channel namings. At some point we should consider if conventions should become a stronger prat of the format. From a users perspective this would be useful. Cheers Tim Ahern Director of Data Services IRIS IRIS DMC 1408 NE 45th Street #201 Seattle, WA 98105 (206)547-0393 x118 (206) 547-1093 FAX

…

On Jan 25, 2018, at 6:36 AM, Philip Crotwell ***@***.***> wrote: The primary reason for expanding the channel code is that (almost) all of the instrument codes have been used up. As a revision like this only happens after decades, leaving the channel code at 3 chars would be a mistake I believe. I prefer the longer 8 char limit, but we should do at least 4 chars to allow additional instrument codes. So much the better if we can also handle synthetic/derived/processed within the channel code as well. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#30 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Ah7veR1Ci3l9D5YQNRCyryJ17wRJYFqzks5tOGdEgaJpZM4Rbiqd>.