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.
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
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).
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/