Luke,
I hope you don't mind me responding to the GLIMS database list. Your
complete message is below, interspersed with my comments.
On 2002-02-21 16:19 -0700, Luke Copland wrote:
> Hi Bruce,
> It's very useful to see a mockup GLIMS dataset, and I have a few
> comments after quickly glancing through it:
> 1. We won't be able to submit glacier outlines as a series of PolyLineZ
> segments due to the huge amount of work this would involve (for each of
> our many ice caps, there are hundreds of basins which each consist of
> many hundreds of line segments). Rather, we will have to submit our
> outlines as a single PolygonZ for each basin, which will mean that the
> material on either side of the outline will not be identified. This
> shouldn't be a problem, though, as the 'mugshots' of each glacier should
> enable a user to see the conditions around the basin edge.
Attributes for each segment are not mandatory, so this is fine. Perhaps
with increased automation, material attributes can be assigned
automatically in the future.
> 2. A second set of shapefiles will be included for each basin outline to
> distinguish exposed rock areas within the basin. This is partly due to
> the fact that we are using hydrological basins as our basic unit of
> analysis, not the exact outline of the edge of the ice/glacier (although
> these often coincide).
We have several types of arcs or polygons other than glacier outlines
defined in the database already: centerlines, ela_lines, etc. We have
decided to generalize the table in the database to hold this kind of
information, so that one table will hold all these types of features. An
attribute will distinguish the feature type. I think this is a good way to
store information about internal features such as nunataks and debris cover
also.
> 3. We won't be able to include any information about tiepoint regions:
> we are using orthorectified and mosaicked Landsat 7 imagery which does
> not have this information.
Tiepoint regions are optional. The idea behind them is to facilitate
automatic image registration. The analyst (at the RC) can identify a
region suitable for finding tie points for coregistering images, draw a
polygon around it, and submit this as a "tiepoint region". Obviously, such
a region would include rock outcrops and the like, and exclude glaciers and
bodies of water.
> 4. You haven't made any mention of which format you would prefer
> elevation data to be in.
I'm not sure what you mean with this question. If elevation values are
known along the outlines, x,y,z triplets can be stored in the shapefile;
that's the Z in PolygonZ. Or, are you talking about how to handle a DEM
derived from ASTER data? Point elevation data derived from field
measurements?
> 5. I still know very little about PVL, and how you go about putting a
> PVL file together for GLIMS. Is there a special program I can use to do
> this? Have you thought about putting all the information for a basin in
> the attribute table associated with the shapefile for that basin, rather
> than in PVL? This would seem like a convenient way of reducing the
> number and complexity of files.
The Parameter Value Language (PVL) concept came about because there seemed
to be information that didn't neatly fit into the attribute tables of the
shapefiles. In the current design, there is only one shapefile per
analysis session, which holds spatial information either a) on a
per-segment basis (with several segments making up a complete outline for
each glacier), or b) on a per-glacier basis (akin to your proposal in 1).
But there is information that doesn't neatly fit into either of these.
Brainstorming here for a moment, it appears that there are several "levels"
of attribute information:
- per segment: Segment.segment_left_material, etc.; positional
uncertainties
- per basin (or per glacier): Glacier_Dynamic.width, .length, .area,
.speed, location of "mugshot"
- per session: Glacier_Dynamic.analysis_timestamp, .analyst_last_name,
.institution_id, etc.
- area-elevation histogram: per glacier, but slightly different?
- displacement vectors, vector set information
It appears possible to put all information in shapefiles and eliminate the
PVL file, but we would need to have several levels of shapefiles. Thus,
the overall number of files would increase, but they would all be
shapefiles. A couple of comments on the possibility of going in this
direction:
A. The folks in Flagstaff are writing interactive software to assist in
the creation of the PVL file and (I think) shapefile, under the current
design. Other than that, I know of no software to generate PVL files.
However, the format is rather simple. Rick/Hugh/Jeff: What's the status
of this software?
B. We need input soon from anyone who feels strongly one way or the
other about PVL files vs. shapefiles. This issue needs to be settled
soon, because we are at the stage of needing to write the data ingest
software.
> ...we're in the process of putting some of our data up on an ArcIMS web
> server, which should give you a better idea of how our stuff is fitting
> together. I'll let you know when this is up and running.
> Am interested to hear any thoughts you have about my comments.
>
> Cheers,
> Luke
Thanks for your comments, Luke.
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(a)nsidc.org
