International Federation of Digital Seismograph Networks

Thread: StationXML extensions proposed by the IRIS DMC

None
Started: July 13, 2015, 5:22 p.m.
Last activity: Aug. 5, 2015, 3:06 p.m.
Chad Trabant
July 13, 2015, 5:22 p.m.

Hello WG-II,

As requested at the 2015 working group meeting, below are StationXML changes proposed by the IRIS DMC.

If approved by the WG, the DMC will prepare a modified schema for technical review through a pull request on Github.

regards,
Chad
IRIS DMC


Proposed StationXML changes from the IRIS DMC:

1) Allow the Station::CreationDate element to be optional.
Rationale: This value denotes when a station/site was originally installed and is distinct from the startDate attribute used to note the station epoch start. There is no need for it to be required, it cannot be retained in conversions and many data centers do not have this information forcing them to set it to, e.g., the startDate.

2) Use xs:double type instead of xs:decimal type for ApproximationLowerBound, ApproximationUpperBound and MaximumError values (in PolynomialType::ApproximationType).
Rationale: For consistency, xs:double is used for most other floating point values in the schema. Also xs:double allows values in scientific notation.

3) Allow the startDate attribute of Network, Station and Channel elements to be optional.
Rationale: The startDate for Network is not commonly known or contained in SEED, forcing the insertion of potentially bad dates.

4) Replace usage of SampleRateType with FrequencyType.
Rationale: The two Types are effectively the same except units described as HERTZ versus SAMPLES/S and therefore redundant. If the replacement is not desired, the DecimationType::InputSampleRate should be changed to SampleRateType for consistency.

5) Include data availability elements described in the fdsn-station+availability-1.0.xsd extension schema as optional elements of the main schema.
Rationale: There is very little down side to integrating this extension with the main schema, maintaining and using it as a separate schema is more difficult and there are other time series date attributes (e.g. restrictedStatus) already in the schema.

6) Allow the Channel::Response::Stage::StageGain element to be optional.
Rationale: For some channels, e.g. SOH, there is no reasonable stage gain. The current required status might lead to bad values included in metadata.



  • Florian Haslinger
    July 14, 2015, 6:24 a.m.
    Hi Chad & all,

    while reading through, one suggestion:

    to (6) Channel::Response::Stage::StageGain to be optional
    Wouldn’t it be better if there was a well defined entry for ‘not applicable’ and keep the field mandatory? I could imagine that having the entry optional (and thus not receiving an error if entry is not given, when checking) might lead to lassitude and omission of that gain value even if it was there.
    (For any decimation stages that are really part of the processing but that do not affect the gain - a value of ‘1’ should be used anyway, I would think…)


    cheers,
    florian


    On 14 Jul 2015, at 2:22 am, Chad Trabant <chad<at>iris.washington.edu> wrote:


    Hello WG-II,

    As requested at the 2015 working group meeting, below are StationXML changes proposed by the IRIS DMC.

    If approved by the WG, the DMC will prepare a modified schema for technical review through a pull request on Github.

    regards,
    Chad
    IRIS DMC


    Proposed StationXML changes from the IRIS DMC:

    1) Allow the Station::CreationDate element to be optional.
    Rationale: This value denotes when a station/site was originally installed and is distinct from the startDate attribute used to note the station epoch start. There is no need for it to be required, it cannot be retained in conversions and many data centers do not have this information forcing them to set it to, e.g., the startDate.

    2) Use xs:double type instead of xs:decimal type for ApproximationLowerBound, ApproximationUpperBound and MaximumError values (in PolynomialType::ApproximationType).
    Rationale: For consistency, xs:double is used for most other floating point values in the schema. Also xs:double allows values in scientific notation.

    3) Allow the startDate attribute of Network, Station and Channel elements to be optional.
    Rationale: The startDate for Network is not commonly known or contained in SEED, forcing the insertion of potentially bad dates.

    4) Replace usage of SampleRateType with FrequencyType.
    Rationale: The two Types are effectively the same except units described as HERTZ versus SAMPLES/S and therefore redundant. If the replacement is not desired, the DecimationType::InputSampleRate should be changed to SampleRateType for consistency.

    5) Include data availability elements described in the fdsn-station+availability-1.0.xsd extension schema as optional elements of the main schema.
    Rationale: There is very little down side to integrating this extension with the main schema, maintaining and using it as a separate schema is more difficult and there are other time series date attributes (e.g. restrictedStatus) already in the schema.

    6) Allow the Channel::Response::Stage::StageGain element to be optional.
    Rationale: For some channels, e.g. SOH, there is no reasonable stage gain. The current required status might lead to bad values included in metadata.


    _______________________________________________
    fdsn-wg2-data mailing list
    fdsn-wg2-data<at>iris.washington.edu
    http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data



    • Philip Crotwell
      July 14, 2015, 12:27 p.m.
      Hi

      I agree with 1, 2, 4 and 5.

      But on 6 I think I agree with Florian. Can you give a concrete example of a
      channel that has a meaningful Stage, but without a StageGain? I can see the
      case of a SOH channel that has no Stages at all, for example it is ascii
      text logging messages, but why would a channel with no gain even have
      Stages or even a Response? And in cases where the gain is meant to be
      unity, I think it is better to explicitly state that.

      On 3, I am also not sure about making the startdate on Network, Station and
      Channel optional. The problem I worry about is that without that date you
      can't uniquely identify channels as the codes are often reused, BHZ last
      year may not be the same as BHZ today. And this is even occasionally the
      case with stations. And even with Networks you need the start date if it is
      a temporary network. XA in 2001 might be very different from XA in 2005.

      Perhaps a better solution would be to change the meaning of the date in the
      case of networks. Instead of it being required to be the actual start date,
      it should be the start date if that is know, but if not then it can be some
      date that is known to lie within the effective times of the network? For
      example if I don't know the start time of the XA network, but I know the
      channel I am working on, within the XA network, started at 2001-06-01, then
      I can use the start date of the channel for the network as well, allowing
      the network potentially to be identified.

      thanks
      Philip


      On Tue, Jul 14, 2015 at 2:24 AM, Haslinger Florian <
      florian.haslinger<at>sed.ethz.ch> wrote:

      Hi Chad & all,

      while reading through, one suggestion:

      to (6) Channel::Response::Stage::StageGain to be optional
      Wouldn’t it be better if there was a well defined entry for ‘not
      applicable’ and keep the field mandatory? I could imagine that having the
      entry optional (and thus not receiving an error if entry is not given, when
      checking) might lead to lassitude and omission of that gain value even if
      it was there.
      (For any decimation stages that are really part of the processing but that
      do not affect the gain - a value of ‘1’ should be used anyway, I would
      think…)


      cheers,
      florian


      On 14 Jul 2015, at 2:22 am, Chad Trabant <chad<at>iris.washington.edu>
      wrote:


      Hello WG-II,

      As requested at the 2015 working group meeting, below are StationXML
      changes proposed by the IRIS DMC.

      If approved by the WG, the DMC will prepare a modified schema for
      technical review through a pull request on Github.

      regards,
      Chad
      IRIS DMC


      Proposed StationXML changes from the IRIS DMC:

      1) Allow the Station::CreationDate element to be optional.
      Rationale: This value denotes when a station/site was originally
      installed and is distinct from the startDate attribute used to note the
      station epoch start. There is no need for it to be required, it cannot be
      retained in conversions and many data centers do not have this information
      forcing them to set it to, e.g., the startDate.

      2) Use xs:double type instead of xs:decimal type for
      ApproximationLowerBound, ApproximationUpperBound and MaximumError values
      (in PolynomialType::ApproximationType).
      Rationale: For consistency, xs:double is used for most other floating
      point values in the schema. Also xs:double allows values in scientific
      notation.

      3) Allow the startDate attribute of Network, Station and Channel
      elements to be optional.
      Rationale: The startDate for Network is not commonly known or contained
      in SEED, forcing the insertion of potentially bad dates.

      4) Replace usage of SampleRateType with FrequencyType.
      Rationale: The two Types are effectively the same except units described
      as HERTZ versus SAMPLES/S and therefore redundant. If the replacement is
      not desired, the DecimationType::InputSampleRate should be changed to
      SampleRateType for consistency.

      5) Include data availability elements described in the
      fdsn-station+availability-1.0.xsd extension schema as optional elements of
      the main schema.
      Rationale: There is very little down side to integrating this extension
      with the main schema, maintaining and using it as a separate schema is more
      difficult and there are other time series date attributes (e.g.
      restrictedStatus) already in the schema.

      6) Allow the Channel::Response::Stage::StageGain element to be optional.
      Rationale: For some channels, e.g. SOH, there is no reasonable stage
      gain. The current required status might lead to bad values included in
      metadata.


      _______________________________________________
      fdsn-wg2-data mailing list
      fdsn-wg2-data<at>iris.washington.edu
      http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data


      _______________________________________________
      fdsn-wg2-data mailing list
      fdsn-wg2-data<at>iris.washington.edu
      http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data


      • Stephane Zuzlewski
        July 14, 2015, 9:49 a.m.

        I concur with Philip. Items 1, 2, 4 & 5 look reasonable.
        Concerning item 3, the start date is usually part of the primary key in the
        different metadata schema; not having it will make the import/export of
        FDSN Station XML into/from a database a complex operation.


        Stephane

        On 7/14/15 9:27 AM, Philip Crotwell wrote:

        Hi

        I agree with 1, 2, 4 and 5.

        But on 6 I think I agree with Florian. Can you give a concrete example
        of a channel that has a meaningful Stage, but without a StageGain? I
        can see the case of a SOH channel that has no Stages at all, for
        example it is ascii text logging messages, but why would a channel
        with no gain even have Stages or even a Response? And in cases where
        the gain is meant to be unity, I think it is better to explicitly
        state that.

        On 3, I am also not sure about making the startdate on Network,
        Station and Channel optional. The problem I worry about is that
        without that date you can't uniquely identify channels as the codes
        are often reused, BHZ last year may not be the same as BHZ today. And
        this is even occasionally the case with stations. And even with
        Networks you need the start date if it is a temporary network. XA in
        2001 might be very different from XA in 2005.

        Perhaps a better solution would be to change the meaning of the date
        in the case of networks. Instead of it being required to be the actual
        start date, it should be the start date if that is know, but if not
        then it can be some date that is known to lie within the effective
        times of the network? For example if I don't know the start time of
        the XA network, but I know the channel I am working on, within the XA
        network, started at 2001-06-01, then I can use the start date of the
        channel for the network as well, allowing the network potentially to
        be identified.

        thanks
        Philip


        On Tue, Jul 14, 2015 at 2:24 AM, Haslinger Florian
        <florian.haslinger<at>sed.ethz.ch <florian.haslinger<at>sed.ethz.ch>>
        wrote:

        Hi Chad & all,

        while reading through, one suggestion:

        to (6) Channel::Response::Stage::StageGain to be optional
        Wouldn’t it be better if there was a well defined entry for ‘not
        applicable’ and keep the field mandatory? I could imagine that
        having the entry optional (and thus not receiving an error if
        entry is not given, when checking) might lead to lassitude and
        omission of that gain value even if it was there.
        (For any decimation stages that are really part of the processing
        but that do not affect the gain - a value of ‘1’ should be used
        anyway, I would think…)


        cheers,
        florian


        On 14 Jul 2015, at 2:22 am, Chad Trabant
        <chad<at>iris.washington.edu <chad<at>iris.washington.edu>> wrote:


        Hello WG-II,

        As requested at the 2015 working group meeting, below are
        StationXML changes proposed by the IRIS DMC.

        If approved by the WG, the DMC will prepare a modified schema
        for technical review through a pull request on Github.

        regards,
        Chad
        IRIS DMC


        Proposed StationXML changes from the IRIS DMC:

        1) Allow the Station::CreationDate element to be optional.
        Rationale: This value denotes when a station/site was originally
        installed and is distinct from the startDate attribute used to
        note the station epoch start. There is no need for it to be
        required, it cannot be retained in conversions and many data
        centers do not have this information forcing them to set it to,
        e.g., the startDate.

        2) Use xs:double type instead of xs:decimal type for
        ApproximationLowerBound, ApproximationUpperBound and MaximumError
        values (in PolynomialType::ApproximationType).
        Rationale: For consistency, xs:double is used for most other
        floating point values in the schema. Also xs:double allows values
        in scientific notation.

        3) Allow the startDate attribute of Network, Station and Channel
        elements to be optional.
        Rationale: The startDate for Network is not commonly known or
        contained in SEED, forcing the insertion of potentially bad dates.

        4) Replace usage of SampleRateType with FrequencyType.
        Rationale: The two Types are effectively the same except units
        described as HERTZ versus SAMPLES/S and therefore redundant. If
        the replacement is not desired, the
        DecimationType::InputSampleRate should be changed to
        SampleRateType for consistency.

        5) Include data availability elements described in the
        fdsn-station+availability-1.0.xsd extension schema as optional
        elements of the main schema.
        Rationale: There is very little down side to integrating this
        extension with the main schema, maintaining and using it as a
        separate schema is more difficult and there are other time series
        date attributes (e.g. restrictedStatus) already in the schema.

        6) Allow the Channel::Response::Stage::StageGain element to be
        optional.
        Rationale: For some channels, e.g. SOH, there is no reasonable
        stage gain. The current required status might lead to bad values
        included in metadata.


        _______________________________________________
        fdsn-wg2-data mailing list
        fdsn-wg2-data<at>iris.washington.edu
        <fdsn-wg2-data<at>iris.washington.edu>
        http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data


        _______________________________________________
        fdsn-wg2-data mailing list
        fdsn-wg2-data<at>iris.washington.edu
        <fdsn-wg2-data<at>iris.washington.edu>
        http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data




        _______________________________________________
        fdsn-wg2-data mailing list
        fdsn-wg2-data<at>iris.washington.edu
        http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data

        --
        ------------------------------------------------------------------
        Stephane Zuzlewski University of California, Berkeley
        stephane<at>seismo.berkeley.edu Berkeley Seismological Laboratory
        Office: 510-664-9029 (Thu) 215 McCone Hall # 4760
        Fax: 510-643-5811 Berkeley, CA 94720-4760
        Remote: 209-724-9540 (Mon,Tue,Wed,Fri)


        • Chad Trabant
          July 15, 2015, 2:53 p.m.

          Hi all,

          Regarding the comments for proposal #'s 3 and 6:

          #3 In reviewing the schema, the startDate and endDate attributes are already optional. Our proposal is hereby retracted.

          To expand on the rationale for the sake of completeness: SEED information does not contain any dates for networks (start or end), so when creating StationXML from SEED information (SEED headers or database) one is required to put "something" in there. This will often be auto-generated or bogus values, which propagate and live for a long time in archives. Another reason would be to support FDSN network information, station lists, station books, etc. for networks where the start/end are unknown.


          #6 The main issue is that stages documenting sensors using polynomial response should not have sensitivity values (some SOH channels are documented with stages, but polynomial responses are the real problem). Most uses of the polynomial response description are precisely for the cases when a simple scalar relationship is not possible. Furthermore, using or recommended a dummy value of "1" could lead to blind use of the sensitivity when it would be completely wrong.

          An example: http://ncedc.org/fdsnws/station/1/query?net=BK&sta=CMB&loc=--&cha=UK2&starttime=2004-06-01T00:00:00&endtime=2004-06-02T00:00:00&level=response&format=xml&nodata=404

          In reviewing this response in more detail, it becomes clear that the InstrumentSensitivity::Value and InstrumentSensitivity::Frequency should also be optional. The reason is that a polynomial may be placed in the <InstrumentSensitivity> element to describe the total system, and then a simple linear scalar value is inappropriate. With this in mind the new proposal is:

          6) Allow the Channel::Response::Stage::StageGain, InstrumentSensitivity::Value and InstrumentSensitivity::Frequency elements to be optional.
          Rationale: These elements are inappropriate for responses using polynomial descriptions and potentially other SOH channels.

          We could document in writing that those values are required when anything but a polynomial response is used. I do not think such a rule can be codified in the XSchema language though, unless someone learns how, such a rule would not be enforceable by XML schema-document validation.

          Florian's idea of flagging the gain (and frequency) as 'not applicable' might work, but it puts a burden on all software reading the information. While this might help push for the inclusion of sensitivity values, we'll still end up with bogus ones and incur a cost of complexity for all readers. In the longer term I think we need an FDSN StationXML validation suite/program that performs both schema valuation and application of all the SEED rules that we cannot express in the XSchema language.

          cheers,
          Chad


          On Jul 14, 2015, at 9:49 AM, Stephane Zuzlewski <stephane<at>seismo.berkeley.edu> wrote:


          I concur with Philip. Items 1, 2, 4 & 5 look reasonable.
          Concerning item 3, the start date is usually part of the primary key in the
          different metadata schema; not having it will make the import/export of
          FDSN Station XML into/from a database a complex operation.


          Stephane

          On 7/14/15 9:27 AM, Philip Crotwell wrote:

          Hi

          I agree with 1, 2, 4 and 5.

          But on 6 I think I agree with Florian. Can you give a concrete example of a channel that has a meaningful Stage, but without a StageGain? I can see the case of a SOH channel that has no Stages at all, for example it is ascii text logging messages, but why would a channel with no gain even have Stages or even a Response? And in cases where the gain is meant to be unity, I think it is better to explicitly state that.

          On 3, I am also not sure about making the startdate on Network, Station and Channel optional. The problem I worry about is that without that date you can't uniquely identify channels as the codes are often reused, BHZ last year may not be the same as BHZ today. And this is even occasionally the case with stations. And even with Networks you need the start date if it is a temporary network. XA in 2001 might be very different from XA in 2005.

          Perhaps a better solution would be to change the meaning of the date in the case of networks. Instead of it being required to be the actual start date, it should be the start date if that is know, but if not then it can be some date that is known to lie within the effective times of the network? For example if I don't know the start time of the XA network, but I know the channel I am working on, within the XA network, started at 2001-06-01, then I can use the start date of the channel for the network as well, allowing the network potentially to be identified.

          thanks
          Philip


          On Tue, Jul 14, 2015 at 2:24 AM, Haslinger Florian < <florian.haslinger<at>sed.ethz.ch>florian.haslinger<at>sed.ethz.ch <florian.haslinger<at>sed.ethz.ch>> wrote:
          Hi Chad & all,

          while reading through, one suggestion:

          to (6) Channel::Response::Stage::StageGain to be optional
          Wouldn’t it be better if there was a well defined entry for ‘not applicable’ and keep the field mandatory? I could imagine that having the entry optional (and thus not receiving an error if entry is not given, when checking) might lead to lassitude and omission of that gain value even if it was there.
          (For any decimation stages that are really part of the processing but that do not affect the gain - a value of ‘1’ should be used anyway, I would think…)


          cheers,
          florian


          On 14 Jul 2015, at 2:22 am, Chad Trabant < <chad<at>iris.washington.edu>chad<at>iris.washington.edu <chad<at>iris.washington.edu>> wrote:


          Hello WG-II,

          As requested at the 2015 working group meeting, below are StationXML changes proposed by the IRIS DMC.

          If approved by the WG, the DMC will prepare a modified schema for technical review through a pull request on Github.

          regards,
          Chad
          IRIS DMC


          Proposed StationXML changes from the IRIS DMC:

          1) Allow the Station::CreationDate element to be optional.
          Rationale: This value denotes when a station/site was originally installed and is distinct from the startDate attribute used to note the station epoch start. There is no need for it to be required, it cannot be retained in conversions and many data centers do not have this information forcing them to set it to, e.g., the startDate.

          2) Use xs:double type instead of xs:decimal type for ApproximationLowerBound, ApproximationUpperBound and MaximumError values (in PolynomialType::ApproximationType).
          Rationale: For consistency, xs:double is used for most other floating point values in the schema. Also xs:double allows values in scientific notation.

          3) Allow the startDate attribute of Network, Station and Channel elements to be optional.
          Rationale: The startDate for Network is not commonly known or contained in SEED, forcing the insertion of potentially bad dates.

          4) Replace usage of SampleRateType with FrequencyType.
          Rationale: The two Types are effectively the same except units described as HERTZ versus SAMPLES/S and therefore redundant. If the replacement is not desired, the DecimationType::InputSampleRate should be changed to SampleRateType for consistency.

          5) Include data availability elements described in the fdsn-station+availability-1.0.xsd extension schema as optional elements of the main schema.
          Rationale: There is very little down side to integrating this extension with the main schema, maintaining and using it as a separate schema is more difficult and there are other time series date attributes (e.g. restrictedStatus) already in the schema.

          6) Allow the Channel::Response::Stage::StageGain element to be optional.
          Rationale: For some channels, e.g. SOH, there is no reasonable stage gain. The current required status might lead to bad values included in metadata.


          _______________________________________________
          fdsn-wg2-data mailing list
          fdsn-wg2-data<at>iris.washington.edu <fdsn-wg2-data<at>iris.washington.edu>
          http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data


          _______________________________________________
          fdsn-wg2-data mailing list
          fdsn-wg2-data<at>iris.washington.edu <fdsn-wg2-data<at>iris.washington.edu>
          http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data



          _______________________________________________
          fdsn-wg2-data mailing list
          fdsn-wg2-data<at>iris.washington.edu <fdsn-wg2-data<at>iris.washington.edu>
          http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data

          --
          ------------------------------------------------------------------
          Stephane Zuzlewski University of California, Berkeley
          stephane<at>seismo.berkeley.edu <stephane<at>seismo.berkeley.edu> Berkeley Seismological Laboratory
          Office: 510-664-9029 (Thu) 215 McCone Hall # 4760
          Fax: 510-643-5811 Berkeley, CA 94720-4760
          Remote: 209-724-9540 (Mon,Tue,Wed,Fri)
          _______________________________________________
          fdsn-wg2-data mailing list
          fdsn-wg2-data<at>iris.washington.edu
          http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data


          • Stephane Zuzlewski
            July 15, 2015, 4:30 p.m.

            Actually, the representation from the NCEDC web service for a polynomial
            response is incorrect;
            The <InstrumentPolynomial> element should be used instead of the
            <InstrumentSensitivity> one
            to represent the overall response.

            See:
            http://service.iris.edu/fdsnws/station/1/query?net=BK&sta=CMB&loc=--&cha=UK2&starttime=2004-06-01T00:00:00&endtime=2004-06-02T00:00:00&level=response&format=xml&nodata=404


            Stephane

            On 7/15/15 2:53 PM, Chad Trabant wrote:

            Hi all,

            Regarding the comments for proposal #'s 3 and 6:

            #3 In reviewing the schema, the startDate and endDate attributes are
            /already/ optional. Our proposal is hereby retracted.

            To expand on the rationale for the sake of completeness: SEED
            information does not contain any dates for networks (start or end), so
            when creating StationXML from SEED information (SEED headers or
            database) one is required to put "something" in there. This will often
            be auto-generated or bogus values, which propagate and live for a long
            time in archives. Another reason would be to support FDSN network
            information, station lists, station books, etc. for networks where the
            start/end are unknown.


            #6 The main issue is that stages documenting sensors using polynomial
            response should not have sensitivity values (some SOH channels are
            documented with stages, but polynomial responses are the real
            problem). Most uses of the polynomial response description are
            precisely for the cases when a simple scalar relationship is not
            possible. Furthermore, using or recommended a dummy value of "1"
            could lead to blind use of the sensitivity when it would be completely
            wrong.

            An example:
            http://ncedc.org/fdsnws/station/1/query?net=BK&sta=CMB&loc=--&cha=UK2&starttime=2004-06-01T00:00:00&endtime=2004-06-02T00:00:00&level=response&format=xml&nodata=404

            In reviewing this response in more detail, it becomes clear that the
            InstrumentSensitivity::Value and InstrumentSensitivity::Frequency
            should also be optional. The reason is that a polynomial may be
            placed in the <InstrumentSensitivity> element to describe the total
            system, and then a simple linear scalar value is inappropriate. With
            this in mind the new proposal is:

            6) Allow the Channel::Response::Stage::StageGain,
            InstrumentSensitivity::Value and InstrumentSensitivity::Frequency
            elements to be optional.
            Rationale: These elements are inappropriate for responses using
            polynomial descriptions and potentially other SOH channels.

            We could document in writing that those values are required when
            anything but a polynomial response is used. I do not think such a
            rule can be codified in the XSchema language though, unless someone
            learns how, such a rule would not be enforceable by XML
            schema-document validation.

            Florian's idea of flagging the gain (and frequency) as 'not
            applicable' might work, but it puts a burden on all software reading
            the information. While this might help push for the inclusion of
            sensitivity values, we'll still end up with bogus ones and incur a
            cost of complexity for all readers. In the longer term I think we
            need an FDSN StationXML validation suite/program that performs both
            schema valuation and application of all the SEED rules that we cannot
            express in the XSchema language.

            cheers,
            Chad


            On Jul 14, 2015, at 9:49 AM, Stephane Zuzlewski
            <stephane<at>seismo.berkeley.edu <stephane<at>seismo.berkeley.edu>>
            wrote:


            I concur with Philip. Items 1, 2, 4 & 5 look reasonable.
            Concerning item 3, the start date is usually part of the primary key
            in the
            different metadata schema; not having it will make the import/export of
            FDSN Station XML into/from a database a complex operation.


            Stephane

            On 7/14/15 9:27 AM, Philip Crotwell wrote:

            Hi

            I agree with 1, 2, 4 and 5.

            But on 6 I think I agree with Florian. Can you give a concrete
            example of a channel that has a meaningful Stage, but without a
            StageGain? I can see the case of a SOH channel that has no Stages at
            all, for example it is ascii text logging messages, but why would a
            channel with no gain even have Stages or even a Response? And in
            cases where the gain is meant to be unity, I think it is better to
            explicitly state that.

            On 3, I am also not sure about making the startdate on Network,
            Station and Channel optional. The problem I worry about is that
            without that date you can't uniquely identify channels as the codes
            are often reused, BHZ last year may not be the same as BHZ today.
            And this is even occasionally the case with stations. And even with
            Networks you need the start date if it is a temporary network. XA in
            2001 might be very different from XA in 2005.

            Perhaps a better solution would be to change the meaning of the date
            in the case of networks. Instead of it being required to be the
            actual start date, it should be the start date if that is know, but
            if not then it can be some date that is known to lie within the
            effective times of the network? For example if I don't know the
            start time of the XA network, but I know the channel I am working
            on, within the XA network, started at 2001-06-01, then I can use the
            start date of the channel for the network as well, allowing the
            network potentially to be identified.

            thanks
            Philip


            On Tue, Jul 14, 2015 at 2:24 AM, Haslinger Florian
            <florian.haslinger<at>sed.ethz.ch> wrote:

            Hi Chad & all,

            while reading through, one suggestion:

            to (6) Channel::Response::Stage::StageGain to be optional
            Wouldn’t it be better if there was a well defined entry for ‘not
            applicable’ and keep the field mandatory? I could imagine that
            having the entry optional (and thus not receiving an error if
            entry is not given, when checking) might lead to lassitude and
            omission of that gain value even if it was there.
            (For any decimation stages that are really part of the
            processing but that do not affect the gain - a value of ‘1’
            should be used anyway, I would think…)


            cheers,
            florian


            On 14 Jul 2015, at 2:22 am, Chad Trabant
            <chad<at>iris.washington.edu> wrote:


            Hello WG-II,

            As requested at the 2015 working group meeting, below are
            StationXML changes proposed by the IRIS DMC.

            If approved by the WG, the DMC will prepare a modified schema
            for technical review through a pull request on Github.

            regards,
            Chad
            IRIS DMC


            Proposed StationXML changes from the IRIS DMC:

            1) Allow the Station::CreationDate element to be optional.
            Rationale: This value denotes when a station/site was
            originally installed and is distinct from the startDate
            attribute used to note the station epoch start. There is no
            need for it to be required, it cannot be retained in conversions
            and many data centers do not have this information forcing them
            to set it to, e.g., the startDate.

            2) Use xs:double type instead of xs:decimal type for
            ApproximationLowerBound, ApproximationUpperBound and
            MaximumError values (in PolynomialType::ApproximationType).
            Rationale: For consistency, xs:double is used for most other
            floating point values in the schema. Also xs:double allows
            values in scientific notation.

            3) Allow the startDate attribute of Network, Station and
            Channel elements to be optional.
            Rationale: The startDate for Network is not commonly known or
            contained in SEED, forcing the insertion of potentially bad dates.

            4) Replace usage of SampleRateType with FrequencyType.
            Rationale: The two Types are effectively the same except units
            described as HERTZ versus SAMPLES/S and therefore redundant. If
            the replacement is not desired, the
            DecimationType::InputSampleRate should be changed to
            SampleRateType for consistency.

            5) Include data availability elements described in the
            fdsn-station+availability-1.0.xsd extension schema as optional
            elements of the main schema.
            Rationale: There is very little down side to integrating this
            extension with the main schema, maintaining and using it as a
            separate schema is more difficult and there are other time
            series date attributes (e.g. restrictedStatus) already in the
            schema.

            6) Allow the Channel::Response::Stage::StageGain element to be
            optional.
            Rationale: For some channels, e.g. SOH, there is no reasonable
            stage gain. The current required status might lead to bad
            values included in metadata.


            _______________________________________________
            fdsn-wg2-data mailing list
            fdsn-wg2-data<at>iris.washington.edu
            <fdsn-wg2-data<at>iris.washington.edu>
            http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data


            _______________________________________________
            fdsn-wg2-data mailing list
            fdsn-wg2-data<at>iris.washington.edu
            <fdsn-wg2-data<at>iris.washington.edu>
            http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data




            _______________________________________________
            fdsn-wg2-data mailing list
            fdsn-wg2-data<at>iris.washington.edu
            http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data

            --
            ------------------------------------------------------------------
            Stephane Zuzlewski University of California, Berkeley
            stephane<at>seismo.berkeley.edu Berkeley Seismological Laboratory
            Office: 510-664-9029 (Thu) 215 McCone Hall # 4760
            Fax: 510-643-5811 Berkeley, CA 94720-4760
            Remote: 209-724-9540 (Mon,Tue,Wed,Fri)
            _______________________________________________
            fdsn-wg2-data mailing list
            fdsn-wg2-data<at>iris.washington.edu
            <fdsn-wg2-data<at>iris.washington.edu>
            http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data



            _______________________________________________
            fdsn-wg2-data mailing list
            fdsn-wg2-data<at>iris.washington.edu
            http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data

            --
            ------------------------------------------------------------------
            Stephane Zuzlewski University of California, Berkeley
            stephane<at>seismo.berkeley.edu Berkeley Seismological Laboratory
            Office: 510-664-9029 (Thu) 215 McCone Hall # 4760
            Fax: 510-643-5811 Berkeley, CA 94720-4760
            Remote: 209-724-9540 (Mon,Tue,Wed,Fri)


            • Chad Trabant
              July 15, 2015, 4:49 p.m.

              Ah, very good point. Thanks for clarifying.

              We still need the optionality of Stage::StageGain for the case of <Polynomial> usage. Which brings us back to the original #6 proposal.

              Chad

              On Jul 15, 2015, at 4:30 PM, Stephane Zuzlewski <stephane<at>seismo.berkeley.edu> wrote:

              Actually, the representation from the NCEDC web service for a polynomial response is incorrect;
              The <InstrumentPolynomial> element should be used instead of the <InstrumentSensitivity> one
              to represent the overall response.

              See: http://service.iris.edu/fdsnws/station/1/query?net=BK&sta=CMB&loc=--&cha=UK2&starttime=2004-06-01T00:00:00&endtime=2004-06-02T00:00:00&level=response&format=xml&nodata=404


              Stephane

              On 7/15/15 2:53 PM, Chad Trabant wrote:

              Hi all,

              Regarding the comments for proposal #'s 3 and 6:

              #3 In reviewing the schema, the startDate and endDate attributes are already optional. Our proposal is hereby retracted.

              To expand on the rationale for the sake of completeness: SEED information does not contain any dates for networks (start or end), so when creating StationXML from SEED information (SEED headers or database) one is required to put "something" in there. This will often be auto-generated or bogus values, which propagate and live for a long time in archives. Another reason would be to support FDSN network information, station lists, station books, etc. for networks where the start/end are unknown.


              #6 The main issue is that stages documenting sensors using polynomial response should not have sensitivity values (some SOH channels are documented with stages, but polynomial responses are the real problem). Most uses of the polynomial response description are precisely for the cases when a simple scalar relationship is not possible. Furthermore, using or recommended a dummy value of "1" could lead to blind use of the sensitivity when it would be completely wrong.

              An example: http://ncedc.org/fdsnws/station/1/query?net=BK&sta=CMB&loc=--&cha=UK2&starttime=2004-06-01T00:00:00&endtime=2004-06-02T00:00:00&level=response&format=xml&nodata=404

              In reviewing this response in more detail, it becomes clear that the InstrumentSensitivity::Value and InstrumentSensitivity::Frequency should also be optional. The reason is that a polynomial may be placed in the <InstrumentSensitivity> element to describe the total system, and then a simple linear scalar value is inappropriate. With this in mind the new proposal is:

              6) Allow the Channel::Response::Stage::StageGain, InstrumentSensitivity::Value and InstrumentSensitivity::Frequency elements to be optional.
              Rationale: These elements are inappropriate for responses using polynomial descriptions and potentially other SOH channels.

              We could document in writing that those values are required when anything but a polynomial response is used. I do not think such a rule can be codified in the XSchema language though, unless someone learns how, such a rule would not be enforceable by XML schema-document validation.

              Florian's idea of flagging the gain (and frequency) as 'not applicable' might work, but it puts a burden on all software reading the information. While this might help push for the inclusion of sensitivity values, we'll still end up with bogus ones and incur a cost of complexity for all readers. In the longer term I think we need an FDSN StationXML validation suite/program that performs both schema valuation and application of all the SEED rules that we cannot express in the XSchema language.

              cheers,
              Chad


              On Jul 14, 2015, at 9:49 AM, Stephane Zuzlewski <stephane<at>seismo.berkeley.edu <stephane<at>seismo.berkeley.edu>> wrote:


              I concur with Philip. Items 1, 2, 4 & 5 look reasonable.
              Concerning item 3, the start date is usually part of the primary key in the
              different metadata schema; not having it will make the import/export of
              FDSN Station XML into/from a database a complex operation.


              Stephane

              On 7/14/15 9:27 AM, Philip Crotwell wrote:

              Hi

              I agree with 1, 2, 4 and 5.

              But on 6 I think I agree with Florian. Can you give a concrete example of a channel that has a meaningful Stage, but without a StageGain? I can see the case of a SOH channel that has no Stages at all, for example it is ascii text logging messages, but why would a channel with no gain even have Stages or even a Response? And in cases where the gain is meant to be unity, I think it is better to explicitly state that.

              On 3, I am also not sure about making the startdate on Network, Station and Channel optional. The problem I worry about is that without that date you can't uniquely identify channels as the codes are often reused, BHZ last year may not be the same as BHZ today. And this is even occasionally the case with stations. And even with Networks you need the start date if it is a temporary network. XA in 2001 might be very different from XA in 2005.

              Perhaps a better solution would be to change the meaning of the date in the case of networks. Instead of it being required to be the actual start date, it should be the start date if that is know, but if not then it can be some date that is known to lie within the effective times of the network? For example if I don't know the start time of the XA network, but I know the channel I am working on, within the XA network, started at 2001-06-01, then I can use the start date of the channel for the network as well, allowing the network potentially to be identified.

              thanks
              Philip


              On Tue, Jul 14, 2015 at 2:24 AM, Haslinger Florian < <florian.haslinger<at>sed.ethz.ch>florian.haslinger<at>sed.ethz.ch <florian.haslinger<at>sed.ethz.ch>> wrote:
              Hi Chad & all,

              while reading through, one suggestion:

              to (6) Channel::Response::Stage::StageGain to be optional
              Wouldn’t it be better if there was a well defined entry for ‘not applicable’ and keep the field mandatory? I could imagine that having the entry optional (and thus not receiving an error if entry is not given, when checking) might lead to lassitude and omission of that gain value even if it was there.
              (For any decimation stages that are really part of the processing but that do not affect the gain - a value of ‘1’ should be used anyway, I would think…)


              cheers,
              florian


              On 14 Jul 2015, at 2:22 am, Chad Trabant <chad<at>iris.washington.edu <chad<at>iris.washington.edu>> wrote:


              Hello WG-II,

              As requested at the 2015 working group meeting, below are StationXML changes proposed by the IRIS DMC.

              If approved by the WG, the DMC will prepare a modified schema for technical review through a pull request on Github.

              regards,
              Chad
              IRIS DMC


              Proposed StationXML changes from the IRIS DMC:

              1) Allow the Station::CreationDate element to be optional.
              Rationale: This value denotes when a station/site was originally installed and is distinct from the startDate attribute used to note the station epoch start. There is no need for it to be required, it cannot be retained in conversions and many data centers do not have this information forcing them to set it to, e.g., the startDate.

              2) Use xs:double type instead of xs:decimal type for ApproximationLowerBound, ApproximationUpperBound and MaximumError values (in PolynomialType::ApproximationType).
              Rationale: For consistency, xs:double is used for most other floating point values in the schema. Also xs:double allows values in scientific notation.

              3) Allow the startDate attribute of Network, Station and Channel elements to be optional.
              Rationale: The startDate for Network is not commonly known or contained in SEED, forcing the insertion of potentially bad dates.

              4) Replace usage of SampleRateType with FrequencyType.
              Rationale: The two Types are effectively the same except units described as HERTZ versus SAMPLES/S and therefore redundant. If the replacement is not desired, the DecimationType::InputSampleRate should be changed to SampleRateType for consistency.

              5) Include data availability elements described in the fdsn-station+availability-1.0.xsd extension schema as optional elements of the main schema.
              Rationale: There is very little down side to integrating this extension with the main schema, maintaining and using it as a separate schema is more difficult and there are other time series date attributes (e.g. restrictedStatus) already in the schema.

              6) Allow the Channel::Response::Stage::StageGain element to be optional.
              Rationale: For some channels, e.g. SOH, there is no reasonable stage gain. The current required status might lead to bad values included in metadata.


              _______________________________________________
              fdsn-wg2-data mailing list
              fdsn-wg2-data<at>iris.washington.edu <fdsn-wg2-data<at>iris.washington.edu>
              http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data


              _______________________________________________
              fdsn-wg2-data mailing list
              fdsn-wg2-data<at>iris.washington.edu <fdsn-wg2-data<at>iris.washington.edu>
              http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data



              _______________________________________________
              fdsn-wg2-data mailing list
              fdsn-wg2-data<at>iris.washington.edu <fdsn-wg2-data<at>iris.washington.edu>
              http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data

              --
              ------------------------------------------------------------------
              Stephane Zuzlewski University of California, Berkeley
              stephane<at>seismo.berkeley.edu <stephane<at>seismo.berkeley.edu> Berkeley Seismological Laboratory
              Office: 510-664-9029 (Thu) 215 McCone Hall # 4760
              Fax: 510-643-5811 Berkeley, CA 94720-4760
              Remote: 209-724-9540 (Mon,Tue,Wed,Fri)
              _______________________________________________
              fdsn-wg2-data mailing list
              fdsn-wg2-data<at>iris.washington.edu <fdsn-wg2-data<at>iris.washington.edu>
              http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data



              _______________________________________________
              fdsn-wg2-data mailing list
              fdsn-wg2-data<at>iris.washington.edu <fdsn-wg2-data<at>iris.washington.edu>
              http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data

              --
              ------------------------------------------------------------------
              Stephane Zuzlewski University of California, Berkeley
              stephane<at>seismo.berkeley.edu <stephane<at>seismo.berkeley.edu> Berkeley Seismological Laboratory
              Office: 510-664-9029 (Thu) 215 McCone Hall # 4760
              Fax: 510-643-5811 Berkeley, CA 94720-4760
              Remote: 209-724-9540 (Mon,Tue,Wed,Fri)
              _______________________________________________
              fdsn-wg2-data mailing list
              fdsn-wg2-data<at>iris.washington.edu
              http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data


              • Philip Crotwell
                July 20, 2015, 10:21 a.m.
                Hi

                Thanks for the additional information. So if I understand correctly how the
                polynomial response works, it always gives volts to "earth units",
                backwards of how other responses work, and so should never have a
                StageGain. Moreover, since it is never a digital decimation, it should also
                never have a Decimation?

                I would prefer that the schema represent these requirements rather than
                just making things optional. So, how about this change to the schema to
                address this:

                https://github.com/FDSN/StationXML/pull/2

                Philip



                On Wed, Jul 15, 2015 at 7:49 PM, Chad Trabant <chad<at>iris.washington.edu>
                wrote:


                Ah, very good point. Thanks for clarifying.

                We still need the optionality of Stage::StageGain for the case of
                <Polynomial> usage. Which brings us back to the original #6 proposal.

                Chad



                • Chad Trabant
                  July 22, 2015, 2:54 p.m.
                  Hi Philip,

                  Others have expressed a similar sentiment to leans toward enforcement of sane responses versus making things optional and I would tend to agree. I like your pull request, it is simple and I believe addresses the issue with the Polynomial usage. Thanks for thinking about it enough to generate that. The DMC would accept this pull request as an alternative to making StageGain optional (#6 in our list).

                  For those slightly more interested:
                  As for SOH channels with regards to StageGain optionality, here is an example of what we have run into:
                  http://service.iris.edu/fdsnws/station/1/query?net=CI&sta=PASC&loc=00&cha=LOG&level=response&format=xml&includecomments=true&nodata=404

                  A LOG channel with response stages and no B58 stage gain, so we cannot create a StageGain element and therefore the document is invalid.
                  Most folks would look at that and say the response shouldn't be there at all and I agree, it's something the operator should cleanup. But it is allowed in SEED. It will take some time before all of the wrinkles are ironed out of SEED-based holdings so they fit cleanly within StationXML, a useful process to be sure, we'll all be better off when most metadata is created and exchanged in StationXML.

                  Chad

                  Hi

                  Thanks for the additional information. So if I understand correctly how the polynomial response works, it always gives volts to "earth units", backwards of how other responses work, and so should never have a StageGain. Moreover, since it is never a digital decimation, it should also never have a Decimation?

                  I would prefer that the schema represent these requirements rather than just making things optional. So, how about this change to the schema to address this:

                  https://github.com/FDSN/StationXML/pull/2

                  Philip



                  On Wed, Jul 15, 2015 at 7:49 PM, Chad Trabant <chad<at>iris.washington.edu <chad<at>iris.washington.edu>> wrote:

                  Ah, very good point. Thanks for clarifying.

                  We still need the optionality of Stage::StageGain for the case of <Polynomial> usage. Which brings us back to the original #6 proposal.

                  Chad

                  _______________________________________________
                  fdsn-wg2-data mailing list
                  fdsn-wg2-data<at>iris.washington.edu
                  http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data


  • Marcelo Belentani de Bianchi
    July 15, 2015, 11:09 p.m.
    Chad,

    Regarding propose #3,

    3) Allow the startDate attribute of Network, Station and Channel
    elements to be optional. Rationale: The startDate for Network is not
    commonly known or contained in SEED, forcing the insertion of
    potentially bad dates.

    i would also enforce that network attribution by FDSN is given by years
    and networks description should enforce the attributed years. Many
    databases use this as key together with code since network codes alone
    are not unique.

    As Philip mention ...

    Perhaps a better solution would be to change the meaning of the date
    in the case of networks. Instead of it being required to be the
    actual start date, it should be the start date if that is know, but
    if not then it can be some date that is known to lie within the
    effective times of the network? For example if I don't know the start
    time of the XA network, but I know the channel I am working on,
    within the XA network, started at 2001-06-01, then I can use the
    start date of the channel for the network as well, allowing the
    network potentially to be identified.

    and this could be implemented in the tool that generate the metadata. I
    normally do that for stations dates, they grow to include all channels
    that belongs to then, but networks I normally tends to follow the
    attributed value given requested this input from the user.

    When working with permanent networks the issue is reduced, and a safer
    1980-01-01 - [open] guess fits most of the networks.

    I have no clear view on the other suggested points but looks reasonable
    at the first glance.

    regards,

    Bianchi
    --
    Dr. Marcelo Bianchi
    Centro de Sismologia da USP
    Instituto de Astronomia, Geofísica e Ciências Atmosféricas (IAG/USP)
    Rua do matão, 1226 São Paulo/SP 05508-090 Brasil
    Phone: +55 11 3091-4743 Cel: +55 11 9820-10-930
    http://moho.iag.usp.br/ http://www.iag.usp.br/

    • Catherine Pequegnat
      July 20, 2015, 6:24 a.m.
      Dear all,

      About last Marcello's comments :

      On 07/16/2015 04:09 AM, Marcelo B. de Bianchi wrote:
      Chad,

      Regarding propose #3,

      3) Allow the startDate attribute of Network, Station and Channel
      elements to be optional. Rationale: The startDate for Network is not
      commonly known or contained in SEED, forcing the insertion of
      potentially bad dates.

      i would also enforce that network attribution by FDSN is given by years
      and networks description should enforce the attributed years. Many
      databases use this as key together with code since network codes alone
      are not unique.
      we do agree. Enforce the attributed years to FDSN networks will save a
      lot of code...

      ....

      When working with permanent networks the issue is reduced, and a safer
      1980-01-01 - [open] guess fits most of the networks.
      Do not you think that it should be suitable to propose some standard
      manner to present the 'No ending date' information (at Network,
      Station,, Channel levels) in stationXML output ?


      I have no clear view on the other suggested points but looks reasonable
      at the first glance.
      Best regards

      Catherine Péquegnat
      for RESIF-DC, France


      regards,

      Bianchi
      --
      Dr. Marcelo Bianchi
      Centro de Sismologia da USP
      Instituto de Astronomia, Geofísica e Ciências Atmosféricas (IAG/USP)
      Rua do matão, 1226 São Paulo/SP 05508-090 Brasil
      Phone: +55 11 3091-4743 Cel: +55 11 9820-10-930
      http://moho.iag.usp.br/ http://www.iag.usp.br/
      _______________________________________________
      fdsn-wg2-data mailing list
      fdsn-wg2-data<at>iris.washington.edu
      http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data


      --
      Institut des Sciences de la Terre (ISTerre)

      Adresse postale: BP 53, 38041 Grenoble Cedex 9, France
      Adresse géographique: Maison de Géosciences, 1381 rue de la piscine,
      Domaine Universitaire, 38400 St Martin d'Hères

      Tél: +33 (0)4 76 63 52 48
      Fax: +33 (0)4 76 63 52 52



      • Philip Crotwell
        July 20, 2015, 11:45 a.m.
        Hi

        My understanding is that enddate is optional, and so a "currently open"
        net/station/channel simply does not have an enddate attribute.

        thanks
        Philip

        On Mon, Jul 20, 2015 at 12:24 AM, Catherine Pequegnat <
        Catherine.Pequegnat<at>ujf-grenoble.fr> wrote:

        Dear all,

        About last Marcello's comments :

        On 07/16/2015 04:09 AM, Marcelo B. de Bianchi wrote:

        Chad,

        Regarding propose #3,

        3) Allow the startDate attribute of Network, Station and Channel
        elements to be optional. Rationale: The startDate for Network is not
        commonly known or contained in SEED, forcing the insertion of
        potentially bad dates.


        i would also enforce that network attribution by FDSN is given by years
        and networks description should enforce the attributed years. Many
        databases use this as key together with code since network codes alone
        are not unique.

        we do agree. Enforce the attributed years to FDSN networks will save a lot
        of code...


        ....


        When working with permanent networks the issue is reduced, and a safer
        1980-01-01 - [open] guess fits most of the networks.

        Do not you think that it should be suitable to propose some standard
        manner to present the 'No ending date' information (at Network, Station,,
        Channel levels) in stationXML output ?


        I have no clear view on the other suggested points but looks reasonable
        at the first glance.

        Best regards

        Catherine Péquegnat
        for RESIF-DC, France


        regards,

        Bianchi
        --
        Dr. Marcelo Bianchi
        Centro de Sismologia da USP
        Instituto de Astronomia, Geofísica e Ciências Atmosféricas (IAG/USP)
        Rua do matão, 1226 São Paulo/SP 05508-090 Brasil
        Phone: +55 11 3091-4743 Cel: +55 11 9820-10-930
        http://moho.iag.usp.br/ http://www.iag.usp.br/
        _______________________________________________
        fdsn-wg2-data mailing list
        fdsn-wg2-data<at>iris.washington.edu
        http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data



        --
        Institut des Sciences de la Terre (ISTerre)

        Adresse postale: BP 53, 38041 Grenoble Cedex 9, France
        Adresse géographique: Maison de Géosciences, 1381 rue de la piscine,
        Domaine Universitaire, 38400 St Martin d'Hères

        Tél: +33 (0)4 76 63 52 48
        Fax: +33 (0)4 76 63 52 52



        _______________________________________________
        fdsn-wg2-data mailing list
        fdsn-wg2-data<at>iris.washington.edu
        http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data


    • Chad Trabant
      July 22, 2015, 4:06 p.m.

      Hi Marcelo,

      Chad,

      Regarding propose #3,

      3) Allow the startDate attribute of Network, Station and Channel
      elements to be optional. Rationale: The startDate for Network is not
      commonly known or contained in SEED, forcing the insertion of
      potentially bad dates.

      i would also enforce that network attribution by FDSN is given by years
      and networks description should enforce the attributed years. Many
      databases use this as key together with code since network codes alone
      are not unique.

      OK. Currently they are optional (the #3 proposal was retracted). If someone in this camp wants to propose making start and/or end required I suggest creating a schema modification and a pull request on github. I also suggest that the proposal comes with a procedure to be used by data centers (and others) to map purely SEED information, which does not have network start/end times, to StationXML so this can be done consistently.

      As Philip mention ...

      Perhaps a better solution would be to change the meaning of the date
      in the case of networks. Instead of it being required to be the
      actual start date, it should be the start date if that is know, but
      if not then it can be some date that is known to lie within the
      effective times of the network? For example if I don't know the start
      time of the XA network, but I know the channel I am working on,
      within the XA network, started at 2001-06-01, then I can use the
      start date of the channel for the network as well, allowing the
      network potentially to be identified.

      and this could be implemented in the tool that generate the metadata. I normally do that for stations dates, they grow to include all channels that belongs to then, but networks I normally tends to follow the attributed value given requested this input from the user.

      Philip's idea is what the DMC's stationxml-convert does when creating StationXML from dataless SEED, i.e. create a range that covers what is contained.

      This seems counter to the idea of using the network times as keys for a database, etc. I think there would be trouble as the start/end dates change based on the subset of contained stations & channels. Having real start times is crucial for temporary networks and we need some way to exchange that.

      Chad

      When working with permanent networks the issue is reduced, and a safer 1980-01-01 - [open] guess fits most of the networks.

      I have no clear view on the other suggested points but looks reasonable at the first glance.

      regards,

      Bianchi
      --
      Dr. Marcelo Bianchi
      Centro de Sismologia da USP
      Instituto de Astronomia, Geofísica e Ciências Atmosféricas (IAG/USP)
      Rua do matão, 1226 São Paulo/SP 05508-090 Brasil
      Phone: +55 11 3091-4743 Cel: +55 11 9820-10-930
      http://moho.iag.usp.br/ http://www.iag.usp.br/
      _______________________________________________
      fdsn-wg2-data mailing list
      fdsn-wg2-data<at>iris.washington.edu
      http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data



      • Philip Crotwell
        Aug. 5, 2015, 3:06 p.m.
        Have a question about 1), is there a reason to keep CreationDate and
        TerminationDate at all? My guess is that they are almost always either
        unknown and unused, or are just the min and max of all the startTime and
        endTimes from all station epochs. I guess I just don't see that a separate
        field really adds anything and maybe StationXML would be better off without
        it?

        Philip


        On Wed, Jul 22, 2015 at 7:06 PM, Chad Trabant <chad<at>iris.washington.edu>
        wrote:


        Hi Marcelo,

        Chad,

        Regarding propose #3,

        3) Allow the startDate attribute of Network, Station and Channel
        elements to be optional. Rationale: The startDate for Network is not
        commonly known or contained in SEED, forcing the insertion of
        potentially bad dates.

        i would also enforce that network attribution by FDSN is given by years
        and networks description should enforce the attributed years. Many
        databases use this as key together with code since network codes alone
        are not unique.

        OK. Currently they are optional (the #3 proposal was retracted). If
        someone in this camp wants to propose making start and/or end required I
        suggest creating a schema modification and a pull request on github. I
        also suggest that the proposal comes with a procedure to be used by data
        centers (and others) to map purely SEED information, which does not have
        network start/end times, to StationXML so this can be done consistently.

        As Philip mention ...

        Perhaps a better solution would be to change the meaning of the date
        in the case of networks. Instead of it being required to be the
        actual start date, it should be the start date if that is know, but
        if not then it can be some date that is known to lie within the
        effective times of the network? For example if I don't know the start
        time of the XA network, but I know the channel I am working on,
        within the XA network, started at 2001-06-01, then I can use the
        start date of the channel for the network as well, allowing the
        network potentially to be identified.

        and this could be implemented in the tool that generate the metadata. I
        normally do that for stations dates, they grow to include all channels that
        belongs to then, but networks I normally tends to follow the attributed
        value given requested this input from the user.

        Philip's idea is what the DMC's stationxml-convert does when creating
        StationXML from dataless SEED, i.e. create a range that covers what is
        contained.

        This seems counter to the idea of using the network times as keys for a
        database, etc. I think there would be trouble as the start/end dates
        change based on the subset of contained stations & channels. Having real
        start times is crucial for temporary networks and we need some way to
        exchange that.

        Chad

        When working with permanent networks the issue is reduced, and a safer
        1980-01-01 - [open] guess fits most of the networks.

        I have no clear view on the other suggested points but looks reasonable
        at the first glance.

        regards,

        Bianchi
        --
        Dr. Marcelo Bianchi
        Centro de Sismologia da USP
        Instituto de Astronomia, Geofísica e Ciências Atmosféricas (IAG/USP)
        Rua do matão, 1226 São Paulo/SP 05508-090 Brasil
        Phone: +55 11 3091-4743 Cel: +55 11 9820-10-930
        http://moho.iag.usp.br/ http://www.iag.usp.br/
        _______________________________________________
        fdsn-wg2-data mailing list
        fdsn-wg2-data<at>iris.washington.edu
        http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data


        _______________________________________________
        fdsn-wg2-data mailing list
        fdsn-wg2-data<at>iris.washington.edu
        http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data


  • Catherine Pequegnat
    July 20, 2015, 6:32 a.m.
    Good morning,

    And, here is two changes proposed last year by RESIF, which have already
    been proposed and discussed on the list, without any conclusion

    + The element <Vault> is presently defined at the 'Station level'. But
    the <Vault> element should rather be present at the Channel Level,
    because vault can be different 'location' by 'location' in the case of
    a complex antenna.
    It was previously said on the list that in case of a complex antenna
    description, we should use different station codes, but we do not really
    agree with that idea. Multiple examples of different values for vault
    can be found in building complex instrumentation.

    + The element <geology> is presently defined at the 'Station level'. But
    the <geology> element shoud rather be present at the Channel Level for
    each sensor (in the case of a complex antenna, for instance in slopes
    instrumentation)

    thanks in advance,
    regards,

    Catherine Péquegnat


    On 07/14/2015 02:22 AM, Chad Trabant wrote:

    Hello WG-II,

    As requested at the 2015 working group meeting, below are StationXML changes proposed by the IRIS DMC.

    If approved by the WG, the DMC will prepare a modified schema for technical review through a pull request on Github.

    regards,
    Chad
    IRIS DMC


    Proposed StationXML changes from the IRIS DMC:

    1) Allow the Station::CreationDate element to be optional.
    Rationale: This value denotes when a station/site was originally installed and is distinct from the startDate attribute used to note the station epoch start. There is no need for it to be required, it cannot be retained in conversions and many data centers do not have this information forcing them to set it to, e.g., the startDate.

    2) Use xs:double type instead of xs:decimal type for ApproximationLowerBound, ApproximationUpperBound and MaximumError values (in PolynomialType::ApproximationType).
    Rationale: For consistency, xs:double is used for most other floating point values in the schema. Also xs:double allows values in scientific notation.

    3) Allow the startDate attribute of Network, Station and Channel elements to be optional.
    Rationale: The startDate for Network is not commonly known or contained in SEED, forcing the insertion of potentially bad dates.

    4) Replace usage of SampleRateType with FrequencyType.
    Rationale: The two Types are effectively the same except units described as HERTZ versus SAMPLES/S and therefore redundant. If the replacement is not desired, the DecimationType::InputSampleRate should be changed to SampleRateType for consistency.

    5) Include data availability elements described in the fdsn-station+availability-1.0.xsd extension schema as optional elements of the main schema.
    Rationale: There is very little down side to integrating this extension with the main schema, maintaining and using it as a separate schema is more difficult and there are other time series date attributes (e.g. restrictedStatus) already in the schema.

    6) Allow the Channel::Response::Stage::StageGain element to be optional.
    Rationale: For some channels, e.g. SOH, there is no reasonable stage gain. The current required status might lead to bad values included in metadata.


    _______________________________________________
    fdsn-wg2-data mailing list
    fdsn-wg2-data<at>iris.washington.edu
    http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data



    --
    Institut des Sciences de la Terre (ISTerre)

    Adresse postale: BP 53, 38041 Grenoble Cedex 9, France
    Adresse géographique: Maison de Géosciences, 1381 rue de la piscine,
    Domaine Universitaire, 38400 St Martin d'Hères

    Tél: +33 (0)4 76 63 52 48
    Fax: +33 (0)4 76 63 52 52



  • Catherine Pequegnat
    July 20, 2015, 6:38 a.m.
    Good morning,

    The working group DOI for FDSN network has recommended the mention of
    the PID in stationXML
    cf www.fdsn.org/wgIII/V1.0-21Jul2014-DOIFDSN.pdf
    (p12)

    Could this extension be part of the next stationXML release ?

    Best regards,
    Catherine Péquegnat



    On 07/14/2015 02:22 AM, Chad Trabant wrote:

    Hello WG-II,

    As requested at the 2015 working group meeting, below are StationXML changes proposed by the IRIS DMC.

    If approved by the WG, the DMC will prepare a modified schema for technical review through a pull request on Github.

    regards,
    Chad
    IRIS DMC


    Proposed StationXML changes from the IRIS DMC:

    1) Allow the Station::CreationDate element to be optional.
    Rationale: This value denotes when a station/site was originally installed and is distinct from the startDate attribute used to note the station epoch start. There is no need for it to be required, it cannot be retained in conversions and many data centers do not have this information forcing them to set it to, e.g., the startDate.

    2) Use xs:double type instead of xs:decimal type for ApproximationLowerBound, ApproximationUpperBound and MaximumError values (in PolynomialType::ApproximationType).
    Rationale: For consistency, xs:double is used for most other floating point values in the schema. Also xs:double allows values in scientific notation.

    3) Allow the startDate attribute of Network, Station and Channel elements to be optional.
    Rationale: The startDate for Network is not commonly known or contained in SEED, forcing the insertion of potentially bad dates.

    4) Replace usage of SampleRateType with FrequencyType.
    Rationale: The two Types are effectively the same except units described as HERTZ versus SAMPLES/S and therefore redundant. If the replacement is not desired, the DecimationType::InputSampleRate should be changed to SampleRateType for consistency.

    5) Include data availability elements described in the fdsn-station+availability-1.0.xsd extension schema as optional elements of the main schema.
    Rationale: There is very little down side to integrating this extension with the main schema, maintaining and using it as a separate schema is more difficult and there are other time series date attributes (e.g. restrictedStatus) already in the schema.

    6) Allow the Channel::Response::Stage::StageGain element to be optional.
    Rationale: For some channels, e.g. SOH, there is no reasonable stage gain. The current required status might lead to bad values included in metadata.


    _______________________________________________
    fdsn-wg2-data mailing list
    fdsn-wg2-data<at>iris.washington.edu
    http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data



    --
    Institut des Sciences de la Terre (ISTerre)

    Adresse postale: BP 53, 38041 Grenoble Cedex 9, France
    Adresse géographique: Maison de Géosciences, 1381 rue de la piscine,
    Domaine Universitaire, 38400 St Martin d'Hères

    Tél: +33 (0)4 76 63 52 48
    Fax: +33 (0)4 76 63 52 52