International Federation of Digital Seismograph Networks

FDSN Working Group II

Data Format, Data Centers and Software

Email address
fdsn-wg2-data@lists.fdsn.org
Type
Subscribers
162
Moderated by
Philip Crotwell, Javier Quinteros, IRIS Webmaster
Login to manage your subscriptions
March
February
January
December
November
October (1)
September
August (1)
July (3)
June
May
April (25)
March (1)
February
January
December
November
October
September (1)
August (8)
July (1)
June
May
April
March
February
January
December (2)
November (23)
October
September (1)
August
July
June
May (1)
April
March (4)
February
January
December
November
October
September
August
July (2)
June
May (1)
April (2)
March
February
January
December
November
October
September
August
July
June (1)
May
April (1)
March
February (2)
January (5)
December (1)
November (10)
October
September
August (2)
July (7)
June
May
April
March
February (1)
January
December
November
October
September (3)
August
July (3)
June (1)
May (5)
April
March (1)
February
January
December
November
October
September
August
July (10)
June
May
April (1)
March
February
January
December (1)
November (9)
October
September
August
July
June
May (2)
April
March
February
January
December
November
October
September
August
July
June (4)
May
April
March
February
January (6)
December (1)
November
October
September
August
July
June
May (1)
April (5)
March (5)
February
January
December
November
October
September
August
July
June
May
April
March
February
January (6)
December
November
October
September
August
July
June
May
April
March
February
January
December
November (2)
October (2)
September
August
July
June (1)

Active Message Threads for August 2015

Philip Crotwell
2015-08-03 16:34:11 - 2015-08-11 19:30:53
One issue I have with the existing StationXML is that it can be very large and with much repeated information, particularly for responses. For example, it is very common to have 3 components of motion recorded at a station on a single "sensor" for which the response of the 3 channels are identical, but the information is repeated for each channel. Moreover, the response is very often the nominal response of that model of sensor, and so is repeated for all stations with that model sensor. Simila… [more]
Replies
Philip Crotwell
2015-08-05 22:30:31 - 2015-08-06 00:01:19
Hi Is it worth expanding the data availability in the next StationXML to include multiple data centers? For example, suppose: dataCenterA has metadata for all of network XX has waveforms for station XX.AAA but not XX.BBB has information of data availability for station XX.BBB at dataCenterB dataCenterB has waveforms for station XX.BBB Then it would be useful to the client when getting metadata about network XX from dataCenterA to learn about the availability of waveforms at … [more]
Replies
Tobias Megies
2015-07-21 19:40:15 - 2015-08-05 23:46:43
Hi Fabian, hi Philipp, good to see that development of QuakeML is still active! However, I have some critical comments: A) I find it extremely hard to keep track of changes introduced in recent times. You mention bugfixes and clean-up to elements of QuakeML 1.2.. where can I find a list of changes? B) Is the version control system to keep track of changes publicly visible somewhere? I would strongly encourage to have some sort of schema file (probably rather RelaxNG than XSD, see earlier pro… [more]
Replies
Philip Crotwell
2015-08-05 22:50:20
Hi I think that StorageFormat probably should be removed from the ChannelType. This is supposedly to represent the data storage, like SEED or miniSeed, but that seems to me to really be a property of the waveform itself and not the metadata. And because the same waveform can be requested in several different formats, all of which might share the same stationxml file, it really doesn't make sense. This came up in the discussions of SIS ( http://maui.gps.caltech.edu/SIStrac/wiki/SIS/UI). Pull … [more]
Replies
Chad Trabant
2015-07-14 00:22:58 - 2015-08-05 22:06:15
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 no… [more]
Replies
Philip Crotwell
2015-08-05 17:25:01
Is it worth expanding the data availability in the next StationXML to include multiple data centers? For example, suppose: dataCenterA has metadata for all of network XX has waveforms for station XX.AAA but not XX.BBB has information of data availability for station XX.BBB at dataCenterB dataCenterB has waveforms for station XX.BBB Then it would be useful to the client when getting metadata about network XX from dataCenterA to learn about the availability of waveforms at data… [more]
No replies