Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expansion and convention of the network code #27

Open
krischer opened this issue Jan 11, 2018 · 3 comments
Open

Expansion and convention of the network code #27

krischer opened this issue Jan 11, 2018 · 3 comments

Comments

@krischer
Copy link
Contributor

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

@chad-earthscope
Copy link
Member

chad-earthscope commented Jan 11, 2018

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

  • Allow up to 8 characters Uppercase [A-Z] and Numeric [0-9]
  • Adopt the following convention for temporary network codes:

Network codes for deployments that are known to be temporary must include the 4-digit start year of the deployment at the end of the code. A prefix of 1-4 characters may then be used to describe the deployment. Other than including a start year, a temporary network code is globally unique and treated no differently than any other network code. The pattern for a temporary network code is as follows:

<1-4 characters><4-digit start year>

For example, “SEIS2018” would be a valid network code and imply that the initial deployment was in the year 2018 and is temporary.

Mapping of previously allocated temporary network codes

Earlier temporary network codes were allocated as two-character codes, with the first character being a digit or the letters X, Y or Z. Many of these codes have been reused for different deployments in different years and are therefore not globally unique. A data owner or delegate data center may wish to convert, or provide an alias, for data using the older, 2-character codes. The mapping from the 2-character codes is strongly recommended to follow this pattern:

<2-character code><4-digit start year>

For example, the a network deployment allocated a network code of “XA” operating in the years 2002 and 2003 could be mapped to “XA2002”.

@jmsaurel
Copy link

As I said in #28, I think FDSN should recommend to keep using the two letter network code for any new permanent network mainly aimed at distributing broadband quality data that could be used by tsunami warning or EEW centers.

For other new permanent networks, a rule of good practice could be to reserve the latest 2 characters of the network code to the country ISO code.

@crotwell
Copy link

I agree with @jmsaurel. But we may wish to make compatibility even stronger.

There are 3 time periods we need to consider with network codes.

  1. Past - codes issued before the new structure is adopted
  2. Transition - codes issued after adoption but where miniseed2 is still widely used
  3. Future - NGF is 'the' data distribution format

For Past and Future, Chad's rules work well. I would also say once we reach the Future period, the distinction between temporary and permanent no longer matters and network codes should just be assigned without any special restrictions for temporary networks. Using the ending 4 digits of year should not be required.

However, the Transition will probably be a significant time period and it is wise to at least encourage miniseed2 compatibility when it can be done. So I would recommend that in the transition period, temporary network codes be assigned a 6 char network code. The last 4 characters would be the start year while the first 2 characters would be assigned under existing temporary network rules. So a temporary network starting in 2019 might be XB2019. As long as that network assigned station, location and channel codes to fit within the existing 5,2,3 rules, the data would be available in either miniseed2 or NGF without loss. Within the transition, all networks should be encouraged to follow the 5,2,3 rules where possible for this same reason.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants