post-Chamonix database changes, etc.

[Bruce Raup]

Hi Luke and everyone.  Sorry about redundant postings.

On 2002-10-28 14:23 -0700,  Luke Copland wrote:

> Hi Bruce,
> 	Attached is the 'databasing guide' that I spoke about at the Chamonix
> meeting - hopefully you will find it useful when putting together the
> 'cookbooks'. It's not finalized yet, but should provide a decent start.
> 	In response to your questions about the databasing, I think that Fabian
> Munz's descriptors provide a good start. They cover all the basic WGMS
> characteristics, as well as a couple of useful additions. In terms of
> having more than one descriptor for a particular glacier, I tend to
> favour your second idea of allowing multiple entries. These don't
> necessarily have to be in the same column, however, as the commas might
> be confusing. Couldn't you just have multiple columns for (e.g.)
> long_char, front_char, etc.?
> 	As we chatted about before, I also favour having 3 primary segments for
> each glacier: ice outline, rock outline, and basin outline. From what I
> can tell, this is really the only way to cover all the angles in any
> potential data analysis. Only two of these really have to be defined for
> any particular glacier as the third segment can be calculated as an
> addition or subtraction of the other two.
> 	Your other suggestions also sound fine for mean slope, etc. However, I
> have the feeling that people are getting confused by the large number of
> potential inputs to the database for each glacier (I know that I have a
> hard time keeping track of everything!). Hopefully, the 'cookbooks' will
> make life much easier for the regional centres when figuring out what
> they need to produce for GLIMS.

Thanks for the guide!  In my note to the glims mailing list, I meant to
mention yours, but forgot.  Sorry.

Your document seems to fit into the "Analysis Guidelines" category.  I
think the Flagstaff group will soon have a similar document based on their
"glimsview" program.  At least in the short term, I suggest that there be
links to these two documents from the main GLIMS web site in Flagstaff.
Your guide could be on a server of yours, of course, but it would have to
be in HTML.  For the analysis guidelines, it might be good to have a few
end-to-end descriptions, or case studies, that are based on different
tools.

Regarding multiple descriptors for glacier characteristics:  Your
suggestion of using multiple columns is a possibility I didn't mention.  I
suppose that in this case, the number of simultaneously applicable
characteristics is limited enough that multiple columns could work -- allow
a maximum of two or three, for example.

I think your ideas about 3 primary segments are compatible with mine about
an additional table to define "glacier membership" for different line
types.  I agree that "ice outline = basin outline - rock outline".  But
somewhere, this logic must be implemented:

if ("ice outline" doesn't exist) {
  ice outline = basin outline - rock outline
}

and the question is Where?  The GLIMS database is designed to contain
"glacier" outlines as the primary data; thus, I think that this kind of
topological subtraction should be done before ingest into the database,
preferably at the RCs, so that they (you) can have control over the
integrity of that process.

Then there's the topic of calculating glacier areas from data in the
database.  Because we've decided not to store polygons with holes in them,
many glacier outlines will include areas (nunataks, e.g.) that should not
be included in the area calculation.  (The topological subtraction above
shouldn't operate on rock that's completely internal to the ice boundary.)
That's where the proposed new "glacier membership" table comes in.  Glacier
area would then be the area of the ice outline minus the area inside all
the "internal rock" outlines.  Rock outlines that are not completely
internal to the ice outline shouldn't be stored in the database.  If a rock
outline straddles an ice outline, then the topological subtraction wasn't
done properly before ingest.  (Note that outlines of surface features, such
as debris or lakes, could straddle the ice boundary.)

BTW, I don't know how easy this sort of topological subtraction is using
your tools.  If such an algorithm hasn't been implemented in tools we have
available, I've sketched out how I would do it from scratch.  It's pretty
straight-forward conceptually, but there are a few pathological cases.

These are just my ideas.  Storing basin outlines in the GLIMS database
could potentially work too, but that would require some changes to the
database design, as well as additional logic for keeping things straight
(i.e. when the ice outline isn't explicitly stored).  We could easily add
the line type "basin_boundary", as we've planned, but the glacier outline
still needs to be stored explicitly, I think.

Cheers,
Bruce

-- 
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