International Federation of Digital Seismograph Networks

Thread: pending proposals WG2

None
Started: June 30, 2017, 10:09 p.m.
Last activity: July 12, 2017, 9:09 a.m.
Reinoud Sleeman
June 30, 2017, 10:09 p.m.


Dear FDSN WG2 members,



after the previous WG2 meeting in Prague (2015) a number of proposals for changes in StationXML have been

sent and discussed on the mailing list, and are still pending. Only the addition of the Persistent Identifier (DOI)

to the Station element has been accepted so far.



The list below provides an overview of the different proposals and replies, which - I hope - is complete and correctly

represents the general view. In case you do miss your proposal please let me know :). Also, for completeness I added

3 calls for discussion to remind you on the calls. All calls received no replies yet.



For a quick review I provided the general view: consensus or not. Based on that I suggest to accept the proposal or not.

In case you have a well-motivated different view on any my suggestions please let me know, before July 20. Otherwise

my suggestions will be the final decision for that proposal.



I will ask Chad to bundle and implement the accepted changes into the next version of the StationXML schema, which

will be version 1.1



Best regards,

Reinoud Sleeman









Calls for discussion:



Proposal of a major revision of StationXMLhttp://www.fdsn.org/message-center/thread/181/ - a proposal by ETH to design a new data model for representing seismic stations rather than applying patches and instance files of multiple versions of StationXML.



Replies: none



FDSN Station JSON schema for core seismic metadatahttp://www.fdsn.org/message-center/thread/114/ - a proposal by IRIS DMC to gather parties interested in a JSON representation of important (core) FDSN station metadata.



Replies: none



Strawman proposal for OBS data/metadata standardshttp://www.fdsn.org/message-center/thread/471/ - a strawman proposal to accept OBS best-practices as FDSN OBS standard



Replies: none





Proposals:



station xml extension for obshttp://www.fdsn.org/message-center/thread/107/ - this is an older proposal to extend StationXML with elements specific for OBS.



Replies: Two replies with questions asking for more information.



Suggestion: Not ready to accept.



vault and geology in channelhttp://www.fdsn.org/message-center/thread/116/ - this is an older proposal to add elements Vault and Geology to Channel level instead of Station level.



Reply: one support



Suggestion: accept



Persistent identifier element addition to StationXML, schema modification for technical reviewhttp://www.fdsn.org/message-center/thread/180/

This proposal adds the Persiistent Identifier element (DOI) in StationXML and has been accepted by WG2 (14 March 2016).



To be released in StationXML version 1.1.



Proposal for changes to unify response elementshttp://www.fdsn.org/message-center/thread/115 with 2 requests:

1) Change NumeratorCoefficient in FIRType to use attribute "number" instead of "i" and add attribute "number" to Numerator and Demoninator in CoefficientsType.

2) Change NumeratorCoefficient in FIRType and Numerator and Demoninator in CoefficientsType to FloatNoUnitType.



Reply: one support



Suggestion: accept



StationXML extensions proposed by the IRIS DMChttp://www.fdsn.org/message-center/thread/113/

1) Allow the Station::CreationDate element to be optional.

2) Use xs:double type instead of xs:decimal type for ApproximationLowerBound, ApproximationUpperBound and MaximumError values (in PolynomialType::ApproximationType).

4) Replace usage of SampleRateType with FrequencyType.

5) Include data availability elements described in the fdsn-station+availability-1.0.xsd extension schema as optional elements of the main schema.
6) Allow the Channel::Response::Stage::StageGain element to be optional.



Reply: many, mainly consensus



Suggestion: accept





response in Sensor and DataLoggerhttp://www.fdsn.org/message-center/thread/183/ - proposal to avoid multiple instances of similar response information by for example link to an external repository;



Replies: many, no consensus



Suggestion: not ready to accept



data availability in StationXMLhttp://www.fdsn.org/message-center/thread/192/ - proposal to expand the data availability in StationXML to include multiple data centers



Reply: one, no consensus



Suggestion: not ready to accept



remove StorageFormat from Channelhttp://www.fdsn.org/message-center/thread/193/ - data storage is a property that belongs to the waveforms, not to the metadata



Reply: one, support



Suggestion: accept



Change to <Operator>/<Agency> elementhttp://www.fdsn.org/message-center/thread/272/ - a proposal that no more than one <Agency> element is permitted within <Operator>.



Reply: one support



Suggestion: accept





Force UTC times in the StationXML schemahttp://www.fdsn.org/message-center/thread/464/ - force all datetimes to be explicitly marked as being in UTC.



Reply: several, mainly consensus



Suggestion: accept






  • Philipp Kästli
    July 11, 2017, 9:43 a.m.
    Dear Reinoud, dear WG

    there has been some discussion on whether StationXML should be changed in a minor release (keeping the structure, "add missing stuff somewhere"), a major release (including changes to the structure) or both, subsequently.
    As within the roadmap to the next generation miniseed, drafted this spring at the workshop in De Bilt, a major revision of stationXML is foreseen for year 1 and 2, I would propose to drop the idea for an anterior minor revision, and forward all accepted changes as feature requests to the major revision (otherwise, we will be required to maintain 3 different stationXML formats [in addition to full seed], and corresponding services, in the next 5 years...)






    Calls for discussion:



    Proposal of a major revision of StationXMLhttp://www.fdsn.org/message-center/thread/181/ - a proposal by ETH to design a new data model for representing seismic stations rather than applying patches and instance files of multiple versions of StationXML.



    Replies: none

    ð Has been extensively discussed in De Bilt, and added to the proposal of the work plan for miniseed 3



    FDSN Station JSON schema for core seismic metadatahttp://www.fdsn.org/message-center/thread/114/ - a proposal by IRIS DMC to gather parties interested in a JSON representation of important (core) FDSN station metadata.



    Replies: none

    ð I don't support this: it leads to fragmentation of the software implementations, thus reduced interoperability, while increasing maintenance requirements for the datacenters. With regards to the transported information content, it is, in the best case, indifferent.



    Strawman proposal for OBS data/metadata standardshttp://www.fdsn.org/message-center/thread/471/ - a strawman proposal to accept OBS best-practices as FDSN OBS standard



    ð See below





    Proposals:



    station xml extension for obshttp://www.fdsn.org/message-center/thread/107/ - this is an older proposal to extend StationXML with elements specific for OBS.



    Replies: Two replies with questions asking for more information.



    Suggestion: Not ready to accept.



    ð Should be done in the major release. Discussed proposals are still too simple, not taking into account lake instrumentation (water level cannot be derived from elevation) and the relationship of borehole and underwater instrumentation (a borehole can be at the bottom of a water body, and a borehole "on land" can be partly filled with water...)





    vault and geology in channelhttp://www.fdsn.org/message-center/thread/116/ - this is an older proposal to add elements Vault and Geology to Channel level instead of Station level.



    Reply: one support



    Suggestion: accept

    Channel is the wrong place (it is a property of a sensor location; more generally of a location with or without sensor). Adding location properties to channels would raise consistency and data management issues). Propose to introduce the concept of sensorlocation/site in the major release, and solve the problem there.



    Persistent identifier element addition to StationXML, schema modification for technical reviewhttp://www.fdsn.org/message-center/thread/180/

    This proposal adds the Persiistent Identifier element (DOI) in StationXML and has been accepted by WG2 (14 March 2016).



    To be released in StationXML version 1.1.

    ð It is actually an URI, not necessarily a DOI. Although it is the only element already decided on, I doubt it is worth introducing an extra minor revision just for this.



    Proposal for changes to unify response elementshttp://www.fdsn.org/message-center/thread/115 with 2 requests:

    1) Change NumeratorCoefficient in FIRType to use attribute "number" instead of "i" and add attribute "number" to Numerator and Demoninator in CoefficientsType.

    2) Change NumeratorCoefficient in FIRType and Numerator and Demoninator in CoefficientsType to FloatNoUnitType.



    Reply: one support



    Suggestion: accept

    ð Support, in major revision



    StationXML extensions proposed by the IRIS DMChttp://www.fdsn.org/message-center/thread/113/

    1) Allow the Station::CreationDate element to be optional.

    => would keep it mandatory - it is useful for many purposes, even if derived.

    2) Use xs:double type instead of xs:decimal type for ApproximationLowerBound, ApproximationUpperBound and MaximumError values (in PolynomialType::ApproximationType).
    => accept

    4) Replace usage of SampleRateType with FrequencyType.
    => accept

    5) Include data availability elements described in the fdsn-station+availability-1.0.xsd extension schema as optional elements of the main schema.
    => don't accept. This is not describing a seismic station. Answer the question on data availability in Wfparam/Mustang, which are describing the data holdings of a data center rather than a seismic station.
    6) Allow the Channel::Response::Stage::StageGain element to be optional.

    (no opinion)



    Reply: many, mainly consensus



    Suggestion: accept





    response in Sensor and DataLoggerhttp://www.fdsn.org/message-center/thread/183/ - proposal to avoid multiple instances of similar response information by for example link to an external repository;



    Replies: many, no consensus



    Suggestion: not ready to accept

    ð Proposals for the major revision include having top level elements for response, and address them by URI reference.



    data availability in StationXMLhttp://www.fdsn.org/message-center/thread/192/ - proposal to expand the data availability in StationXML to include multiple data centers



    Reply: one, no consensus



    Suggestion: not ready to accept

    => solve data availability in Wfparam/Mustang, which are describing the data holdings of a data center rather than a seismic station.



    remove StorageFormat from Channelhttp://www.fdsn.org/message-center/thread/193/ - data storage is a property that belongs to the waveforms, not to the metadata



    Reply: one, support



    Suggestion: accept

    ð accept



    Change to <Operator>/<Agency> elementhttp://www.fdsn.org/message-center/thread/272/ - a proposal that no more than one <Agency> element is permitted within <Operator>.



    Reply: one support



    Suggestion: accept
    => ... and one contact, yes. While you can still have multiple operators at the same time? Of the same agency? With what reference to the (unique) agency_code of station? I think the topic needs further thought, and further specification what information these tags are actually intended to hold.





    Force UTC times in the StationXML schemahttp://www.fdsn.org/message-center/thread/464/ - force all datetimes to be explicitly marked as being in UTC.



    Reply: several, mainly consensus



    Suggestion: accept
    => would make sense.


    Best regards, Philipp



    • Tim Ahern
      July 12, 2017, 9:09 a.m.
      I would support Philipp’s perspective. Lets capture all the changes at the same time.

      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 Jul 11, 2017, at 3:44 AM, Philipp Kästli @fdsn.fdsn.org <kaestli<at>sed.ethz.ch> wrote:

      Dear Reinoud, dear WG



      there has been some discussion on whether StationXML should be changed in a minor release (keeping the structure, “add missing stuff somewhere”), a major release (including changes to the structure) or both, subsequently.

      As within the roadmap to the next generation miniseed, drafted this spring at the workshop in De Bilt, a major revision of stationXML is foreseen for year 1 and 2, I would propose to drop the idea for an anterior minor revision, and forward all accepted changes as feature requests to the major revision (otherwise, we will be required to maintain 3 different stationXML formats [in addition to full seed], and corresponding services, in the next 5 years…)





      Calls for discussion:

      Proposal of a major revision of StationXML <http://www.fdsn.org/message-center/thread/181/ – a proposal by ETH to design a new data model for representing seismic stations rather than applying patches and instance files of multiple versions of StationXML.

      Replies: none
      ð Has been extensively discussed in De Bilt, and added to the proposal of the work plan for miniseed 3

      FDSN Station JSON schema for core seismic metadata <http://www.fdsn.org/message-center/thread/114/ – a proposal by IRIS DMC to gather parties interested in a JSON representation of important (core) FDSN station metadata.

      Replies: none
      ð I don’t support this: it leads to fragmentation of the software implementations, thus reduced interoperability, while increasing maintenance requirements for the datacenters. With regards to the transported information content, it is, in the best case, indifferent.

      Strawman proposal for OBS data/metadata standards <http://www.fdsn.org/message-center/thread/471/ – a strawman proposal to accept OBS best-practices as FDSN OBS standard

      ð See below


      Proposals:

      station xml extension for obs <http://www.fdsn.org/message-center/thread/107/ – this is an older proposal to extend StationXML with elements specific for OBS.

      Replies: Two replies with questions asking for more information.

      Suggestion: Not ready to accept.

      ð Should be done in the major release. Discussed proposals are still too simple, not taking into account lake instrumentation (water level cannot be derived from elevation) and the relationship of borehole and underwater instrumentation (a borehole can be at the bottom of a water body, and a borehole “on land” can be partly filled with water…)


      vault and geology in channel <http://www.fdsn.org/message-center/thread/116/ – this is an older proposal to add elements Vault and Geology to Channel level instead of Station level.

      Reply: one support

      Suggestion: accept
      Channel is the wrong place (it is a property of a sensor location; more generally of a location with or without sensor). Adding location properties to channels would raise consistency and data management issues). Propose to introduce the concept of sensorlocation/site in the major release, and solve the problem there.

      Persistent identifier element addition to StationXML, schema modification for technical review <http://www.fdsn.org/message-center/thread/180/
      This proposal adds the Persiistent Identifier element (DOI) in StationXML and has been accepted by WG2 (14 March 2016).

      To be released in StationXML version 1.1.
      ð It is actually an URI, not necessarily a DOI. Although it is the only element already decided on, I doubt it is worth introducing an extra minor revision just for this.

      Proposal for changes to unify response elements <http://www.fdsn.org/message-center/thread/115 with 2 requests:

      1) Change NumeratorCoefficient in FIRType to use attribute "number" instead of "i" and add attribute "number" to Numerator and Demoninator in CoefficientsType.

      2) Change NumeratorCoefficient in FIRType and Numerator and Demoninator in CoefficientsType to FloatNoUnitType.

      Reply: one support

      Suggestion: accept
      ð Support, in major revision

      StationXML extensions proposed by the IRIS DMC <http://www.fdsn.org/message-center/thread/113/
      1) Allow the Station::CreationDate element to be optional.
      => would keep it mandatory – it is useful for many purposes, even if derived.
      2) Use xs:double type instead of xs:decimal type for ApproximationLowerBound, ApproximationUpperBound and MaximumError values (in PolynomialType::ApproximationType).
      => accept
      4) Replace usage of SampleRateType with FrequencyType.
      => accept
      5) Include data availability elements described in the fdsn-station+availability-1.0.xsd extension schema as optional elements of the main schema.
      => don’t accept. This is not describing a seismic station. Answer the question on data availability in Wfparam/Mustang, which are describing the data holdings of a data center rather than a seismic station.
      6) Allow the Channel::Response::Stage::StageGain element to be optional.
      (no opinion)

      Reply: many, mainly consensus

      Suggestion: accept


      response in Sensor and DataLogger <http://www.fdsn.org/message-center/thread/183/ – proposal to avoid multiple instances of similar response information by for example link to an external repository;

      Replies: many, no consensus

      Suggestion: not ready to accept
      ð Proposals for the major revision include having top level elements for response, and address them by URI reference.

      data availability in StationXML <http://www.fdsn.org/message-center/thread/192/ – proposal to expand the data availability in StationXML to include multiple data centers

      Reply: one, no consensus

      Suggestion: not ready to accept

      => solve data availability in Wfparam/Mustang, which are describing the data holdings of a data center rather than a seismic station.

      remove StorageFormat from Channel <http://www.fdsn.org/message-center/thread/193/ – data storage is a property that belongs to the waveforms, not to the metadata

      Reply: one, support

      Suggestion: accept
      ð accept

      Change to <Operator>/<Agency> element <http://www.fdsn.org/message-center/thread/272/ - a proposal that no more than one <Agency> element is permitted within <Operator>.

      Reply: one support

      Suggestion: accept
      => … and one contact, yes. While you can still have multiple operators at the same time? Of the same agency? With what reference to the (unique) agency_code of station? I think the topic needs further thought, and further specification what information these tags are actually intended to hold.


      Force UTC times in the StationXML schema <http://www.fdsn.org/message-center/thread/464/ - force all datetimes to be explicitly marked as being in UTC.

      Reply: several, mainly consensus

      Suggestion: accept
      => would make sense.

      Best regards, Philipp






      ----------------------
      FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)

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