Discussion lists are for back-and-forth exchanges among a smaller audience.
Only subscribers can post (most of the time), and subscriptions have to be approved.
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]
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]
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]
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]
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]
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]