Thread: The future of miniSeed

None

Started: 2016-03-31 15:44:07

Last activity: 2016-08-11 17:16:44

Topics: FDSN Working Group II FDSN Working Group III

Tim Ahern

2016-03-31 15:44:07

Hello everyone, You are receiving this email because either you were in the initial list I sent the announcement to, are a member of FDSN WGII or WGIII or have expressed an interest in attending these discussions at the EGU. This includes a good mix of FDSN Network and data center personnel as well as representatives from equipment manufacturers.

I am attaching a draft agenda that identifies the topics of discussion as well as giving the time and meeting place. I am also attaching a straw man document that several groups in the US have discussed. The straw man may help us as it provides a starting point for our discussions as well as giving you a sense of some of the considerations we have identified as being important.

We wil be proposing a Request for Comment (RFC) process to reach closure on the next version with specific timelines in mind. The proposed process will be presented at the meeting as we are still developing the RFC approach we will propose.

And here is the draft proposal with some of our thoughts on this topic

Tim Ahern

Director of Data Services
IRIS

IRIS DMC
1408 NE 45th Street #201
Seattle, WA 98105

(206)547-0393 x118
(206) 547-1093 FAX

Joachim Saul

Re: The future of miniSeed

2016-04-15 22:23:05

Tim Ahern wrote on 03/31/2016 05:47 PM:

I am attaching a draft agenda that identifies the topics of discussion as well as giving the time and meeting place. I am also attaching a straw man document that several groups in the US have discussed. The straw man may help us as it provides a starting point for our discussions as well as giving you a sense of some of the considerations we have identified as being important.

We wil be proposing a Request for Comment (RFC) process to reach closure on the next version with specific timelines in mind. The proposed process will be presented at the meeting as we are still developing the RFC approach we will propose.

Hello Tim,

in the draft document you sent, changes for consideration include:

* Expand location identifier and disallow empty values (synonymous with
all other series identifiers).

About 2 years ago we had a lively discussion about empty location
identifiers in StationXML and the conclusion was to allow them. May I
ask what is the rationale for now wanting to disallow empty values in a
future version of MiniSEED?

Cheers
Joachim
- Chad Trabant
  
  Re: The future of miniSeed
  
  2016-04-15 15:08:47
  
  Hello Tim,
  
  in the draft document you sent, changes for consideration include:
  
  * Expand location identifier and disallow empty values (synonymous with
  all other series identifiers).
  
  About 2 years ago we had a lively discussion about empty location
  identifiers in StationXML and the conclusion was to allow them. May I
  ask what is the rationale for now wanting to disallow empty values in a
  future version of MiniSEED?
  
  Cheers
  Joachim
  
  Hello Joachim,
  
  The previous discussion, as you write, was about StationXML. A central issue in the discussion was that without a corresponding change in (mini)SEED the two formats would be out of sync in regards to requirements. A new version of miniSEED is the right time to consider such a change.
  
  Review the end of the discussion: http://www.iris.washington.edu/pipermail/fdsn-wg2-data/2014-September/000072.html
  and note that the (mini)SEED discussion was yet to be conducted. The arguments for why an empty string location ID are problematic remain the same.
  
  regards,
  Chad
  - Joachim Saul
    
    Re: The future of miniSeed
    
    2016-04-18 16:54:49
    
    Hello Chad
    
    Chad Trabant wrote on 04/15/16 17:08:
    
    he arguments for why an empty string location ID are problematic remain the same.
    
    The same is true for the arguments that were put forward *against*
    disallowing non-empty location identifiers.
    
    Empty location identifiers are a very common reality and have been for
    many years. Definitely not without good reasons. If data centers had
    wanted to use a non-empty location identifier they could have done so
    (some have done) and still can. Seismologists have learned to work with
    both empty and non-empty location identifiers.
    
    The new specification, meant to ease restrictions w.r.t. channel naming,
    should not enforce new restrictions which are not only unneeded but
    would create additional complexity and confusion. This would be
    counterproductive to a seamless transition between MiniSEED versions.
    
    Cheers
    Joachim
    
    Chad Trabant
    
    Re: The future of miniSeed
    
    2016-04-18 09:34:47
    
    Hi Joachim,
    
    Chad Trabant wrote on 04/15/16 17:08:
    
    he arguments for why an empty string location ID are problematic remain the same.
    
    The same is true for the arguments that were put forward *against*
    disallowing non-empty location identifiers.
    
    This is not quite correct. The previous discussion was for StationXML and the argument that the representation between StationXML and miniSEED would be out of sync no longer applies.
    
    I agree with your implication that the ability to transition to the next version of the format is very important. Regarding any potential change to location ID, this is still possible; keep in mind that all users are already used to specifying the location ID as something other than an empty string (out of necessity). There are other proposed changes and likely more that will come up that also impact forward compatibility and a transition.
    
    Regardless, I think this should be discussed at the miniSEED level, it is the right place after all.
    
    Chad
    
    Joachim Saul
    
    Re: The future of miniSeed
    
    2016-04-19 05:53:02
    
    Hi Chad,
    
    Chad Trabant wrote on 04/18/16 11:34:
    
    Chad Trabant wrote on 04/15/16 17:08:
    
    he arguments for why an empty string location ID are problematic
    remain the same.
    
    The same is true for the arguments that were put forward *against*
    disallowing non-empty location identifiers.
    
    This is not quite correct. The previous discussion was for StationXML
    and the argument that the representation between StationXML and miniSEED
    would be out of sync no longer applies.
    
    The previous discussion was in fact about channel naming and location ID
    naming in particular. StationXML happened to be the context at that
    time, now it's the future MiniSEED. The issue remains the same.
    
    It's clear that channel naming must be independent of the data format.
    To the extent the main data format allows technically, of course, but
    the purpose of the proposed changes is to relax some of the previously
    quite tight length limits. So let's not impose new limits.
    
    I agree with your implication that the ability to transition to the next
    version of the format is very important. Regarding any potential change
    to location ID, this is still possible; keep in mind that all users are
    already used to *specifying* the location ID as something other than an
    empty string (out of necessity).
    
    Interfaces are one thing, data encoding is another. A time formatted
    like "2016-04-18T10:11:12.345678" is used in a request but a different,
    binary encoding is used in the MiniSEED header. Likewise it may be
    natural to write "--" in a data request file containing space-separated
    columns. Out of necessity, but that necessity arises from the use of
    spaces as column separators in a particular interface, not from the
    encoding of the location ID itself.
    
    Cheers
    Joachim
Chad Trabant

Re: The future of miniSeed

2016-04-15 23:23:35
Hello all,

To make the best use of our time during this meeting I attach a series of slides with description and rationale for each of the changes in the straw man. Ideally, this will allow us to spend more time discussing the issues and less time overviewing each topic. This is intended to be the start of a process, we fully expect that some of the details will modified, some changes deemed not necessary and other changes proposed.

Chad Trabant
IRIS DMC

On Mar 31, 2016, at 8:44 AM, Tim Ahern <tim<at>iris.washington.edu> wrote:

Hello everyone, You are receiving this email because either you were in the initial list I sent the announcement to, are a member of FDSN WGII or WGIII or have expressed an interest in attending these discussions at the EGU. This includes a good mix of FDSN Network and data center personnel as well as representatives from equipment manufacturers.

I am attaching a draft agenda that identifies the topics of discussion as well as giving the time and meeting place. I am also attaching a straw man document that several groups in the US have discussed. The straw man may help us as it provides a starting point for our discussions as well as giving you a sense of some of the considerations we have identified as being important.

We wil be proposing a Request for Comment (RFC) process to reach closure on the next version with specific timelines in mind. The proposed process will be presented at the meeting as we are still developing the RFC approach we will propose.

<Agenda-miniSeed-SOH.pdf>

And here is the draft proposal with some of our thoughts on this topic

<Next-Generation-miniSEED-2016-3-30.pdf>

Tim Ahern

Director of Data Services
IRIS

IRIS DMC
1408 NE 45th Street #201
Seattle, WA 98105

(206)547-0393 x118
(206) 547-1093 FAX
Attachments

Next Generation miniSEED 2016-4-1.pdf
Tim Ahern

Re: The future of miniSeed

2016-06-17 21:00:11

There has been a request to extend the period to respond to the first iteration of the proposed changes to miniSeed. After consideration I think we must grant the requested extension for this first round of iterations. However to make sure we have time to complete the 4 iterations and allow time for the editors to synthesis all the comments between iterations it is essential that we meet the future time frame. I you have comments for future iterations you will have 3 weeks only.

Please make note of the following FIRM deadline of July 8, 2016. Send your comments to the FDSN WG II list

Subsequent iterations will allow only three weeks for comments after the editors have produced the next version of the straw man.
We will still stick with a total of 4 iterations.

The timing is driven by the calendar and when the FDSN will next meet.

Cheers and thanks for adhering to this new deadline for Iteration 1 comments and the 3 week period for the next 3 iterations.

Tim Ahern

Director of Data Services
IRIS

IRIS DMC
1408 NE 45th Street #201
Seattle, WA 98105

(206)547-0393 x118
(206) 547-1093 FAX

On Mar 31, 2016, at 8:44 AM, Tim Ahern <tim<at>iris.washington.edu> wrote:

Hello everyone, You are receiving this email because either you were in the initial list I sent the announcement to, are a member of FDSN WGII or WGIII or have expressed an interest in attending these discussions at the EGU. This includes a good mix of FDSN Network and data center personnel as well as representatives from equipment manufacturers.

I am attaching a draft agenda that identifies the topics of discussion as well as giving the time and meeting place. I am also attaching a straw man document that several groups in the US have discussed. The straw man may help us as it provides a starting point for our discussions as well as giving you a sense of some of the considerations we have identified as being important.

We wil be proposing a Request for Comment (RFC) process to reach closure on the next version with specific timelines in mind. The proposed process will be presented at the meeting as we are still developing the RFC approach we will propose.

<Agenda-miniSeed-SOH.pdf>

And here is the draft proposal with some of our thoughts on this topic

<Next-Generation-miniSEED-2016-3-30.pdf>

Tim Ahern

Director of Data Services
IRIS

IRIS DMC
1408 NE 45th Street #201
Seattle, WA 98105

(206)547-0393 x118
(206) 547-1093 FAX
- Tim Ahern
  
  Continuing to push forward on the miniSeed straw man
  
  2016-08-11 17:05:42
  
  Hello all,
  
  Following the guidance of the FDSN Chair (Göran Ekstrom in his August 4th email) we will shortly be soliciting feedback on all of the change proposals to the 2016-3-30 straw man (iteration 1). One email will be sent for each proposal received, which you are encouraged to reply to with your comments on the proposal. Please keep all discussion on each proposal in their respective threads.
  
  All feedback should be received by Wednesday August 24th, after which, a new straw man will be compiled and sent back out to the group and new change proposals will be solicited (iteration 2). A total of 4 iterations are still planned.
  
  I am attaching a screenshot of Goran’s email since it was only sent to FDSN WG II and not to everyone on this email. Please direct your responses to the forthcoming emails from Chad to this same email list to be inclusive.
  
  Thanks and sorry for the delay in moving this effort forward.
  
  Cheers
  
  Dr. Tim Ahern
  tim<at>iris.washington.edu
  
  Chair of FDSN WG III on
  Products, Tools and Services
  - Tim Ahern
    
    Re: Continuing to push forward on the miniSeed straw man
    
    2016-08-11 17:16:44
    
    Sorry for not including the attachment, I really thought I had it attached. Here it is again as a screenshot
    
    Dr. Tim Ahern
    tim<at>iris.washington.edu
    
    Chair of FDSN WG III on
    Products, Tools and Services
    
    On Aug 11, 2016, at 10:05 AM, Tim Ahern <tim<at>iris.washington.edu> wrote:
    
    Hello all,
    
    Following the guidance of the FDSN Chair (Göran Ekstrom in his August 4th email) we will shortly be soliciting feedback on all of the change proposals to the 2016-3-30 straw man (iteration 1). One email will be sent for each proposal received, which you are encouraged to reply to with your comments on the proposal. Please keep all discussion on each proposal in their respective threads.
    
    All feedback should be received by Wednesday August 24th, after which, a new straw man will be compiled and sent back out to the group and new change proposals will be solicited (iteration 2). A total of 4 iterations are still planned.
    
    I am attaching a screenshot of Goran’s email since it was only sent to FDSN WG II and not to everyone on this email. Please direct your responses to the forthcoming emails from Chad to this same email list to be inclusive.
    
    Thanks and sorry for the delay in moving this effort forward.
    
    Cheers
    
    Dr. Tim Ahern
    tim<at>iris.washington.edu
    
    Chair of FDSN WG III on
    Products, Tools and Services
    
    Attachments
    
    PastedGraphic-8.png

Thread: The future of miniSeed

Attachments

Attachments

Attachments