pending proposals WG2

0 views

Skip to first unread message

Reinoud Sleeman

unread,

Jul 1, 2017, 8:09:53 AM7/1/17

to fdsn-w...@fdsn.org

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 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

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

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

Replies: none

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.

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

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.

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

StationXML extensions proposed by the IRIS DMC<http://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 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

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

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

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

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

Philipp Kästli

unread,

Jul 11, 2017, 7:43:25 PM7/11/17

to fdsn-w...@fdsn.org

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:

Replies: none

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

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

Tim Ahern

unread,

Jul 12, 2017, 7:09:46 PM7/12/17

to fdsn-w...@fdsn.org

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 <kae...@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/ <http://www.fdsn.org/message-center/topic/fdsn-wg2-data/>)
>
> Sent from the FDSN Message Center (http://www.fdsn.org/message-center/ <http://www.fdsn.org/message-center/>)
> Update subscription preferences at http://www.fdsn.org/account/profile/ <http://www.fdsn.org/account/profile/>

Reply all

Reply to author

Forward

0 new messages