1.- Pending schema change requests: =================================== #61 (P. Lombard): Units table: "spectral peak amplitude" is not a meaningful description. ----------------------------------------------------------------- The description of the unit labeled "spa" needs to specify the exact units; as it is now users have no idea if this is acceleration or velocity, let alone whether it is m/sec, %g, etc. ----------------------------------------------------------------- ------------------------------------------------------------------------ ==> Discussed. Caltech tasked to find out what are the exact units. One option is to ask Hiroo Kanamori. ==> Approved. Correct units are cm/sec^2. ------------------------------------------------------------------------ #60 (P. Lombard): Units table: "integral of velocity squared" is not a meaningful description. ----------------------------------------------------------------- Several different length and time combinations could be used for "integral of velocity squared". Is the velocity in cm/sec, or m/sec? Is the integral with respect to time, or distance? ----------------------------------------------------------------- ------------------------------------------------------------------------ ==> Discussed. Caltech tasked to find out what are the exact units. One option is to ask Hiroo Kanamori. ------------------------------------------------------------------------ 2.- New schema change requests: =============================== #116 (S. Zuzlewski): Add table ProxyWsMap. ----------------------------------------------------------------- A new table ProxyWsMap needs to be added in order to use the proxy wave server. The table has the following structure: CREATE TABLE ProxyWsMap ( net VARCHAR2(8) NOT NULL, sta VARCHAR2(8) NOT NULL, seedchan VARCHAR2(8) NOT NULL, location VARCHAR2(8), wstype VARCHAR2(15) NOT NULL, wsgroup VARCHAR2(15) NOT NULL, datetime_on NUMBER(25,10) NOT NULL, datetime_off NUMBER(25,10) NOT NULL, lddate DATE DEFAULT (SYSDATE) NOT NULL ); ----------------------------------------------------------------- ------------------------------------------------------------------------ ==> Discussed. Doug G. proposed to use the AppChannels table rather than creating a new one. Pete L. to look into this idea. ------------------------------------------------------------------------ #115 (P. Lombard): Change Event.version to NOT NULL, default 0. ----------------------------------------------------------------- Change needed to support planned use of Event.version field. Already approved by CISN Software Working Group. ----------------------------------------------------------------- ------------------------------------------------------------------------ ==> Approved. ------------------------------------------------------------------------ #23 (D. Given): The meaning and use of Origin.vmodelid and Origin.cmodelid is unclear. ----------------------------------------------------------------- The meaning and use of Origin.vmodelid and Origin.cmodelid is unclear. --> Definitions have been changed at some point to: vmodelid VARCHAR2(2) Velocity model identification cmodelid VARCHAR2(2) Velocity model domain --> From Hypoinverse manual: 165 2 A2 Code for domain (ie. NC, CI) in which the location was made. 167 2 A2 Code for processing version (ie 01, 02) of set of location files. ----------------------------------------------------------------- ------------------------------------------------------------------------ ==> Approved. Doug N. to come up with definitions. The cmodelid is a string that identifies the organization responsible for the velocity model. Recommendations for this field are the SEED network name, or a unique abbreviation of the processing center when using data from multiple networks. The vmodelid is a string that identifies a version (instance) of the velocity model for the specified domain and algorithm. This version should be changed whenever the velocity model is changed. It is recommended that values 00 - 99 be used for this field. The (cmodelid, vmodelid) pair should uniquely identify an instance of the velocity model for the specified algorithm. It is the responsibility of the organization to externally maintain the detailed information concerning the velocity model for each instance, and to provide a method of mapping the (cmodelid, vmodelid) to this information. Hypoinverse has 2 fields in the event summary line which may be used to populate these fields in the database. These fields are set by hypoinverse directives in the hypoinverse "input deck". ------------------------------------------------------------------------ #13 (D. Given): Remove column "iphase" from ARRIVAL table. ----------------------------------------------------------------- ARRIVAL.IPHASE is redundant. (Need only ASSOCARO.IPHASE). --> The idea behind this field was to represent the type of arrival that may be determined by an anaylst or automated picker, such as P, S, or Surface. Perhaps the field should be renamed to "phasetype". ----------------------------------------------------------------- ------------------------------------------------------------------------ ==> Withdrawn. Even though this field is redundant, it would take a significant amount of work to update all of the applications. Let's keep this request in mind for the next generation schema. ------------------------------------------------------------------------ 3.- Possible use of SVN for tracking schema related documentation: ================================================================== * DDL scripts (SQL): a) Schema creation (PI,WF,HT,IR,SIS): - Should we just store the logical model of the schemas? NC & SC physical models are different. b) Alternate tables (RT, post processing): - Does SC already store them in svn? - NC should do the same (ChannelMap, AssocWfRc, ...). c) Views: - NC & SC have different versions of some views (md_magparms_view, ...). d) Packages: - Does SC already store them in svn? - Berkeley should do the same (Truetime, ...). * ER/Studio files (HTML). ------------------------------------------------------------------------ 2008/03/21 We decided in a 1st pass to store only the logical views of the DDL scripts. Ellen volunteered to come up with a draft for the SVN structure. 2008/04/25 Ellen came up with a strawman for the repository structure. ----------------------------------------------------------------- I just spoke with Rae Yip concerning using SVN to store the database creation scripts. Rae tells me that the scope of this SVN repository is to store source code and not site-specific configurations. So it seems that we would only check scripts concerning relational properties (and not physical or table properties) into this repository. Here is a strawman for these scripts. Current SVN repository structure for database scripts: DB ->trunk ->branches (there is a leap second dev branch - currently only storedprocedures is under this branch) Under "->trunk" ->storedprocedures ->tables ->types ->views ->snapshots Other scripts that are site-specific: 1. sequences 2. users 3. grants 4. table site-specific storage parameters ----------------------------------------------------------------- ------------------------------------------------------------------------