Dear Colleagues and Members of Working Group II:
About a year ago (August 6, 2016) I wrote to you concerning the
recognized current need for an updated miniSEED format, and in support
of the ongoing efforts in WGII to develop a new FDSN standard. While
I did not attend the Utrecht workshop on this topic earlier this year,
I understand that it was productive and that much progress has
been made on the detailed definition of a new standard.
I now write again to request that you use the Kobe meeting to
take the next steps toward adoption and implementation of a new
FDSN standard.
My understanding is that a nearly complete, though not final,
specification for a new format - miniSEED3 - exists and has been
discussed by the team of technical developers identified at the
meeting in Utrecht. Input came from a number of groups that
commented on the initial strawman proposed by IRIS, and modifications
were made based on input from the Utrecht meeting and through further
discussions in the technical evaluation team.
I will not delve into, or argue for, specific features of the
proposed format. Most of you are more familiar with its details
than I. I will, however, highlight some important aspects of the
new format, as presented by its developers and proponents:
1. It solves the imminent data-center need to identify and
accommodate larger numbers of networks, stations, and sensors.
[Some modern data sets relevant for the FDSN community cannot be
accommodated with the current miniSEED format. ]
2. Conversion of miniSEED2 to miniSEED3, for archiving or
distribution, is simple and lossless.
3. Networks and data centers that do not need the new features
offered by miniSEED3 may not see any benefit in adopting miniSEED3
and can continue relying on miniSEED2 and their current
infrastructure in their operation.
4. By design, miniSEED3 is not intended to be a low-latency
real-time data format. It primarily addresses issues in data archiving,
data management and data exchange.
Point (1) addresses the critical issue that some data centers have
to deal with now. Having an FDSN standard will strongly encourage
data centers to implement the same standard, facilitating continued
sharing of software and development.
Points (2-3) make it clear that the new format does not impose a
burden on those data centers and networks that do not need miniSEED3.
Point (4) clarifies the limitations of the scope of miniSEED3 and
identifies the separate need for an effort to clarify/develop
standards in the field recording and transmission of data and
to address related issues, such as data latency.
I urge you to use the WGII meeting in Kobe to review and consider the
miniSEED3 format proposal. While doing so, I hope you will not forget
the strategic benefits of having an FDSN standard and also to consider
the risks associated with not adopting a standard. I also hope that your
deliberations will lead to a recommendation that the FDSN Steering
Committee can consider during the second plenary meeting.
My assessment is that the FDSN is ready to, and needs to, move forward
with a solution.
Best regards,
Göran
Goran Ekstrom