International Federation of Digital Seismograph Networks

Thread: Next generation miniSEED - 2016-3-30 straw man change proposal 13 - Change name of location ID to group ID and expand to 4 characters

None
Started: Aug. 11, 2016, 12:59 p.m.
Last activity: Aug. 20, 2016, 10:40 a.m.

Hi all,

Change proposal #13 to the 2016-3-30 straw man (iteration 1) is attached: Change name of location ID to group ID and expand to 4 characters.

Please use this thread to provide your feedback on this proposal by Wednesday August 24th.

thanks,
Chad




  • A agree with concept of expanding and renaming the existing locid,
    "location id" always seemed very confusing to me and "group" seems as
    good as any. But see my earlier proposal for an alternative.

    However, I feel it is important for any change such as this one to
    also explain how existing channel codes will be expressed in the new
    file format. Old data will not go away just because of a new file
    format and I would hope that miniseed3 eventually becomes the standard
    way of both getting data into and out of datacenters. In particular,
    this proposal, because it says that the group id "Cannot be empty",
    needs to spell out how current channels with "empty" loc ids would be
    mapped.

    I prefer my proposal, which combined the loc id and channel code into
    a single string and therefore had a natural mapping for old channels,
    but in either case we cannot ignore existing data.

    thanks
    Philip

    On Thu, Aug 11, 2016 at 4:00 PM, Chad Trabant <chad<at>iris.washington.edu> wrote:

    Hi all,

    Change proposal #13 to the 2016-3-30 straw man (iteration 1) is attached:
    Change name of location ID to group ID and expand to 4 characters.

    Please use this thread to provide your feedback on this proposal by
    Wednesday August 24th.

    thanks,
    Chad





    ----------------------
    Posted to multiple topics:
    FDSN Working Group II
    (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
    FDSN Working Group III
    (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

    Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
    Update subscription preferences at http://www.fdsn.org/account/profile/


    • Philip Crotwell wrote on 08/12/2016 07:29 PM:
      A agree with concept of expanding and renaming the existing locid,
      "location id" always seemed very confusing to me and "group" seems as
      good as any. But see my earlier proposal for an alternative.

      There is no need to change the name of the location identifier field. A
      few more explanatory sentences as to what this field is used for would
      be fully sufficient. MiniSEED is a binary format and the name of the
      attribute is not and will not be part of the encoding, neither as
      "location" nor as "group". The name could in fact be anything, like
      "khole" as in SAC format.

      The nomenclature using "location" may not be optimal but is widely used
      and understood. FDSN StationXML, FDSN web services, QuakeML etc., are
      important standards in Seismology that adopted the term "location" from
      SEED for good reasons! We are therefore now in the comfortable situation
      that stream identification using SCNL is consistent among the most
      important seismological standards. Don't give that up!

      However, I feel it is important for any change such as this one to
      also explain how existing channel codes will be expressed in the new
      file format. Old data will not go away just because of a new file
      format and I would hope that miniseed3 eventually becomes the standard
      way of both getting data into and out of datacenters. In particular,
      this proposal, because it says that the group id "Cannot be empty",
      needs to spell out how current channels with "empty" loc ids would be
      mapped.

      After a lengthy discussion two years ago about empty location codes in
      FDSN StationXML it was concluded that these must be allowed. Therefore
      no unnecessary restrictions like "Cannot be empty" must be introduced in
      a future MiniSEED revision.

      Regards
      Joachim

      • Hello All

        I am agnostic about the name of the attribute. Joachim raises some good points about familiarity. In some ways location actually does make sense for both reasons of having this attribute, array elements and a second sensor actually both have different locations. But as I say I don’t feel strongly about the name of the attribute.

        However I do feel strongly that allowing empty location/group codes is something that was not well thought out in the original (30 year old) format specification. The first data available in SEED simply did not fill in the field since the format did not require it to be filled in and at that time it was not needed. Allowing an empty field has prompted several groups to find different ways to accommodate a null field in a variety of places that include file naming conventions, how a user species a null field when requesting data, etc. I feel strongly that any new version of miniSeed should not allow key naming elements in the SNCL to be null, or space. It should be a required field that meets a specification as to what valid entries are in the field. I can not see a good reason not to require the location/group field to have an actual entry…. what has been done in the past is not a good reason in my opinion as we are trying to improve the next version of miniseed.

        I also think that the FDSN should establish a convention (not part of the format) for how to use the location code. As far as I am aware the GSN has a convention that makes some sense in terms of multiple sensors on one station. I think WG II should try to establish a convention for what should be used in the location/group field. But the convention need not be part of the format specification.

        Cheers
        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 Aug 16, 2016, at 1:43 PM, Joachim Saul <saul<at>gfz-potsdam.de> wrote:

        Philip Crotwell wrote on 08/12/2016 07:29 PM:
        A agree with concept of expanding and renaming the existing locid,
        "location id" always seemed very confusing to me and "group" seems as
        good as any. But see my earlier proposal for an alternative.

        There is no need to change the name of the location identifier field. A
        few more explanatory sentences as to what this field is used for would
        be fully sufficient. MiniSEED is a binary format and the name of the
        attribute is not and will not be part of the encoding, neither as
        "location" nor as "group". The name could in fact be anything, like
        "khole" as in SAC format.

        The nomenclature using "location" may not be optimal but is widely used
        and understood. FDSN StationXML, FDSN web services, QuakeML etc., are
        important standards in Seismology that adopted the term "location" from
        SEED for good reasons! We are therefore now in the comfortable situation
        that stream identification using SCNL is consistent among the most
        important seismological standards. Don't give that up!

        However, I feel it is important for any change such as this one to
        also explain how existing channel codes will be expressed in the new
        file format. Old data will not go away just because of a new file
        format and I would hope that miniseed3 eventually becomes the standard
        way of both getting data into and out of datacenters. In particular,
        this proposal, because it says that the group id "Cannot be empty",
        needs to spell out how current channels with "empty" loc ids would be
        mapped.

        After a lengthy discussion two years ago about empty location codes in
        FDSN StationXML it was concluded that these must be allowed. Therefore
        no unnecessary restrictions like "Cannot be empty" must be introduced in
        a future MiniSEED revision.

        Regards
        Joachim

        ----------------------
        Posted to multiple topics:
        FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
        FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

        Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
        Update subscription preferences at http://www.fdsn.org/account/profile/


        • Hi Tim & all,

          a quick-shot response / add-on:

          I agree that leaving the state of the locID in limbo is not good - so ‘a value’ should indeed be required. But (and not only for backward compatibility) - ‘no LocID’ should be a valid entry. Just define how (with what string) that shall be expressed.

          One could use ’00’ (as many as required) for a default locID - but that again may be interpreted to have some meaning other than ‘no locID is used’ - so I’d rather use a more special ascii char combination.

          Such a definition should avoid incompatibilities with other formats, where locID could (still) be empty - that string would just be translated in whatever represents an ‘empty’ value in the other format.

          cheers
          florian


          On 17 Aug 2016, at 4:54 PM, Tim Ahern <tim<at>iris.washington.edu> wrote:

          Hello All

          I am agnostic about the name of the attribute. Joachim raises some good points about familiarity. In some ways location actually does make sense for both reasons of having this attribute, array elements and a second sensor actually both have different locations. But as I say I don’t feel strongly about the name of the attribute.

          However I do feel strongly that allowing empty location/group codes is something that was not well thought out in the original (30 year old) format specification. The first data available in SEED simply did not fill in the field since the format did not require it to be filled in and at that time it was not needed. Allowing an empty field has prompted several groups to find different ways to accommodate a null field in a variety of places that include file naming conventions, how a user species a null field when requesting data, etc. I feel strongly that any new version of miniSeed should not allow key naming elements in the SNCL to be null, or space. It should be a required field that meets a specification as to what valid entries are in the field. I can not see a good reason not to require the location/group field to have an actual entry…. what has been done in the past is not a good reason in my opinion as we are trying to improve the next version of miniseed.

          I also think that the FDSN should establish a convention (not part of the format) for how to use the location code. As far as I am aware the GSN has a convention that makes some sense in terms of multiple sensors on one station. I think WG II should try to establish a convention for what should be used in the location/group field. But the convention need not be part of the format specification.

          Cheers
          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 Aug 16, 2016, at 1:43 PM, Joachim Saul <saul<at>gfz-potsdam.de> wrote:

          Philip Crotwell wrote on 08/12/2016 07:29 PM:
          A agree with concept of expanding and renaming the existing locid,
          "location id" always seemed very confusing to me and "group" seems as
          good as any. But see my earlier proposal for an alternative.

          There is no need to change the name of the location identifier field. A
          few more explanatory sentences as to what this field is used for would
          be fully sufficient. MiniSEED is a binary format and the name of the
          attribute is not and will not be part of the encoding, neither as
          "location" nor as "group". The name could in fact be anything, like
          "khole" as in SAC format.

          The nomenclature using "location" may not be optimal but is widely used
          and understood. FDSN StationXML, FDSN web services, QuakeML etc., are
          important standards in Seismology that adopted the term "location" from
          SEED for good reasons! We are therefore now in the comfortable situation
          that stream identification using SCNL is consistent among the most
          important seismological standards. Don't give that up!

          However, I feel it is important for any change such as this one to
          also explain how existing channel codes will be expressed in the new
          file format. Old data will not go away just because of a new file
          format and I would hope that miniseed3 eventually becomes the standard
          way of both getting data into and out of datacenters. In particular,
          this proposal, because it says that the group id "Cannot be empty",
          needs to spell out how current channels with "empty" loc ids would be
          mapped.

          After a lengthy discussion two years ago about empty location codes in
          FDSN StationXML it was concluded that these must be allowed. Therefore
          no unnecessary restrictions like "Cannot be empty" must be introduced in
          a future MiniSEED revision.

          Regards
          Joachim

          ----------------------
          Posted to multiple topics:
          FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
          FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

          Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
          Update subscription preferences at http://www.fdsn.org/account/profile/


          ----------------------
          Posted to multiple topics:
          FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
          FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

          Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
          Update subscription preferences at http://www.fdsn.org/account/profile/



          • Hi Florian and all,

            Regarding a value to define empty, I think it should be distinct from any value that could possibly be used as a valid location ID to avoid ambiguities. For example, the value of '00' is already in common use so we wouldn't be able to distinguish between empty and an actual '00' value. Previously I had proposed using the value of '--', which is not a legal location (no possible conflict with non-empty IDs) and is already in use for requesting SEED referenced data (already known by centers and users). It could very well be something else. Regardless I think the approach of creating an alias for empty, as you suggest, is a good balance between 2.4 SEED with empty codes and required non-empty fields in some future version.

            Regarding the field renaming in the change proposal, I am not too stuck on that and agree with Tim and Joachim that familiarity is valuable. The point is that if we ever wanted to rename it, a major format change would be a decent opportunity, at minimum for discussion.
            The name location remains confusing for many people, including seismologists. For example, distinct location IDs are not necessarily related to distinct locations. Given that 'location' is embedded throughout the SEED ecosystem (documentation, software, schemas, vernacular), the cost of a rename may not be worth it.

            Chad

            On Aug 17, 2016, at 8:13 AM, Florian Haslinger <florian.haslinger<at>sed.ethz.ch> wrote:

            Hi Tim & all,

            a quick-shot response / add-on:

            I agree that leaving the state of the locID in limbo is not good - so ‘a value’ should indeed be required. But (and not only for backward compatibility) - ‘no LocID’ should be a valid entry. Just define how (with what string) that shall be expressed.

            One could use ’00’ (as many as required) for a default locID - but that again may be interpreted to have some meaning other than ‘no locID is used’ - so I’d rather use a more special ascii char combination.

            Such a definition should avoid incompatibilities with other formats, where locID could (still) be empty - that string would just be translated in whatever represents an ‘empty’ value in the other format.

            cheers
            florian


            On 17 Aug 2016, at 4:54 PM, Tim Ahern <tim<at>iris.washington.edu> wrote:

            Hello All

            I am agnostic about the name of the attribute. Joachim raises some good points about familiarity. In some ways location actually does make sense for both reasons of having this attribute, array elements and a second sensor actually both have different locations. But as I say I don’t feel strongly about the name of the attribute.

            However I do feel strongly that allowing empty location/group codes is something that was not well thought out in the original (30 year old) format specification. The first data available in SEED simply did not fill in the field since the format did not require it to be filled in and at that time it was not needed. Allowing an empty field has prompted several groups to find different ways to accommodate a null field in a variety of places that include file naming conventions, how a user species a null field when requesting data, etc. I feel strongly that any new version of miniSeed should not allow key naming elements in the SNCL to be null, or space. It should be a required field that meets a specification as to what valid entries are in the field. I can not see a good reason not to require the location/group field to have an actual entry…. what has been done in the past is not a good reason in my opinion as we are trying to improve the next version of miniseed.

            I also think that the FDSN should establish a convention (not part of the format) for how to use the location code. As far as I am aware the GSN has a convention that makes some sense in terms of multiple sensors on one station. I think WG II should try to establish a convention for what should be used in the location/group field. But the convention need not be part of the format specification.

            Cheers
            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 Aug 16, 2016, at 1:43 PM, Joachim Saul <saul<at>gfz-potsdam.de> wrote:

            Philip Crotwell wrote on 08/12/2016 07:29 PM:
            A agree with concept of expanding and renaming the existing locid,
            "location id" always seemed very confusing to me and "group" seems as
            good as any. But see my earlier proposal for an alternative.

            There is no need to change the name of the location identifier field. A
            few more explanatory sentences as to what this field is used for would
            be fully sufficient. MiniSEED is a binary format and the name of the
            attribute is not and will not be part of the encoding, neither as
            "location" nor as "group". The name could in fact be anything, like
            "khole" as in SAC format.

            The nomenclature using "location" may not be optimal but is widely used
            and understood. FDSN StationXML, FDSN web services, QuakeML etc., are
            important standards in Seismology that adopted the term "location" from
            SEED for good reasons! We are therefore now in the comfortable situation
            that stream identification using SCNL is consistent among the most
            important seismological standards. Don't give that up!

            However, I feel it is important for any change such as this one to
            also explain how existing channel codes will be expressed in the new
            file format. Old data will not go away just because of a new file
            format and I would hope that miniseed3 eventually becomes the standard
            way of both getting data into and out of datacenters. In particular,
            this proposal, because it says that the group id "Cannot be empty",
            needs to spell out how current channels with "empty" loc ids would be
            mapped.

            After a lengthy discussion two years ago about empty location codes in
            FDSN StationXML it was concluded that these must be allowed. Therefore
            no unnecessary restrictions like "Cannot be empty" must be introduced in
            a future MiniSEED revision.

            Regards
            Joachim

            ----------------------
            Posted to multiple topics:
            FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
            FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

            Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
            Update subscription preferences at http://www.fdsn.org/account/profile/


            ----------------------
            Posted to multiple topics:
            FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
            FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

            Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
            Update subscription preferences at http://www.fdsn.org/account/profile/


            ----------------------
            Posted to multiple topics:
            FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
            FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

            Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
            Update subscription preferences at http://www.fdsn.org/account/profile/


            • All,

              I did want to point out that expansion of the location id to 4 characters has some larger implications on those of us dealing with real time systems. A large number of these systems include Earthworm, AQMS, Hydra rely on EW ‘tracebufs’ in some part of the processing. This has proven a useful format for an “in-the-clear” representation of a short time series segment. The TraceBuf format stores data as C string (zero terminated). In the TraceBuf header the location code cannot be expanded in place beyond the current two characters as the TraceBuf version offset is only 3 bytes away. This format is used for query from EW WaveServers and Winston wave servers - so a big portion of the community will have some heart burn over expanding this field. I imagine it would take the EW community some time to agree on the “trace buf 3” standard and to roll it out in the many systems out there as well so time series with more than two character location codes would not be available in real time systems for some time.

              I personally have never seen the need to increase this field - I have trouble imagining a use case where 1296 two character combinations are not adequate. I am sure there are some for experiments or really big arrays, but the station name can always be change (and probably should be), for many of these cases.

              My own feeling is users like the NEIC would likely punt this issue and only use data with two character location codes until circumstance cause a need to add stations not abiding by this convention. I am guessing this would not really affect the NEIC in that a normal seismic station would have little reason to use more than a two character location code.

              The discussion about this field not being empty also has struck me a being a bit of a no-win holy war. I have always viewed an “empty” location code as two spaces since it is a two position space padded field IMHO. I suspect there will be some push back on forcing this requirement to have printable characters as so much of the world’s data leaves this field empty. The GSN convention was born of necessity when they started putting two weak motion instruments at a station. The location was needed to make the two seismometers distinct. The GSN followed this convention to assign each transducer a location code even if there were no ambiguously named channels. At some stations those seismometers are a couple of meters apart so “location code” now means “different seismometers” in this case, if you consider such seismometers colocated.

              Dave


              On Aug 19, 2016, at 12:01 PM, Chad Trabant <chad<at>iris.washington.edu> wrote:


              Hi Florian and all,

              Regarding a value to define empty, I think it should be distinct from any value that could possibly be used as a valid location ID to avoid ambiguities. For example, the value of '00' is already in common use so we wouldn't be able to distinguish between empty and an actual '00' value. Previously I had proposed using the value of '--', which is not a legal location (no possible conflict with non-empty IDs) and is already in use for requesting SEED referenced data (already known by centers and users). It could very well be something else. Regardless I think the approach of creating an alias for empty, as you suggest, is a good balance between 2.4 SEED with empty codes and required non-empty fields in some future version.

              Regarding the field renaming in the change proposal, I am not too stuck on that and agree with Tim and Joachim that familiarity is valuable. The point is that if we ever wanted to rename it, a major format change would be a decent opportunity, at minimum for discussion.
              The name location remains confusing for many people, including seismologists. For example, distinct location IDs are not necessarily related to distinct locations. Given that 'location' is embedded throughout the SEED ecosystem (documentation, software, schemas, vernacular), the cost of a rename may not be worth it.

              Chad

              On Aug 17, 2016, at 8:13 AM, Florian Haslinger <florian.haslinger<at>sed.ethz.ch> wrote:

              Hi Tim & all,

              a quick-shot response / add-on:

              I agree that leaving the state of the locID in limbo is not good - so ‘a value’ should indeed be required. But (and not only for backward compatibility) - ‘no LocID’ should be a valid entry. Just define how (with what string) that shall be expressed.

              One could use ’00’ (as many as required) for a default locID - but that again may be interpreted to have some meaning other than ‘no locID is used’ - so I’d rather use a more special ascii char combination.

              Such a definition should avoid incompatibilities with other formats, where locID could (still) be empty - that string would just be translated in whatever represents an ‘empty’ value in the other format.

              cheers
              florian


              On 17 Aug 2016, at 4:54 PM, Tim Ahern <tim<at>iris.washington.edu> wrote:

              Hello All

              I am agnostic about the name of the attribute. Joachim raises some good points about familiarity. In some ways location actually does make sense for both reasons of having this attribute, array elements and a second sensor actually both have different locations. But as I say I don’t feel strongly about the name of the attribute.

              However I do feel strongly that allowing empty location/group codes is something that was not well thought out in the original (30 year old) format specification. The first data available in SEED simply did not fill in the field since the format did not require it to be filled in and at that time it was not needed. Allowing an empty field has prompted several groups to find different ways to accommodate a null field in a variety of places that include file naming conventions, how a user species a null field when requesting data, etc. I feel strongly that any new version of miniSeed should not allow key naming elements in the SNCL to be null, or space. It should be a required field that meets a specification as to what valid entries are in the field. I can not see a good reason not to require the location/group field to have an actual entry…. what has been done in the past is not a good reason in my opinion as we are trying to improve the next version of miniseed.

              I also think that the FDSN should establish a convention (not part of the format) for how to use the location code. As far as I am aware the GSN has a convention that makes some sense in terms of multiple sensors on one station. I think WG II should try to establish a convention for what should be used in the location/group field. But the convention need not be part of the format specification.

              Cheers
              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 Aug 16, 2016, at 1:43 PM, Joachim Saul <saul<at>gfz-potsdam.de> wrote:

              Philip Crotwell wrote on 08/12/2016 07:29 PM:
              A agree with concept of expanding and renaming the existing locid,
              "location id" always seemed very confusing to me and "group" seems as
              good as any. But see my earlier proposal for an alternative.

              There is no need to change the name of the location identifier field. A
              few more explanatory sentences as to what this field is used for would
              be fully sufficient. MiniSEED is a binary format and the name of the
              attribute is not and will not be part of the encoding, neither as
              "location" nor as "group". The name could in fact be anything, like
              "khole" as in SAC format.

              The nomenclature using "location" may not be optimal but is widely used
              and understood. FDSN StationXML, FDSN web services, QuakeML etc., are
              important standards in Seismology that adopted the term "location" from
              SEED for good reasons! We are therefore now in the comfortable situation
              that stream identification using SCNL is consistent among the most
              important seismological standards. Don't give that up!

              However, I feel it is important for any change such as this one to
              also explain how existing channel codes will be expressed in the new
              file format. Old data will not go away just because of a new file
              format and I would hope that miniseed3 eventually becomes the standard
              way of both getting data into and out of datacenters. In particular,
              this proposal, because it says that the group id "Cannot be empty",
              needs to spell out how current channels with "empty" loc ids would be
              mapped.

              After a lengthy discussion two years ago about empty location codes in
              FDSN StationXML it was concluded that these must be allowed. Therefore
              no unnecessary restrictions like "Cannot be empty" must be introduced in
              a future MiniSEED revision.

              Regards
              Joachim

              ----------------------
              Posted to multiple topics:
              FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
              FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

              Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
              Update subscription preferences at http://www.fdsn.org/account/profile/


              ----------------------
              Posted to multiple topics:
              FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
              FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

              Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
              Update subscription preferences at http://www.fdsn.org/account/profile/


              ----------------------
              Posted to multiple topics:
              FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
              FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

              Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
              Update subscription preferences at http://www.fdsn.org/account/profile/


              ----------------------
              Posted to multiple topics:
              FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
              FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

              Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
              Update subscription preferences at http://www.fdsn.org/account/profile/