Thread: Next generation miniSEED - 2016-3-30 straw man change proposal 13 - Change name of location ID to group ID and expand to 4 characters

All,

I did want to point out that expansion of the location id to 4 characters has some larger implications on those of us dealing with real time systems. A large number of these systems include Earthworm, AQMS, Hydra rely on EW ‘tracebufs’ in some part of the processing. This has proven a useful format for an “in-the-clear” representation of a short time series segment. The TraceBuf format stores data as C string (zero terminated). In the TraceBuf header the location code cannot be expanded in place beyond the current two characters as the TraceBuf version offset is only 3 bytes away. This format is used for query from EW WaveServers and Winston wave servers - so a big portion of the community will have some heart burn over expanding this field. I imagine it would take the EW community some time to agree on the “trace buf 3” standard and to roll it out in the many systems out there as well so time series with more than two character location codes would not be available in real time systems for some time.

I personally have never seen the need to increase this field - I have trouble imagining a use case where 1296 two character combinations are not adequate. I am sure there are some for experiments or really big arrays, but the station name can always be change (and probably should be), for many of these cases.

My own feeling is users like the NEIC would likely punt this issue and only use data with two character location codes until circumstance cause a need to add stations not abiding by this convention. I am guessing this would not really affect the NEIC in that a normal seismic station would have little reason to use more than a two character location code.

The discussion about this field not being empty also has struck me a being a bit of a no-win holy war. I have always viewed an “empty” location code as two spaces since it is a two position space padded field IMHO. I suspect there will be some push back on forcing this requirement to have printable characters as so much of the world’s data leaves this field empty. The GSN convention was born of necessity when they started putting two weak motion instruments at a station. The location was needed to make the two seismometers distinct. The GSN followed this convention to assign each transducer a location code even if there were no ambiguously named channels. At some stations those seismometers are a couple of meters apart so “location code” now means “different seismometers” in this case, if you consider such seismometers colocated.

Dave

On Aug 19, 2016, at 12:01 PM, Chad Trabant <chad<at>iris.washington.edu> wrote:


Hi Florian and all,

Regarding a value to define empty, I think it should be distinct from any value that could possibly be used as a valid location ID to avoid ambiguities. For example, the value of '00' is already in common use so we wouldn't be able to distinguish between empty and an actual '00' value. Previously I had proposed using the value of '--', which is not a legal location (no possible conflict with non-empty IDs) and is already in use for requesting SEED referenced data (already known by centers and users). It could very well be something else. Regardless I think the approach of creating an alias for empty, as you suggest, is a good balance between 2.4 SEED with empty codes and required non-empty fields in some future version.

Regarding the field renaming in the change proposal, I am not too stuck on that and agree with Tim and Joachim that familiarity is valuable. The point is that if we ever wanted to rename it, a major format change would be a decent opportunity, at minimum for discussion.
The name location remains confusing for many people, including seismologists. For example, distinct location IDs are not necessarily related to distinct locations. Given that 'location' is embedded throughout the SEED ecosystem (documentation, software, schemas, vernacular), the cost of a rename may not be worth it.

Chad

On Aug 17, 2016, at 8:13 AM, Florian Haslinger <florian.haslinger<at>sed.ethz.ch> wrote:

Hi Tim & all,

a quick-shot response / add-on:

I agree that leaving the state of the locID in limbo is not good - so ‘a value’ should indeed be required. But (and not only for backward compatibility) - ‘no LocID’ should be a valid entry. Just define how (with what string) that shall be expressed.

One could use ’00’ (as many as required) for a default locID - but that again may be interpreted to have some meaning other than ‘no locID is used’ - so I’d rather use a more special ascii char combination.

Such a definition should avoid incompatibilities with other formats, where locID could (still) be empty - that string would just be translated in whatever represents an ‘empty’ value in the other format.

cheers
florian

On 17 Aug 2016, at 4:54 PM, Tim Ahern <tim<at>iris.washington.edu> wrote:

Hello All

I am agnostic about the name of the attribute. Joachim raises some good points about familiarity. In some ways location actually does make sense for both reasons of having this attribute, array elements and a second sensor actually both have different locations. But as I say I don’t feel strongly about the name of the attribute.

However I do feel strongly that allowing empty location/group codes is something that was not well thought out in the original (30 year old) format specification. The first data available in SEED simply did not fill in the field since the format did not require it to be filled in and at that time it was not needed. Allowing an empty field has prompted several groups to find different ways to accommodate a null field in a variety of places that include file naming conventions, how a user species a null field when requesting data, etc. I feel strongly that any new version of miniSeed should not allow key naming elements in the SNCL to be null, or space. It should be a required field that meets a specification as to what valid entries are in the field. I can not see a good reason not to require the location/group field to have an actual entry…. what has been done in the past is not a good reason in my opinion as we are trying to improve the next version of miniseed.

I also think that the FDSN should establish a convention (not part of the format) for how to use the location code. As far as I am aware the GSN has a convention that makes some sense in terms of multiple sensors on one station. I think WG II should try to establish a convention for what should be used in the location/group field. But the convention need not be part of the format specification.

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 Aug 16, 2016, at 1:43 PM, Joachim Saul <saul<at>gfz-potsdam.de> wrote:

Philip Crotwell wrote on 08/12/2016 07:29 PM:

A agree with concept of expanding and renaming the existing locid,
"location id" always seemed very confusing to me and "group" seems as
good as any. But see my earlier proposal for an alternative.

There is no need to change the name of the location identifier field. A
few more explanatory sentences as to what this field is used for would
be fully sufficient. MiniSEED is a binary format and the name of the
attribute is not and will not be part of the encoding, neither as
"location" nor as "group". The name could in fact be anything, like
"khole" as in SAC format.

The nomenclature using "location" may not be optimal but is widely used
and understood. FDSN StationXML, FDSN web services, QuakeML etc., are
important standards in Seismology that adopted the term "location" from
SEED for good reasons! We are therefore now in the comfortable situation
that stream identification using SCNL is consistent among the most
important seismological standards. Don't give that up!

However, I feel it is important for any change such as this one to
also explain how existing channel codes will be expressed in the new
file format. Old data will not go away just because of a new file
format and I would hope that miniseed3 eventually becomes the standard
way of both getting data into and out of datacenters. In particular,
this proposal, because it says that the group id "Cannot be empty",
needs to spell out how current channels with "empty" loc ids would be
mapped.

After a lengthy discussion two years ago about empty location codes in
FDSN StationXML it was concluded that these must be allowed. Therefore
no unnecessary restrictions like "Cannot be empty" must be introduced in
a future MiniSEED revision.

Regards
Joachim

----------------------
Posted to multiple topics:
FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences at http://www.fdsn.org/account/profile/

----------------------
Posted to multiple topics:
FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences at http://www.fdsn.org/account/profile/

----------------------
Posted to multiple topics:
FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences at http://www.fdsn.org/account/profile/

----------------------
Posted to multiple topics:
FDSN Working Group II (http://www.fdsn.org/message-center/topic/fdsn-wg2-data/)
FDSN Working Group III (http://www.fdsn.org/message-center/topic/fdsn-wg3-products/)

Sent via IRIS Message Center (http://www.fdsn.org/message-center/)
Update subscription preferences at http://www.fdsn.org/account/profile/