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

network name and description #159

Open
WayneCrawford opened this issue Nov 20, 2024 · 3 comments
Open

network name and description #159

WayneCrawford opened this issue Nov 20, 2024 · 3 comments

Comments

@WayneCrawford
Copy link

On the FDSN.org site, both a "Network name" and "Description" are specified for a given FDSN code. But, in StationXML, only "description" is allowed. More confusingly, the StationXML "description" often corresponds to the "Network name" and not the "Description" (see example screenshots below, taken from the fdsn.org website and the https://www.fdsn.org/webservices/fdsnws-station-1.1.pdf example.

I think that either a "name" field should be added to StationXML , or the fdsn.org site should rename "Network name" to "Description" (and "Decription" to "Long Description"?)

FDSN_IU_website

FDSN_IU_XMLexample

@crotwell
Copy link
Collaborator

crotwell commented Nov 20, 2024

Seems reasonable.

Currently Station has a description, but also a name inside Site. Perhaps adding Site to Network would also be useful, where the "site" in this case means the whole geographical area for the network? That would allow the use of other tags like country that may be useful for national networks.

In the meantime, perhaps put the name into description and the longer description into a comment with subject being set to "long description" or something similar.

Alternatively, setting website in the network operator at least allows people to find more description if desired.

@megies
Copy link
Contributor

megies commented Nov 21, 2024

Everybody please keep in mind that changes to the standard have a lot of downstream implications (e.g. to software tools supporting said standard) that can force tough decisions like causing backwards incompatible changes that affect thousands of users writing code.
On the other hand text fields on websites that are designed for humans reading them and not necessarily for automated applications can easily shuffle around field names without disruptions.

Adding new fields/tags in the standard isn't the worst for downstream applications but making changes to existing fields, their meaning and semantics creates problems for maintainers and users.
I guess what I'm trying to say is, we should try and keep standard changes to a bare minimum whenever they can't be avoided but in cases like this I'd massively argue it's better to adjust the webpage to use the existing standard first of all (and "Network name" simply isn't part of FDSN's own standard so it should get adjusted/fixed on the webpage IMO).

@crotwell
Copy link
Collaborator

Yes, but I suspect the chances of a stationxml revision in the next decade are really small. So this is more about remembering things that might need to be updated if/when a revision happens. The FDSN rarely moves very fast! :)

Use of <Comment> seems the best for holding longer descriptions for foreseeable future.

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

3 participants