- Request #153 (L. Gee/E. Yu): Addition of new event types. Mapping of AQMS/QuakeMl event types.
------------------------------

1.- The NCSS is interested in seeing some event types added to AQMS and, further, adding the QuakeML types to the database as described below in order to standardize the mapping of AQMS event types to QuakeML event types.

The NCSS is particularly interested in adding:

CX: controlled explosion (useful instead of CHEMICAL EXPLOSION)
AX: accidental explosion  (like accidental fertilizer/refinery/gas explosions , like San Bruno gas pipe explosion in 2010)
HE: hydroacoustic event  (we had a few of these detected in NC from the Hawaiian Kilauea eruptions earlier this year)  
IE: induced or trig...
RL: reservoir loading
FI: fluid injection
FE: fluid extraction
AE: anthropogenic event  

==> Approved.
- The AQMS currently supports the following QuakeML event types:
    eq: earthquake
    co: mine collapse
    bc: building collapse
    sh: explosion
    ex: chemical explosion
    qb: quarry blast
    nt: nuclear explosion
    rb: rock burst
    pc: plane crash
    sn: sonic boom
    th: thunder
    av: snow avalanche
    df: debris avalanche
    ls: landslide
    rs: rockslide
    mi: meteorite
    ve: volcanic eruption

- We approved the addition of the following QuakeML event types to AQMS:
    ne: not existing
    nr: not reported
    ae: anthropogenic event
    cl: collapse
    cc: cavity collapse
    ax: accidental explosion
    cx: controlled explosion
    ee: experimental explosion
    de: industrial explosion
    me: mining explosion
    rc: road cut
    bl: blasting levee
    ie: induced or triggered event
    rl: reservoir loading
    fi: fluid injection
    fe: fluid extraction
    cr: crash
    tc: train crash
    oc: boat crash
    oe: other event
    pe: atmospheric event
    sb: sonic blast
    an: acoustic noise
    al: avalanche
    he: hydroacoustic event
    iq: ice quake
    sl: slide

- I did check the QuakeML documentation and no new event types have been added to it recently.


2.- Proposal to add QuakeML event types to the database.
The idea would be to add a new field to the EventType table that would provide a
mapping to the equivalent QuakeMl event type. That table would look something like:

 Name                                    Null    Type
 -----------------------------------------------------------------
 ETYPE                                   NOT NULL  VARCHAR2(2)
 NAME                                    NOT NULL  VARCHAR2(16)
 DESCRIPTION                                       VARCHAR2(80)
 QMLTYPE                                           VARCHAR2(80)

For each database event type, a corresponding QuakeMl type (if applicable) would
be specified in the QMLTYPE field. This would allow applications (e.g. qml)
to query this table in order to retrieve the appropriate QuakeMl event type and
not having to maintain a hard coded mapping list inside the program.
Another benefit of this approach would be that whenever a new database or QuakeMl
event type is added, applications would not need to be modified.

==> Approved.


- Request #158 (L. Gee): Designating events in the catalog as unlocatable
------------------------

The PRSN folks maintain a catalog of observed events with a few phase readings, but the events do not have locations.
We currently do not have a specific field to designate events that cannot be located.
In order to associate phase readings with such an event, we would most likely define
a bogus origin (lat & lon of 0 and bogusflag set to 1). We could set the event type
to "uk" (unknown) and insert a comment in the Event or Origin row indicating that this
event cannot currently be located.
One proposal is to add a new possible value for the Origin.type field. Currently we have:
        type = {H | C | A | D | U}
                H = hypocenter
                C = centroid
                A = amplitude
                D = double difference
                U = unknown
A "N" value could mean "non locatable".

==> Approved.


- Request #159 (R. Hartog): PCS_STATE table Primary Key
---------------------------

From Renate:

I changed the PCS function and kept the primary key the same (group,source,state,id), and though we have not run
into issues, I am not very satisfied with the level of testing that we have done. However, that is what is in the
DB/branches/uw-dev-branch/DBpg directory. That is the only DB directory suitable for PostgreSQL, the rest of the
DB/ stuff is all Oracle specific.

It would be more safe to make the PK: group,source,state,id,rank (CalTech) or even more permissive group,source,state,id,lddate (UCB).


- Request #152 (P. Friberg): VERSION table for tracking database changes
----------------------------

Version table to be added to track the version of the AQMS DB installed at a site.

Fields:
    version       - a number that increments with each version
    tracking_info - the SVN tag or release number or git URL to grab that version
    lddate        - when was this DB updated

Then we start tracking this in our DB repo for any changes and provide new insert
statements for the VERSION table after we make any changes.

==> Approved.
Add 'remark - Optional remarks' field.
Track schema and stored procedures changes.


- Request #157 (S. Zuzlewski): AssocArO.ema definition erroneous
------------------------------

The current schema definition (assocaro.ema is the *residual* between the observed/calculated emergence angle) is incorrect.
The following definition is proposed:

AssocArO.ema : the takeoff (emergence) angle at the source, measured in degrees, wrt vertical DOWN.
ema=0 leaves the source straight down, while ema=180 leaves the source straight up; calculated in Hypoinverse using
the velocity model.

Clara Yoon checked the Jiggle source codes and agreed with the proposed definition.

==> Approved.