International Federation of Digital Seismograph Networks
Thread: fdsn event changes
John Clinton
Dear FDSN WG3,
over the last year or so, the FDSN III mailing list has seen a number of comments / suggestions / requests for modifications to each of the FDSN web services. Despite often quite vigorous discussions, there has not yet been a clear path for how version updates are agreed and implemented.
I propose we use the (short) time before now and the IASPEI meeting in Kobe in the beginning of August to agree on how we as a community agree on version updates and how they are implemented, and if possible, propose some changes that may be ratified at Kobe.
An obvious modification that was basically agreed in exchanges last summer ( http://www.fdsn.org/message-center/thread/425/ ) was for the fdsnws event to support event type. I reiterate what I would propose for including the event type:
- support in the query (default = earthquake)
- add column for event type in the text output
- open question: limit event type to the quakeMl1.2 definitions, or extend to quakeML2.0, or leave free form to be defined in the local web service documentation. This last part is tricky, as there remain complications with hierarchies on the de facto (unpublished?) Storchak et al. standard for event types
We can also use a review period to
1. review other proposed changes posted to the mailing list related to fdsn-event that may also warrant inclusion in a new version
2. try to collect individual extensions to the standard and see if they should be included if relevant (eg USGS already support the event type, as well as other useful tools such as count, but also have some tools that are internal to USGS such as pager alert level - https://earthquake.usgs.gov/fdsnws/event/1/#parameters )
3. take the opportunity to tighten the existing specifications in places (e.g. where possible, directly specify which parameter in quakeMl1.2 maps for both the query and response format)
comments or thoughts?
regards,
John
over the last year or so, the FDSN III mailing list has seen a number of comments / suggestions / requests for modifications to each of the FDSN web services. Despite often quite vigorous discussions, there has not yet been a clear path for how version updates are agreed and implemented.
I propose we use the (short) time before now and the IASPEI meeting in Kobe in the beginning of August to agree on how we as a community agree on version updates and how they are implemented, and if possible, propose some changes that may be ratified at Kobe.
An obvious modification that was basically agreed in exchanges last summer ( http://www.fdsn.org/message-center/thread/425/ ) was for the fdsnws event to support event type. I reiterate what I would propose for including the event type:
- support in the query (default = earthquake)
- add column for event type in the text output
- open question: limit event type to the quakeMl1.2 definitions, or extend to quakeML2.0, or leave free form to be defined in the local web service documentation. This last part is tricky, as there remain complications with hierarchies on the de facto (unpublished?) Storchak et al. standard for event types
We can also use a review period to
1. review other proposed changes posted to the mailing list related to fdsn-event that may also warrant inclusion in a new version
2. try to collect individual extensions to the standard and see if they should be included if relevant (eg USGS already support the event type, as well as other useful tools such as count, but also have some tools that are internal to USGS such as pager alert level - https://earthquake.usgs.gov/fdsnws/event/1/#parameters )
3. take the opportunity to tighten the existing specifications in places (e.g. where possible, directly specify which parameter in quakeMl1.2 maps for both the query and response format)
comments or thoughts?
regards,
John
-
Hello John, hello everyone,
Just a quick question as you speak about quakeML2.0.
What's the status of this new quakeML version ?
As it already been formally adopted ?
Or maybe will it be adopted at Kobé ?
Otherwise, I support the event_type filtering, that would be very usefull.
Regards.
Have a nice week-end.
Jean-Marie SAUREL.
On 06/09/2017 04:06 PM, John Clinton wrote:
Dear FDSN WG3,
--
over the last year or so, the FDSN III mailing list has seen a number of
comments / suggestions / requests for modifications to each of the FDSN
web services. Despite often quite vigorous discussions, there has not
yet been a clear path for how version updates are agreed and implemented.
I propose we use the (short) time before now and the IASPEI meeting in
Kobe in the beginning of August to agree on how we as a community agree
on version updates and how they are implemented, and if possible,
propose some changes that may be ratified at Kobe.
An obvious modification that was basically agreed in exchanges last
summer ( http://www.fdsn.org/message-center/thread/425/ ) was for the
fdsnws event to support event type. I reiterate what I would propose for
including the event type:
- support in the query (default = earthquake)
- add column for event type in the text output
- open question: limit event type to the quakeMl1.2 definitions, or
extend to quakeML2.0, or leave free form to be defined in the local web
service documentation. This last part is tricky, as there remain
complications with hierarchies on the de facto (unpublished?) Storchak
et al. standard for event types
We can also use a review period to
1. review other proposed changes posted to the mailing list related to
fdsn-event that may also warrant inclusion in a new version
2. try to collect individual extensions to the standard and see if they
should be included if relevant (eg USGS already support the event type,
as well as other useful tools such as count, but also have some tools
that are internal to USGS such as pager alert level
- https://earthquake.usgs.gov/fdsnws/event/1/#parameters )
3. take the opportunity to tighten the existing specifications in places
(e.g. where possible, directly specify which parameter in quakeMl1.2
maps for both the query and response format)
comments or thoughts?
regards,
John
----------------------
FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)
Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences at http://www.fdsn.org/account/profile/
--------------------------------------
ICG-CARIBE-EWS Working Group 1 chair
Institut de Physique du Globe de Paris
Observatoires Volcanologiques
1 rue Jussieu
75238 Paris Cédex 05
+33(0)183957437
France
-
Hi all,
Just a quick question as you speak about quakeML2.0.
"QuakeML 2.0" is an umbrella term for a series of data models/schemas that are currently
What's the status of this new quakeML version ?
under development. These are thematic extensions to QuakeML 1.2, which covers only
"Basic Event Description". Some of these packages are already quite mature and are
currently under RfC. See http://quakeml.org/QuakeML2.0 .
There will also be an updated BasicEventDescription package (QuakeML-BED v1.3). This
will include mild changes to the well-known QuakeML 1.2. In particular, the event type
enumeration needs to be revised. We would like to introduce precise definitons with
literature references, and a hierarchy of terms with clear semantics. Suggestions are
welcome!
Best regards,
Fabian
As it already been formally adopted ?
--
Or maybe will it be adopted at Kobé ?
Otherwise, I support the event_type filtering, that would be very usefull.
Regards.
Have a nice week-end.
Jean-Marie SAUREL.
On 06/09/2017 04:06 PM, John Clinton wrote:
Dear FDSN WG3,
over the last year or so, the FDSN III mailing list has seen a number of
comments / suggestions / requests for modifications to each of the FDSN
web services. Despite often quite vigorous discussions, there has not
yet been a clear path for how version updates are agreed and implemented.
I propose we use the (short) time before now and the IASPEI meeting in
Kobe in the beginning of August to agree on how we as a community agree
on version updates and how they are implemented, and if possible,
propose some changes that may be ratified at Kobe.
An obvious modification that was basically agreed in exchanges last
summer ( http://www.fdsn.org/message-center/thread/425/ ) was for the
fdsnws event to support event type. I reiterate what I would propose for
including the event type:
- support in the query (default = earthquake)
- add column for event type in the text output
- open question: limit event type to the quakeMl1.2 definitions, or
extend to quakeML2.0, or leave free form to be defined in the local web
service documentation. This last part is tricky, as there remain
complications with hierarchies on the de facto (unpublished?) Storchak
et al. standard for event types
We can also use a review period to
1. review other proposed changes posted to the mailing list related to
fdsn-event that may also warrant inclusion in a new version
2. try to collect individual extensions to the standard and see if they
should be included if relevant (eg USGS already support the event type,
as well as other useful tools such as count, but also have some tools
that are internal to USGS such as pager alert level
- https://earthquake.usgs.gov/fdsnws/event/1/#parameters )
3. take the opportunity to tighten the existing specifications in places
(e.g. where possible, directly specify which parameter in quakeMl1.2
maps for both the query and response format)
comments or thoughts?
regards,
John
----------------------
FDSN Working Group III
(http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)
Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences at http://www.fdsn.org/account/profile/
-----------------------------------------------------------------------------
Fabian Euchner phone +41 44 633 7178
Institute of Geophysics fax +41 44 633 1065
ETH Zurich, NO F5 e-mail fabian<at>sed.ethz.ch
Sonneggstrasse 5 orcid.org/0000-0001-6340-7439
8092 Zurich (Switzerland)
-----------------------------------------------------------------------------
QuakeML http://quakeml.org QuakePy http://quakepy.org
CSEP http://www.cseptesting.org/centers/eth
-----------------------------------------------------------------------------
-
Hello Fabian,
Thanks for those informations.
Regarding "event type", that's also one of the limitation of QuakeML1.2
we are facing in volcanoe observatories.
Do you think it could be possible to have, in addition to the existing
or extended event types list, a possibility to reference to specific
catalogs of event types ?
I'm thinking about something similar to the SEED abbreviation
catalog/reference scheme.
This could allow to have extensive event type description, including
litterature as you point, and an event type list that could be extended
to the user specific needs.
Regards.
Jean-Marie SAUREL.
On 06/14/2017 12:33 PM, Fabian Euchner wrote:
Hi all,
--
Just a quick question as you speak about quakeML2.0.
"QuakeML 2.0" is an umbrella term for a series of data models/schemas
What's the status of this new quakeML version ?
that are currently under development. These are thematic extensions to
QuakeML 1.2, which covers only "Basic Event Description". Some of these
packages are already quite mature and are currently under RfC. See
http://quakeml.org/QuakeML2.0 .
There will also be an updated BasicEventDescription package (QuakeML-BED
v1.3). This will include mild changes to the well-known QuakeML 1.2. In
particular, the event type enumeration needs to be revised. We would
like to introduce precise definitons with literature references, and a
hierarchy of terms with clear semantics. Suggestions are welcome!
Best regards,
Fabian
As it already been formally adopted ?
implemented.
Or maybe will it be adopted at Kobé ?
Otherwise, I support the event_type filtering, that would be very usefull.
Regards.
Have a nice week-end.
Jean-Marie SAUREL.
On 06/09/2017 04:06 PM, John Clinton wrote:
Dear FDSN WG3,
over the last year or so, the FDSN III mailing list has seen a number of
comments / suggestions / requests for modifications to each of the FDSN
web services. Despite often quite vigorous discussions, there has not
yet been a clear path for how version updates are agreed and
--I propose we use the (short) time before now and the IASPEI meeting in
Kobe in the beginning of August to agree on how we as a community agree
on version updates and how they are implemented, and if possible,
propose some changes that may be ratified at Kobe.
An obvious modification that was basically agreed in exchanges last
summer ( http://www.fdsn.org/message-center/thread/425/ ) was for the
fdsnws event to support event type. I reiterate what I would propose for
including the event type:
- support in the query (default = earthquake)
- add column for event type in the text output
- open question: limit event type to the quakeMl1.2 definitions, or
extend to quakeML2.0, or leave free form to be defined in the local web
service documentation. This last part is tricky, as there remain
complications with hierarchies on the de facto (unpublished?) Storchak
et al. standard for event types
We can also use a review period to
1. review other proposed changes posted to the mailing list related to
fdsn-event that may also warrant inclusion in a new version
2. try to collect individual extensions to the standard and see if they
should be included if relevant (eg USGS already support the event type,
as well as other useful tools such as count, but also have some tools
that are internal to USGS such as pager alert level
- https://earthquake.usgs.gov/fdsnws/event/1/#parameters )
3. take the opportunity to tighten the existing specifications in places
(e.g. where possible, directly specify which parameter in quakeMl1.2
maps for both the query and response format)
comments or thoughts?
regards,
John
----------------------
FDSN Working Group III
(http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)
Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences at http://www.fdsn.org/account/profile/
-----------------------------------------------------------------------------
Fabian Euchner phone +41 44 633 7178
Institute of Geophysics fax +41 44 633 1065
ETH Zurich, NO F5 e-mail fabian<at>sed.ethz.ch
Sonneggstrasse 5 orcid.org/0000-0001-6340-7439
8092 Zurich (Switzerland)
-----------------------------------------------------------------------------
QuakeML http://quakeml.org QuakePy http://quakepy.org
CSEP http://www.cseptesting.org/centers/eth
-----------------------------------------------------------------------------
--------------------------------------
ICG-CARIBE-EWS Working Group 1 chair
Institut de Physique du Globe de Paris
Observatoires Volcanologiques
1 rue Jussieu
75238 Paris Cédex 05
+33(0)183957437
France
-
Hi Jean-Marie,
not sure whether I correctly understand what you mean.
The basic question is whether the definition of event types should be (i) included in the
standard and be fixed, or (ii) be a free-text field. The latter would allow to use URIs/URLs
of terms defined in other vocabularies, however, the drawback is that URLs are never as
stable as one hopes. Therefore, I would suggest that we use (i) and copy all useful terms
that we can find in other vocabularies into our own (and specify the semantic relation to
the other term). I have the impression that the existing QuakeML 1.2 event type list is too
detailed, especially for events that are served through fdsnws-event services (I haven't
seen any train crashes or accidental explosions so far). The task will be to find a hierarchy
that covers basic classifications of all communities, but is not unnecessarily broad.
Regards,
Fabian
Hello Fabian,
Thanks for those informations.
Regarding "event type", that's also one of the limitation of QuakeML1.2
we are facing in volcanoe observatories.
Do you think it could be possible to have, in addition to the existing
or extended event types list, a possibility to reference to specific
catalogs of event types ?
I'm thinking about something similar to the SEED abbreviation
catalog/reference scheme.
This could allow to have extensive event type description, including
litterature as you point, and an event type list that could be extended
to the user specific needs.
Regards.
Jean-Marie SAUREL.
On 06/14/2017 12:33 PM, Fabian Euchner wrote:
Hi all,
Just a quick question as you speak about quakeML2.0.
"QuakeML 2.0" is an umbrella term for a series of data models/schemas
What's the status of this new quakeML version ?
that are currently under development. These are thematic extensions to
QuakeML 1.2, which covers only "Basic Event Description". Some of these
packages are already quite mature and are currently under RfC. See
http://quakeml.org/QuakeML2.0 .
There will also be an updated BasicEventDescription package (QuakeML-BED
v1.3). This will include mild changes to the well-known QuakeML 1.2. In
particular, the event type enumeration needs to be revised. We would
like to introduce precise definitons with literature references, and a
hierarchy of terms with clear semantics. Suggestions are welcome!
Best regards,
Fabian
As it already been formally adopted ?
implemented.
Or maybe will it be adopted at Kobé ?
Otherwise, I support the event_type filtering, that would be very
usefull.
Regards.
Have a nice week-end.
Jean-Marie SAUREL.
On 06/09/2017 04:06 PM, John Clinton wrote:
Dear FDSN WG3,
over the last year or so, the FDSN III mailing list has seen a number
of
comments / suggestions / requests for modifications to each of the FDSN
web services. Despite often quite vigorous discussions, there has not
yet been a clear path for how version updates are agreed and
I propose we use the (short) time before now and the IASPEI meeting in
Kobe in the beginning of August to agree on how we as a community agree
on version updates and how they are implemented, and if possible,
propose some changes that may be ratified at Kobe.
-
Fabian,
not sure whether I correctly understand what you mean.
Well, you are pretty close.
I'm not very familiar with XML semantic, but I think I was refering to
the free-text field as a reference to a URI pointing to a more precise
description elsewhere.
The basic question is whether the definition of event types should be
I think I would favor both solutions.
(i) included in the standard and be fixed, or (ii) be a free-text field.
The latter would allow to use URIs/URLs of terms defined in other
vocabularies, however, the drawback is that URLs are never as stable as
one hopes. Therefore, I would suggest that we use (i) and copy all
useful terms that we can find in other vocabularies into our own (and
specify the semantic relation to the other term). I have the impression
that the existing QuakeML 1.2 event type list is too detailed,
especially for events that are served through fdsnws-event services (I
haven't seen any train crashes or accidental explosions so far). The
task will be to find a hierarchy that covers basic classifications of
all communities, but is not unnecessarily broad.
We would like to use the QuakeML and it's associated webservices and
tools to distribute, for example, volcano events.
If we can do so, we won't need to develop our own exotic format, nor to
maintain our own webservices code and so on.
On volcano, the identification and number of events is at least as
important as their localization, sometimes even more.
Each volcano has a unique set of event types (or event species). Some
volcano have "summit events", "deep events", some others have "LP
events", "hybrid event". A "type B volcano-tectonic event" is not
necessarily the same on two different volcano.
The problem is very similar when you deal with event classification and
wants to deal with "family 123 event" and so on.
We would like to have a way to include this diversity in the QuakeML
"event type" field. And I don't think we could ever build a definitive
list of types.
Maybe there is already an additional package in QuakeML2.0 related to
this issue. In which case it could be interesting to something in the
BasicEventDescription telling the user he must look at the extension for
more precise informations.
Regards.
Jean-Marie.
Regards,
--
Fabian
Hello Fabian,
the FDSN
Thanks for those informations.
Regarding "event type", that's also one of the limitation of QuakeML1.2
we are facing in volcanoe observatories.
Do you think it could be possible to have, in addition to the existing
or extended event types list, a possibility to reference to specific
catalogs of event types ?
I'm thinking about something similar to the SEED abbreviation
catalog/reference scheme.
This could allow to have extensive event type description, including
litterature as you point, and an event type list that could be extended
to the user specific needs.
Regards.
Jean-Marie SAUREL.
On 06/14/2017 12:33 PM, Fabian Euchner wrote:
Hi all,
Just a quick question as you speak about quakeML2.0.
"QuakeML 2.0" is an umbrella term for a series of data models/schemas
What's the status of this new quakeML version ?
that are currently under development. These are thematic extensions to
QuakeML 1.2, which covers only "Basic Event Description". Some of these
packages are already quite mature and are currently under RfC. See
http://quakeml.org/QuakeML2.0 .
There will also be an updated BasicEventDescription package (QuakeML-BED
v1.3). This will include mild changes to the well-known QuakeML 1.2. In
particular, the event type enumeration needs to be revised. We would
like to introduce precise definitons with literature references, and a
hierarchy of terms with clear semantics. Suggestions are welcome!
Best regards,
Fabian
As it already been formally adopted ?
Or maybe will it be adopted at Kobé ?
Otherwise, I support the event_type filtering, that would be very
usefull.
Regards.
Have a nice week-end.
Jean-Marie SAUREL.
On 06/09/2017 04:06 PM, John Clinton wrote:
Dear FDSN WG3,
over the last year or so, the FDSN III mailing list has seen a number
of
comments / suggestions / requests for modifications to each of
meeting in
implemented.web services. Despite often quite vigorous discussions, there has not
yet been a clear path for how version updates are agreed and
I propose we use the (short) time before now and the IASPEI
agreeKobe in the beginning of August to agree on how we as a community
local webon version updates and how they are implemented, and if possible,
propose some changes that may be ratified at Kobe.
An obvious modification that was basically agreed in exchanges last
summer ( http://www.fdsn.org/message-center/thread/425/ ) was for the
fdsnws event to support event type. I reiterate what I would propose
for
including the event type:
- support in the query (default = earthquake)
- add column for event type in the text output
- open question: limit event type to the quakeMl1.2 definitions, or
extend to quakeML2.0, or leave free form to be defined in the
Storchakservice documentation. This last part is tricky, as there remain
complications with hierarchies on the de facto (unpublished?)
related toet al. standard for event types
We can also use a review period to
1. review other proposed changes posted to the mailing list
if theyfdsn-event that may also warrant inclusion in a new version
2. try to collect individual extensions to the standard and see
type,should be included if relevant (eg USGS already support the event
(http://www.fdsn.org/message-center/)as well as other useful tools such as count, but also have some tools
that are internal to USGS such as pager alert level
- https://earthquake.usgs.gov/fdsnws/event/1/#parameters )
3. take the opportunity to tighten the existing specifications in
places
(e.g. where possible, directly specify which parameter in quakeMl1.2
maps for both the query and response format)
comments or thoughts?
regards,
John
----------------------
FDSN Working Group III
(http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)
Sent from the FDSN Message Center
http://www.fdsn.org/account/profile/Update subscription preferences at
----------------------------------------------------------------------------
-----------------------------------------------------------------------------
Fabian Euchner phone +41 44 633 7178
Institute of Geophysics fax +41 44 633 1065
ETH Zurich, NO F5 e-mail fabian<at>sed.ethz.ch
Sonneggstrasse 5 orcid.org/0000-0001-6340-7439
8092 Zurich (Switzerland)
-----------------------------------------------------------------------------
QuakeML http://quakeml.org QuakePy http://quakepy.org
CSEP http://www.cseptesting.org/centers/eth
-----
-----------------------------------------------------------------------------
Fabian Euchner phone +41 44 633 7178
Institute of Geophysics fax +41 44 633 1065
ETH Zurich, NO F5 e-mail fabian<at>sed.ethz.ch
Sonneggstrasse 5 orcid.org/0000-0001-6340-7439
8092 Zurich (Switzerland)
-----------------------------------------------------------------------------
QuakeML http://quakeml.org QuakePy http://quakepy.org
CSEP http://www.cseptesting.org/centers/eth
-----------------------------------------------------------------------------
----------------------
FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)
Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences at http://www.fdsn.org/account/profile/
--------------------------------------
ICG-CARIBE-EWS Working Group 1 chair
Institut de Physique du Globe de Paris
Observatoires Volcanologiques
1 rue Jussieu
75238 Paris Cédex 05
+33(0)183957437
France
-
-
-
-
-
Hi John, hi all,
An obvious modification that was basically agreed in exchanges last summer (
I would make the "catch all" wildcard the default, including empty/unset values. There is
http://www.fdsn.org/message-center/thread/425/ ) was for the fdsnws event
to support event type. I reiterate what I would propose for including the
event type: - support in the query (default = earthquake)
no guarantee that the underlying data model has an event type. In QuakeML, eventType is
optional and may not be set. The output from the ISC event web service, e.g., does not
include eventType.
Also, if "catch all" is the default, queries yield the same result for current services and
future eventtype-enabled ones (without using eventtype query parameter).
- open question: limit event type to the quakeMl1.2 definitions, or extend
If the results are still intended to be QuakeML 1.2, the output eventType has to be from
to quakeML2.0, or leave free form to be defined in the local web service
documentation. This last part is tricky, as there remain complications with
hierarchies on the de facto (unpublished?) Storchak et al. standard for
event types
the list defined in QuakeML 1.2. Theoretically, the allowed values for the query parameter
could be different (e.g., in order to account for "legacy" event types), but I'm not sure if
this would be helpful rather than confusing.
Best regards,
Fabian
--
-----------------------------------------------------------------------------
Fabian Euchner phone +41 44 633 7178
Institute of Geophysics fax +41 44 633 1065
ETH Zurich, NO F5 e-mail fabian<at>sed.ethz.ch
Sonneggstrasse 5 orcid.org/0000-0001-6340-7439
8092 Zurich (Switzerland)
-----------------------------------------------------------------------------
QuakeML http://quakeml.org QuakePy http://quakepy.org
CSEP http://www.cseptesting.org/centers/eth
-----------------------------------------------------------------------------
-
Hi,
Just wanted to say that the ISC-NEIC-EMSC document on event types,
mentioned by John Clinton, is available here at the ISC website
http://www.isc.ac.uk/standards/event_types/event_types.pdf.
Regards,
Dmitry
Dr. Dmitry A. Storchak
Director
International Seismological Centre (ISC)
United Kingdom
www.isc.ac.uk
+44 (0)1635 861022
On 09/06/2017 17:06, John Clinton wrote:
Dear FDSN WG3,
over the last year or so, the FDSN III mailing list has seen a number
of comments / suggestions / requests for modifications to each of the
FDSN web services. Despite often quite vigorous discussions, there has
not yet been a clear path for how version updates are agreed and
implemented.
I propose we use the (short) time before now and the IASPEI meeting in
Kobe in the beginning of August to agree on how we as a community
agree on version updates and how they are implemented, and if
possible, propose some changes that may be ratified at Kobe.
An obvious modification that was basically agreed in exchanges last
summer ( http://www.fdsn.org/message-center/thread/425/ ) was for the
fdsnws event to support event type. I reiterate what I would propose
for including the event type:
- support in the query (default = earthquake)
- add column for event type in the text output
- open question: limit event type to the quakeMl1.2 definitions, or
extend to quakeML2.0, or leave free form to be defined in the local
web service documentation. This last part is tricky, as there remain
complications with hierarchies on the de facto (unpublished?)
Storchak et al. standard for event types
We can also use a review period to
1. review other proposed changes posted to the mailing list related to
fdsn-event that may also warrant inclusion in a new version
2. try to collect individual extensions to the standard and see if
they should be included if relevant (eg USGS already support the event
type, as well as other useful tools such as count, but also have some
tools that are internal to USGS such as pager alert level -
https://earthquake.usgs.gov/fdsnws/event/1/#parameters )
3. take the opportunity to tighten the existing specifications in
places (e.g. where possible, directly specify which parameter in
quakeMl1.2 maps for both the query and response format)
comments or thoughts?
regards,
John
----------------------
FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)
Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences at http://www.fdsn.org/account/profile/
-
Hi all,
the discussion seems to have moved from the basic question ‘what to do with event types in FDSN services’ to ‘what to do about event types’ (which was one of John’s initial ‘open questions’…).
While obviously connected, I feel that it would be appropriate to try and keep these discussions separated - or at least be conscious about what exactly we are discussing.
I believe it would be worthwhile to pick up the ‘what to do about event types’ discussion again. At the end, any service or format should then ‘just implement’ the community decided definitions.
A couple of thoughts / questions on that:
- which is the appropriate body / forum to discuss (and propose/decide) event type definition standards?
From seismology, we have at least two bodies within the IASPEI framework - CoSOI (a IASPEI commission) and FDSN (having IASPEI commission status) which play a role here. To me at least it is not fully clear which of the two could claim ‘ownership’ of this issue.
But by now we also have other communities starting to share our services (data and / or formats), or being actively encouraged to share, like volcanology, infrasound, GNSS. They may have specific requests for event type definitions that we haven’t yet covered (as Jean-Marie nicely described for the volcanology case).
To me, seismology is naturally in the lead, but perhaps we should formally invite / involve the other communities (via IUGG structures?).
Sorry if that gets political, but the alternative in my view is that we just live with everybody implementing their own ideas in some private modification of a standard (thereby killing the standard…).
- how hierarchical should the event type definitions be?
The CoSOI standard (that’s what I call the ISC-NEIC-EMSC proposal forwarded by Dmitry, as - if I recall correctly - it was approved by CoSOI some years ago), has an implicit hierarchy for some types, but that is not comprehensive enough (and the hierarchy is not reflected in the structure of the definition).
The volcano use-case described by Jean-Marie indicates that a ‘private typology’ may be required (or at least very useful) in their domain, and that may be true for other domains. So perhaps the opportunity to specify such a private type definition should be provided.
Drawback / caveat: lazy people may just prefer to use the private types so that they don’t have to worry about following standards… Careful consideration is required where to draw the line between the private types and the standard ones.
- related to the above - how referential should the event type definitions be?
(see email discussion between Fabian and Jean-Marie)
should we allow ‘any’ vocabulary as long as it can be referred to? should ‘private’ vocabularies be required to come with a reference / resource link?
There are certainly various other ‘issues’ that also need to be addressed … Kobe would provide a good opportunity to discuss this further (at least in CoSOI and FDSN WGIII meetings…), and it would be great if we could collect input / views before the meeting (fully supporting John’s initial intention :-)
As I couldn’t find any generic CoSOI mailing list, I at least include its current Chair (Thomas Meier) in cc, not sure whether he is on the FDSN WGIII list.
Kind regards,
Florian
----------------------------
Swiss Seismological Service
ETH Zurich
Dr. Florian Haslinger
NO H65
Sonneggstr. 5
CH - 8092 Zürich
Switzerland
ph: +41-44-633 4670
www.seismo.ethz.chhttp://www.seismo.ethz.ch
On 15 Jun 2017, at 6:37 PM, Dmitry Storchak <dmitry<at>isc.ac.uk<dmitry<at>isc.ac.uk>> wrote:
Hi,
Just wanted to say that the ISC-NEIC-EMSC document on event types, mentioned by John Clinton, is available here at the ISC websitehttp://www.isc.ac.uk/standards/event_types/event_types.pdf.
Regards,
Dmitry
Dr. Dmitry A. Storchak
Director
International Seismological Centre (ISC)
United Kingdom
www.isc.ac.ukhttp://www.isc.ac.uk/
+44 (0)1635 861022
On 09/06/2017 17:06, John Clinton wrote:
Dear FDSN WG3,
over the last year or so, the FDSN III mailing list has seen a number of comments / suggestions / requests for modifications to each of the FDSN web services. Despite often quite vigorous discussions, there has not yet been a clear path for how version updates are agreed and implemented.
I propose we use the (short) time before now and the IASPEI meeting in Kobe in the beginning of August to agree on how we as a community agree on version updates and how they are implemented, and if possible, propose some changes that may be ratified at Kobe.
An obvious modification that was basically agreed in exchanges last summer ( http://www.fdsn.org/message-center/thread/425/ ) was for the fdsnws event to support event type. I reiterate what I would propose for including the event type:
- support in the query (default = earthquake)
- add column for event type in the text output
- open question: limit event type to the quakeMl1.2 definitions, or extend to quakeML2.0, or leave free form to be defined in the local web service documentation. This last part is tricky, as there remain complications with hierarchies on the de facto (unpublished?) Storchak et al. standard for event types
We can also use a review period to
1. review other proposed changes posted to the mailing list related to fdsn-event that may also warrant inclusion in a new version
2. try to collect individual extensions to the standard and see if they should be included if relevant (eg USGS already support the event type, as well as other useful tools such as count, but also have some tools that are internal to USGS such as pager alert level - https://earthquake.usgs.gov/fdsnws/event/1/#parameters )
3. take the opportunity to tighten the existing specifications in places (e.g. where possible, directly specify which parameter in quakeMl1.2 maps for both the query and response format)
comments or thoughts?
regards,
John
----------------------
FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)
Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences at http://www.fdsn.org/account/profile/
----------------------
FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)
Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences at http://www.fdsn.org/account/profile/
-
Hi all,
If CoSOI of IASPEI is needed for something, then it is for the jobs like
this. Indeed, all interested parties (volcanology, infrasound etc)
should be invited to take part in a corresponding working group.
Regards,
Dmitry
Dr. Dmitry A. Storchak
Director
International Seismological Centre (ISC)
United Kingdom
www.isc.ac.uk
+44 (0)1635 861022
On 16/06/2017 12:13, Florian Haslinger wrote:
Hi all,
the discussion seems to have moved from the basic question ‘what to do
with event types in FDSN services’ to ‘what to do about event types’
(which was one of John’s initial ‘open questions’…).
While obviously connected, I feel that it would be appropriate to try
and keep these discussions separated - or at least be conscious about
what exactly we are discussing.
I believe it would be worthwhile to pick up the ‘what to do about
event types’ discussion again. At the end, any service or format
should then ‘just implement’ the community decided definitions.
A couple of thoughts / questions on that:
- which is the appropriate body / forum to discuss (and
propose/decide) event type definition standards?
From seismology, we have at least two bodies within the IASPEI
framework - CoSOI (a IASPEI commission) and FDSN (having IASPEI
commission status) which play a role here. To me at least it is not
fully clear which of the two could claim ‘ownership’ of this issue.
But by now we also have other communities starting to share our
services (data and / or formats), or being actively encouraged to
share, like volcanology, infrasound, GNSS. They may have specific
requests for event type definitions that we haven’t yet covered (as
Jean-Marie nicely described for the volcanology case).
To me, seismology is naturally in the lead, but perhaps we should
formally invite / involve the other communities (via IUGG structures?).
Sorry if that gets political, but the alternative in my view is that
we just live with everybody implementing their own ideas in some
private modification of a standard (thereby killing the standard…).
- how hierarchical should the event type definitions be?
The CoSOI standard (that’s what I call the ISC-NEIC-EMSC proposal
forwarded by Dmitry, as - if I recall correctly - it was approved by
CoSOI some years ago), has an implicit hierarchy for some types, but
that is not comprehensive enough (and the hierarchy is not reflected
in the structure of the definition).
The volcano use-case described by Jean-Marie indicates that a ‘private
typology’ may be required (or at least very useful) in their domain,
and that may be true for other domains. So perhaps the opportunity to
specify such a private type definition should be provided.
Drawback / caveat: lazy people may just prefer to use the private
types so that they don’t have to worry about following standards…
Careful consideration is required where to draw the line between the
private types and the standard ones.
- related to the above - how referential should the event type
definitions be?
(see email discussion between Fabian and Jean-Marie)
should we allow ‘any’ vocabulary as long as it can be referred to?
should ‘private’ vocabularies be required to come with a reference /
resource link?
There are certainly various other ‘issues’ that also need to be
addressed … Kobe would provide a good opportunity to discuss this
further (at least in CoSOI and FDSN WGIII meetings…), and it would be
great if we could collect input / views before the meeting (fully
supporting John’s initial intention :-)
As I couldn’t find any generic CoSOI mailing list, I at least include
its current Chair (Thomas Meier) in cc, not sure whether he is on the
FDSN WGIII list.
Kind regards,
Florian
----------------------------
Swiss Seismological Service
ETH Zurich
Dr. Florian Haslinger
NO H65
Sonneggstr. 5
CH - 8092 Zürich
Switzerland
ph: +41-44-633 4670
www.seismo.ethz.ch http://www.seismo.ethz.ch
On 15 Jun 2017, at 6:37 PM, Dmitry Storchak <dmitry<at>isc.ac.uk
----------------------
<dmitry<at>isc.ac.uk>> wrote:
Hi,
Just wanted to say that the ISC-NEIC-EMSC document on event types,
mentioned by John Clinton, is available here at the ISC website
http://www.isc.ac.uk/standards/event_types/event_types.pdf.
Regards,
Dmitry
Dr. Dmitry A. Storchak
Director
International Seismological Centre (ISC)
United Kingdom
www.isc.ac.uk
+44 (0)1635 861022
On 09/06/2017 17:06, John Clinton wrote:
Dear FDSN WG3,
----------------------
over the last year or so, the FDSN III mailing list has seen a
number of comments / suggestions / requests for modifications to
each of the FDSN web services. Despite often quite vigorous
discussions, there has not yet been a clear path for how version
updates are agreed and implemented.
I propose we use the (short) time before now and the IASPEI meeting
in Kobe in the beginning of August to agree on how we as a community
agree on version updates and how they are implemented, and if
possible, propose some changes that may be ratified at Kobe.
An obvious modification that was basically agreed in exchanges last
summer ( http://www.fdsn.org/message-center/thread/425/
http://www.fdsn.org/message-center/thread/425/ ) was for the
fdsnws event to support event type. I reiterate what I would propose
for including the event type:
- support in the query (default = earthquake)
- add column for event type in the text output
- open question: limit event type to the quakeMl1.2 definitions, or
extend to quakeML2.0, or leave free form to be defined in the local
web service documentation. This last part is tricky, as there remain
complications with hierarchies on the de facto (unpublished?)
Storchak et al. standard for event types
We can also use a review period to
1. review other proposed changes posted to the mailing list related
to fdsn-event that may also warrant inclusion in a new version
2. try to collect individual extensions to the standard and see if
they should be included if relevant (eg USGS already support the
event type, as well as other useful tools such as count, but also
have some tools that are internal to USGS such as pager alert level
- https://earthquake.usgs.gov/fdsnws/event/1/#parameters )
3. take the opportunity to tighten the existing specifications in
places (e.g. where possible, directly specify which parameter in
quakeMl1.2 maps for both the query and response format)
comments or thoughts?
regards,
John
----------------------
FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)
Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences athttp://www.fdsn.org/account/profile/
FDSN Working Group III
(http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)
Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences at
http://www.fdsn.org/account/profile/
http://www.fdsn.org/account/profile/
FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)
Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences at http://www.fdsn.org/account/profile/
-
-
-
Hi John
While the conversation continues, I think to move this forward when you are ready you should bring it to the FDSN WGIII for approval in Kobe.
Specifically I think
http://www.fdsn.org/webservices/FDSN-WS-Specifications-1.1.pdf
documentation needs to be updated to identify defaults and other things related to parameter specification.
I also think that you need to coordinate this with WG II where the FDSN Schema is vetted. I think WG II is still relevant to this or do you do it within ETH? Events are a bit different than what I usually track.
So something should be brought to WG III about parameters and something to WGII for schema as needed. Then the WGs can adopt as they see fit.
Is this possible?
Cheers
Tim Ahern
Director of Data Services
IRIS
IRIS DMC
1408 NE 45th Street #201
Seattle, WA 98105
(206)547-0393 x118
(206) 547-1093 FAX
On Jun 9, 2017, at 9:06 AM, John Clinton <jclinton<at>sed.ethz.ch> wrote:
Dear FDSN WG3,
over the last year or so, the FDSN III mailing list has seen a number of comments / suggestions / requests for modifications to each of the FDSN web services. Despite often quite vigorous discussions, there has not yet been a clear path for how version updates are agreed and implemented.
I propose we use the (short) time before now and the IASPEI meeting in Kobe in the beginning of August to agree on how we as a community agree on version updates and how they are implemented, and if possible, propose some changes that may be ratified at Kobe.
An obvious modification that was basically agreed in exchanges last summer ( http://www.fdsn.org/message-center/thread/425/ ) was for the fdsnws event to support event type. I reiterate what I would propose for including the event type:
- support in the query (default = earthquake)
- add column for event type in the text output
- open question: limit event type to the quakeMl1.2 definitions, or extend to quakeML2.0, or leave free form to be defined in the local web service documentation. This last part is tricky, as there remain complications with hierarchies on the de facto (unpublished?) Storchak et al. standard for event types
We can also use a review period to
1. review other proposed changes posted to the mailing list related to fdsn-event that may also warrant inclusion in a new version
2. try to collect individual extensions to the standard and see if they should be included if relevant (eg USGS already support the event type, as well as other useful tools such as count, but also have some tools that are internal to USGS such as pager alert level - https://earthquake.usgs.gov/fdsnws/event/1/#parameters )
3. take the opportunity to tighten the existing specifications in places (e.g. where possible, directly specify which parameter in quakeMl1.2 maps for both the query and response format)
comments or thoughts?
regards,
John
----------------------
FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)
Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences at http://www.fdsn.org/account/profile/
-
Hello Tim, hello everyone,
I hope it's not too late, but I would like to submit this comment and
ask for a slight change in the webservice specification for starttime
and endtime options, regarding dataselect only.
http://www.fdsn.org/webservices/FDSN-WS-Specifications-1.1.pdf
Currently, for dataselect, it says (page 6) that starttime selects any
data on or after the value specified.
And endtime selects any data on or prior the value specified.
So the user have at most the data requested.
I would like to suggest that, for dataselect only, the starttime selects
any data starting from a block including the starttime.
And endtime selects any data ending on a block including the endtime.
The user then have at least the data requested.
* Rationale
-----------
When you have a webservice that doesn't trim the miniseed records (which
is good), the current specification implies that you will end up with
less data than you requested.
The data will start at the first block after the starttime and end at
the last block before the endtime.
If you request several channels for, let's say, some cross-correlation
computation, you will then need to trim your data to the smallest common
data portion, which might not be enough.
If you have slightly more data than asked as suggested, the user can
trim the data to the exact starttime and endtime it has requested.
Finally, from an implementation point of vue, it's way easier to find
the miniseed blocks that include the start and end time than to find the
first miniseed block that start at or doesn't include the starttime and
the last miniseed block that ends at or doesn't include the endtime.
Regards.
Jean-Marie SAUREL.
--
--------------------------------------
Institut de Physique du Globe de Paris
Observatoires Volcanologiques
1 rue Jussieu
75238 Paris Cédex 05
+33(0)183957437
France
-
Hi all,
On 07/06/2017 09:04 AM, Jean-Marie Saurel wrote:
I hope it's not too late, but I would like to submit this comment and
This is what our (SeisComp) fdsnws-dataselect implementation
ask for a slight change in the webservice specification for starttime
and endtime options, regarding dataselect only.
http://www.fdsn.org/webservices/FDSN-WS-Specifications-1.1.pdf
Currently, for dataselect, it says (page 6) that starttime selects any
data on or after the value specified.
And endtime selects any data on or prior the value specified.
So the user have at most the data requested.
I would like to suggest that, for dataselect only, the starttime selects
any data starting from a block including the starttime.
And endtime selects any data ending on a block including the endtime.
The user then have at least the data requested.
in fact does. See the illustration at Note 5 on
http://geofon.gfz-potsdam.de/waveform/webservices.php
This means
(1) our server doesn't have to break up mini-SEED records,
(2) users may receive more data than they requested, but
never less, if we have it.
So GEOFON would support Jean-Marie's suggestion above, I think.
P.
--
Dr. Peter L. Evans, Sect. 2.4 Seismology
GFZ German Research Centre for Geosciences
pevans<at>gfz-potsdam.de Tel. +49 (0)331 288-1261
http://geofon.gfz-potsdam.de/ Fax +49 (0)331 288-1277
-
Hi Peter and all
I understand the motivation but if one looks at this from the data requestor’s side rather than the data center’s side I think this would be the wrong approach, A data requestor wants to specify a start time and end time and get the data contained within their request, they are not concerned about how the data are packaged at the data center,
I think a better solution would be to modify SeisComp3 behavior and solve the problem for most of the implementations of dataselect that exist, I don’t think IRIS would want to change its current implementation that does honor the user specified times, So I would advocate for retaining the current specifications and change the SeisComp3 behavior,
Cheers
Tim Ahern
Director of Data Services
IRIS
IRIS DMC
1408 NE 45th Street #201
Seattle, WA 98105
(206)547-0393 x118
(206) 547-1093 FAX
On Jul 10, 2017, at 8:47 AM, Pete Evans <pevans<at>gfz-potsdam.de> wrote:
Hi all,
On 07/06/2017 09:04 AM, Jean-Marie Saurel wrote:
I hope it's not too late, but I would like to submit this comment and
This is what our (SeisComp) fdsnws-dataselect implementation
ask for a slight change in the webservice specification for starttime
and endtime options, regarding dataselect only.
http://www.fdsn.org/webservices/FDSN-WS-Specifications-1.1.pdf
Currently, for dataselect, it says (page 6) that starttime selects any
data on or after the value specified.
And endtime selects any data on or prior the value specified.
So the user have at most the data requested.
I would like to suggest that, for dataselect only, the starttime selects
any data starting from a block including the starttime.
And endtime selects any data ending on a block including the endtime.
The user then have at least the data requested.
in fact does. See the illustration at Note 5 on
http://geofon.gfz-potsdam.de/waveform/webservices.php
This means
(1) our server doesn't have to break up mini-SEED records,
(2) users may receive more data than they requested, but
never less, if we have it.
So GEOFON would support Jean-Marie's suggestion above, I think.
P.
--
Dr. Peter L. Evans, Sect. 2.4 Seismology
GFZ German Research Centre for Geosciences
pevans<at>gfz-potsdam.de Tel. +49 (0)331 288-1261
http://geofon.gfz-potsdam.de/ Fax +49 (0)331 288-1277
----------------------
FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)
Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences at http://www.fdsn.org/account/profile/
-
Hello Tim, hello everyone,
I didn't made the initial comment from a datacenter point of vue, but
from a user point of vue.
I understand the motivation but if one looks at this from the data
You're correct, they are not concerned about how the data is handled by
requestor’s side rather than the data center’s side I think this would
be the wrong approach, A data requestor wants to specify a start time
and end time and get the data contained within their request, they are
not concerned about how the data are packaged at the data center,
the datacenter.
But I think the data requestor usually prefers to have "at least" the
data requested than "at most", if data is available of course.
I think a better solution would be to modify SeisComp3 behavior and
The IRIS webservices currently meet the specifications, and with the
solve the problem for most of the implementations of dataselect that
exist, I don’t think IRIS would want to change its current
implementation that does honor the user specified times, So I would
proposed change, they will still meet the specifications, so no changes
will be needed.
If I'm correct, the IRIS dataselect always trim the data to the nearest
sample matching the request, and so gives "exactly" what the user needs.
As a side note, while the user is not concerned by the way the data are
handled in the data center, most advanced users wants the purest data
they can have and so would like to get the data as they were pushed in
the datacenter by the station operator, ie without any triming or data
modification.
Regards.
Jean-Marie SAUREL.
advocate for retaining the current specifications and change the
--
SeisComp3 behavior,
Cheers
Tim Ahern
Director of Data Services
IRIS
IRIS DMC
1408 NE 45th Street #201
Seattle, WA 98105
(206)547-0393 x118
(206) 547-1093 FAX
On Jul 10, 2017, at 8:47 AM, Pete Evans <pevans<at>gfz-potsdam.de
----------------------
<pevans<at>gfz-potsdam.de>> wrote:
Hi all,
On 07/06/2017 09:04 AM, Jean-Marie Saurel wrote:
I hope it's not too late, but I would like to submit this comment and
This is what our (SeisComp) fdsnws-dataselect implementation
ask for a slight change in the webservice specification for starttime
and endtime options, regarding dataselect only.
http://www.fdsn.org/webservices/FDSN-WS-Specifications-1.1.pdf
Currently, for dataselect, it says (page 6) that starttime selects any
data on or after the value specified.
And endtime selects any data on or prior the value specified.
So the user have at most the data requested.
I would like to suggest that, for dataselect only, the starttime selects
any data starting from a block including the starttime.
And endtime selects any data ending on a block including the endtime.
The user then have at least the data requested.
in fact does. See the illustration at Note 5 on
http://geofon.gfz-potsdam.de/waveform/webservices.php
This means
(1) our server doesn't have to break up mini-SEED records,
(2) users may receive more data than they requested, but
never less, if we have it.
So GEOFON would support Jean-Marie's suggestion above, I think.
P.
--
Dr. Peter L. Evans, Sect. 2.4 Seismology
GFZ German Research Centre for Geosciences
pevans<at>gfz-potsdam.de Tel. +49 (0)331 288-1261
http://geofon.gfz-potsdam.de/ Fax +49 (0)331 288-1277
----------------------
FDSN Working Group III
(http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)
Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences at http://www.fdsn.org/account/profile/
FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)
Sent from the FDSN Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences at http://www.fdsn.org/account/profile/
--------------------------------------
Institut de Physique du Globe de Paris
Observatoires Volcanologiques
1 rue Jussieu
75238 Paris Cédex 05
+33(0)183957437
France
-
On 07/10/2017 05:16 PM, Tim Ahern wrote:
I think a better solution would be to modify SeisComp3 behavior and
OK, we are changing the SC3 behavior.
solve the problem for most of the implementations of dataselect that
exist, I don’t think IRIS would want to change its current
implementation that does honor the user specified times, So I would
advocate for retaining the current specifications and change the
SeisComp3 behavior,
According to the spec [1], page 6: "The starttime parameter should be
interpreted as selecting any data or information (time series samples,
earthquake origins, metadata epochs) at times on or later than the value
specified. Similarly, the endtime selects any data or information at
times on or prior to the value specified."
AFAICS, there are 2 possibilities to honor the spec:
(1) Return less data than the user requested.
(2) Trim first and last record. (Note: with very low sample rates we
still may have to return much less data than the user requested if there
is no sample at specified time.)
I guess (2) is preferred over (1) from users' perspective, but I'm not
sure about how to implement this correctly:
1. Should the quality indicator of trimmed records be set to "M"
(modified)? Even if it was previously "Q" (quality controlled)?
2. What about flags like "beginning of event", etc.? It is undefined if
they apply to the part of record that is cut off or retained.
Regards,
Andres.
[1] http://www.fdsn.org/webservices/FDSN-WS-Specifications-1.1.pdf
-
-
-
-
Jean-Marie Saurel
Fabian Euchner
Dmitry Storchak
Florian Haslinger
Tim Ahern
Pete Evans
Andres Heinloo