Requirement: Conversion tools must perform conversion from MiniSEED 2 without loss of important information

[krischer]

Conversion tools developed for the new format must perform conversion from miniSEED2 without loss of important information. (although it is preferred that a full miniSEED2 to NGF conversion and then back to miniSEED2 cycle should be possible without loss of information, this is generally not feasible so is not a basic requirement). The loss of information that will arise from conversions for a candidate NGF must be clearly described and agreed by FDSN (which ultimately defines ‘important’).

[chad-earthscope]

Being able to convert from miniSEED .2x will no or minimal loss is a very important requirement.

Through the previous discussions and evaluations here is what appears to me to be acceptable loss, i.e. fields/structures lost when converting from miniSEED 2:

• Beam related blockettes (400 & 405). [Personally I know of none in any archives]
• Blockette 2000. [Personally I know of none in any archives]
• Different "clock model" designations if multiple blockette 500s are in a single record.

Edit: Additionally, the flags identified in this comment on #23.

Furthermore, I support two fields required in miniSEED 2.x to be optionally retained during conversion:

• Sequence number
• Data header & quality indicator

[tim-iris]

Based on previous input I think this is essential. Solutions must be lossless when moving from the old to the new format. Thought should be given if networks transcribe their data to the new format however as to is the information really needed in their opinion.

[krischer]

Summary

(Please let me know if I missed a point or misunderstood something)

Please vote on the following issues:

1. Is data-loss acceptable at all? (Yes/No) - all other points will not be valid anymore if this is a "no".
2. Is it acceptable to loose information regarding the Beam related blockettes (400 & 405)? (Yes/No)
3. Is it acceptable to loose information for Blockette 2000? (Yes/No)
4. Is it acceptable to loose different "clock model" designations if multiple blockette 500s are in a single record? (Yes/No)
5. Is it acceptable if the "Sequence number" field in miniSEED 2.x is only optionally retained? (Yes/No)
6. Is it acceptable if the "Data header & quality indicator" field in miniSEED 2.x is only optionally retained? (Yes/No)

[crotwell]

1 Yes
2 Yes
3 Yes
4 Yes
5 Yes
6 Yes

[chad-earthscope]

1. Yes.
2. Yes, unused as far we know.
3. Yes, as long as any usage of it can stay in miniSEED 2.x format or be mapped to optional headers.
4. Yes.
5. Yes.
6. Yes.

[kaestli]

1 Yes
2 Yes
3 Yes
4 Yes
5 Yes
6 Yes

[ozym]

1. Yes
2. Yes
3. Yes
4. Yes
5. Yes
6. Yes

[claudiodsf]

1. Is data-loss acceptable at all? (Yes/No) - all other points will not be valid anymore if this is a "no".

Yes

2. Is it acceptable to loose information regarding the Beam related blockettes (400 & 405)? (Yes/No)

Yes

3. Is it acceptable to loose information for Blockette 2000? (Yes/No)

Yes

4. Is it acceptable to loose different "clock model" designations if multiple blockette 500s are in a single record? (Yes/No)

Yes. But this information should be transferred to metadata.

5. Is it acceptable if the "Sequence number" field in miniSEED 2.x is only optionally retained? (Yes/No)

Yes

6. Is it acceptable if the "Data header & quality indicator" field in miniSEED 2.x is only optionally retained? (Yes/No)

No. It should be mandatory. Moving this to metadata would produce too much complexity (a new metadata period every time the quality flag changes)

[chad-earthscope]

No. It should be mandatory. Moving this to metadata would produce too much complexity (a new metadata period every time the quality flag changes)

To clarify, I do not believe this implied moving the D, R, Q, M value to metadata, but instead to make it optional within the time series data format.

[ihenson-bsl]

1 Yes
2 Yes
3 Yes
4 Yes
5 Yes
6 Yes

[ValleeMartin]

1 Yes
2 Yes
3 Yes
4 Yes
5 Yes
6 No

[JoseAntonioJara]

1. Yes
2. Yes
3. Yes
4. Yes
5. Yes
6. Yes