coordinate systems used in GLIMS

Hello GLIMS-related folks. I submit the following for your feedback. I am sending it to the entire community because 1) the issue touches the whole community, and 2) this list has too little traffic on it. :-) Happy New Year. Bruce Issue: coordinate systems used in GLIMS Previous idea: Multiple coordinate systems would be supported by (stored in) the GLIMS database. Examples include: lat/long, locally defined northings/eastings, UTM. Benefit of previous idea: GLIMS data suppliers (Regional Centers) could work in their preferred coordinate systems and submit the data without conversion. Problems with previous idea: - End users of the GLIMS database who query the database over potentially large regions should be able to expect the returned data to be in a uniform coordinate system, not a hodge-podge of different projections. - Storing many coordinate systems complicates the design of the database. Proposal: The only coordinate system stored in the GLIMS database will be lon/lat on the WGS84 datum. Benefits of current proposal: Having a single coordinate system for the entire GLIMS database would greatly simplify its use, as well as its implementation. Potential problem with current proposal: Regional Centers must translate their output data into lon/lat/WGS84. (This is thought not to be a big problem.) Notes: - Absolute and relative positional uncertainties will still be tracked separately. - We acknowledge that many RCs do or will work in local coordinate systems (e.g. UTM/NAD83, Polar Stereographic), but we assume it wouldn't be a big burden to request that all new analysis results be submitted in lon/lat/WGS84. Is this assumption correct? - For older data, and perhaps special cases with newer data, NSIDC may be able to do the coordinate conversion at time of data ingest. But my sense is that most RCs should be able to do the translation easily with whatever package(s) they use to generate the results. - Commercial packages like ESRI's should be able to handle coordinate transformations easily. I also know of a few free software packages that will do coordinate transformation: GMT (Generic Mapping Tools (http://gmt.soest.hawaii.edu/)) Proj.4 (Cartographic Projections Library; does datum shifts as well. (http://www.remotesensing.org/proj/)) GRASS (actually uses Proj.4 internally; http://www.baylor.edu/grass/) - Distances and areas are generally calculated in projected coordinates. Obviously, this can still be done at Regional Centers. There is, however, the question of how individual points (polygon vertices) are assumed to be connected: along great circles, or as straight lines in some projection. A quick test has shown (see below) that this difference will not be a problem, assuming 1) suitable projections are used by both data supplier and end user, and 2) points that are connected aren't more than 100 km or so apart. In the below, "Error" is the distance between the midpoint of the segment as calculated on the great circle connection versus that calculated on the straight-line connection in the projection. Lengths (last two columns) are great circle lengths. Projection: South polar stereographic, true scale at -71 degrees) Input coordinates Length Error (lon,lat,lon,lat) Note (km) (km) --------------------------------------------------------------------------- -60 -75 -50 -77 Ronne Ice Shelf front 349.700 0.290 -165 -78 -180 -78 Ross Ice Shelf front 347.335 0.249 -165 -78 -166 -78 Ross Ice Shelf front 23.219 0.001 -165 -78 -169.33 -78 100 km segment, east-west 100.516 0.021 -165 -78 -165 -78.9 100 km segment, north-south 100.484 0.019 Projection: (UTM zone 13, over Colorado, USA) Input coordinates Length Error (lon,lat,lon,lat) Note (km) (km) --------------------------------------------------------------------------- -105.6505 40.0233 -105.6490 40.0251 Arapaho Glacier 0.237 0.000 -105 40 -105 40.9 100 km segment north-south 99.939 0.002 -105 40 -106.175 40 100 km segment east-west 100.337 0.002 -108 40 -108 40.9 same N-S, at edge of zone 99.939 0.008 -108 40 -109.175 40 same E-W, at edge of zone 100.337 0.010 -- 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

Bruce: The new proposal of course requires double precision. I agree that conversion between geographic and mapping coordinates generally is not impractical. I think arc interpolation is not as issue, as GLIMS points will rarely be spaced by more than a few km, the fractional error is roughly linear with spacing, and at 10 km is < 1.E-5 . My sole remaining concern is tracking of absolute location uncertainty and how to update all points associated with an image analysis when the image location is improved by whatever means. If points remain linked to their image origin, and the basis for locating that image is tracked, then updates can be automated. Is this capability being built into the GLIMS database? Hugh ----------------------------------------------------- Hugh H. Kieffer hkieffer@flagmail.wr.usgs.gov U.S. Geological Survey Phone 928-556-7015 2255 N. Gemini Drive FAX -7014 Flagstaff, AZ 86001 Main Office -7000 -----------------------------------------------------

GLIMSters: All feedback I received (from 7 or 8 people) regarding storing only lon/lat coordinates in the GLIMS database was generally positive. So, while we've been proceeding in this direction already for several weeks now, I would like to state clearly on this list that this has been firmly decided. Notes: 1. RCs will do (or are doing) their analyses in the projection of their choosing. Only final results to be submitted to NSIDC need be converted to longitude/latitude on the WGS84 datum. 2. It can be (and, indeed, has been) shown that the difference between interpolation between polygon points in a projection versus along a great circle is negligible for GLIMS applications. 3. Both local (relative, or within-image) and global (absolute geodetic) uncertainties will be stored for each polygon or segment. (The new data dictionary and Entity Relation Diagram will be on the website soon.) 4. GLIMS segments (parts of glacier outlines, centerlines, ELA lines, etc.) are linked to their source images in the database. Thus, if the geolocation of a source image is improved upon, the positions of segments derived from this image (and their uncertainties) can be updated. 5. Having made this decision, the parts of the database design that dealt with reference points, coordinate system definitions, etc. have been removed. 6. As has been noted before, there is good and freely available software for doing coordinate transformations. Examples include: Proj.4 - Cartographic Projections Library (http://www.remotesensing.org/proj/). This includes utilities for doing batch-oriented or interactive coordinate transformations, including datum shifts. Generic Mapping Tools (http://gmt.soest.hawaii.edu/) Cheers to all, 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
participants (2)
-
Bruce Raup
-
Hugh Kieffer (GD.Flagstaff) (928)556-7015