GLIMS Database: Details

Information on the GLIMS NSIDC glacier database design

The following represents the current state of the design of the GLIMS glacier relational database. The Data Dictionary contains detailed information about the fields in each table, and the Entity Relation Diagram illustrates the relationships between the tables. If you find the ERD hard to follow, perhaps the table relationship statements will help.

Database features:

1. The two main tables are Glacier_Static and Glacier_Dynamic. The first stores static (unchanging) information, such as glacier name. The second stores all of the measured attributes of a glacier, including its outline, speed, and the like. Several tables, such as Glacier_Outline, Center_Line, Area_Histogram, conceptually reside within Glacier_Dynamic, as records within those tables are associated with one "snapshot" in Glacier_Dynamic. A record in the Glacier_Dynamic table (a "snapshot") is referred to as an "analysis".
2. A few tables hold related information. The Institution table holds information about participants in the GLIMS project, including who did a particular analysis. The Point_Measurement table holds information about physical measurements that are associated with a particular glacier, but not necessarily with an analysis in the Glacier_Dynamic table. These point measurements might include albedo, temperature, debris thickness, etc.
3. The Tiepoint_Region table contains polygons enclosing areas on the ground which are seen to be good areas for finding tie points using automatic cross-correlation methods. This is to support the future automation of coregistration of imagery.
4. The scheme decided on to represent the glacier outlines, centerlines, etc. was to store "segments", which can contain many points, in one place. These segments are then used as building blocks by the Glacier_Outline, Centerline, and Tiepoint_Region tables. Segments can be shared. For example, at an ice flow divide, the boundaries of the glaciers on either side will coincide. These segments are stored in the geometry column of the Segment table, and are in geodetic (longitude/latitude) coordinates.
5. Glacier outlines are required to be closed. If part of a glacier is obscured by clouds, then the analyst should come up with a "best guess", and that particular segment will be labeled as being interpolated through cloud. Segment types include "measured", and "arbitrary" (useful for closing the polygon at the upper end of a glacier that merges into an ice field, where the flow divides are unknown). See the Segment table attributes for the various ways a segment can be labeled. Segment attributes can be assigned that define the feature or material on the "left" or "right" side of the segment. These are to be assigned bearing in mind that vertices in glacier outlines go counterclockwise (anticlockwise), and internal rock boundaries go clockwise.
6. There is an intersection table between Glacier_Dynamic and Image, meaning that a particular analysis can have more than one image associated with it. This might be useful, say, if the analysis is done from an image mosaic, or from the result of the fusion of different types of images. If more than one image is associated with a particular glacier analysis, then the "as-of" date will be taken to be the date of acquisition of the most recent image.
7. A tentative list of minimum requirements for a submission from a Regional Center is as follows:
1. glacier outline
2. GLIMS ID (based on the lat/lon location of a "centerpoint" on the glacier)
3. Data source
4. Date and time of analysis
5. Analyst's name
6. Analyst's institution
7. Description of processing, including algorithms
Some of these items will be enforced at the application level, a level above the database itself. That is, the database design itself with not mandate all of these items, in order to allow addition of historical glacier data.

The Flagstaff and Boulder groups discussed how best to represent the dendritic nature of the interconnections between glaciers. Glaciers can flow into each other, diverge from a common 'parent' ice body, and so on. This information can be partially stored in the database, since each record in Glacier_Static can point to a "parent ice mass" via the "parent_icemass_id" field. However, this scheme may be augmented in the future.

2001-02-16: We've decided to go with a tagged reference format, along the lines of the Endnote text-based format.

Entity Relation Diagram (ERD)

• Version 2008-07-17

Data Dictionary

• Data Dictionary

List of valids for enumerated fields

• valids.txt