International Federation of Digital Seismograph Networks

Thread: The future of miniSeed

None
Started: 2016-03-31 15:44:07
Last activity: 2016-08-11 17:16:44
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
    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
      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
        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
          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
            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
    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






  • Tim Ahern
    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






    • 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




      • 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