1.- Review of pending requests: =============================== 1.1.- Request #136 (A. Walter): ------------------------------- --> 2 new tables: gazetteer_region_group and assoc_region_group. ----------------------------------------------------------------- ==> The new tables are approved. How deep should the auth be set? Only at the event level. Where do we store the auth? 1.- Use existing Event.auth field. 2.- Create new field in Event table. 3.- Create new table. - Pete wrote a recommendation and circulated it around: Proposal for AQMS Modifications to Support Event Attribution for Tier 2 and Tier 3 Regional Seismic Networks The proposed design discussed herein is not complete: several questions need to be answered in order to complete the design. These are noted in the following discussion. Some AQMS operators need to have event attribution based on the geographical location of events detected by their AQMS systems. By "event attribution", we mean agency name or code published with AQMS or related notification products. For notifications published in CUBE formats, this typically would be the 2-letter "Data Source" or "regional network designation" field. This field together with the event ID typically function as the unique name by which an event is named. Because of this use of the network designation plus event ID, it is desirable that the selected network designation never change once it is assigned. Currently AQMS supports only an RSN-wide, configuration controlled (sometimes hard-coded) of this network designation field. The following changes to AQMS are intended provide AQMS operators with more flexibility to assign network designators based on predefined polygonal regions. The changes can be grouped in several sections: 1. a set of database tables and stored procedures (SQL and/or java). The tables can be configured by AQMS operators to define and name one of more polygonal regions, as well as lists of region names eligible for various uses. For example, these tables could be used to define applicability regions for various velocity models. The stored procedures provide methods for determining within which region an given event epicenter lies. 2. changes to Event Coordinator (ec). The ec is the one part of the AQMS real-time system where events located by the Earthworm binder_ew/eqassemble/hyp2000 system are entered into the database. The change will allow ec to determine the region in which the computer location lies and to enter that information into the database. We propose to use the "Auth" field of the Event table to record this network designation value. Currently the value that ec puts in the Event Auth field is read from ec's configuration file. The Auth field of other Parametric Information tables will continue to be populated is it is now, typically from the populating application's configuration file. 3. changes to jiggle. Events other than "binder" events (from the RT system) get their first location using jiggle. These include both subnet triggers from the RT system, and events "cloned" from existing events using jiggle. For these events, jiggle must determine region in which these initial locations fall and enter that information into the database. 4. changes to AQMS product generation programs. Programs that generate products from an AQMS system need to be modified so that they use the "regional network designation", determined and stored by ec and jiggle, for inclusion in the generated product. This includes alarm action programs that generate CUBE messages and email, as well as post-processing applications such as publishers of First Motion mechanisms. Modifications may be need to some ShakeMap programs as well. Any RSNs which use locally designed programs outside the standard AQMS system will need determine what changes are needed to these programs to support the goal of region-based event attribution. ----------------------------------------------------------------- ----------------------------------------------------------------- ==> Approved. - Pete will work on EC. Allan already modified Jiggle. - NC & SC to start testing. ----------------------------------------------------------------- 1.2.- Request #131 (E. Yu): --------------------------- --> Store categories of applications in an AppCategory and AssocAppCat table (similar to event types). ----------------------------------------------------------------- ==> Ellen sent a link to a GUI. People to look at it and come back with some feedback. http://jishin.gps.caltech.edu/sis/stations/appcatg/ ----------------------------------------------------------------- ----------------------------------------------------------------- ==> Put the request on hold for now. ----------------------------------------------------------------- 1.3.- Request #53 (D. Given): ----------------------------- --> Add integer attribute for each channel to hold COSMOS "Table 6" value. ------------------------------------------------------------------------ ==> Allan sent a new version of the Cosmos schema. - Stephane loaded the Cosmos schema on a test database and updated createv0_xml to use those tables. Other applications could benefit from those tables. For example: v02mseed, Shakemap. - NC & SC will start writing an application to populate the main table (C_ChannelData) for their respective networks. - Stephane updated the tables with new values from the Cosmos documentation. Sent out new version of the schema. - Stephane sent an initial spreadsheet for BK sites to Peggy. Outstanding issue concerning borehole sites. - Tony said that code 52 should be used for boreholes. - SC will go through their site codes. Current SC algorithm for assigning site codes: IF depth < 10 m THEN 4 ELSE 52 ----------------------------------------------------------------- ----------------------------------------------------------------- ==> Stephane started working on an application to populate the Cosmos schema main table. ----------------------------------------------------------------- 1.4.- Request #10 (D. Given): ----------------------------- --> Add new column "nobs" to NETMAG table. ------------------------------------------------------------------------ ==> Request has been approved. - This change has eventual implications for the following applications: Trimag, EC, Jiggle, MT, dbselect, Stored Procedures, STP(SC), RTMd(SC). - Ellen tested and documented a procedure to perform a DDL operation in a replication environment. - Ellen used the procedure to add the new field in SC. - Allan updated Jiggle & the stored procedures. - NC added the new field to its production databases. - Historic data need to be updated in the database. - Pete updated trimag, EC & TMTS. New version of dbselect cannot be installed until historic data is corrected. - No change is needed for STP. - Allan implemented a stored procedure to update historic data. ------------------------------------------------------------------------ 1.5.- Request #130 (S. Zuzlewski): ---------------------------------- --> AppChannels vs Config_Channel. ------------------------------------------------------------------------ Issue of config_channel/program tables use by RT programs and applications/appchannels by post proc. We should ideally create one set of tables and both should use the same set. It will simplify the schema, and avoid the confusion of what tables to populate for program's channel lists. - In NC, Pete created a script to reconfigure channel list Id's and names. Also Config_Channel is now a view of AppChannels and Program a synonym of Applications. - Ellen sent a link to a GUI interface to better manage channel lists. * Test interface with NC data: http://surtsey.gps.caltech.edu/stationui/sandbox/ * Read-only interface with SC data: http://surtsey.gps.caltech.edu/stationui/readonly/ ----------------------------------------------------------------- ----------------------------------------------------------------- ==> Discussed. - Pete tested it out and provided some feedback. One desireable feature would be to be able to temporary turning off a channel (as opposed to deleting it). - Based on the suggestions, Ellen will come up with the next version. ----------------------------------------------------------------- 1.6.- Request #129 (S. Zuzlewski): ---------------------------------- --> Add hardware ownership information. ------------------------------------------------------------------------ We want to add hardware ownership information to the HT schema in order to identify which piece of hardware belongs to whom (similar to the 'owners' table in SIS). It would require a new table: ownerid int (PK) name string contact string lddate date We would then add the field 'ownerid' as a foreign key in the Sensor, Filamp & Datalogger tables. - D. Given pointed out that contact information can change often. NC to discuss some more about it. - Currently waiting on ANSS looking at SIS. ------------------------------------------------------------------------