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.
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".
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.
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.
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
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.
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
A tentative list of minimum requirements for a submission from
a Regional Center is as follows:
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 outline
- GLIMS ID (based on the lat/lon location of a "centerpoint" on the
- Data source
- Date and time of analysis
- Analyst's name
- Analyst's institution
- Description of processing, including algorithms
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
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)
List of valids for enumerated fields