International Federation of Digital Seismograph Networks
Thread: StationXML extensions proposed by the IRIS DMC
Chad Trabant
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.
-
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
-
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,
changes proposed by the IRIS DMC.
As requested at the 2015 working group meeting, below are StationXML
If approved by the WG, the DMC will prepare a modified schema for
technical review through a pull request on Github.
regards,
installed and is distinct from the startDate attribute used to note the
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
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.
as HERTZ versus SAMPLES/S and therefore redundant. If the replacement is
Rationale: The two Types are effectively the same except units described
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.
gain. The current required status might lead to bad values included in
Rationale: For some channels, e.g. SOH, there is no reasonable stage
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
-
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,
StationXML changes proposed by the IRIS DMC.
As requested at the 2015 working group meeting, below are
If approved by the WG, the DMC will prepare a modified schema
for technical review through a pull request on Github.
regards,
installed and is distinct from the startDate attribute used to
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
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.
described as HERTZ versus SAMPLES/S and therefore redundant. If
Rationale: The two Types are effectively the same except units
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<at>iris.washington.edu>
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
<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)
-
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
-
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,
StationXML changes proposed by the IRIS DMC.
As requested at the 2015 working group meeting, below are
If approved by the WG, the DMC will prepare a modified schema
for technical review through a pull request on Github.
regards,
originally installed and is distinct from the startDate
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
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.
described as HERTZ versus SAMPLES/S and therefore redundant. If
Rationale: The two Types are effectively the same except units
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<at>iris.washington.edu>
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
<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)
-
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
-
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
-
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
-
-
-
-
-
-
-
-
Chad,
Regarding propose #3,
3) Allow the startDate attribute of Network, Station and Channel
i would also enforce that network attribution by FDSN is given by years
elements to be optional. Rationale: The startDate for Network is not
commonly known or contained in SEED, forcing the insertion of
potentially bad dates.
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
and this could be implemented in the tool that generate the metadata. I
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.
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/
-
Dear all,
About last Marcello's comments :
On 07/16/2015 04:09 AM, Marcelo B. de Bianchi wrote:
Chad,
we do agree. Enforce the attributed years to FDSN networks will save a
Regarding propose #3,
3) Allow the startDate attribute of Network, Station and Channel
i would also enforce that network attribution by FDSN is given by years
elements to be optional. Rationale: The startDate for Network is not
commonly known or contained in SEED, forcing the insertion of
potentially bad dates.
and networks description should enforce the attributed years. Many
databases use this as key together with code since network codes alone
are not unique.
lot of code...
....
When working with permanent networks the issue is reduced, and a safer
Do not you think that it should be suitable to propose some standard
1980-01-01 - [open] guess fits most of the networks.
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
Best regards
at the first glance.
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
-
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,
we do agree. Enforce the attributed years to FDSN networks will save a lot
Regarding propose #3,
3) Allow the startDate attribute of Network, Station and Channel
elements to be optional. Rationale: The startDate for Network is not
i would also enforce that network attribution by FDSN is given by years
commonly known or contained in SEED, forcing the insertion of
potentially bad dates.
and networks description should enforce the attributed years. Many
databases use this as key together with code since network codes alone
are not unique.
of code...
....
Do not you think that it should be suitable to propose some standard
When working with permanent networks the issue is reduced, and a safer
1980-01-01 - [open] guess fits most of the networks.
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
Best regards
at the first glance.
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
-
-
Hi Marcelo,
Chad,
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.
Regarding propose #3,
3) Allow the startDate attribute of Network, Station and Channel
i would also enforce that network attribution by FDSN is given by years
elements to be optional. Rationale: The startDate for Network is not
commonly known or contained in SEED, forcing the insertion of
potentially bad dates.
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 ...
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.
Perhaps a better solution would be to change the meaning of the date
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.
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.
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
-
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,
OK. Currently they are optional (the #3 proposal was retracted). If
Regarding propose #3,
3) Allow the startDate attribute of Network, Station and Channel
i would also enforce that network attribution by FDSN is given by years
elements to be optional. Rationale: The startDate for Network is not
commonly known or contained in SEED, forcing the insertion of
potentially bad dates.
and networks description should enforce the attributed years. Many
databases use this as key together with code since network codes alone
are not unique.
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 ...
normally do that for stations dates, they grow to include all channels that
Perhaps a better solution would be to change the meaning of the date
and this could be implemented in the tool that generate the metadata. I
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.
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
-
-
-
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
-
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
Florian Haslinger
Philip Crotwell
Stephane Zuzlewski
Marcelo Belentani de Bianchi
Catherine Pequegnat