1.- New request:
================

1.1.- Request #124 (P. Lombard):
--------------------------------

        -----------------------------------------------------------------
        --> Add new table "Swarm_Events" To Application Schema to support
	    swarm monitoring.

	Swarm_Events table serves as a helper for swarmon program to
	minimize expensive queries to Event and Origin tables and calls
	to Wheres package.
        -----------------------------------------------------------------

------------------------------------------------------------------------
==> Discussed.
    How is this table going to be maintained?
    Permanent storage or "scratch pad"?
    In what context is the query "expensive"?
    Wheres vs. geo_region package.
    If direct access to DB, there is the advantage of seeing any recent
    changes; for example if an event was relocated.
------------------------------------------------------------------------


2.- Review of pending requests:
===============================

2.1.- Request #19 (D. Given):
-----------------------------

--> Add "timequality" to ARRIVAL.
------------------------------------------------------------------------
==> Approved.
    Two new tables in the AP schema are being proposed.

	CLOCKQUAL_ARRIVAL
	 arid		integer		(primary key)
	 clockqual	integer		[0-100]
	 clockqualid	integer		(foreign key)

	CLOCKQUAL_SOURCE
	 clockqualid	integer		(primary key)
	 clockqualsrc	string		String defining source of quality,
					eg Quanterra, Reftek, ...
------------------------------------------------------------------------

------------------------------------------------------------------------
==> Approved.
------------------------------------------------------------------------


2.2.- Request #10 (D. Given):
-----------------------------

--> Add new column "nobs" to NETMAG table.
------------------------------------------------------------------------
==> Request has been approved but the implementation is on hold until:
     1.- NC is done migrating to the new CISN software.
     2.- SC is done migrating to the leap seconds compliant code.

==> SC: End of July 2009.
    NC: End of June 2009.

==> Ellen to test replication issues associated with adding a new field
    to an existing table.

==> This change has eventual implications for the following applications:
    Trimag, EC, Jiggle, MT, dbselect, Stored Procedures, STP(SC), RTMd(SC).
------------------------------------------------------------------------

------------------------------------------------------------------------
==> Ellen started testing the replication issues associated with adding
    a new field to an existing table. She came to the conclusion that
    during the update to the replication environment, there is a small
    time window where transactions can be lost. There does not seem
    to be a way around this issue.
------------------------------------------------------------------------


2.3.- Request #53 (D. Given):
-----------------------------

--> Add integer attribute for each channel to hold COSMOS "Table 6" value.
------------------------------------------------------------------------
==> A. Walter is currently involved in NSMP project.
    We should wait until he has more information concerning this matter.

==> A. Walter sent out a proposal. Ellen & Stephane to look at it and
    provide feedback.
------------------------------------------------------------------------

------------------------------------------------------------------------
==> Stephane to send comments to the group.
------------------------------------------------------------------------


2.4.- Request #4 (B. Worden):
-----------------------------

--> Add new association table between amps and events.
-----------------------------------------------------------------
Need to associate amplitudes with events.

(The schema originally had this association, and it was removed
at Caltech's request, due to performance implications in the
real-time system when events were merged).

==> D. Neuhauser sent out a strawman for implementing sets.

Strong Ground Motion Sets.
Strawman:

1. Create a new table SGMAMPSET with fields:
	sgmampsetid 	(integer)	composite primary key
	ampid		(integer)	composite primary key

2. Add to ORIGIN table:
	sgmampsetid	(integer)

Before inserting strong ground motion info into the database for
an event, if the sgmampsetid in the ORIGIN table is NULL,
get a new counter for the sgmampsetid, and update the ORIGIN
table with is value.  When inserting strong ground motion
into the database for an event, associated with the set specified
by the sgmampsetid in the preferred origin on the event.

When a new origin is computed that "near" the previous preferred
origin, the new origin can be assigned the same sgmapampsetid
as the previous origin.  If the new origin is significantly 
different, the sgmampsetid can be left NULL to indicate that
there is no current set of strong ground motions to be 
associated with this event (really with this origin).

Programs that want to harvest strong ground motion records
for an event would only have to get all amplitudes associated
with the sgmampsetid of the preferred origin.
-----------------------------------------------------------------