GLIMS definition issues

John L Dwyer dwyer at usgs.gov
Fri Aug 24 10:36:28 MDT 2001


Bruce -

I've embedded some comments below preceded by ***.

Thanks,

John


John Dwyer
EDC DAAC Project Scientist
Raytheon ITSS
USGS EROS Data Center
Sioux Falls, SD 57198
Voice: (605) 594-6060
Fax:    (605) 594-6567
email:  dwyer at usgs.gov
http://edcdaac.usgs.gov


                                                                                                                                 
                    Bruce Raup <braup at nsidc.org>                                                                                 
                    Sent by:                               To:     GLIMS Parameters mailing list                                 
                    owner-glims_database at flagmail.w        <glims_param at flagmail.wr.usgs.gov>, GLIMS Database mailing list       
                    r.usgs.gov                             <glims_database at flagmail.wr.usgs.gov>, <jferrign at oemg.er.usgs.gov>,   
                                                           <rswilliams at usgs.gov>                                                 
                                                           cc:                                                                   
                    08/23/01 11:52 AM                      Subject:     GLIMS definition issues                                  
                                                                                                                                 
                                                                                                                                 



Hello all.

I am readying a manuscript for submission to Eos about the GLIMS database
and the scientific considerations that went (are going) into its design.
Below are a few excerpts which need discussion in the wider GLIMS
community.  The issues are:

1.  Definition of a "glacier"
2.  How to treat ice shelves
3.  Coordinate systems

I'm asking for your feedback on the way I've addressed this issues, and
whether you think there are any problems with this.  Thanks in advance for
your quick and insightful comments.

Bruce

P.S.  Sorry if you get this message more than once.

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


\section{Scientific Considerations}

\subsection{Glacier as Basic Unit}

The fundamental unit in the GLIMS database is the \emph{glacier}.
The definition of ``glacier,'' however, can be a bit problematic.  Glacier
networks, following the underlying drainage basins, are topologically
tree-like.  At one extreme, one could treat a contiguous, but possibly
highly complex and dendritic, ice mass as one unit, and track changes in
its area over time, in a way similar to how sea ice or seasonal snow cover
are tracked using remote sensing.  At the other extreme, one could decide
to treat each branch and ``leaf'' of the tree as a separate unit, putting
arbitrary boundaries between different branches of the glacier complex at
confluence points.  While more complicated, this approach would have the
advantage of treating as separate units masses of ice that historically
have been
given separate names, despite possibly being connected to other ice bodies.
Introducing arbitrary boundaries at confluence points allows the
distinctions between ``glaciers'' to be made that have always been made by
field-based scientists.

***I think an important point to emphasize is that the data becoming
routinely available
from satellite-based remote sensing systems will enable us to address
numerous challenges in
conducting a global inventory of glaciers.
(1) We will have opportunities to bridge and/or fill in gaps in the
field-based observations,
     at least with respect to some parameters (area, terminus positions,
etc.)
(2) Remote sensing will allow us to conduct analyses at multiple scales
(3) There are always going to be discontinuities, geographically and
temporally, in the
     information available.  However, one of the strengths of the GLIMS
project is that
     we will be using fairly consistent baseline data sets (ASTER, Landsat)
and common
     data processing and analysis protocols.

A problem with mandating that all GLIMS analyses dice up ice masses to the
ultimate level is that such detailed distinctions are seen as burdensome
and unnecessary in areas where there is no such historical view.  In
regions studied for the first time through remote sensing methods, Regional
Center analysts should be free to include tributaries as part of a larger
trunk glacier.

***I don't think we should shy away from even the most simple mensurations,
particularly
for those areas that have not been previously studies.  Multi-resolution,
multi-source
remotely sensed data should enable us to conduct mapping geographic extents
not possible
or feasible with aerial photography, for example.

Thus, the GLIMS group has decided on an intermediate approach:  the
database is designed to store information about any body of ice contained
in a single (simple or compound) drainage basin.  A ``glacier'' can thus be
an ice mass in a simple valley, or a large glacier system with many
tributaries.  Ice flow divides are necessarily considered glacier
boundaries.  In the database, glacier records can be related, so that,
should a compound glacier system be analyzed at a greater level of detail
in later years (e.g., a glacier system is analyzed as three glaciers
instead of one), the database records for the ``children'' glaciers can be
associated with that of their ``parent.''


Within the GLIMS framework, ice shelves are not considered to be part of
glacier systems.  Thus, the ``terminus'' of an ice stream that feeds an
ice shelf is the grounding zone.  If the location of the grounding zone is
uncertain, this will be reflected in the error estimates in the position
recorded in the database.

***Similar to geologic mapping, many features can/should be delineated as
known
or inferred.  The uncertainty for each should be quantified and catalogued
where possible.

\subsection{Coordinate Systems and Errors}

Three fundamental coordinate systems are used in the GLIMS processing
stream:
\begin{enumerate}
\item Local image coordinate system (abbreviated L/S).  Units are
      line/sample, and are referenced to a corner of a particular band of
      a particular image.
***uniform pixel size (IFOV) is assumed.

\item Local ground coordinate system (abbreviated N/E).  Units are
      meters north and meters east of a \emph{reference point} on the
ground
      that is typically, but not necessarily, contained in a given image
being
      analyzed.
      Typically, there is one reference point per glacier, although
      a single reference point can be shared by many glaciers.
***ASTER Level-1B and Landsat Level-1 products are all geographically
referenced
using the satellite empemeris data to model satellite position and
attitude,
as well as sensor geometry.

\item Global coordinate system (abbreviated L/L).  Units are geodetic
      east longitude and latitude (decimal degrees).
***This is no doifferent from above except for the projection and units.

\end{enumerate}

***I'm a little confused about the points you are trying to make here.
Certainly, there
is a distinction between the local image coordinates (line/sample) and
geographic
coordinates (lat/long or N/E).  However, the accuracy of the geographic
referencing is
determined by the level of geometric processing: Level-1 systematic
corrections versus
precision geolocation using controls points corrected for relief
displacement versus
full terrain correction resulting in an orthorectified product.

***For georeferenced images, it is imperative to know the projection AND
datum.  The axes
of the ellipsoids can be retrieved from the Generalized Cartographic
Transformation Package
(GCTP), but the datum can not.  the latter must be defined explicitly.  You
need both in order
to move between cartographic projections.  It is also necessary to know
cell or map scale in
cases where only one georeferenced point is provided.

The relationships between the coordinate systems are illustrated in
Figure \ref{fig:coords}.

At the image processing stage, the L/S coordinate system is used.  Once
glacier outlines, centerlines, and other point and vector data have been
produced from the analysis, these coordinates are transformed to either N/E
coordinates, a system of northings and eastings referenced to an easily
identifiable point in the image, or L/L coordinates.  The database has been
designed to store coordinates in either system.

In most cases, the location of objects within an image will be known
relative to each other with higher accuracy (~15 m or less) than the
knowledge of their absolute positions (on the order of 100 m from
spacecraft position and attitude (orientation) knowledge).
When glacier outlines are stored in N/E coordinates, relative and absolute
positions are inherently stored separately, with the N/E coordinates
carrying the relative information, and the L/L position of the reference
point carrying the absolute information.  When glacier outlines are stored
in L/L coordinates, uncertainties in relative and absolute positions will
be explicitly stored separately in the database.

***I don't necessarily agree with the last two statements as written.  It
depends on whether
one set of coordinates is associated with a systematically corrected
product and the
other relates to a precision corrected product.  Expressing the coordinates
of a point
in one set of projection units versus another does not improve accuracy by
itself.

The alignment between the image coordinate system (L/S) and the true L/L
grid is determined by the angle the orbit track makes with the meridian
lines (a known function) and the yaw of the spacecraft, typically known to
better than 10 arc-seconds (48 urad).  This amounts to 3 m over the
60 km width of an ASTER image.  The maximum error in calculated northings
and
eastings should therefore be on the order of 3 m, after terrain correction
has been applied.  The angular relation between the N/E system and the L/L
grid varies slightly over a spacecraft scene and depends upon the
cartographic projection used.  Any well-defined cartographic projection may
be used; GLIMS uses the Universal Transverse Mercator (UTM) projection.

***I think you are mixing relative accuracy, with respect to a
systematically
corrected product and its internal geometry, with absolute accuracy once an
image
has been precision/terrain corrected.  See the attached file (if you can
read a
Powerpoint slide) that shows how well the geometry and georeferencing of an
ASTER
Level-1B product compares with a map-overlay.  I would consider either
re-writing this
paragraph or leaving it out.


For the inclusion of older data from other sources, outlines in L/L
coordinates will also be storable in the database.  If a L/L system is
used, the ellipsoid is also recorded; if a N/E system is used, information
about the reference point is stored.

***Again, projection AND datum are most important. Cell size (for images)
or
scale (for map-derived vector data) should also be provided.










More information about the GLIMS mailing list