...new subject line to keep separate proposals separate...
I feel it would be ok to add Vault and Geology to Channel, with
documentation that says that if it is specified in both Station and Channel
then the Channel takes precedence. Having it in both places would allow
backwards compatibility and allow the majority of stations where these are
common to only specify it once.
On Mon, Jul 20, 2015 at 12:32 AM, Catherine Pequegnat <
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
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
thanks in advance,
On 07/14/2015 02:22 AM, Chad Trabant wrote:
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.
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
Rationale: For consistency, xs:double is used for most other floating
point values in the schema. Also xs:double allows values in scientific
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
fdsn-wg2-data mailing list
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