Misc Discussions

[krischer]

Please don't open arbitrary new issues but discuss generic things here. A new issue will be opened in case it is deemed necessary.

[crotwell]

Possible new requirement,
Temporary Network Identification Avoiding Reusing Codes.

The space of network codes should be expanded to allow each temporary network to have its own code that is not reused. This must also include a mapping for older temporary networks to allow them to have a unique identifier. A suggestion is to assign the temporary network with old code XA that started in 1992 to XA1992.

This may be part of #4 and also relates to #7. Also see previous discussion

[krischer]

This is already being proposed in the draft for the new FDSN identifiers (https://github.com/FDSN/miniSEED3-TechnicalEvaluation/files/1607757/FDSN.Identifiers.-.2018-1-3.pdf) as discussed in #4.

[chad-earthscope]

We need an issue to discuss the "Name of the Next Generation Format (NGF)", i.e. should it be called miniSEED, should it only be called miniSEED under certain circumstances, if not what names should be considered.

[krischer]

We need an issue to discuss the "Name of the Next Generation Format (NGF)", i.e. should it be called miniSEED, should it only be called miniSEED under certain circumstances, if not what names should be considered.

Done in #26.

[aringler-usgs]

Sorry if these issues have already been discussed or this is not the place for this or not even related:

Most of the ASL run networks (IU, US, NE, IC, IW, CU) make use of calibrations blockettes. If these were going to be removed #20 we would still want to be able to capture this information.

We would appreciate if things like calibration blockettes were captured in a consistent way. The freedom of timing quality (Blockette 1001 field 3) has caused us a bit of headache since it is not consistent between digitizer manufacturers. Would #14 allow for a number of different ways to present the same information?

Will the the NGF keep support for gain ranged data (e.g. SRO, HGLP, DWSSN)? We have a fair bit of data in SRO format.

Some of our administrative channels (e.g. OCF from a Q330) contain blockette 2000 which are likely of limited value to most data users. We do have such data in our holdings #7 so it would be nice to not throw this information away. I would guess this data doesn't make it to IRIS since there isn't associated metadata.

[krischer]

Most of the ASL run networks (IU, US, NE, IC, IW, CU) make use of calibrations blockettes. If these were going to be removed #20 we would still want to be able to capture this information.

These will be retained in some fashion according to #7.

We would appreciate if things like calibration blockettes were captured in a consistent way. The freedom of timing quality (Blockette 1001 field 3) has caused us a bit of headache since it is not consistent between digitizer manufacturers. Would #14 allow for a number of different ways to present the same information?

That is not decided yet but one proposal somewhere was to namespace the additional information - then each manufacturer can have its own namespace and provide their own definition of what they mean by timing quality.

Will the the NGF keep support for gain ranged data (e.g. SRO, HGLP, DWSSN)? We have a fair bit of data in SRO format.

The current plan is to keep support for reasonably widely used encodings (and potentially add new ones). I guess having a significant data set somewhere with an encoding is reason enough to retain support for it in NGF.

Some of our administrative channels (e.g. OCF from a Q330) contain blockette 2000 which are likely of limited value to most data users. We do have such data in our holdings #7 so it would be nice to not throw this information away. I would guess this data doesn't make it to IRIS since there isn't associated metadata.

#11 and #14 would be the right places to discuss this.

[chad-earthscope]

The freedom of timing quality (Blockette 1001 field 3) has caused us a bit of headache since it is not consistent between digitizer manufacturers. Would #14 allow for a number of different ways to present the same information?

An excellent point.

That is not decided yet but one proposal somewhere was to namespace the additional information - then each manufacturer can have its own namespace and provide their own definition of what they mean by timing quality.

I think the FDSN should try and provide a common header (or two or more) of some sort to describe timing quality that is defined and usable by any manufacturer. With a flexible header system, manufacturer-specific headers can always be added, but that just pushes the problem of determining what each means to the user.

In an earlier specification draft I had an "Estimated Maximum Error (seconds)" header, I'm not sure that's realistic for manufacturers, but it would be readily useful for data users and manufacturer-agnostic. But this is off topic for this issue, we might need a place to record thoughts on new fields or existing fields that need further definition or changes.

[jmsaurel]

Hello,

I see that there is no vote for issues #27, #28, #29 and #30.
Of course, this is not as format relevant as the point #4, but I think those are important questions.

@krischer, how do you plan to integrate the output of the discussions on those issues ?

[krischer]

Yes this is on purpose for a number of reasons:

1. There is neither consensus nor have the available options been explored in sufficient detail.
2. This is a broader FDSN issue and should thus be discussed in a bigger forum potentially also evolving the likes of IASPEI and other organizations.
3. Assuming Requirement: A new method of identifying a time series #4 is accepted the issue is pretty independent of the actual data format.

To my understanding there will be a separate discussion of some form on the identifiers and I can offer to collect the current discussion in a pdf or maybe also as part of the final report of the results of this stage.