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@nsidc.org