Publications: SRL: Electronic Seismologist |
The purpose of this article is to explore new Web-based resources for disseminating data in an interactive and intuitive way that is accessible and engaging to the public without sacrificing scientific utility. This article highlights these new opportunities and describes their synthesis with recently developed automated tremor monitoring methodologies. The resulting product is a website that the reader may find useful to explore in tandem with this article, http://www.pnsn.org/tremor.
In this article, the data dissemination example is specifically applied to Cascadia tremor, but the utilization of freely accessible Web applications to provide an interactive Web experience for the public and scientific community alike could easily be applied to many different aspects of seismology.
Since their discovery nearly a decade ago, advances in both instrumentation and methodology in subduction zones around the world have brought the causal connection between seismically observed tectonic tremor (Obara 2002) and geodetically observed slow slip (Dragert et al. 2001) into sharper focus. In addition to the strong spatio-temporal correlation between the separately observed phenomena (Wech et al. 2009), mounting evidence indicates that deep, non-volcanic tremor represents slow shear (Ide et al. 2007; Wech and Creager 2007) occurring at the interface (Shelly et al. 2006, 2007) between the subducting oceanic and overriding continental plates, suggesting the two phenomena are different manifestations of the same process. Of course, there is still ongoing debate over the depth and mechanism of tectonic tremor (Kao et al. 2005; McCausland et al. 2005), but what is clear is that tremor serves as a proxy for slow slip. Considering geodesy’s lower limits in spatial resolution and slow slip detection together with the abundance of low-level, ageodetic tremor, this connection makes tremor a key component for monitoring when, where, and how much slip is occurring. Because slow slip transfers stress to the updip seismogenic portion of the plate interface (e.g., Rogers and Dragert 2003; Mazzotti and Adams 2004), monitoring transient events may serve in forecasting the threat of a megathrust earthquake by inferring the temporal and spatial variations in the loading of the seismogenic zone.
Assuming the task of monitoring tremor is of some importance, the process of creating a complete system to continuously monitor tremor begs a couple key questions:
I would like to outline a system developed to automatically detect, locate, and report tremor activity results on an interactive Web page (Figures 1 and 2). This system addresses the first aforementioned question by expanding on a recently developed technique (Wech and Creager 2008) using waveform envelope correlation and clustering (WECC) for simultaneously locating and detecting tremor. The second question, which is perhaps of greater interest in this column, draws on a combination of Google application programming interface (API; http://code.google.com/apis/ajax) products. These freely available APIs are powerful and dynamic resources that provide a number of utilities, which allow users to embed applications interfaced with their data in their own Web pages using JavaScript (I started here: http://en.wikipedia.org/wiki/JavaScript) and HTML. In combination with a freely available Dynarch JavaScript Calendar package (http://www.dynarch.com/projects/calendar) enabling interactive calendar displays, this tremor monitoring system utilizes applications from two Google API products: Google Maps API (http://code.google.com/apis/maps/documentation) and Google Visualization API (http://code.google.com/apis/visualization/documentation). I don’t need to tell you about Google Maps, but its unique mashup with the Annotated Time Line application (http://code.google.com/apis/visualization/documentation/gallery/annotatedtimeline.html) of Google Visualization API provides a very intuitive and dynamic user experience by providing an interactive timeline of tremor activity that is interfaced with the custom time range selection functionality. Finally, Google’s flash-based Motion Chart application (http://code.google.com/apis/visualization/documentation/gallery/motionchart.html) of Google Visualization API allows users to dynamically explore several indicators over time.
Combined, this system, which is currently being applied to the majority of the Cascadia subduction zone from northern California to mid-Vancouver Island, seamlessly and automatically turns raw waveforms into an interactive online catalog (Figure 1) and sends e‑mail/text alerts to interested parties with activity updates. Of course, the individual processes composing this system are not new. Near-real-time tremor detection and location has been addressed before on Vancouver Island (Kao et al. 2008), and there are many examples of realtime earthquake catalogs overlaying earthquake activity on maps. However, Cascadia tremor monitoring has never been done on this scale, and earthquake Web maps tend not to be very interactive or give the user very much control. Often these earthquake maps display a fixed time period of activity. So while the individual pieces aren’t new, it is the combination of these processes and utilization of freely available API resources that yields a useful and novel product of general public interest and accessibility that also addresses the growing collaborative efforts required by this interdisciplinary phenomenon.
Tremor is monitored across the subduction zone by piecing together seven overlapping subnetworks (seen by hovering cursor over region name in the “Region Options” pane on Web site), each containing ~20 stations, from northern California to mid-Vancouver Island. At the end of a GMT day, data from the Pacific Northwest Seismic Network (PNSN), Pacific Geoscience Center, Plate Boundary Observatory, and Northern California Regional Network are processed from 24-hour-long data files available at the PNSN. These data consist of approximately 100 short-period and broadband stations that span the up- and down-dip extent of the slow slip zone across the margin. Vertical component waveforms are bandpass filtered from 1–6 Hz (tremor frequency band), converted into envelope functions, low-pass filtered at 0.1 Hz, and decimated to 1 Hz. These preprocessed 1 sps envelopes are saved for a whole day and will be read in by the location code, which will parse out each region’s subnetwork. A parallel process also simultaneously generates envelopes low-passed at 0.05 Hz, decimated to 0.2 sps and saved as seven separate PDF documents (to be linked by the Web site for data viewing).
Detections and locations are automatically determined using WECC. For a given region, I choose a subnet of about 20 stations based on geographic distribution and known station quality. One region at a time, the location code reads in the daily envelope data and parses out the appropriate subnet of stations as defined by a database text file. Tremor epicenters then are automatically detected and located by employing a cross-correlation method to generate potential epicenters before using the resulting epicenters to detect tremor (Wech and Creager 2008). By automatically analyzing network coherence through epicentral reliability and spatial repeatability, this method simultaneously detects tremor and produces robust estimates of tremor locations.
Using a reversed methodology, WECC locates before detecting tremor. For a given five-minute time window of vertical- component envelope data, WECC automatically obtain centroid location estimates by cross-correlating all station pairs and performing a 3-D grid search over potential sourcelocation S-wave lag times that optimize the cross correlations. Using boot-strap error estimates of every 50%-overlapping window, only those solutions with epicentral error estimates less than 5 km are kept as potential tremor sources. These potential locations are then tested as an enduring signal localized in space. Two or more locations within a 0.1 x 0.1 degree area in a day are considered a cluster. These clustered epicenters are counted, and a successful detection is obtained when more than one hour of tremor (spread throughout the region and day) is identified in a region (as determined by summing fiveminute- windowed locations accounting for overlap). If this is the case, the latitude, longitude, and beginning time for each five-minute window for each tremor epicenter—defined by a five-minute window contributing to a successful detection—is appended to a text file catalog of that region. See Wech and Creager (2008) for details on detection, location, weights, and error estimates.
WECC is independently applied to each subnetwork with a grid spanning 2.5 degrees latitude and 4 degrees longitude. Because of detection limitations on the fringes of each network, the networks share edge stations and latitudinally overlap each other by about 50%. Analysis of duplicated locations within 25 km of each other obtained by overlapping networks shows that adjacent networks obtain epicenters with differences typically less than 10 km. This result has two positive outcomes. 1) It means that I can safely average the epicenters from duplicated time windows in regions of overlap. 2) The redundancy gives us further confidence in the reliability of WECC results.
As each region completes, it checks to see how many regions have completed that day. Once this check yields seven, the system checks if any of the seven regions detected more than one hour of tremor. If so, it composes an e‑mail summarizing the region(s) and amount(s) of tremor and sends this to recipients interested in alerts for a detected region. Also, if the system breaks somewhere along the line (e.g., missing data), it sends an e‑mail and text message alert to the person “overseeing” the process (me for the moment).
Regardless of detected activity, the final step (simultaneous with composing or not composing e‑mails) for the system is to get the results into a format that can be read and interpreted by Google’s APIs using Extensible Markup Language (XML) (http://www.w3.org/TR/REC-xml). XML is a set of rules for encoding electronic documents to represent arbitrary data structures with wide Internet compatibility. XML’s ability to contain a variety of data structures in a human legible format makes it very simple to transform a catalog of latitude, longitude, time, and region into an XML file that can be interpreted by JavaScript on the Web. For example, an XML file containing three tremor epicenters can be described as a marker with those attributes as follows:
<markers>
<marker lat="48.2800" lon="-122.9000"
time="01/07/2007 01:25:00" region="NW"/>
<marker lat="48.3000" lon="-122.8800"
time="01/07/2007 01:27:30" region="NW"/>
<marker lat="48.3000" lon="-122.8700"
time="01/07/2007 01:30:00" region="NW"/>
</markers>
This file can then be read in dynamically via JavaScript, and the attributes can be assigned to variables. Passing these variables into functions provided by Google Maps API will overlay markers at those locations on top of a Google Map.
As seen in the example above, an XML file is easy to interpret, and there are several ways to generate them. For smaller, static files like those containing station information, it is easy to iterate over network information to generate this XML file. However, for a tremor catalog comprised of tens of thousands of locations and counting, a static file would be several megabytes large. This continually growing file is too cumbersome for a browser to process for every plot request. Therefore, I generate these XML files dynamically using a Common Gateway Interface (CGI) (http://www.w3.org/CGI) script on the server side. After the system is finished analyzing all seven regions, it adds all locations to a MySQL database (http://www.mysql.com) (Figure 2). Then, with each plot request, a Python CGI script (http://www.python.org) queries this MySQL database, to return two query-specific XML files (Figure 2). The first is a catalog XML file that looks like the example above. The second is a summary XML file that has daily summaries of duration and number of epicenters for each region as well as the margin as a whole. This latter file is used by the Google Visualization API to generate the Annotated Time Line and the Motion Chart. These files are dynamically generated and returned to JavaScript functions to update the Web site.
Every step short of the Web Site (Figure 2) is performed using MATLAB software from MathWorks (http://www.mathworks.com). Day-long waveforms are read into and preprocessed with MATLAB via CORAL (Creager 1997), completing in about 10–15 minutes. Depending on tremor activity and station quality, per region WECC takes somewhere between 5 and 40 minutes. Using a quad-core computer, four regions are processed simultaneously. Monitoring a whole day across the entire margin is, therefore, completed in roughly an hour, and daily results are available online around 02:00 UTC.
With each region and date range request from the user, the catalog XML file is returned by the Python CGI (Figure 2) and individual epicenters are added to the map. To do this overlay, one uses a Google Maps API function to generate a “marker” for each epicenter. Each marker is then added to the map added to the table in the side bar containing a list of times for each tremor location. For all markers, I simply point to a low resolution image file of a red dot or a highlighting dot. This works well when there are not that many locations satisfying the request criteria. The full catalog, however, contains tens of thousands of epicenters, the attempted overlay of which would crash the Internet browser. Because each marker has many attributes (such as icon image file, height, width, shadow, html, info window, etc.), trial and error revealed that 1,000 of these “markers,” in fact, seemed to be the limit. Thus, requests of more than 1,000 locations require a different approach. First, to speed things up, requests of 1,000 or more epicenters no longer generate a list in the side bar. Also, there is an extension JavaScript of Google Map API, called “markerlight.js,” which generates a slimmed-down version of a “marker.” This light marker sheds information about an info window, shadow, etc. but can render much faster. Thus, for requests larger than 1,000 epicenters, the markers are generated using markerlight.js. They load faster and the map can handle more, but you lose the ability to click on them and obtain location information. This speeds things up considerably. But even so, the system simply can’t handle plotting 40,000+ light markers on a map. Therefore, for requests of more than 5,000 locations, the epicenter list is decimated to 5,000 epicenters by the Python CGI. Finally, the user has the option of color-coding the locations with time. This is achieved by creating 101 image files (pregenerated in MATLAB) of dots that smoothly vary from blue to red. For each location, the image file used in generating the light marker is determined by the time of the epicenter relative to the requested time range.
As mentioned before, a summary XML file is generated that contains daily summaries of number of epicenters and duration for each region. This file has four functions.
Though slightly unorthodox, tremor is summarized in duration rather than amplitude because the emergent and enduring nature of tremor signals creates a nebulous definition of what constitutes a tremor “event” or size. Determining tremor size is a work in progress, but at least knowing what fraction of a day was active in a given region seems to have meaning. Both the calendar (which highlights and provides summaries for active days) and the timeline are regenerated with each toggle of a new region. This allows the user to use the data presented in each to choose a date range. Furthermore, because of this connection between the timeline and date selection, a change in the timeline automatically populates the date fields with its current date range and each time range request automatically changes the timeline.
Some additional features worth mentioning:
Through a combination of techniques, I have developed a nearreal- time system that automatically turns raw waveforms into an interactive online catalog of tremor epicenters. Each of the two major aspects of this system, monitoring and dissemination, presents a new approach to a problem with potential efficacy beyond its current application in the Cascadia subduction zone. As tremor is found in more and more places and the quantity of data grow, the need for efficient systematic monitoring increases. Though I am not presenting it as a truly portable system, this detection and location approach provides a good option for systematic tremor searches and could be applied in other subduction zones. More important, regarding dissemination of information, the approach presented here provides the user with an intuitive and flexible experience that maintains the balance of general public accessibility and scientific utility— an experience that will only get better with the inevitable inclusion of more APIs and more server-side processing.
This example is specifically applied to Cascadia tremor, but the utilization of the APIs to provide an interactive Web experience could easily be applied in many different aspects of science and seismology—most notably earthquake catalogs. I use MATLAB to identify tremor and Python to generate XML files, but one could use any language to easily turn any catalog into an XML file that is interfaced dynamically via HTML and JavaScript with Google (or other) APIs. In the case of earthquakes, rather than automatically updating static maps with a catalog of the most recent weeks of earthquakes, one could dynamically generate or automatically update an XML file that serves to update dynamic maps with a full catalog of activity. I employed options to sort data by time and region, but the same approach could be extended to filter by region (predefined or custom), time, depth, magnitude, etc. One could even dynamically color-code by depth, magnitude, or time. Those are a few application ideas, but the incorporation of a CGI script performing server-side data manipulation or something like the Motion Chart application of Google Visualization API provides extraordinary flexibility. Both are powerful tools whose capabilities are only barely demonstrated in this paper. Together with its simple implementation, Motion Chart’s ability to enable users to simultaneously examine data with an x-dimension (linearly and logarithmically), y-dimension (linearly and logarithmically), color, and size—all with varying time—makes it an incredibly powerful tool with no end of possibilities, just begging to be explored.
Ultimately, I hope to have brought to your attention a whole host of Web resources for data dissemination. This paper highlighted a few specific APIs and how to interface these with data, but has just barely scratched the surface of possibilities. There are many more, and even the implementation of the ones discussed here could be improved upon and/or used in other ways. These tools are freely available, intuitive for users, easily interfaced with many types of data, useful for the public and scientists alike, and capable of facilitating clean and efficient data dissemination with surprisingly little effort.
This work was funded by USGS grant nos. 08HQGR0034, G09AP00024, and G10AP00033. Data are provided by the Pacific Northwest Seismic Network, Pacific Geoscience Center, Plate Boundary Observatory, and Northern California Regional Network. This work greatly benefited from support by Stephen D. Malone. Thanks to Google and to Jon Connelly, Mike Williams, and Pamela Fox for insights related to Google Maps. The intimate company of Weston A. Thelen, Daniel J. Morgan, and The Macallan is responsible for inspiration at lofty, golden heights. Lastly, I want to give a shout out to Creags, baller extraordinaire.
Creager, K. C. (1997). CORAL. Seismological Research Letters 68, 269– 271.
Dragert, H., K. Wang, and T. S. James (2001). A silent slip event on the deeper Cascadia subduction interface. Science 292, 1,525–1,528; doi:10.1126/science.1060152.
Ide, S., D. R. Shelly, and G. C. Beroza (2007). Mechanism of deep low frequency earthquakes: Further evidence that deep non-volcanic tremor is generated by shear slip on the plate interface. Geophysical Research Letters 34, L03308; doi:10.1029/2006GL028890.
Kao, H., S. Shan, H. Dragert, G. Rogers, J. F. Cassidy, and K. Ramachandran (2005). A wide depth distribution of seismic tremors along the northern Cascadia margin. Nature 436, 841–844; doi:10.1038/nature03903.
Kao, H., P. J. Thompson, S. Shan, G. Rogers, H. Dragert, and G. Spence (2008). Tremor activity monitoring in Northern Cascadia. Eos, Transactions, American Geophysical Union 89 (42), 405–416.
Mazzotti, S., and J. Adams (2004). Variability of near-term probability for the next great earthquake on the Cascadia subduction zone. Bulletin of the Seismological Society of America 94, 1,954–1,959.
McCausland, W., S. Malone, and D. Johnson (2005). Temporal and spatial occurrence of deep non-volcanic tremor: From Washington to northern California. Geophysical Research Letters 32, L24311; doi:10.1029/2005GL024349.
McCrory, P. A., J. L. Blair, D. H. Oppenheimer, and S. R. Walter (2006). Depth to the Juan de Fuca slab beneath the Cascadia subduction margin: A 3-D model for sorting earthquakes. U. S. Geological Survey Data, Series 91, v. 1.2, http://pubs.usgs.gov/ds/91.
Obara, K. (2002), Nonvolcanic deep tremor associated with subduction in southwest Japan. Science 296, 1,679–1,681.
Rogers, G., and H. Dragert (2003). Episodic tremor and slip on the Cascadia subduction zone: The chatter of silent slip. Science 300, 1,942–1,943; doi:10.1126/science.1084783.
Shelly, D. R., G. C. Beroza, S. Ide, and S. Nakamura (2006). Lowfrequency earthquakes in Shikoku, Japan, and their relationship to episodic tremor and slip. Nature 442, 188–191.
Shelly, D. R., G. C. Beroza, and S. Ide (2007). Non-volcanic tremor and low-frequency earthquake swarms. Nature 446, 305–307; doi:10.1038/nature05666.
Wech, A. G., and K. C. Creager (2007). Cascadia tremor polarization evidence for plate interface slip. Geophysical Research Letters 34, L22306.
Wech, A. G., and K. C. Creager (2008). Automatic detection and location of Cascadia tremor. Geophysical Research Letters 35, L20302.
Wech, A. G., K. C. Creager, and T. I. Melbourne (2009). Seismic and geodetic constraints on Cascadia slow slip. Journal of Geophysical Research 114, B10316.
[ Back ]
Posted: 25 June 2010