Welcome, haere mai to another GeoNet Data Blog. Today we look at what happened behind the scenes when GeoNet recently installed new monitoring sites in response to volcanic unrest at Lake Taupō. We talk about how what we did enables many of our automatic data processing and analysis tools to work and allows everyone to access data from the new sites.
GeoNet maintains more than 800 permanent monitoring sites around Aotearoa New Zealand. We have such a large network because we need to continuously monitor Aotearoa’s tectonic activity and make sure that when a major event such as a large earthquake happens, we already have the monitoring sites in place to record the high-quality data necessary to assess and understand the event. In general, the sites are well distributed across the country, but there are situations where events can highlight gaps or limitations in our monitoring network in local areas. In those cases, we sometimes install additional monitoring sites to fill those gaps and to boost our monitoring capabilities. One such situation has been the recent volcanic unrest at Lake Taupō volcano, and especially the magnitude 5.7 earthquake that occurred on 30 November 2022.
Since the magnitude 5.7 earthquake we’ve made four enhancements to our monitoring network: - We built a completely new site on the western shore of Lake Taupō that has a seismic sensor and a GNSS sensor. - We added a seismic sensor to an existing GNSS site on the eastern shore of Lake Taupō. - We added a tsunami monitoring gauge to the navigation platform at Horomatangi in Lake Taupō where we already had a GNSS sensor. - We upgraded an existing GNSS site used by researchers to continuously transmit its data.
Establishing these new sites and sensors required effort from much of GeoNet. The Volcano Monitoring Group and Remote Infrastructure Management team worked closely with the Tuwharetoa Māori Trust Board, who own the bed of Lake Taupō, and other landowners, and then built and installed the sites. The Platform team set up and configured the communications from the sites to GeoNet’s data centres so that we could receive the new data in real-time. The Science Operations and Data team set up the meta-data that permitted automatic processing and analysis of the new data. It’s this final step that we are going to focus on today.
Delta is where GeoNet keeps all of the meta-data on its monitoring network and the equipment installed at all of the sites. Collectively, we call this our sensor network meta-data. It’s the data that allows everyone to understand and use the data we collect. Delta has two main components: a collection of comma separated value (CSV) files that contain all the information, and software that ensures the information in the CSV files are consistent. All of that is packaged in a GitHub repository. GitHub is normally used for software development, but our specialists have adapted it to become a highly effective network database. The Delta repository is public, so everyone can access and use the files stored there. If you are interested take a look. Even better, if you see an issue, please let us know at https://github.com/GeoNet/help, or raise a pull request. Delta is not only a repository, but also a dataset in itself, and can be cited appropriately.
Virtually all of GeoNet’s automatic data collection, processing, analysis, and data delivery relies on Delta. In the case of the Lake Taupō sites, the earthquake detection and location system, the system that calculates ground deformation from GNSS sites, and the application that delivers lake water level changes from the tsunami monitoring gauge, all rely on Delta to operate. In a similar way, we couldn’t provide webcam images, deep-ocean DART tsunami wave observations, or landslide information from Fox Glacier Valley without Delta.
When it comes to GeoNet’s monitoring network, we call Delta our “single source of truth”.
We must be careful changing files in Delta as a mistake might affect our data processing or analysis. GitHub, which hosts Delta, is a “version control” system so, if we need to, we can revert changes to files. The software we keep in Delta automatically checks the consistency of related CSV files, helping reduce the chance of mistakes. We also reduce mistakes by using GitHub’s system of “peer review”, where every change must be checked and accepted by an appropriate specialist before it can be made.
Here are the main groups of files in Delta. They cover all of what you need to understand what data we are collecting, where, and with what instruments, they make special configuration files for data processing (more on that soon), and there is software to do the automatic checking we’ve mentioned.
|network||locations of observation sites and groups of sites|
|environment||geological and physical environment of data collection points|
|assets||equipment used to collect observations – make, model, serial no., etc|
|install||equipment installed, configuration, connection details|
|calibration||sensor calibration information|
|docs||documenting naming conventions used|
|tests||software to automatically check files in Delta|
|tools||software to automatically make configuration files for data processing|
|resp||describing exactly how seismic sites record ground shaking|
|tides||describing the tides at tsunami monitoring gauge sites|
While Delta is critical to how GeoNet works with its data, it’s really difficult to make it sound exciting! Let’s take a look at the new western Lake Taupō site and see if we can’t do a better job!
The new site is called Karangahape. Sites all use unique site codes, so we don’t have to refer to them by their full name all the time, Karangahape has two site codes, one for the seismic part (KPRZ) and one for the GNSS part (TGK1).
The file network/stations.csv gives where the site is located.
There are few important things to note about the meta-data in Delta. Locations are always in decimal degrees of latitude and longitude in the WGS84 datum, never NZTM or any other coordinate system. This is because GeoNet’s seismic data are used by overseas agencies for detecting and locating earthquakes, and a New Zealand specific coordinate system isn’t very practical for that. Dates and times are always in Universal Time (UTC), which is indicated by the “Z” after the start and end dates. All of our data collection instruments use UTC; it makes it easier for the international community to share data when no one has to worry about time zones, not to mention daylight saving time! An End Date of 9999-01-01T00:00:00Z means that the site is still operating. The file network/sites.csv contains a similar entry, but shows the Location code, 10. This allows us to describe multiple sensors installed at the same site and distinguish their data.
Station Network Name Latitude Longitude Elevation Depth Datum Start Date End Date KPRZ TP Karangahape -38.801994 175.792935 593 WGS84 2022-12-13T00:00:00Z 9999-01-01T00:00:00Z
Station Location Latitude Longitude Elevation Depth Datum Survey Start Date End Date KPRZ 10 -38.801994 175.792935 593 WGS84 Internal GPS Clock 2022-12-13T00:00:00Z 9999-01-01T00:00:00Z
The files install/dataloggers.csv and install/sensors.csv show the seismic digitiser and sensor installed at Karangahape, their make, model, and serial number. This allows us to track what was installed at what site and is really useful if we later discover problems with an instrument. Here is the file showing the digitiser.
Our seismic digitiser at KPRZ collects data at a rate of 100 samples per second (sps) and 1 sps. That’s important for someone using the data to know, so it’s recorded in install/streams.csv.
Make Model Serial Place Role Start Date End Date Nanometrics Centaur CTR4-6S 9460 Karangahape 2022-12-13T00:00:00Z 9999-01-01T00:00:00Z
Station Location Band Source Sampling Rate Axial Reversed Triggered Start Date End Date KPRZ 10 L H 1 false false false 2022-12-13T00:00:00Z 9999-01-01T00:00:00Z KPRZ 10 H H 100 false false false 2022-12-13T00:00:00Z 9999-01-01T00:00:00Z
All the meta-data in Delta from seismic sites are used to generate a stationxml file that is used as configuration for our SeisComP earthquake processing system.
GNSS site The files in Delta that hold information about GNSS sites are slightly different from those used for seismic sites because the nature of the data and their collection and processing are different. GNSS data are used to monitor slow and ongoing deformation of the ground. For that, data are collected and processed every day to determine the position of a site and its subtle change with time. To do so, geodesists, as GNSS specialists are known, need comprehensive and accurate meta-data so their processing is correct, and results have maximum precision.
The file network/marks.csv contains the basic information about a site’s location.
You may have noticed that the position and elevation information for the GNSS site is much more precise than for the seismic site; for example, the elevation is given to a precision of 1 millimetre. This is because the position is the result of our analysis of the GNSS data. GNSS data users need to know details about the survey mark used at a site, how high the antenna is above the ground surface, and how the survey mark is built. This information is held in the network/monuments.csv file. The file also contains information about Bedrock and Geology, but for clarity we’ve not shown those here.
Mark Network Igs Name Latitude Longitude Elevation Datum Start Date End Date TGK1 XX no Karangahape -38.802024175 175.792913036 580.135 WGS84 2022-12-19T00:00:00Z 9999-01-01T00:00:00Z
Mark Domes Number Mark Type Type Ground Relationship Foundation Type Foundation Depth Start Date End Date TGK1 Forced Centering Steel Mast -0.73 Reinforced Concrete 0 2022-12-19T00:00:00Z 9999-01-01T00:00:00Z
To obtain the best accuracy, the processing software also need to know what equipment was used to collect GNSS data. We provide the make and model of antenna used to receive the signal from the GNSS satellites in install/antennas.csv.
Make Model Serial Mark Height North East Azimuth Start Date End Date Trimble Navigation Ltd. TRM115000.00 2612758717 TGK1 0 0 0 0 2022-12-19T21:53:26Z 9999-01-01T00:00:00Z
We also provide calibration files for each model of GNSS antenna.
There’s also a corresponding file for the receiver (the GNSS equivalent of the seismic digitiser) and the receiver firmware, but we won’t show that here. All of these files are used by the processing software to accurately decode and interpret the raw GNSS data.
Software in Delta automatically makes “sitelog” and “stationinfo” files for each site from the GNSS meta-data. These are used in the international geodetic community to share information about GNSS sites and to setup analysis software. Our “Gamit/Globk” analysis system uses the stationinfo file.
At the navigation platform at Horomatangi in Lake Taupō we added a tsunami monitoring gauge. The sensor and the digitiser are the same as we use at our coastal sea level sites where we observe tsunami waves, but this is the first installed in a lake. The site code is HRMT. The information in Delta is quite similar to what we’ve seen before, it is in network/stations.csv.
Some of our applications need to distinguish HRMT from coastal sites. On the coast, we need to remove the tide from the water level so it’s easier to see tsunami waves. But Lake Taupō has no tides, so we don’t need “de-tided” data. We distinguish HRMT by the Network code “LG”, for Lake Gauge, while coastal sites have a Network code “TG”, for Tsunami Gauge. As HRMT is our first site to observe tsunami waves on a lake, we had to carefully think through what we needed to do to get data processing working the way we needed.
Station Network Name Latitude Longitude Elevation Depth Datum Start Date End Date HRMT LG Horomatangi Reefs -38.8128616 175.996331 385.999 WGS84 2022-12-22T00:31:15Z 9999-01-01T00:00:00Z
HRMT has similar files for the sensor and digitiser as the seismic sites, so we’ll skip showing those.
As with the seismic and GNSS sites, we use the Delta meta-data to configure “downstream” data processing. For tsunami gauges such as HRMT, an important activity is ingesting the data into the Tilde application which we use to provide data collected at (relatively) low rates to everyone. Tilde also uses Delta as it’s “source of truth”.
You can see how the Delta meta-data powers Tilde by visiting our Data Discovery GUI (Graphical User Interface). To view data from HRMT you need to select “coastal” as the Domain, “water-height” as the Name, and “HRMT” as the Station.
We all know that the exciting stuff GeoNet does are things like installing new sites in spectacular locations, flying round volcanoes sniffing gases, tracking how quickly a landslide moves downhill, and sitting on the edge of our seat waiting to see if large undersea earthquake has triggered a tsunami. All of these things work because we have a tool like Delta that acts as an engine to setup and drive most of what grabs everyone’s attention. It’s sometimes useful to remind ourselves that what goes on behind the scenes is essential, and without it most of the exciting stuff simply wouldn’t work! You can find our earlier blog posts through the News section on our web page just select the Data Blog filter before hitting the Search button.
We welcome your feedback, and if there are any GeoNet data topics you’d really like us to talk about, please let us know! Ngā mihi nui.