"left" and "right" sides of glacier boundaries

[Graham Cogley]

     One problem with hydrological "handedness" (look downstream and identify
"left" with your left hand) is that it does not work for polygons for which
"downstream" has no meaning, such as drainage divides. In computer graphics,
and more generally in topology, the decision between "inside on the left" and
"inside on the right" becomes arbitrary - it doesn't matter which you choose,
*but* it is essential that you make your choice and then stick to it. In the 
nesting of polygons, for example, it is desirable for nunataks to have the
opposite polarity from glaciers and for glaciers inside nunataks to have the
same polarity as glaciers. If they do, then all the glacier areas come out 
positive and all the nunatak areas come out negative. In other words, the
polygons carry valuable information implicitly, and for this basic measurement
it is not necessary to rely on explicit coding of the polygon type.

     For what little it is worth (because I am not contributing actively to 
GLIMS), my vote would be for the opposite convention from Bruce's (because all 
of the polygons on my computer are that way around). But I would urge the
desirability of getting as soon as possible to the state described in Bruce's 
second paragraph. There are ways of achieving this, but they mean a little
work. As an interim measure, would it be feasible to provide a button to 
reverse the polarity of any polygon (or polyline)? Or even a button to reverse 
the polarity of all polygons/polylines sharing some chosen attribute?

     Graham.
     gcogley@
          _/                                            _/
         _/                                            _/
      _/_/_/     _/ _/_/     _/_/_/      _/ _/_/    _/_/_/    _/     _/
       _/       _/_/   _/  _/     _/    _/_/   _/    _/      _/     _/
      _/       _/         _/_/_/_/_/   _/      _/   _/      _/     _/
     _/  _/   _/          _/          _/      _/   _/  _/  _/     _/
     _/_/    _/            _/_/_/    _/      _/    _/_/     _/_/_/  .ca

             J. Graham Cogley, Ph.D., Professor of Geography,
                Department of Geography, Trent University,
        1600 West Bank Drive, Peterborough, Ontario, CANADA K9J 7B8.
    Fax 705-742-2131.  Tel 705-748-1011-ext1440.  Email gcogley at trentu.ca
             http://www.trentu.ca/geography/glaciology.htm

----- Original Message ----- 
From: Bruce Raup 
To: gcogley1 at cogeco.ca ; GLIMS Mailing List 
Sent: Thursday, 24 February 2005 17:28
Subject: "left" and "right" sides of glacier boundaries


Hi all,

As you probably know, the GLIMS database provides for storing information
about what materials and features are on the left and right sides of
glacier boundary segments, and the GLIMSView program makes it fairly easy
to assign such attributes to digitized glacier boundaries.  However, the
definition of "left" and "right" hasn't really been firmly specified.

Ultimately, it would be nice if in GLIMSView, you could just click on one
side or the other and not worry about whether it is "left" or "right".
But we're not there yet.

I propose the following solution.  Since it might negatively impact those
who have already assigned such attributes, I want to get your feedback.  I
propose ordering all polygons to be in counter-clockwise order (interior
on left) at ingest time.  References to left and right would be according
to this vertex ordering.

GLIMSView currently outputs polygon segments with points ordered in the
direction of digitization, and can therefore output segments with
inconsistent direction when placed within the polygon.  My ingest software
already puts the segments together so that they match up end-to-end in a
consistent direction.  Now I'd like to make the handedness consistent too.

Comments?

Bruce

-- 
Bruce Raup                                               Phone:  303-492-8814
National Snow and Ice Data Center, U. of Colorado, 449 UCB, Boulder, CO 80309
http://cires.colorado.edu/~braup/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://nsidc.org/pipermail/glims/attachments/20050225/1e822d0b/attachment-0001.html>