Replacement for Channel type functionality?

I see that there is a note regarding Channel types being removed in the future.

https://github.com/FDSN/StationXML/blob/7ccd7ddaf3082f242a09591a8d6f5ffa88b6213b/docs/level-channel.rst#type

Where should information such as whether a channel is Triggered or Continuous be stored, if this field is removed?

I personally don't care much about losing Geophysical/Health, etc. That information is mostly redundant with the channel naming codes. But having a flag that indicates whether a channel is continuous or triggered is valuable metadata.

[crotwell]

The original issue is #44 fyi.

You can of course continue to use this field in stationXMl 1.2. My guess is that 1.2 will be "the" version for the foreseeable future (many years), so I would not worry about an imminent deprecation. I would expect that if Type is removed, and a new place to store it is created, then there will be an XSLT transform to convert 1.2 xml to a new 2.0 version xml that handles the switchover just like there was for 1.x to 1.2.

I suppose there are cases where knowing triggered vs continuous might be useful, but given that no information is provided about what the trigger parameters are, and of course even continuous data can have lots of gaps, so I am not sure that such how much the attribute really adds. But you are probably right that it is worth enough to warrant a place to put it should <Type> be removed eventually.

Perhaps adding an optional <Triggered/> element within Channel would address this? Triggered channels could be marked, and the absence of this tag would imply continuous or unknown? The other option I can see would be just to add it to the <Description>. That is less desirable if a processing system needs to know about it, as opposed to just a human reader, but is at least a way to retain the information.

Is there a need (or ability?) to provide any further information about the trigger? A textual description, or are parameters standardized enough to attempt a structure to record them? I would guess that triggered data streams are becoming less and less common, so would you think this is mostly only for historical metadata?

[nackerley]

I want to second the motion by the original poster here - triggered vs. continuous is a very important distinction for channels. At CHIS/NRCan here in Canada We network performance metrics such as the percentage of stations currently coming in in realtime, and it is useful to have a way to distinguish between types, so that we can omit non-continuous realtime data from the statistics.

At the same time, totally agreed that SEED channel codes should be sufficient to distinguish geophysical and state-of-health channels. That idea is the part of the channel time that should be deprecated.