Expansion and convention of the location code

[krischer]

Assuming the FDSN identifiers will be used in the new data format (please discuss this in #4) how should the location code be expanded (or not) and what conventions should be adopated (if any)?

[krischer]

The location code and its current lack of semantics and accepted conventions is confusing for users. In the SEED manual its described at one point as the "array subcode" but to my knowledge its mostly used to distinguish different instruments at one station. The huge amount of existing data prevents backwards incompatible changes but it would at least be nice to properly document the most widely used schemes.

[chad-earthscope]

As one idea described in an draft of new identifiers, posted to #4, the location code could be enhanced in the following ways:

• Allow up to 8 characters
• Allow dash "-" character in addition the the traditional Uppercase [A-Z] and Numeric [0-9] characters.

I agree with @krischer that location code has most often been used to identify different instruments at a single station, in particular to logically separate sensors that produce the same channels and the "group" channels by a sub-processor.

Documenting the existing schemes would be good. I also think coming up with a new convention that takes advantage of the above enhancements (should they be accepted) would be wise. For example:

When used to designate many sensors deployed in a grid the convention is to identify the X-Y location of the node in the location code. For example, the node in “column” 14 and “row” 984 could use a location code of “14-986”.

[jmsaurel]

Do we take the opportunity of the NGF to clarify the location code role ?
For example, do we say that it is associated to a geographical position of a channel/stream/sensor ?

[ozym]

We also use the location code to distinguish between SOH streams from multiple dataloggers that may be installed at a single "station". e.g. LCQ or LOG ...

[krischer]

The location code is currently used for two separate things:

• Distinguishing different instruments or data streams (e.g. QC) in the same physical location
• Distinguishing spatially different sensors as part of a small array ("array subcode")

The first case seems to be far more prevalent. With some redefinition and more space in the station code there might be a chance to lump the "array subcode" into the station code and clearly state that the location code serves to distinguish different instruments. I guess it could also be renamed to something more sensible at that stage.

[kaestli]

An other typical present-day use case is to differentiate levels in borehole instrumentation.

[kaestli]

As there was no STANDARDIZED descriptive meaning of the location code in miniseed2, we cannot introduce one without breaking the proposed mapping of old SNCL identifiers to the new FDSN: subscheme of stream identification. For practical reasons, the identification mapping from old to new is much more important than to have speaking location codes in the new format
(same argument as for channel codes: there is no way to get SUFFICIENT information in a few letters code anyway, e.g. in borehole or building instrumentation, you would not only want to know the array numbers, but hight or depth relative to surface, in arrays you may have circular [or any other shape] rather than gridded arrays, and in colocated instruments, you would probably like not only to differentiate, but to identify the instrument).
Thus: the DESCRIPTION problem should be solved in the metadata. And in order to solve the IDENTIFICATION problem in a backward compatible way, don't change the meaning of station codes (not even from nothing to something)
Leave it untouched, consider it deprecated.

[jmsaurel]

don't change the meaning of station codes

I guess you meant location codes.

I agree with @kaestli last comment

[jsaul]

Agreed. Don't change the meaning. Don't introduce new characters. Do address the need for longer location codes. Recognize the fact that many (many!) stations have no location code set at all and don't require a location code to be set in the future.