• Antelope Release 5.5 Linux 2.6.32-220.el6.x86_64 2015-04-21

 

NAME

event2json.rpy - deliver JSON data from events in a database

SYNOPSIS

**** NO BRTT SUPPORT ****
Author: "Juan Reyes"<reyes@ucsd.edu>

This tool is an extension to the rtwebserver program. It is design to read a database containing events and origins and produce a memory cached object for fast delivery to web clients. This object will be converted to a JSON formatted string easy to interpret by JavaScript and, unlike XML, readable by people. You need to copy the event2jon.rpy by hand to the folder that you are using to run the rtwebserver.

SUPPORT


Contributed code: NO BRTT support.
THIS PIECE OF SOFTWARE WAS CONTRIBUTED BY THE ANTELOPE USER COMMUNITY. BRTT DISCLAIMS ALL OWNERSHIP, LIABILITY, AND SUPPORT FOR THIS PIECE OF SOFTWARE.

FOR HELP WITH THIS PIECE OF SOFTWARE, PLEASE CONTACT THE CONTRIBUTING AUTHOR.

DESCRIPTION

The rtwebserver will declare an instance of a Event() class that will handle all database interactions and web requests. This class will read an origin table and possibly an event table if it exists. Then try to combine this information with a netmag table if present.

All the configuration parameters for this Event() class are specified in the [siteconfig] Arr of the rtwebserver.pf running the instance. Multiple databases can be served out of the same instance by specifying different databases in this [site][siteconfig][databases] Arr in the configuration file. If the origin table is not valid for a database then the system will skip the database and will not store any data for it. If the netmag table is not available then the system will not produce any magnitudes for the events.

The tool will track the checksum of every table and determine if there is a change from the last time the cache was updated. If the checksum is different then the Events() class will attempt to read the database and update the cached object. The data will be converted from a dictionary structure to a JSON string at the end of the extraction to minimize delivery time to the clients.

The selected magnitude for the event will be the one with the last lddate time.

A successful response from the server will have Content-Type and Expires fields set. The Expires will be set by the server to be the time of the query in addition to the refresh time specified on the parameter file. Example of headers set in this way:

Content-Type    application/json
Date    Fri, 24 Oct 2014 04:21:56 GMT
Expires Fri, 24 Oct 2014 04:22:56 GMT
Server  TwistedWeb/13.1.0

JSON FORMAT

{

    "allmags": [
        {
            "printmag": "4.9 mb",
            "magid": 238710,
            "magtype": "mb",
            "uncertainty": 0.28,
            "auth": "orbevproc",
            "magnitude": 4.9,
            "lddate": 1414106024.76122
        }
    ],
    "auth": "tele",
    "lat": 14.99,
    "srname": "MEXICO - GUATEMALA AREA",
    "orid": 1364877,
    "strtime": "10/23/14 (296) 23:06:02 UTC",
    "nass": 50,
    "evid": 1171883,
    "review": "-",
    "lon": -89.5402,
    "depth": 200,
    "magnitude": "4.9 mb",
    "grname": "GUATEMALA",
    "time": 1414105562.3846

}

PARAMETER FILE

All is configured on the [rtwebserver.pf] file. You need to specify the tool in the [site][pages] area of the parameter file. The [data][events] configuration use here will be the same values you will use on the URL when you try to query the tool. http://127.0.0.1:8000/events?db=ta Example:

site &Arr{
   event2jsonconfig &Arr{
        debug           False
        verbose         True
        time_limit      999999999999
        refresh         60
        timezone        UTC
        timeformat      %D (%j) %H:%M:%S %z
        databases &Arr{
                demo    /opt/antelope/data/db/demo/demo
                ta      /anf/TA/rt/usarray/usarray
        }
   }
   pages &Arr{
       data &Arr{
           events     rpy:event2json.rpy
       }
   }
}
The time_limit is the number of seconds is the past that you want to track on the event and origin tables. Using a big value here so you can see output when running on the demo database. Usually this will be a week or a month in seconds. The timezone and timeformat will specify a pre-formatted time string included on the JSON object. The epoch time of the origin will be there too in case you want to use that on your client code. The databases segment are a list of tuples. The first value is an arbitrarily name that we select for the instance. This is important because that is used on the URL to request data from that database. The second is the path to the descriptor file for that database.

EXAMPLE

/Users/reyes/antelope_contrib/bin/webservices/event2json

volcano{reyes}% make; make install;

volcano{reyes}%rtwebserver -p ./rtwebserver_example.pf
rtwebserver: Starting rtwebserver at '23:24:54.546 10/23/14 UTC' as pid 37034
rtwebserver: Events(): init()
rtwebserver:  debug: False
rtwebserver:  verbose: True
rtwebserver:  timeformat: %D (%j) %H:%M:%S %z
rtwebserver:  timezone: UTC
rtwebserver:  time_limit: 999999999999
rtwebserver:  dbname: {'demo': '/opt/antelope/data/db/demo/demo'}
rtwebserver:  refresh: 60
rtwebserver:  ####################
rtwebserver:  Loading Events!
rtwebserver:  ####################
rtwebserver: Test demo db: /opt/antelope/data/db/demo/demo
rtwebserver *complain*: Empty or missing /opt/antelope/data/db/demo/demo.event
rtwebserver: Loading Events()
rtwebserver: Events(demo): updating from /opt/antelope/data/db/demo/demo
rtwebserver: Done loading Events()

rtwebserver: READY!

SEE ALSO

rtwebserver(1), rtwebserver_rpy(3y)

BUGS AND CAVEATS

**** NO BRTT SUPPORT **** You DON'T need to copy the code to the folder structure running the rtwebserver instance. Just make sure that you "make install;" the code and then set the absolute path on the rtwebserver.pf file for the rpy file.

AUTHOR

Juan Reyes <reyes@ucsd.edu>
Antelope User Group Contributed Software
Printer icon