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.
Florian Haslinger
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
> _______________________________________________
> fdsn-wg2-data mailing list
> fdsn-w...@iris.washington.edu
> http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data
Stephane Zuzlewski
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....@sed.ethz.ch <mailto:florian....@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
> <mailto:fdsn-w...@iris.washington.edu>
> > http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data
>
>
> _______________________________________________
> fdsn-wg2-data mailing list
> fdsn-w...@iris.washington.edu
> <mailto:fdsn-w...@iris.washington.edu>
> http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data
>
>
>
>
> _______________________________________________
> fdsn-wg2-data mailing list
> fdsn-w...@iris.washington.edu
> http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data
--
------------------------------------------------------------------
Stephane Zuzlewski University of California, Berkeley
step...@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)
Philip Crotwell
thanks
Philip
Chad Trabant
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.
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
>> > http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data <http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data>
>>
>>
>> _______________________________________________
>> fdsn-wg2-data mailing list
>> fdsn-w...@iris.washington.edu <mailto:fdsn-w...@iris.washington.edu>
>> http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data <http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data>
>>
>>
>>
>> _______________________________________________
>> fdsn-wg2-data mailing list
>> fdsn-w...@iris.washington.edu <mailto:fdsn-w...@iris.washington.edu>
>> http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data <http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data>
>
> --
> ------------------------------------------------------------------
> Stephane Zuzlewski University of California, Berkeley
> step...@seismo.berkeley.edu <mailto:step...@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)
Stephane Zuzlewski
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.
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.
>> <step...@seismo.berkeley.edu <mailto:step...@seismo.berkeley.edu>>
>>> <florian....@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
>>> _______________________________________________
>>> fdsn-wg2-data mailing list
>>> fdsn-w...@iris.washington.edu
>>> http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data
>>
>> --
>> ------------------------------------------------------------------
>> Stephane Zuzlewski University of California, Berkeley
>> step...@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-w...@iris.washington.edu
>> <mailto:fdsn-w...@iris.washington.edu>
>> http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data
>
>
>
> _______________________________________________
> fdsn-wg2-data mailing list
> fdsn-w...@iris.washington.edu
> http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data
--
------------------------------------------------------------------
Stephane Zuzlewski University of California, Berkeley
step...@seismo.berkeley.edu Berkeley Seismological Laboratory
Chad Trabant
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 <step...@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 <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 <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>
>>>> > http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data <http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data>
>>>>
>>>>
>>>> _______________________________________________
>>>> fdsn-wg2-data mailing list
>>>> fdsn-w...@iris.washington.edu <mailto:fdsn-w...@iris.washington.edu>
>>>> http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data <http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> fdsn-wg2-data mailing list
>>>> fdsn-w...@iris.washington.edu <mailto:fdsn-w...@iris.washington.edu>
>>>> http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data <http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data>
>>>
>>> --
>>> ------------------------------------------------------------------
>>> Stephane Zuzlewski University of California, Berkeley
>>> step...@seismo.berkeley.edu <mailto:step...@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-w...@iris.washington.edu <mailto:fdsn-w...@iris.washington.edu>
>>> http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data <http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data>
>>
>>
>>
>> _______________________________________________
>> fdsn-wg2-data mailing list
>> fdsn-w...@iris.washington.edu <mailto:fdsn-w...@iris.washington.edu>
>> http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data <http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data>
>
> --
> ------------------------------------------------------------------
> Stephane Zuzlewski University of California, Berkeley
> step...@seismo.berkeley.edu <mailto:step...@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-w...@iris.washington.edu
> http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data
Marcelo Belentani de Bianchi
Regarding propose #3,
> 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.
i would also enforce that network attribution by FDSN is given by years
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
> 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.
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.
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/
Catherine Pequegnat
About last Marcello's comments :
On 07/16/2015 04:09 AM, Marcelo B. de Bianchi wrote:
> Chad,
>
> Regarding propose #3,
>
>> 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.
>
> i would also enforce that network attribution by FDSN is given by years
> and networks description should enforce the attributed years. Many
> databases use this as key together with code since network codes alone
> are not unique.
we do agree. Enforce the attributed years to FDSN networks will save a
lot of code...
>
....
>
> When working with permanent networks the issue is reduced, and a safer
> 1980-01-01 - [open] guess fits most of the networks.
Do not you think that it should be suitable to propose some standard
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
> at the first glance.
Best regards
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-w...@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
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 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
Catherine Pequegnat
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:
>
Philip Crotwell
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 <ch...@iris.washington.edu>
wrote:
Philip Crotwell
My understanding is that enddate is optional, and so a "currently open"
net/station/channel simply does not have an enddate attribute.
thanks
Philip
Chad Trabant
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 <https://github.com/FDSN/StationXML/pull/2>
>
> Philip
>
>
>
> On Wed, Jul 15, 2015 at 7:49 PM, Chad Trabant <ch...@iris.washington.edu <mailto:ch...@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
>
Chad Trabant
Hi Marcelo,
> Chad,
>
> Regarding propose #3,
>
>> 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.
>
> i would also enforce that network attribution by FDSN is given by years
> and networks description should enforce the attributed years. Many
> databases use this as key together with code since network codes alone
> are not unique.
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.
> As Philip mention ...
>
>> 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.
>
> 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.
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/
Philip Crotwell
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 <ch...@iris.washington.edu>
wrote:
>