post-Chamonix database changes, etc.

[Bruce Raup]

Hello,

After the Chamonix meeting, a long message sent to the main GLIMS mailing
list included summaries of issues discussed by the two working groups.
I've quoted the database section of that below, and interspersed some
further thoughts, proposals, and comments.

Changes to the database are mostly additions of valids for some fields, but
there are two issues that are a bit more tricky.  Here goes.

> Database (compiled by Raup, Database/Parameters WG leader):
>
>   The following items were identified as high-priority issues for the
>   database/parameters working group:
>
>   - Identify sensible set of glacier characteristics -- improved over WGMS
>     and existing GLIMS.  Should be able to combine different descriptors
>     for one glacier:  both piedmont and calving.  Fabian Mauz's pictorial
>     dictionary of glacier types, forms, is a good prototype "cookbook" to
>     describe glacier parameters.

There are really two things here:

  1) what set of characteristics should we use? (probably a superset of the
     WGMS parameters), and

  2) how do we implement the ability to combine different descriptors for
     one glacier?  An example is that the "frontal_characteristics" field
     for a glacier should be both "piedmont" and "calving".  There are
     three possibilities:

       - Instead of simple numeric codes for the valids, use binary numbers
         that are strings of bits, each one a flag for a particular
         characteristic.

       - Simply use the existing codes, but allow them to be concatenated
         together, separated by commas.

       - Use an intersection table in the database to allow the
         many-to-many relationship.

     The first two methods have the disadvantage that the user would need
     to parse the code/string.  The third method makes the database even
     more complicated.  The simplest to implement would be the second one,
     but may cause headaches down the road.  The complexity with the third
     one might also cause headaches down the road.  Another option, I
     suppose, is not to allow combined characteristics.

>   - We need "cookbook" guidelines!
>
>   - Definitions of various parameters need to be made more clear:  glacier
>     width, length, area, speed (where?), snowline.  In all these cases, we
> need
>     segments which show the future user where the quantity was measured.
>     Check WGMS definitions in each case.

We have decided to add more valids to the "line_type" field in the
Glacier_Line table (which currently be things like "outline", "centerline",
"snowline", etc.) to store segments in the database that illustrate where
various scalar measurements were taken, such as width, length, etc.  The
issue of WGMS definitions should be addressed in the Analysis Guidelines.
(See my note to the glims mailing list of 3 days ago.)  That is, that
document should describe where widths and lengths should be measured, where
the ID point should be located, etc.

>   - (mean) aspect and slope, in accumulation and ablation areas, should be
>     added to the database.  Possibly allow different definitions of mean
>     slope:  mean of cells in raster DEM; overall slope calculated as
>     rise/run.

This could potentially lead to 6 new scalars:  mean slope from DEM, mean
slope calculated from two x,y,z points, and mean aspect, each for
accumulation and ablation areas.  Further, the mean slope calculated from
two points would probably need to be associated with a new vector segment,
since one would need to know how the distance between the two points was
measured (along a straight line?  along a flow line of the glacier?).

I sense we should put this one on hold for a while, until we get a better
handle on what data actually get generated.  Other thoughts?

>   - Defining glacier boundaries, especially where rock outcrops intersect
>     basin boundaries.
>
>   - Add category "basinbnd", if it's not there already.
>
>   - Category:  "non-glacier-outline" (rocks, water) vs "glacier-outline"
>     (debris).  At top level, could have 3 categories:  basin boundary, ice
>     boundary, and non-ice boundary.  This is so we can easily distinguish
>     between non-glacier segments (rocks) and supraglacial segments
>     (centerlines, lakes, debris, etc.).

Restating this problem:  When doing automatic calculations of, for example,
glacier area, we need to know which other polygons to include as part of
the "glacier" (e.g. debris cover, supraglacial lakes), and which to exclude
(nunataks).

So far, we have a number of line types:  glacier outline, rocks, debris,
etc.  I propose creating a new table in the database, which would be
pre-populated by NSIDC, that would pair with each line type a flag
describing whether it's part of a glacier or not:

  Proposed Table "Glacier_Membership":
    line_type                   primary key
    part_of_glacier_flag        Y/N

That way we don't have to make the system of line types more complicated by
adding things like "non-glacier-outline".  That would be encoded in this
new table.

> --Category: Other profile data types required, such as surface profile
> (segment),
>     basement profile, field point measurements

For datasets such as Keith Echelmeyer's laser altimeter profiles of glacier
surface, I propose adding the line types "sfc_elev_profile",
"bed_elev_profile".  Does this make sense to everyone?

>   - When filling in data, the operator/database should make a distinction
>     between "unclassified" and "no data".

In cases of "no data", fields can be left blank.

-- 
Bruce Raup
National Snow and Ice Data Center                     Phone:  303-492-8814
University of Colorado, 449 UCB                       Fax:    303-492-2468
Boulder, CO  80309-0449                                    braup at nsidc.org