1.- Request #121 (D. Given - NEW): ================================== ----------------------------------------------------------------- --> Change the precision of AssocArO.delta from 5,1 to 6,1 to allow teleseisms Precision of AssocArO.delta is currently 5,1 which overflows at teleseismic distances (>9,999.9km). Note that we approved a documentation change in 5/08 to change the units from degrees to km (#101). ----------------------------------------------------------------- ------------------------------------------------------------------------ ==> Approved. New precision will be (9,4). Change will apply to AssocAmO.delta and AssocCoO.delta as well. ------------------------------------------------------------------------ 2.- Request #19 (D. Given - PENDING): ===================================== ----------------------------------------------------------------- --> Add "timequality" to WAVEFORM. Need to store waveform time quality (Currently must retrieve SEED timeseries data and read headers to get this info). ----------------------------------------------------------------- ------------------------------------------------------------------------ D. Given added: "Egill is OK with the time quality scheme documented in SEED and used by Quanterra. SEED = Timing quality is a vendor specific value from 0 to 100% of maximum accuracy, taking into account both? A float value from 0.0-1.0 expressible as a percentage would be consistent with similar fields in the dbase or it could be an INT from 0-100. This is carried in Blockette 1001 of SEED and sent by the Quanterras. That's the value reported by SeisNetWatch as 'Average Clock Quality' e.g. Average Clock Quality from Blockette 1001 of the last 2 packets from the datalog files for the channel specified. CRITERIA: 0-16 BAD, 17-40 FAIR, >40 GOOD [0.0<=Bad<17.0<=Fair<40.0<=Good] I don't know how the value is computed by the logger." P. Lombard added: "For a description of how the datalogger sets the value of clock quality, see pages 30 and 31 of "Quanterra MULTI_SHEAR Software Configuration Guide (Documentation for Software Release 36/09-0531) Revision E: February 24, 2000", or other Quanterra documentation about the "clock" process." ------------------------------------------------------------------------ ------------------------------------------------------------------------ ==> Discussed. D. Neuhauser to send email to Egill about his concerns. ------------------------------------------------------------------------ 3.- Request #10 (D. Given - PENDING): ===================================== ----------------------------------------------------------------- --> Add new column "nread" to NETMAG table. ----------------------------------------------------------------- ------------------------------------------------------------------------ Every magnitude in the dbase has an attribute called "NSTA". Most programs write the number of *observations* (amps, codas) contributing to the magnitude in this field. One program (TriMag) writes the number of *stations*. So the field name doesn't match its most common usage. This will be confusing to future developers. The WG considered just changing TriMag to write # of observations and leaving the misleading column name (NSTA) as it is. This may cause difficulties as the software propagates out to other networks. The WG is now proposing to "fix" the situation by doing the following: * add a new field called NOBS for # observations * retroactively rewrite NSTA and populate NOBS in the dbase to reflect this change * change all codes to use the new NOBS field and interpret NSTA as # stations This change would require changes to several codes. For example, TriMag, data import and load programs, Jiggle, STP, dbselect, EWmag2CISN, magPref package, alarm rules, and more. QUESTION: Do you think it is worth the effort to change the code to fix the 'misnamed' NSTA field and record both the number of observations and the number of stations? ------------------------------------------------------------------------ ------------------------------------------------------------------------ ==> Approved. The implementation should wait until: 1.- NC is done migrating to the new CISN software. 2.- SC is done migrating to the leap seconds compliant code. In the meantime we can think about: 1.- Inventory of applications. 2.- Ways of handling historical data. ------------------------------------------------------------------------ 4.- Request #18 (D. Given - NEW): ================================= ----------------------------------------------------------------- --> Add field "actual_rate" to table WAVEFORM. Specify actual waveform sample rate. (WAVEFORM.SAMPRATE is only the expected rate). ----------------------------------------------------------------- ------------------------------------------------------------------------ ==> Withdrawn. ------------------------------------------------------------------------