Technical Evaluation for the next generation of miniSEED
Final Report
The final report is available here: https://github.com/FDSN/miniSEED3-TechnicalEvaluation/blob/master/report.md
It consists of a short summary of every issue and the final tally of the votes. This repository additionally sparked a few discussion with broader implications about potential changes to the FDSN identifiers:
- #27: Expansion and convention of the network code
- #28: Expansion of the station code
- #29: Expansion and convention of the location code
- #30: Expansion and convention of the channel code
This GitHub repository, and especially its issues, will be used for step 2 of the design of the next generation miniSEED format. The three stages, previously identified of its design are:
- Step 1: Community agreement on the basic requirements for the next generation miniSEED.
- Step 2: Technical evaluation of these requirements.
- Step 3: Technical discussion targeting selection of the best solution.
The goal of step 2 is to evaluate the requirements agreed on in stage 1 and
- confirm that each requirement is technically feasible and
- discuss technical approaches for each requirement, voting to identify the consensus for preference of approach.
Multiple possible technical solutions for some requirements are expected. The outcome of this stage will be a clear yes/no for acccepting each requirement as technically feasible and identification of a consensus approach for each. Combining the results of this stage to form full implementation specification proposals for step 3 may be done by any interested parties.
References to discussions and so far produced documents:
Procedure and Timeline
-
Discussion will start right now and will be moderated by @krischer. Anyone is invited to join. A separate issue is available for each discussion point.
-
Discussion on each issue is expected to be finished by January 29th and voting will end Feburary 2st. The votes will be tallied up by @krischer after February 2nd. Please register to vote (and state which institution you represent) in #1. You can vote either by reacting with :+1: (YES) or :-1: (NO) to the head post in an issue or [please use comments - many issues have been broken down in more than one question] by explicitly stating your support for/contra in a comment in an issue. A transparent vote summary for each issue (including institutions) will be provided by @krischer after voting has concluded. @krischer will not vote but break a tie, if necessary.
Technical Evaluation
The discussion will be broken up in a number of issues:
Administrative Issues:
- #1: Register to vote by posting to this issue.
- #2: Discuss anything related to this readme here.
- #3: Misc discussions. Please don't open arbitrary new issues but discuss generic things here. A new issue will be opened in case it is deemed necessary.
- #26: Discussion about the name of the new format.
Basic Requirements:
- #4: A new method of identifying a time series.
- #5: The new format must be fully self-defining.
- #6: Specify absolute time, including leap seconds, using an existing standard.
- #7: Conversion tools must perform conversion from miniSEED 2 without loss of important information.
- #8: Joint evolution of StationXML.
- #9: Proper documentation, best practices.
Additional Requirements:
- #10: Identification of non-raw, derived data.
- #11: New data payload encoding types (general, opaque).
- #12: Include a CRC (cyclic redundancy check) of the complete record.
- #13: Include both a format and a data/publication version number.
- #14: Allow addition of arbitrary headers by equipment manufacturers, operators, etc. without the need for authorization or approval by the FDSN.
- #15: Support variable length records for efficiency and flexibility (e.g. real time streaming with lower latency).
- #16: Provide nanosecond-timing resolution in both record start time and sample rate/period.
- #17: Provide support for high sampling rates.
- Simplification/reorganization of miniSEED:
- #18: Move key, selected blockette details (e.g. actual sample rate, data payload encoding) into fixed header.
- #19: Fix byte order (e.g. little endian) of binary portions of header; define byte order of payload via encoding values.
- #20: Remove blockette support.
- #21: Simplify and improve record start time.
- #22: Eliminate time correction field as a required, always-present field and retain as an optional field present when needed.
- #23: Combine and drop unused / underspecified bit flags.
- #24: Eliminate sequence number as a required, always-present field and retain as an optional field present when needed.
- #25: Alongside with the new format, a protocol for (near) real time data exchange needs to be specified.
Issues Discussing the Expansion and Conventions of the FDSN Identifiers
Assuming the FDSN identifiers are used (discuss in #4) how should they be expanded and what conventions should be applied? Limitations in the current identifiers are becoming a pressing issues and are a (or the) main motivator for discussing a new data format in the first place.
These are not being voted on right now as they are a broader issue.
- #27: Expansion and convention of the network code
- #28: Expansion of the station code
- #29: Expansion and convention of the location code
- #30: Expansion and convention of the channel code