Thread: pending proposals WG2

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/