-
Notifications
You must be signed in to change notification settings - Fork 1
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 of the station code #28
Comments
As one idea described in an draft of new identifiers, posted to #4, the station code could be enhanced in the following ways:
|
I think FDSN should state that for permanent stations from global broadband networks (typically stations which enter tsunami warning systems or EEW) should continue to follow miniSEED rules :
More generally, I think the new station codes (extended for example at 8 characters, as @chad-iris proposes), should retain the following two rules:
|
Is there an existing SEED requirement that station codes be 3+ chars? |
Maybe not in SEED, but at least in ISC station registration form |
Besides length restriction of the station name (not so relevant in the light of the new stream identification proposals), we may also consider good practices on the level of uniqueness station names should provide. Should it be globally unique in naming an instrumented site (as the ISC station registry implies), is it enough to be unique within a network (as stationXML and seed imply), or is it, also for the FDSN accepted that it is purely descriptive or can be missing (as the stream identification schemes proposed by this format imply) |
I assume by station names you mean station codes? As a practical matter, the network code provides namespace, so I see no reason for station codes to be globally unique. The do need to be unique within the network. The proposal from @chad-iris says One nice extension might be to allow |
@crotwell station names => yes, i meant station codes. identifying a network or a station as a whole? fine, but do you see any use of this here / in purely stream oriented format? |
@kaestli may not be used in NGF directly, I was more thinking of external use cases like getting stationxml for a station from a fdsn web service. This makes it so that I can specify a single station with one parameter instead of 2. |
Assuming the FDSN identifiers will be used in the new data format (please discuss this in #4) how should the station code be expanded (or not)?
The text was updated successfully, but these errors were encountered: