establish pattern for old and new temporary network codes

[crotwell]

Part of the reason for expanding network codes is to fix the reuse of temporary network codes. Given the expansion, is the temporary vs permanent distinction still meaningful, or do all networks just get a "code"? I am not sure if the distinction matters any more, but the migration path from old network codes to new should be part of the new FDSNIdentifiers document.

If there continues to be a distinction, document the pattern for issuing new temporary network codes, such as [XYZ]<1-3 letters/number><4 digit startYear> or something.

Also apply the pattern to all previously issued temporary network codes, retroactively assigning a unique code, based on start year and their existing code. So XA that started in 1992 would get something like XA1992. The idea is not to force the relabeling of old data, but to allow it if datacenters wanted to by marking those network codes as occupied.

It would also be very nice if FDSNStation and FDSNDataSelect understood both the existing temporary codes as well as the newly assigned ones.

[chad-earthscope]

+1 that a convention should be adopted for temporary network codes, and that a mapping from old to new codes should be developed and that the transition of old->new be optional for data centers. The DMC would like to be done with the special XYZ# convention for temporary network codes.

Possibly stating the obvious, but for completeness: network codes should be usable to uniquely identify networks/deployments/experiments with no external knowledge needed to further distinguish the specific network. They should all just be codes. Including a start year solves a large part of the uniqueness problem and provides some useful meaning.

I'm partial to, but not stuck on, a bit broader version of what @crotwell wrote:

<1-4 characters><4 digit start year>
and when mapping old codes:
<OLDCODE><4 digit start year>

It would also be very nice if FDSNStation and FDSNDataSelect understood both the existing temporary codes as well as the newly assigned ones.

You mean so that users could request "XA" and the services would detect a 1-2 character code starting with [#XYZ] and the return anything matching "XA*"? Hhmm, might be some dragons in there, but possible. My gut reaction is to leave that kind of logic out of the services.

[crotwell]

It would also be very nice if FDSNStation and FDSNDataSelect understood both the existing temporary codes as well as the newly assigned ones.

You mean so that users could request "XA" and the services would detect a 1-2 character code starting with [#XYZ] and the return anything matching "XA*"? Hhmm, might be some dragons in there, but possible. My gut reaction is to leave that kind of logic out of the services.

My intent was to provide a migration path, so that data centers could start using the new codes for old networks while still allowing users that did not know about the new codes to access old data. So there would be a period when a request for an hour in 1992 for XA would be the same as requesting that hour for XA1992.

Unfortunately, this "temporary period" could be years or decades! :(

To be clear, this is only for old networks that have already been issued 2 char temp networks. It would not apply to networks issued longer codes, so XABC2021 would be XABC2021 and users would not be able to get data by requesting XA for an hour in 2021. Basically this is "compatibility mode" for all the old temporary network codes.

But perhaps if this happens there would be a v.1 dataselect that understood old codes, and the v.2 dataselect would only understand the longer codes. Important point is just that we need to think about the transition path.

[crotwell]

@chad-iris

I'm partial to, but not stuck on, a bit broader version of what @crotwell wrote:

<1-4 characters><4 digit start year>
and when mapping old codes:
<OLDCODE><4 digit start year>

Do you mean this for all old network codes, or just old temporary network codes? Keeping permanent network codes as-is is desirable I feel, which is why I limited the mapping to just existing temporary codes.

[chad-earthscope]

Do you mean this for all old network codes, or just old temporary network codes? Keeping permanent network codes as-is is desirable I feel, which is why I limited the mapping to just existing temporary codes.

Just temporary codes, those starting with [#XYZ].

[crotwell]

Ah, I get it, you are saying that new temporary networks get a code that can start with any letters/numbers (up to 4) but must end with a 4 digit year? So we switch from temporary being keyed on the first char to temporary being keyed by ending in a 4 digit year? I presume permanent networks should not end with a year?

👍 OK with me.

[chad-earthscope]

Ah, I get it, you are saying that new temporary networks get a code that can start with any letters/numbers (up to 4) but must end with a 4 digit year? So we switch from temporary being keyed on the first char to temporary being keyed by ending in a 4 digit year? I presume permanent networks should not end with a year?

Yes, sorta. We switch from temporary to being keyed on the first char to a strong recommendation (or even a requirement) that temporary deployments end with a year. But after that there is really no need to identify temporary versus not, no need to distinguish if all codes are unique. Permanent network codes could have a year if they want, would be a little strange, but shouldn't matter.