I am attaching a draft agenda that identifies the topics of discussion as well as giving the time and meeting place. I am also attaching a straw man document that several groups in the US have discussed. The straw man may help us as it provides a starting point for our discussions as well as giving you a sense of some of the considerations we have identified as being important.
We wil be proposing a Request for Comment (RFC) process to reach closure on the next version with specific timelines in mind. The proposed process will be presented at the meeting as we are still developing the RFC approach we will propose.
And here is the draft proposal with some of our thoughts on this topic
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
Hello Joachim,
The previous discussion, as you write, was about StationXML. A central issue in the discussion was that without a corresponding change in (mini)SEED the two formats would be out of sync in regards to requirements. A new version of miniSEED is the right time to consider such a change.
Review the end of the discussion: http://www.iris.washington.edu/pipermail/fdsn-wg2-data/2014-September/000072.html
and note that the (mini)SEED discussion was yet to be conducted. The arguments for why an empty string location ID are problematic remain the same.
regards,
Chad
Hello Tim,
To make the best use of our time during this meeting I attach a series of slides with description and rationale for each of the changes in the straw man. Ideally, this will allow us to spend more time discussing the issues and less time overviewing each topic. This is intended to be the start of a process, we fully expect that some of the details will modified, some changes deemed not necessary and other changes proposed.
Chad Trabant
IRIS DMC
> On Mar 31, 2016, at 8:44 AM, Tim Ahern <t...@iris.washington.edu> wrote:
>
> Hello everyone, You are receiving this email because either you were in the initial list I sent the announcement to, are a member of FDSN WGII or WGIII or have expressed an interest in attending these discussions at the EGU. This includes a good mix of FDSN Network and data center personnel as well as representatives from equipment manufacturers.
>
> I am attaching a draft agenda that identifies the topics of discussion as well as giving the time and meeting place. I am also attaching a straw man document that several groups in the US have discussed. The straw man may help us as it provides a starting point for our discussions as well as giving you a sense of some of the considerations we have identified as being important.
>
> We wil be proposing a Request for Comment (RFC) process to reach closure on the next version with specific timelines in mind. The proposed process will be presented at the meeting as we are still developing the RFC approach we will propose.
>
>
> <Agenda-miniSeed-SOH.pdf>
>
> And here is the draft proposal with some of our thoughts on this topic
>
> <Next-Generation-miniSEED-2016-3-30.pdf>
> Chad Trabant wrote on 04/15/16 17:08:
>> he arguments for why an empty string location ID are problematic remain the same.
>
> The same is true for the arguments that were put forward *against*
> disallowing non-empty location identifiers.
This is not quite correct. The previous discussion was for StationXML and the argument that the representation between StationXML and miniSEED would be out of sync no longer applies.
I agree with your implication that the ability to transition to the next version of the format is very important. Regarding any potential change to location ID, this is still possible; keep in mind that all users are already used to specifying the location ID as something other than an empty string (out of necessity). There are other proposed changes and likely more that will come up that also impact forward compatibility and a transition.
Regardless, I think this should be discussed at the miniSEED level, it is the right place after all.
Chad
Chad Trabant wrote on 04/15/16 17:08:
> he arguments for why an empty string location ID are problematic remain the same.
The same is true for the arguments that were put forward *against*
disallowing non-empty location identifiers.
Empty location identifiers are a very common reality and have been for
many years. Definitely not without good reasons. If data centers had
wanted to use a non-empty location identifier they could have done so
(some have done) and still can. Seismologists have learned to work with
both empty and non-empty location identifiers.
The new specification, meant to ease restrictions w.r.t. channel naming,
should not enforce new restrictions which are not only unneeded but
would create additional complexity and confusion. This would be
counterproductive to a seamless transition between MiniSEED versions.
Cheers
Joachim
Chad Trabant wrote on 04/18/16 11:34:
>> Chad Trabant wrote on 04/15/16 17:08:
>>> he arguments for why an empty string location ID are problematic
>>> remain the same.
>>
>> The same is true for the arguments that were put forward *against*
>> disallowing non-empty location identifiers.
>
> This is not quite correct. The previous discussion was for StationXML
> and the argument that the representation between StationXML and miniSEED
> would be out of sync no longer applies.
The previous discussion was in fact about channel naming and location ID
naming in particular. StationXML happened to be the context at that
time, now it's the future MiniSEED. The issue remains the same.
It's clear that channel naming must be independent of the data format.
To the extent the main data format allows technically, of course, but
the purpose of the proposed changes is to relax some of the previously
quite tight length limits. So let's not impose new limits.
> I agree with your implication that the ability to transition to the next
> version of the format is very important. Regarding any potential change
> to location ID, this is still possible; keep in mind that all users are
> already used to *specifying* the location ID as something other than an
> empty string (out of necessity).
Interfaces are one thing, data encoding is another. A time formatted
like "2016-04-18T10:11:12.345678" is used in a request but a different,
binary encoding is used in the MiniSEED header. Likewise it may be
natural to write "--" in a data request file containing space-separated
columns. Out of necessity, but that necessity arises from the use of
spaces as column separators in a particular interface, not from the
encoding of the location ID itself.
Cheers
Joachim
Please make note of the following FIRM deadline of July 8, 2016. Send your comments to the FDSN WG II list
Subsequent iterations will allow only three weeks for comments after the editors have produced the next version of the straw man.
We will still stick with a total of 4 iterations.
The timing is driven by the calendar and when the FDSN will next meet.
Cheers and thanks for adhering to this new deadline for Iteration 1 comments and the 3 week period for the next 3 iterations.
Tim Ahern
Director of Data Services
IRIS
IRIS DMC
1408 NE 45th Street #201
Seattle, WA 98105
> On Mar 31, 2016, at 8:44 AM, Tim Ahern <t...@iris.washington.edu> wrote:
>
> Hello everyone, You are receiving this email because either you were in the initial list I sent the announcement to, are a member of FDSN WGII or WGIII or have expressed an interest in attending these discussions at the EGU. This includes a good mix of FDSN Network and data center personnel as well as representatives from equipment manufacturers.
>
> I am attaching a draft agenda that identifies the topics of discussion as well as giving the time and meeting place. I am also attaching a straw man document that several groups in the US have discussed. The straw man may help us as it provides a starting point for our discussions as well as giving you a sense of some of the considerations we have identified as being important.
>
> We wil be proposing a Request for Comment (RFC) process to reach closure on the next version with specific timelines in mind. The proposed process will be presented at the meeting as we are still developing the RFC approach we will propose.
>
>
> <Agenda-miniSeed-SOH.pdf>
>
> And here is the draft proposal with some of our thoughts on this topic
>
> <Next-Generation-miniSEED-2016-3-30.pdf>