International Federation of Digital Seismograph Networks
Thread: Kobe meeting / evolution of miniSEED
John Clinton
Dear Colleagues in FDSN WGII,
during the Kobe meeting last August, I was elected to take over the Chair of FDSN WG2 from Reinoud Sleeman, with Chad Trabant newly elected as Vice-Chair. Thanks Reinoud for supporting this community over the last 4 years!
A summary of the meeting in Kobe, plus the outcomes, is now available on the FDSN WGII website at http://www.fdsn.org/wg/wgII/
The key issue currently being addressed in this WG is the discussion on miniSEED2. This issue has been the hot topic in this WG since 2016. Though miniSEED2 has been extremely successful, current trends in data collection (e.g. Large N experiments) and processing (need to include in archives processed data, synthetic data), coupled with proliferation in numbers of permanent networks and temporary experiments, are exposing limitations in the existing naming conventions for network / station / location / channel. Basically, miniSEED2 is no longer suited to managing the growing FDSN community needs. Further, if there is no community-agreed extension / alternative to miniSEED2, members of FDSN community will be forced to develop work-arounds in the coming years.
IRIS kicked-off this general discussion in early 2016 [1]. Via this FDSN WGII mailing list, a first attempt to define a consensus path forward stalled following vigorous community discussion. An FDSN meeting in De Bilt in Spring 2017 gave new impetus to the conversation, resulting in a White Paper [2] that included a variety of possible solutions. In Reinoud’s announcement of this paper, he poses key questions - 1) does the FDSN see the need to accommodate these type of new experiments, and 2) if so how can these best be handled - with minimum disruption to the existing miniSEED2 standard, or via a more comprehensive revision. The White Paper proposes a variety of technical solutions that span minimum disruption to generic, comprehensive approaches. I believe the FDSN must accept the challenge to support a wider scope, and to answer the second question, as Reinoud noted, its key to further develop the core requirements for mseed3.
Together with Chad, the Vice-Chair, we propose the following broad steps in order to move forward:
- Step 1: community agreement on actual basic requirements for next generation mseed (Target timeline: complete by end November 17, unless extensions requested)
- Step 2: technical evaluation for requirements (Target timeline: completed by end January 18) - Lion Krischer from ETH has kindly agree to moderate this stage using GitHub, it will be open to any interested persons.
- Step 3: technical discussion targeting selection of the best solution (Target timeline: completion end April 18) - likely another moderated GitHub discussion, also will be open to any interested persons.
A small group have revised the requirements from the White Paper and a proposal is at
https://docs.google.com/document/d/1ymAe9v1rUuucpY7ai5ilKsD7V1ejwt6GxQQmJ5IevDI/edit?usp=sharing
In this brief document, we aim to achieve succinct and clear recommendations that can be used to derive technical requirements. These requirements will be the key elements a technical team will take to justify preferring one solution over another, so its really important to agree this now.
The timeline I propose is relatively tight, and if persons would like to contribute, but require more time, especially for Step 1, please indicate this ASAP. General comments are fine either by email to the mailing list, or by directly adding comments in the google-doc (please make sure you are logged in so are identified!).
Also, please let me know if you would like to directly contribute in Step 2, though the discussion will be open.
best regards,
John
[1] http://www.fdsn.org/message-center/thread/389/#m-584
[2] http://www.fdsn.org/message-center/thread/502/#m-859
during the Kobe meeting last August, I was elected to take over the Chair of FDSN WG2 from Reinoud Sleeman, with Chad Trabant newly elected as Vice-Chair. Thanks Reinoud for supporting this community over the last 4 years!
A summary of the meeting in Kobe, plus the outcomes, is now available on the FDSN WGII website at http://www.fdsn.org/wg/wgII/
The key issue currently being addressed in this WG is the discussion on miniSEED2. This issue has been the hot topic in this WG since 2016. Though miniSEED2 has been extremely successful, current trends in data collection (e.g. Large N experiments) and processing (need to include in archives processed data, synthetic data), coupled with proliferation in numbers of permanent networks and temporary experiments, are exposing limitations in the existing naming conventions for network / station / location / channel. Basically, miniSEED2 is no longer suited to managing the growing FDSN community needs. Further, if there is no community-agreed extension / alternative to miniSEED2, members of FDSN community will be forced to develop work-arounds in the coming years.
IRIS kicked-off this general discussion in early 2016 [1]. Via this FDSN WGII mailing list, a first attempt to define a consensus path forward stalled following vigorous community discussion. An FDSN meeting in De Bilt in Spring 2017 gave new impetus to the conversation, resulting in a White Paper [2] that included a variety of possible solutions. In Reinoud’s announcement of this paper, he poses key questions - 1) does the FDSN see the need to accommodate these type of new experiments, and 2) if so how can these best be handled - with minimum disruption to the existing miniSEED2 standard, or via a more comprehensive revision. The White Paper proposes a variety of technical solutions that span minimum disruption to generic, comprehensive approaches. I believe the FDSN must accept the challenge to support a wider scope, and to answer the second question, as Reinoud noted, its key to further develop the core requirements for mseed3.
Together with Chad, the Vice-Chair, we propose the following broad steps in order to move forward:
- Step 1: community agreement on actual basic requirements for next generation mseed (Target timeline: complete by end November 17, unless extensions requested)
- Step 2: technical evaluation for requirements (Target timeline: completed by end January 18) - Lion Krischer from ETH has kindly agree to moderate this stage using GitHub, it will be open to any interested persons.
- Step 3: technical discussion targeting selection of the best solution (Target timeline: completion end April 18) - likely another moderated GitHub discussion, also will be open to any interested persons.
A small group have revised the requirements from the White Paper and a proposal is at
https://docs.google.com/document/d/1ymAe9v1rUuucpY7ai5ilKsD7V1ejwt6GxQQmJ5IevDI/edit?usp=sharing
In this brief document, we aim to achieve succinct and clear recommendations that can be used to derive technical requirements. These requirements will be the key elements a technical team will take to justify preferring one solution over another, so its really important to agree this now.
The timeline I propose is relatively tight, and if persons would like to contribute, but require more time, especially for Step 1, please indicate this ASAP. General comments are fine either by email to the mailing list, or by directly adding comments in the google-doc (please make sure you are logged in so are identified!).
Also, please let me know if you would like to directly contribute in Step 2, though the discussion will be open.
best regards,
John
[1] http://www.fdsn.org/message-center/thread/389/#m-584
[2] http://www.fdsn.org/message-center/thread/502/#m-859
-
Hello John,
Thanks for this update.
This 3 steps approach looks like a good thing.
In addition to a few comments I added in the Google document, here are some more general thoughts.
* Since the new data format is likely to break compatibility with existing miniSEED and may also benefit from existing data management technologies, I think it would be better to not use the name miniSEED.
I would prefer to use, as it was stated in the Kobe meeting report, the name "Next Generation format".
Until we found a proper name, of course.
* In the requirements, I have the feeling to read two contradictory statements regarding the future support of existing miniSEED2.
- In the Preface, it's quite clearly stated that the new format is needed for new applications (dense deployments, temporary experiments) and that miniSEED2 will continue to be supported by FDSN.
- However, in the general guideline principles part, the penultimate item seems to imply (quite clearly also), that miniSEED2 will only be supported as a temporary measure to ensure everyone has migrated to the new standard.
I think it should be clarified whether or not, for some classical applications, a migration to the new format is expected or foreseen or not.
* The document states the new format, like SEED, is aimed at permanent archival of data, exchange of those data and of subset of those data.
As stated in the second bullet of the general guideline principles, current miniSEED format is also used for real-time data transfer (and it's very handy, I must admit).
However, this use implies some limitations (in-order protocols with no backfill, low-latency issues).
I'm not confident that we could find a format that could suit the best way and in similar manner the needs for permanent archival and exchange of big chunks of data and the needs for low-latency, efficient real-time data streaming.
Thus I think any mention to the real-time use of the new format should be removed from the document. Or to add needs for a real-time specific sub-version of the new format (as we have QuakeML and QuakeML-RT).
Regards.
Jean-Marie SAUREL.
-
I think miniSEED has been popular in the last 15 years largely thanks to SeedLink. MiniSEED, being record-oriented, is inherently suitable for streaming, which is not the case of other formats, eg., SAC.
How do you envision the future of SeedLink? Will it use mseed3, "mseed3-rt" or something completely different?
In any case, I think the community needs a standard format (and protocol) for (near) real-time data exchange. Ideally, it should be possible to archive real-time with as little conversion as possible, eg., not invalidating checksums generated in the digitizer.
A distinction needs to be made between protocol and data format. For example, "backfill" is a feature of protocol, not data format.
I'd like to hear opinions and requirements of SeedLink users too.
Regards,
Andres.
-
1. I added several comments to the google doc.
https://docs.google.com/document/d/1ymAe9v1rUuucpY7ai5ilKsD7V1ejwt6GxQQmJ5IevDI/edit?usp=sharing
On 11/15/2017 11:00 AM, Andres Heinloo wrote:
I think miniSEED has been popular in the last 15 years largely thanks
2. How is SAC more suitable for streaming than MiniSEED?
to SeedLink. MiniSEED, being record-oriented, is inherently suitable
for streaming, which is not the case of other formats, eg., SAC.
The SAC header must contain the number of samples in the timeseries.
Therefore, the timeseries values must be known before the header
can be transmitted.
- Doug N
How do you envision the future of SeedLink? Will it use mseed3,
--
"mseed3-rt" or something completely different?
In any case, I think the community needs a standard format (and
protocol) for (near) real-time data exchange. Ideally, it should be
possible to archive real-time with as little conversion as possible,
eg., not invalidating checksums generated in the digitizer.
A distinction needs to be made between protocol and data format. For
example, "backfill" is a feature of protocol, not data format.
I'd like to hear opinions and requirements of SeedLink users too.
Regards,
Andres.
----------------------
FDSN Working Group II | http://www.fdsn.org/message-center/topic/fdsn-wg2-data/ | Unsubscribe: fdsn-wg2-data-unsubscribe<at>lists.fdsn.org
Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences at http://www.fdsn.org/account/profile/
------------------------------------------------------------------------
Doug Neuhauser (retired) University of California, Berkeley
doug<at>seismo.berkeley.edu Berkeley Seismological Laboratory
Remote Office: 530-752-5615 Berkeley, CA 94720-4760
-
Good morning,
In any case, I think the community needs a standard format (and protocol) for (near) real-time data exchange. Ideally, it should be possible to archive real-time with as little conversion as possible, eg., not invalidating checksums generated in the digitizer.
I agree with that, Andres.
Personally, I'm mostly happy with the current miniSEED and seedlink and thus haven't yet though about the future of seedlink.
On the other hand, I have seen some recent efforts toward protocols more adapted to low latency issues, like the GDI. I haven't yet had the opportunity to look at the CAPS protocol, which seems another alternative.
However, as Joachim said, we only have 6 month to come to a solution, so including some requirements for a new or improved real-time protocol adds some more work.
A distinction needs to be made between protocol and data format. For example, "backfill" is a feature of protocol, not data format.
With the current miniSEED, the time boundaries of a packet is not fixed because it depends on the compression. If your digitizer creates the miniSEED packets on the fly because it uses a more appropriate internal data storage format, the use of miniSEED itself in the seedlink protocol prevent using backfill because it would end up creating overlaps.
Webservices like fdsnws-dataselect could even offer both the new format and the current SEED format, for which converters are required.
That's a good point Reinoud, and I think fdsnws-dataselect should offer both new format and current miniSEED format. That should even be in the requirements document.
Otherwise, even if you state that the current miniSEED should continue to be supported by FDSN, it will not take much time before 90% of the data will be exchanged in the new format and before users will ask for this format only.
Regards.
Jean-Marie SAUREL.
-
-
On 11/14/2017 04:37 PM, Jean-Marie Saurel wrote:
* The document states the new format, like SEED, is aimed at permanent archival of data, exchange of those data and of subset of those data.
I think miniSEED has been popular in the last 15 years largely thanks to
As stated in the second bullet of the general guideline principles, current miniSEED format is also used for real-time data transfer (and it's very handy, I must admit).
However, this use implies some limitations (in-order protocols with no backfill, low-latency issues).
I'm not confident that we could find a format that could suit the best way and in similar manner the needs for permanent archival and exchange of big chunks of data and the needs for low-latency, efficient real-time data streaming.
Thus I think any mention to the real-time use of the new format should be removed from the document. Or to add needs for a real-time specific sub-version of the new format (as we have QuakeML and QuakeML-RT).
SeedLink. MiniSEED, being record-oriented, is inherently suitable for
streaming, which is not the case of other formats, eg., SAC.
How do you envision the future of SeedLink? Will it use mseed3,
"mseed3-rt" or something completely different?
In any case, I think the community needs a standard format (and
protocol) for (near) real-time data exchange. Ideally, it should be
possible to archive real-time with as little conversion as possible,
eg., not invalidating checksums generated in the digitizer.
A distinction needs to be made between protocol and data format. For
example, "backfill" is a feature of protocol, not data format.
I'd like to hear opinions and requirements of SeedLink users too.
Regards,
Andres.
-
Hello Jean-Marie, John, Andres et al.,
On 14.11.2017 16:37, Jean-Marie Saurel wrote:
* Since the new data format is likely to break compatibility with
An important point.
existing miniSEED and may also benefit from existing data management
technologies, I think it would be better to not use the name miniSEED.
I would prefer to use, as it was stated in the Kobe meeting report,
the name "Next Generation format".
Any reference to the exisiting miniSEED in the name (e.g. as in "mseed3"
etc.) would suggest that the new format is just an evolution of
miniSEED. This would only be the case if a miniSEED compatible solution
is chosen like the straightforward "blockette 1002" approach to
accommodate longer network and station codes [1][2].
However, as the new format will not be compatible with miniSEED, it
should be named differently to avoid any confusion.
* In the requirements, I have the feeling to read two contradictory
I fully agree that a clear statement is needed. Continued, long-term
statements regarding the future support of existing miniSEED2. - In
the Preface, it's quite clearly stated that the new format is needed
for new applications (dense deployments, temporary experiments) and
that miniSEED2 will continue to be supported by FDSN. - However, in
the general guideline principles part, the penultimate item seems to
imply (quite clearly also), that miniSEED2 will only be supported as a
temporary measure to ensure everyone has migrated to the new standard.
I think it should be clarified whether or not, for some classical
applications, a migration to the new format is expected or foreseen or
not.
support of the very successful miniSEED format by the FDSN is essential
for most networks which currently acquire, process and distribute
miniSEED, many of which cannot afford to bear the costs involved with
upgrading entire data infrastructures.
I'm not confident that we could find a format that could suit the best
This is a good point and another argument for a long-term commitment to
way and in similar manner the needs for permanent archival and
exchange of big chunks of data and the needs for low-latency,
efficient real-time data streaming.
miniSEED by the FDSN. This would also give more time to develop a future
proof new archival format by/for those who need it. The current time
line with the technical discussions ending in less than half a year from
now is rather ambitious and I doubt that this is the right approach. We
are talking here about a data format meant to one day become an FDSN
standard. Good standards take time to develop and mature.
Meanwhile, the rest of the FDSN who now happily use miniSEED for both
archival and exchange simply continue to use miniSEED.
Regards,
Joachim
[1] http://www.fdsn.org/message-center/thread/413/
[2] http://www.fdsn.org/message-center/thread/461/
-
Hello Jean-Marie, all,
the impression I got after the Kobe meeting was that indeed the next generation SEED format will be specifically
required/designed for the N-large sensor networks, but will not 'force' existing networks to move towards
the new format in their operations. Many smaller networks or data centers may not have resources to implement
such a change easily, or at all. Therefore, the formatting issue would mainly be an issue for the (large) datacenters
and their services to offer the data. Webservices like fdsnws-dataselect could even offer both the new format
and the current SEED format, for which converters are required. In this light the general guideline to only support
miniSEED2 as temporary measure does not reflect the impression I describe above, unless it is the goal to only
offer the new format by the standardized FDSN services. My suggestion would be to relax the general guidelines
and take this statement out as it seems not so important for the design of the format.
Best regards,
Reinoud
-----Original Message-----
From: fdsn-wg2-data-bounce<at>lists.fdsn.org [fdsn-wg2-data-bounce<at>lists.fdsn.org] On Behalf Of Jean-Marie Saurel
Sent: dinsdag 14 november 2017 16:38
To: FDSN Working Group II
Subject: Re: [fdsn-wg2-data] Kobe meeting / evolution of miniSEED
Hello John,
Thanks for this update.
This 3 steps approach looks like a good thing.
In addition to a few comments I added in the Google document, here are some more general thoughts.
* Since the new data format is likely to break compatibility with existing miniSEED and may also benefit from existing data management technologies, I think it would be better to not use the name miniSEED.
I would prefer to use, as it was stated in the Kobe meeting report, the name "Next Generation format".
Until we found a proper name, of course.
* In the requirements, I have the feeling to read two contradictory statements regarding the future support of existing miniSEED2.
- In the Preface, it's quite clearly stated that the new format is needed for new applications (dense deployments, temporary experiments) and that miniSEED2 will continue to be supported by FDSN.
- However, in the general guideline principles part, the penultimate item seems to imply (quite clearly also), that miniSEED2 will only be supported as a temporary measure to ensure everyone has migrated to the new standard.
I think it should be clarified whether or not, for some classical applications, a migration to the new format is expected or foreseen or not.
* The document states the new format, like SEED, is aimed at permanent archival of data, exchange of those data and of subset of those data.
As stated in the second bullet of the general guideline principles, current miniSEED format is also used for real-time data transfer (and it's very \handy, I must admit).
However, this use implies some limitations (in-order protocols with no backfill, low-latency issues).
I'm not confident that we could find a format that could suit the best way and in similar manner the needs for permanent archival and exchange of big chunks of data and the needs for low-latency, efficient real-time data streaming.
Thus I think any mention to the real-time use of the new format should be removed from the document. Or to add needs for a real-time specific sub-version of the new format (as we have QuakeML and QuakeML-RT).
Regards.
Jean-Marie SAUREL.
----------------------
FDSN Working Group II | http://www.fdsn.org/message-center/topic/fdsn-wg2-data/ | Unsubscribe: fdsn-wg2-data-unsubscribe<at>lists.fdsn.org
Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences at http://www.fdsn.org/account/profile/
-
-
Good morning,
In any case, I think the community needs a standard format (and protocol) for (near) real-time data exchange. Ideally, it should be possible to archive real-time with as little conversion as possible, eg., not invalidating checksums generated in the digitizer.
I agree with that, Andres.
Personally, I'm mostly happy with the current miniSEED and seedlink and thus haven't yet though about the future of seedlink.
On the other hand, I have seen some recent efforts toward protocols more adapted to low latency issues, like the GDI. I haven't yet had the opportunity to look at the CAPS protocol, which seems another alternative.
However, as Joachim said, we only have 6 month to come to a solution, so including some requirements for a new or improved real-time protocol adds some more work.
A distinction needs to be made between protocol and data format. For example, "backfill" is a feature of protocol, not data format.
With the current miniSEED, the time boundaries of a packet is not fixed because it depends on the compression. If your digitizer creates the miniSEED packets on the fly because it uses a more appropriate internal data storage format, the use of miniSEED itself in the seedlink protocol prevent using backfill because it would end up creating overlaps.
Webservices like fdsnws-dataselect could even offer both the new format and the current SEED format, for which converters are required.
That's a good point Reinoud, and I think fdsnws-dataselect should offer both new format and current miniSEED format. That should even be in the requirements document.
Otherwise, even if you state that the current miniSEED should continue to be supported by FDSN, it will not take much time before 90% of the data will be exchanged in the new format and before users will ask for this format only.
Regards.
Jean-Marie SAUREL.
-
Hi all,
the proposed deadline for comments on expired last Friday, and I did not hear any requests for an extension. Though there have been a number of diverse opinions and important points made, for such a key issue, I feel there has been a relatively weak engagement from our community - many of us will be affected in the long term - instrument manufacturers, software developers, real-time network operators, data centres, and scientists. This is an important issue, and community support is essential if we are to move forward in a collaborative manner. I encourage you to make your voice heard!
Please note that there is no expectation that a miniSEED2 successor will lead to abandoning support for miniSEED2. FDSN is a community organisation and any such decisions would be a community-made decision. Clearly at the moment this is a long way off. This point will be made more clear in an updated version.
For this phase, I will leave the opportunity to comment open until the end of this week, 24 November, then I will summarise and post an updated document.
Please note there have been multiple issues with people trying to post to this thread directly using their own mail systems. These problems are now solved,
best regards,
John
-
Dear colleagues,
thanks for the good number of comments on the topic of developing miniseed. An updated version is proposed to now pass to the technical evaluation (Step 2) led by Lion.
https://docs.google.com/document/d/1ymAe9v1rUuucpY7ai5ilKsD7V1ejwt6GxQQmJ5IevDI/edit?ts=5a2a921c#
Some key changes:
- a clear statement that there is no intention to migrate to a new format at this stage, and MiniSEED2 will continue to be supported for the foreseeable future.
- the format is now labelled NGF (next generation format) as placeholder to avoid mentioning SEED.
- the need for an accompanying realtime data exchange protocol is now recognised.
If there are comments, please send them ASAP. Meanwhile, Lion will advertise the GitHub project. Anyone from this community will be welcome to join and provide comments. We encourage you to participate so your voice is heard!
regards,
John
-
John Clinton wrote on 12/14/2017 10:57 PM:
- a clear statement that there is no intention to migrate to a new format at this stage, and MiniSEED2 will continue to be supported for the foreseeable future.
Hello John and FDSN WG2,
considering the importance for a continued support of current miniSEED
in the future, the term "foreseeable future" seems rather imprecise and
non-binding, especially compared to the otherwise very precise and tight
time line for NGF developments.
The ubiquity of miniSEED in modern data infrastructures will make a
substitution by an alternative format like NGF complicated, time
consuming and expensive. In many if not most current use cases, a
substitution of miniSEED by another format will not be needed at all. It
is foreseeable that miniSEED will continue to play an important role for
many years to come. After all it is a good and very successful format!
It would obviously be unfortunate if in a year or so it is decided that
the "foreseeable future" has now ended and the FDSN declares that it
will abandon miniSEED. A clarification about what is meant by
"foreseeable future" is therefore clearly needed.
In that context please also note that if one day NGF data starts to
circulate, the need would probably arise to import at least some NGF
data into existing miniSEED data infrastructures, e.g. tsunami warning
systems. Solutions to accommodate extended
network/station/location/channel names in a backwards compatible way by
introducing a new blockette[1][2] will have to be implemented by then.
It wouldn't be difficult but would require coordination. Therefore it is
necessary that the FDSN continues to support backwards compatible
evolutions of current miniSEED if needed.
Cheers
Joachim
[1] http://www.fdsn.org/message-center/thread/461/
[2] http://www.fdsn.org/message-center/thread/441/
-
Dear colleagues.
I’ve been asked to provide a further comment on the continued support of miniSEED2.
Currently probably the primary role of the FDSN, beyond the registry of network codes, is as a forum to agree standards (and guide on their usage) that end up being hugely beneficial not just for seismic networks, but also for stakeholders beyond our core group - including instrument manufacturers and scientists. But the FDSN can never insist on their implementation. Successful formats, like miniSEED2, are successful because they are good. But any network can use what they like, and this is not going to change. So there is a limit to what 'the FDSN' can promise.
The situation we are in today is clear. The FDSN is an organisation based on volunteer time, so we have limited resources. One major FDSN partner has an acute need to develop support for seismic campaigns that cannot easily be accommodated by the existing standard. They wish to develop an alternative within the boundary of the FDSN. They intend to build community agreed specifications. They intend to build a solution that meets these specifications and submit it for community review. They intend to work with the community to provide all relevant documentation and also provide software that will support forward as background conversion as far as can be possible. They also intend to use this format to manage their own archives and collections, and offer it to other users. If at some stage there proves benefit for others to also use the format, there is also an offer to engage with the FDSN to build a migration plan.
As WG II chair, I am happy to support this substantial effort, and am pleased to see many in the community also are constructively engaged in trying to ensure the new format is solid, multipurpose, and, like miniSEED2, can potentially be useful for decades to come.
But this effort is at an early stage. There is a long journey to demonstrate the new format is successful, and other networks will also need to be convinced there is a real need, and benefit, for them to consider supporting the format themselves, either during data collection and archival where more flexible naming options may prove critical; or during data dissemination where users may begin to prefer and request it.
If for example NGF ends up being incompatible with Tsunami alert systems, I’m sure pretty quickly FDSN or other agencies will recommend that networks running tsunami systems do not use it.
miniSEED2 is far and away the most successful standard our community has built, it has revolutionised our ability to archive and share high quality data. It would not be sensible to jeopardise this and I don’t believe we are doing this. We are not voting to kill-off and replace miniSEED2. We are voting to build the best future format that may be a good community solution if in future networks / users find minSEED2 can no longer meet their requirements. This seems to me to be a pragmatic long term strategy.
Consequently, there is no threat as far as I see it that the FDSN are going to ‘abandon’ miniSEED2. I’m not in a position to promise that in the long term miniSEED2 will stay the preferred format of FDSN. As was written in the NGF specification document, the new format should be developed with a 'clear migration path' possible "that includes support for both versions for some time yet encourages teams to migrate to the new format, if the FDSN sees fit to progress in this direction in the future”. I will not put a timeline on any migration, but if indeed one does become necessary, it will be decided within the FDSN, and there will be clearly the opportunity to ensure this is done in a careful manner that take into account the many valid concerns out there in the community.
regards,
John
-
Dear Colleagues,
I would like to update everyone on the efforts to lay the foundation for an FDSN-approved new data format. The technical evaluation of requirements was concluded in early 2018. Many thanks to Lion Krischer for steering this effort and providing the summary report [1]. In addition, I have updated the technical specifications to reflect the outcome of this evaluation [2].
At this stage, anyone willing to develop a new version is free to build their framework with more detailed specifications, software and test data. When we kicked-off this process in Autumn 2017, it was anticipated this would be a 3-step process, culminating in technical discussions and evaluation of different proposed solutions. If indeed group developing new solutions wish to proceed along this line, I encourage them to contact this FDSN Working Group as early as possible in their development path to try to gather community oversight and agreement, which will be invaluable if such a format is to eventually be approved by the FDSN.
Best regards,
John
[1] https://www.fdsn.org/media/message_attachments/2018/02/16/ngf_report.pdf
[2] https://docs.google.com/document/d/1ymAe9v1rUuucpY7ai5ilKsD7V1ejwt6GxQQmJ5IevDI/edit?usp=sharing
-
-
-
-
Jean-Marie Saurel
Andres Heinloo
Doug Neuhauser
Joachim Saul
Reinoud Sleeman
John Clinton