Improving access to geodetic imaging crustal deformation data using GeoGateway

GeoGateway uses a service-oriented architecture with Web-based user interfaces (Fig. 3). GeoGateway provides core services for accessing UAVSAR, GNSS, and related data (Table 1). UAVSAR repeat pass interferometry (RPI) products (Hensley et al. 2005) and UCERF3 (Field et al. 2014) fault traces are provided by GIS services operated by the GeoGateway project and use the open source GeoServer software (http://​geoserver.​org/​). GNSS data services (Heflin et al. 2020) are operated by NASA JPL (https://​sideshow.​jpl.​nasa.​gov/​post/​series.​html), and seismicity data are obtained from USGS earthquake catalog. In addition, users can upload their own data sets in KML format (Fig. 4).

GeoGateway has undergone a significant upgrade, involving a complete rewrite of its user interface, which we have maintained since 2014.The upgraded site was deployed at the end of 2020. We deprecated older Web framework approaches (AngularJS, Node.js, Google Maps) in favor of better supported, non-proprietary technologies (Vue.js, Django, Leaflet). We are also reviewing all software in order to provide better organization so that it will be easier to maintain and to modify by new developers. The new technology stack aligns with other projects in the Indiana University Cyberinfrastructure Integration Research Center, which develops and operates GeoGateway, increasing GeoGateway’s maintainability. The new technology stack is also aligned more closely with Apache Airavata middleware, which enables us to provide better support for executing scientific software asynchronously on managed, shared clusters and supercomputers. It also enables us to build on Apache Airavata’s security components, which can be used to provide improved group management and the ability to share results with collaborators in GeoGateway.

The collection of semi-autonomous services is complemented by execution services that can remotely execute relevant geophysical software. This software ranges in complexity from simple, interactive executions of Okada-based surface displacement calculations (Okada 1985) to the somewhat more computationally demanding inversion of these calculations to find best fit fault models, and to the intensive calculations needed to perform finite element-based simulations of fault systems.

Both data and execution services can be treated as relatively independent services and have APIs. Combining these services into useful workflows, such as linking the InSAR or GNSS data to one of GeoGateway’s geophysical applications, is the task of GeoGateway middleware. In order to manage the executions of software and transfers of data as input and output of analysis applications, GeoGateway provides an abstract container, called “Experiment” (Pierce et al. 2014), that collects all the basic information needed to conduct a specific user-driven workflow. This metadata collection is an immutable object in the system once the experiment is completed, but it can be cloned and used as the basis of other computations. It can also be shared with collaborators or made public.

GeoGateway middleware itself is accessed through its own set of APIs, which mediate calls between the user interface environment and the middleware. The user interface environment encapsulates common usage scenarios, which it translates into GeoGateway middleware calls. Many of the GeoGateway operations are interactive and map-based, so we make extensive use of client-side JavaScript libraries to create the user environment. The middleware thus also plays an important role in mediating service calls from users’ browsers to diverse remote services; the middleware acts as a broker for these calls, which otherwise would be subject to cross-site scripting restrictions on the client.

GeoGateway provides a collection of tools, APIs, and interfaces to access the data hosted on its GeoServer-based data servers (Table 1). These can be integrated with data from various data providers with Open Geospatial Consortium (OGC) standards (http://​www.​opengeospatial.​org/​).

UAVSAR RPI products are distributed as pure binary files with the metadata in a separated annotation file. A single file ranges in size from 500 Mb to 5Gb. To use the RPI data products in common GIS software such as GeoServer used in GeoGateway, ArcGIS, and QGIS, it is necessary to extract geo-spatial information from the annotation file to generate a proper header file. Neither the UAVSAR binary format or the Hierarchical Data Format version 5 (HDF5), specified for the upcoming NISAR mission, are an efficient file format to be used with GeoGateway’s online tools. GeoGateway and its predecessor QuakeSim project (Donnellan et al. 2006; Pierce et al. 2010; Parker et al. 2015) have converted 10 Tb UAVSAR RPI data products into GeoTiff format with the following steps: 1) Extract geo-spatial information from UAVSAR annotation file; 2) Convert UAVSAR from single band binary format to GeoTiff with the tiles and image pyramids options; 3) Calculate histogram and summary statistics; 4) Track metadata changes for the different processing procedures and parameters of UAVSAR images. 5) Register UAVSAR images and pre-rendered full-resolution image overviews with GeoServer. With these processing procedures, it enables GeoGateway to distribute the large UAVSAR image in full-resolution to the downstream applications through the Open Geospatial Consortium’s (OGC) Web Map Service Interface Standard (WMS) and Web Coverage Service (WCS) protocols. This allows rapid exploration and feature extraction of large collections of UAVSAR RPI datasets with open-source GIS software, enhances UAVSAR images with a dynamic coloring scheme (Wang et al. 2015), and provides a color blind-friendly coloring theme as an alternative visualization method to InSAR fringe patterns. For the NISAR mission, ASF will have on the fly converters to GeoTIFF, or better services for handling HDF5 will be available.

The advantages of adopting OGC standards for both data products and web services have been utilized by downstream projects, such as E-DECIDER (Emergency Data Enhanced Cyber-Infrastructure for Disaster Evaluation and Response; Glasscoe et al. 2014; Glasscoe et al. 2015), which employs remote sensing imagery, geodetic data, and tools from GeoGateway to automatically generate change detection products, critical infrastructure and deformation calculations triggered by an earthquake event.

An early motivation of support for overlays is the observation that UAVSAR data are complex and difficult to understand; historically a high level of technical competence has been required. Overlays of different data types in a Google Maps environment are illustrated in Fig. 2, which shows a UAVSAR product for the 2020 M7.2 El Mayor – Cucapah earthquake (Donnellan et al. 2014; Donnellan et al. 2018b), with line-of-sight displacement profile tool, and GNSS overlay. Note that while the tools are accessed by the tabs at the top left of the GeoGateway interface, any imaged item will be retained as the user moves to a new tab and tool to enable composite images. Users may toggle of any of the product overlays. Depending on the investigation, the user may visualize the following products in the map environment individually or in composite:

We continue to add tools, including for modeling, but these are most often used for overlays. All are described in the User Guide. Using all would usually result in excessive clutter, but combinations can be highly helpful in initial exploration of physical processes behind the data sets.

In addition to the combination of UAVSAR and GNSS, overlays of fault traces, forecasts, and seismicity can provide insights about regional hazard. Overlaying fault traces, interferograms, and seismicity may enable discovery of fault slip on minor faults or segments of major faults.

Finally, combining the KML mapper with composite tool-based images allows overlay of GeoGateway scenes with user-supplied mapped items, such as location of strainmeters, field-surveyed locations, polygons marking areas of study, or third-party kmz files, subject to mapping limitations. Often a useful technique is to create markers, polygons, image overlays and so forth in Google Earth, collect them in a folder, and save the folder to KMZ for import into GeoGateway with the KML mapper.

GeoGateway currently supports forward modeling for an arbitrary number of faults using software called Disloc. Users can specify location, geometry and slip for each fault. In the current GeoGateway interface users upload an input file, which is then run on the backend. GeoGateway displays vectors and a simulated interferogram of the output. Users can specify the azimuth and elevation between the pixel on the map and the simulated instrument. A graphical user interface (GUI) that included map selection and parameter input was available in the earlier version thatran under QuakeSim. In the future we plan to implement Disloc using Jupyter Notebooks so that users will have similar GUI capability.

GeoGateway hosts applications that apply machine learning algorithms to GNSS and seismicity data. GeoGateway’s machine learning tools are in transition. The GeoGateway team is developing numerous new machine learning and related applications, which we expect to integrate into the gateway as they mature. The interim integration that we will pursue in the next several months is to deploy JupyterHub and use it to make team-developed Jupyter notebooks available online. This will be integrated with GeoGateway to provide single sign-on, and team-developed notebooks will be developed to use GeoGateway’s underlying services via API calls.

One such approach uses a variant of hidden Markov modeling to search for anomalies in GNSS position time series data (Granat and Donnellan 2002; Granat 2004). We have supported RDAHMM classification of permanent GPS/GNSS stations since 2014 in the current GeoGateway; this application was also included in earlier versions of the gateway.The goal is to focus attention on subtle features in the data.

We are in the process of developing machine learning tools to further analyze the geodetic imaging products. We have developed unsupervised learning methods, which do not require labeled features, to identify GNSS vector clusters as well as to perform time series segmentation. Clustering GPS stations (Granat et al. submitted) not only has the potential for identifying useful scientific information, such as separating regions of post-seismic motion or ranking active fault systems, but also is a necessary initial step in other GPS analysis methods, such as those used to detect aseismic transient signals (Granat et al. 2013). Using this approach, desired features of interest can be selected, including some subset of the three displacement or velocity components, uncertainty estimates, the station location, and any other relevant information present in the data set. Based on those selections, the clustering procedure autonomously groups theGNSS stations according to a selected clustering method; some methods require that the number of groups be specified in advance, while others estimate the number of groups from the data. We have implemented this approach as a Python application, allowing us to draw upon the full range of open source clustering methods available in Python’s scikit-learn package (Pedregosa et al. 2011). The application returns theGNSS stations labeled by group in both tabular form and as a color coded KML file for overlay in Google Earth or GeoGateway.

The GeoGateway Earthquake Hazard Viewer under the nowcast tab provides several useful tools for the evaluation of earthquake hazard and risk. The forecast method is based on the Natural Time Weibull model developed by Holliday et al. (2016) and Rundle et al. (2016a, b). The Forecast Exceedance Probability Table on the web site shows the probability that an earthquake with magnitude exceeding M5, M6, M7, or M8 will occur within the selected region within the next one month, one year, or three years.

The Forecast Timeseries Chart shows the probability, as a function of time, that any point within a 50 km radius of any point in a selected region suffers an earthquake exceeding a given magnitude in the next year. The Global Forecast Map shows for any point on the map the probability that an earthquake of magnitude exceeding M6.5 occurs in the next year in a circle of radius 50 km of that point. The Ground Shaking Estimate is the Peak Ground Acceleration (PGA) that would be expected from an earthquake of given magnitude, location, and other earthquake variables.

An Open Hazards earthquake forecast is a real-time, seismicity-based forecast that computes probabilities in defined spatial areas using the Open Hazards Forecast Model. Open Hazards can compute a forecast at any time using real-time seismic catalogs to obtain the most current probabilities. The model is based on the Gutenberg-Richter magnitude-frequency distribution and on one of the most fundamental ideas in earthquake mechanics, the cycle of stress accumulation and release on major faults. Peak Ground Acceleration (PGA) is a measure of ground shaking. Open Hazards estimates PGA using a slightly modified form of the Cua-Heaton model (Cua and Heaton 2007).

Nowcasting is the prediction of the present, the very near future and the very recent past (Rundle et al. 2016a, b, 2018; Rundle et al. 2019). The term is a contraction of “now” and “forecasting” and has been used for many years in meteorology. Nowcasting uses proxy data to estimate the current dynamical state of a driven complex system such as earthquakes, neural networks, or the financial markets. Seismic nowcasting uses counts of small earthquakes as proxy data to estimate the current dynamical state of an earthquake fault system, or collection of interacting earthquake faults. The result is an earthquake potential score that characterizes the current state of progress of a defined geographic region through its nominal earthquake “cycle.”

The count of small earthquakes since the last large earthquake is the natural time that has elapsed since the last large earthquake. To use the nowcast calculator in GeoGateway , enter the latitude and longitude of a point on the map, as well as a name for the location. The system computes the nowcast within a 100 km radius circle for earthquakes of magnitude larger than 6.0.

Creeping faults are faults that have evident slip apart from the occurrence of local earthquakes, even small earthquakes. Examples well-covered by UAVSAR observations in the time span 2009-present include the roughly constant slip found on the central San Andreas Fault (SAF; Liu et al. 2011), the intermittent slip on the Superstition Hills Fault (SHF) and also parts of the SAF in the Salton Trough, and parts of the Hayward Fault and Rodgers Creek Fault east of the San Francisco Bay. We demonstrate the utility of GeoGateway tools for two case studies, focusing on the central SAF and the SHF.

Fault creep is observed in UAVSAR RPI products near the central part of the creeping SAF segment (Fig. 5). This case study and the next use three GeoGateway tools, accessed by the tabs at upper left of the interface. Note that mapped items are retained as we move from tab to tab, creating a composite mapped image of all the items created. UCERF 3 fault lines are displayed by checking the corresponding box in Map Tools, one of the tabs at top left in GeoGateway. The colorful interferogram is selected and displayed by selecting the UAVSAR tab, then selection of a flight line and repeat pass interferogram are made using methods illustrated in the GeoGateway user guide. Similarly, the line-of-sight (LOS) profile is created on a user-selected line as shown in the user guide. Geometry for converting line of sight to horizontal or vertical displacements is shown in Donnellan et al. (2014). The profile values may be saved to a file for further analysis. The projected displacement across the fault is shown to be 2.2 cm. Assuming pure strike-slip motion, the non-projected actual slip scales this by 1/cos(D)and 1/cos(E), where D is the difference of the fault strike and the radar look azimuth (140–138) = 2^o, and E is the elevation angle = 38^o. So the actual right-lateral slip is 2.2/cos(2^o)/cos(38^o) = 2.8 cm in 12.7 months. The Seismicity tab enables selection of earthquakes from the ANSS catalog, according to constraints of a geographical coordinate box, a time span, and magnitude limits, as described in the user guide. The resulting set of seismic events are displayed as red dots, sized according to magnitude.

Similar results of the same procedure are found for line 08518 (Fig. 6), selecting a profile crossing the Superstition Hills Fault for an interferogram in 2017.The profile indicates projected slip at this point on the fault is 2.2 cm over nearly 6 months, 10 km distant from any seismicity. In this case the difference of the fault strike and the radar look azimuth = 2^o, and the elevation angle = 38^o, indicating right-lateral motion = 2.7 cm. In both cases over 2.5 cm of right-lateral strike slip motion, assuming no dip-slip fault motion, is deduced where the profile crosses the fault. The closest seismic event in the radar pass time span is over 10 km away and about M 3. Therefore, these are creeping events, not caused by local earthquakes.

This Superstition Hills Fault creep event is found here in an interferogram based on a radar pass time span that includes the M 8.2 Chiapas earthquake of September 8, 2017 (UTC date) located in southern Mexico, suggesting that in this case slip may be triggered slip from a 2800 km-distant large earthquake. Triggered creep from this earthquake was detected on the southernn San Andreas fault (Tymofyeyeva et al. 2018). Plausibility is enhanced by a collection of ground water steps and spikes across the continental United States coincident with the Chiapas event, documented at https://​waterdata.​usgs.​gov/​blog/​earthquake.

GeoGateway was used in a study to determine the ability to identify landslides in UAVSAR image pairs. The study focused on the La Conchita landslides of 1995 and 2006, which were catastrophic to the local community (Pulver et al. in preparation). The 1995 slide destroyed or damaged a total of 14 houses over the course of two events that were six days apart. The slide in 2005 was considerably smaller, but caused much more destruction and loss of life. In 2005, the mass movement destroyed or severely damaged 36 houses, and killed 10 people. GeoGateway provided an easy way for early exploratory analysis within a web browser as well as a download link for further exploration. The profile tool was also used in determining ground range change across the La Conchita landslides (Pulver et al. in preparation). The KML mapper feature proved useful when drawing these profiles. It allowed the input of a KML with both the 2005 and 1995 slide areas defined as polygons, and displayed them on the map. The aim of the study was to find an identifiable feature of the landslide in the UAVSAR image to be able to spot slides like this before they happened. The La Conchita slide was clearly visible in the data, even in images collected many years after the sliding event (Fig. 7). The difficult aspect of this is identifying areas of sliding without previous field knowledge of their existence. In this study, the profiles pulled directly from geo-gateway were analyzed for patterns and anomalies in an attempt to identify a signature of the known unstable region of La Conchita.

GeoGateway’s architecture is designed to keep end user environments and abstract middleware tasks separate, allowing us in principle to replace the user environment with other approaches. This has become increasingly important with the emergence of Jupyter Notebooks and their online hosting via JupyterHubs. GeoGateway’s user interface layer can be replaced with online Jupyter Notebooks running in Jupyter Hubs (Fig. 8); this approach provides a simpler operational approach to users running notebooks locally. Notebooks provide a flexible alternative to the fixed user interfaces of the Web-based GeoGateway client environment. With sufficient documentation through example notebooks, advanced users can create their own custom notebooks that are specific to their scientific research efforts. Code can be hidden to provide less experienced users with a more intuitive interface. These notebooks can be shared via GeoGateway’s GitHub repository. Notebooks are also a powerful way to prototype new user interface capabilities. The default GeoGateway Web interface represents a set of tools and capabilities that we consider to be commonly useful. Creating usable interfaces by distributed development teams with diverse expertise is challenging using traditional methods. Notebook interfaces will allow our core team to more quickly prototype new interfaces and enhancements to existing interfaces before pushing these into production usage.

We are working on improved application support for GeoGateway. GeoGateway has simple support for scientific applications, which we are enhancing to support a greater range of applications of interest to our team and the geophysical community. We are working on implementing simpler ways of adding and configuring new applications, both from within our team and from third-party providers. These applications need to run on diverse resources, such as supercomputers, campus resources, and computational clouds for full analysis of complex and large volume geodetic imaging data. The Apache Airavata software for science gateways (Marru et al. 2011) provides us with a much more sophisticated mechanism for executing scientific workflows, managing user identities and permissions, integrating with diverse resources, and managing data transfers.

Finally, we focus on the development of tools that can assist with the more demanding computational requirements of uncertainty quantification and on the development of middleware that can provide better support for the development and execution of machine learning-based applications. Machine-learning applications have several needs. Currently GeoGateway hosts GNSS analysis and seismic analysis machine learning tools. The first searches for anomalies in the GNSS time series data (Granat and Donnellan 2002; Granat 2004). We also display earthquake forecasts and users can create nowcasts (Rundle and Donnellan 2020). We are creating new machine learning applications, which we must verify and validate. GeoGateway then needs to execute mature validated applications as software as a service. This builds on services already part of the Apache Airavata middleware, although there are opportunities to improve support for containerization of codes.

As part of future GeoGateway developments we are developing clustering algorithms to divide GNSS velocity and displacement fields across discontinuities, generally associated with fault boundaries (Granat et al. submitted). We are improving the seismic nowcasting methods. We also plan to display modeling and simulation products related to earthquake and tsunami simulations and improve the automated machine learning tools. Tsunami simulations will involve a new developmental code called Tsunami Squares. This code is a cellular automaton code to propagate ocean bottom disturbances across basin-wide distances. An advantage of this method is that dry-land tsunami run-ups can be easily calculated. The tsunami software must run offline due to the complexity, but we plan to display products from these codes on the GeoGateway website. Future developments also include the deployment of tools to explore geodetic image and cluster velocities or displacements. This helps identify boundaries of deformation and provides a means to rank fault activity. Because geodetic products are non-uniform both in space and time, we are developing approaches to interpolate the data, based on the machine learning algorithms to provide uniform pixel by pixel time dependent displacements that can be used for interpretation and ingestion into geophysical deformation process models. Ultimately our goal is to increase the user base by providing tools to simplify and promote rapid analysis of geodetic data products and move toward expansion of GeoGateway to include user contributed applications.