-
Notifications
You must be signed in to change notification settings - Fork 32
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
BUG: network fix #96
Comments
I fully agree that adding more information to the input station file is the ideal way to make QM more flexible in terms of the trace meta information. To me, the solution would be to extend (perhaps optionally) the columns that can be provided in the station input file e.g.:
However, we want to be able to retain the existing behaviour - if only One major benefit I can see of extending things in this way is that pick files will include all of the important information such that when imported into snuffler they are matched up with the corresponding traces. This doesn't currently really work (and it is a bit annoying!) |
I can get ahead with stripping out the other updates from the previous PR. I hadn't realised that it held all the baggage from the previous rubbish ones. I'll do better this time. My two cents worth is that I think it makes more sense to use trace ids as output from obspy and dealing with internally. This would make QM consistent with accepted naming conventions and include all the necessary information for snuffler. I'll make the PR then you can take a look. |
It would be best to start afresh from a new branch off development (so as to include changes made in the intervening time) and submit a new PR. Again, how does changing things in this way impact previous results? We can construct the obspy-style IDs internally from the information provided in the above format. Doing this in the Also, we have switched everything over to use |
I think essentially my proposal is the same, but the reverse action is performed in |
One solution would be to supply the |
Yeh, to re-emphasise: the next update to development (in review atm) will significantly change how waveform data is handled internally. So we have an opportunity to take stock and decide what improvements we want to make (both what you have raised and looking to the future), how best to do them, and how to ensure backwards compatibility. Just stripping out the irrelevant changes from your previous PR isn't going to leave us with a solution that satisfies all these requirements, and would have to be re-worked to make it compatible with this forthcoming change. So I would hold off for the moment and we can work out how to do it once and do it right - hopefully in a couple of days. |
Sorry gents - I was already full steam ahead and wanted to at least send a PR that isn't formatted crap-ly.
If you could take a look and share your opinions, I would be grateful. I'm not sure there are any problems with how the internal waveforms are referenced, but I'm not up-to-date with your future plans.
Tim
…-------------------------------------------
Tim Greenfield
Leverhulme Early Career Research Fellow
University of Cambridge
tg286@cam.ac.uk
________________________________
From: Tom Winder <notifications@github.com>
Sent: 30 October 2020 14:29
To: QuakeMigrate/QuakeMigrate <QuakeMigrate@noreply.github.com>
Cc: Tim Greenfield <tg286@cam.ac.uk>; Assign <assign@noreply.github.com>
Subject: Re: [QuakeMigrate/QuakeMigrate] BUG: network fix (#96)
Yeh, to re-emphasise: the next update to development (in review atm) will significantly change how waveform data is handled internally. So we have an opportunity to take stock and decide what improvements we want to make (both what you have raised and looking to the future), how best to do them, and how to ensure backwards compatibility.
Just stripping out the irrelevant changes from your previous PR isn't going to leave us with a solution that satisfies all these requirements, and would have to be re-worked to make it compatible with this forthcoming change. So I would hold off for the moment and we can work out how to do it once and do it right - hopefully in a couple of days.
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub<#96 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ALXCVON2ADXQOAX7NBBREO3SNLETPANCNFSM4RH6OLBA>.
|
There was a small bug in the latest changes to allow for networks to be specified. This fixes this bug. Stay tuned for a more complete fix using the full NSLC codes
The text was updated successfully, but these errors were encountered: