search

FDSN / source-identifiers

Data source identifiers for FDSN formats
https://docs.fdsn.org/projects/source-identifiers/
3 stars 2 forks source link

sample rate bounds for LVU band codes #5

Closed crotwell closed 4 years ago

crotwell commented 4 years ago

L V and U band codes have approximate values, but now might be a good time to give them greater than/less than bounds like all the other codes.

Copy from https://github.com/iris-edu/xseed-specification/issues/16

Should give a range for L, U, V band codes like all the others. In particular, it is currently a little confusing as to the correct name for a .001 Hz channel as U is usually .01 but R says strictly less than .001.

Similar, is a 0.2 Hz channel L or V?

Worth perhaps doing: L =1 V >= 0.1 to < 1 U >= 0.01 to < 0.1 so that we keep the >= to < pattern?

Then add another letter for the >= 0.001 to < 0.01 range? W perhaps for "Weally Long Period"???

crotwell commented 4 years ago

Propose this update to the spec:

This makes L, V, U more precise, and fills the gap between U and R. 


+----------+----------------------------------+-------------------------+------------------+
|**L**     |Long Period                       |~ 1                      |                  |
+----------+----------------------------------+-------------------------+------------------+
|**V**     |Very Long Period                  |>= 0.1 to < 1   |                  |
+----------+----------------------------------+-------------------------+------------------+
|**U**     |Ultra Long Period                 |>= 0.01 to < 0.1   |                  |
+----------+----------------------------------+-------------------------+------------------+
|**W**     |Ultra-ultra Long Period         |>= 0.001 to < 0.01     |                  |
+----------+----------------------------------+-------------------------+------------------+
|**R**     |Extremely Long Period             |>= 0.0001 to < 0.001     |                  |
+----------+----------------------------------+-------------------------+------------------+
flofux commented 4 years ago

I support the band code redefinition.

Just one comment: I don't know how familiar these band are, but we should check if the new scheme contradicts any long-standing practices in band naming. Supposedly, for a 0.5sps band you would probably be be using V from the old scheme (~0.1) but in the new scheme it would be U. No idea if this is a real issue, though, or purely theoretical ...

And does anyone have any better suggestion than "Ultra-ultra long period" for the new W band? I admit I don't ...

crotwell commented 4 years ago

@chad-iris can you run a database query on the channels at IRIS to see if if there are many existing channels that would be wrong with this change?

chad-earthscope commented 4 years ago

My worry is the break from SEED's band codes.

@chad-iris can you run a database query on the channels at IRIS to see if if there are many existing channels that would be wrong with this change?

Ha, you'll like this! The results of the query are attached. Basically it's a mess of mis-use. You can ignore the administrative (e.g. 'A') band of course.

1hz_and_lower_bands.txt

crotwell commented 4 years ago

Wow, so my takeaway is things are already so misused that the break is from something already pretty broken, so might as well make the recommendation logically consistent!

The 0.5Hz L channels are the only case where it looks like there are significant numbers of channels that are sort of right now that would be incompatible.

But I also understand wanting to keep compatibility with existing, even if the existing is illogical.

WayneCrawford commented 4 years ago

I like the idea of having precise definitions for the band bounds, but note that "L" is very popular but can be complicated to make from some data sets. I'm specifically thinking of OBS datasets sampled at 62.5 SPS and which can't be decimated to 1sps, but can be to 1.25 sps. Is it better to keep L "pure", or give it a frequency range (like all other letters) that allows some nearby neighbores

crotwell commented 4 years ago

Yes, I agree. That is why I left "L" as approx 1 with the "~" as I was not sure that a range made sense for it given the existing ranges for R,P,T. Perhaps just changing it to "near 1" instead of "~1" would be clearer?

But if ranges could overlap, then maybe a .5 to 2 Hz range around 1 makes sense? The M code is already 1< sps <=10.

I am open to moving the bounds around if that is needed to accommodate common usage, but would like to see ranges for all the band codes if possible.

chad-earthscope commented 4 years ago

I support the clarification of ranges for each code. I also remain concerned about the break from SEED 2 definition and I'm keen to avoid any chance of "submarine" changes buried in the new spec.

I will make this change but ask that it's very clear in the report to the WG.

crotwell commented 4 years ago

OK, I will add something to the report.

chad-earthscope commented 4 years ago

Done, please check: http://docs.fdsn.org/projects/source-identifiers/en/draft/channel-codes.html#band-code

It may take a while for RTD's caching system to update.