International Federation of Digital Seismograph Networks

Thread: The future of miniSeed

None
Started: March 31, 2016, 8:44 a.m.
Last activity: Aug. 11, 2016, 10:16 a.m.
Tim Ahern
March 31, 2016, 8:44 a.m.
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
    April 15, 2016, 3:23 p.m.
    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
      April 15, 2016, 8:08 a.m.

      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
        April 18, 2016, 9:54 a.m.
        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
          April 18, 2016, 2:34 a.m.

          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
            April 18, 2016, 10:53 p.m.
            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
    April 15, 2016, 4:23 p.m.

    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