Participants:

Gordon Adams, NGS
Yehuda Bock, SIO/SOPAC
Fran Boler, UNAVCO Boulder
Maury Dube, GSFC/CDDIS
Bob King, MIT
Chuck Meertens, UNAVCO Boulder
Mark Murray, UCB/NCEDC
Doug Neuhauser, UCB/NCEDC
Will Prescott, USGS/UNAVCO
Michael Scharber, SIO/SOPAC
Dave Stowers, JPL
Bill Sumner, CWU/PANGA
Michelle Van, NGS
 

This was the first meeting of the full U.S. GSAC Working Group since January 1999 and served as a forum for reviewing the status of the current and potential U.S. Wholesalers, the development of the Retailer at SOPAC and its implementation at the UNAVCO Boulder facility, clarifying formats and procedures, and setting goals for the future.

Bob King (GSAC Community Coordinator for UNAVCO) began the meeting by asking each of the participants to give a short report on GSAC and other archiving activities at their institution. Yehuda Bock and Michael Scharber mentioned the work at SOPAC to develop exportable software for implementing both Wholesaler and Retailer services (see below), and also the tie-in of this work to the California Spatial Reference Center (CSRC) based at SOPAC. Chuck Meertens and Fran Boler (and briefly, Wayne Shiver) described the role of the Data Management Group at the UNAVCO facility in testing and implementing both the Wholesaler and Retailer software, and indicated that they are an active Wholesaler. Mark Murray and Doug Neuhauser described the activities of the Northern California Earthquake Data Center (NCEDC) in archiving both GPS and seismic data from the USGS and Berkeley, the status of their GSAC holdings (almost there), and their interest in becoming a Retailer as well as Wholesaler. Bill Sumner, representing the Pacific Northwest Geodetic Array (PANGA) data center at Central Washington University, reiterated his group's long-standing interest in becoming a Wholesaler and potentially a Retailer. Dave Stowers (and, briefly, Frank Webb) indicated JPL's role as manager of NASA's Global GPS Network (GGN) and described three levels of data storage: on-line, fast cache, and off-line (DVD). Gordon Adams and Michelle Van described the NGS role as both an archive and distributer of short-term (hourly) and long-term (daily) files from Continuously Operating Reference Stations (CORS), a role that in both design and resource allocation presents some conflicts with NGS's rapid development as a GSAC Wholesaler or Retailer. Maury Dube from the CDDIS reported that he developed his own scripts for generating GSAC data holdings records (DHRs) and has done so now for over three years. Finally, King expressed his sense that GSAC is close to becoming functional for a meaningful set of data held in U. S. archives, and his hope that the project can secure international participation and sponsorship before it becomes public.

Michael Scharber presented an overview and demonstration of the current Retailer, using an Internet connection to SOPAC. The current interface has both a web and a command-line client, each able to query the data base on attributes (data type, wholesaler, etc.), time, and coordinates. The web client (http://gsac.ucsd.edu/cgi-bin/GSAC.cgi) provides a user-friendly introduction to the system but is more limited than the command-line client (downloadable from http://gsac.ucsd.edu/downloads.html), which has more flexible queries and allows actual retrieval of data files from the Wholesaler archives. SOPAC has not yet devoted time to optimizing the Retailer queries of the data base, current implemented using Postgres, so spatial queries covering more than a few days are quite time consuming. Fixing this, perhaps using a two-tiered search (first spatial, on the Monument Catalog, then with other attributes on the DHRs) is the top priority for the immediate future. Later in the meeting, the group provided detailed feedback on the current web interface, which will be reflected in changes to be made at SOPAC over the next few weeks.

Fran Boler presented an overview of the UNAVCO implementation of the SOPAC (Perl) Wholesaler kit. She has developed ten scripts, based on the kit, to manage UNAVCO's creating, updating, and deleting of GSAC tables. Michael asked whether potential Wholesalers without a working knowledge of Perl might prefer a set of executables (for Linux, Solaris, and Windows). A decision on this should await specific requests by new Wholesalers. Boler noted that with either the Perl kit or executables, a new Wholesaler would still have some work to adapt these tools to the structure of an existing archive.

For the remainder of the meeting, over both of the half-day sessions, the group discussed a number of pending issues, summarized below:

Retailer specifications: Doug Neuhauser pointed out the value of standardizing the interface between the client and the agent that queries the data base so that all groups that want to provide a retail service can use either a client or agent developed by another group. Action item: SOPAC, with help from UNAVCO, will complete the documentation of the Retailer software including specifications for the interfaces.

RINEX navigation files: There is at present no way to publish (that is, create a DHR) on GSAC a merged navigation file. Moreover, the single-site files contribute a large number of records for each day, each providing nearly the same information. Although some commericial processing software requires a navigation file with the same name as the obervation file, this feature can obviously be by-passed by renaming a merged file. Action items: Version 1.1 of the specification document, to be adopted immediately, will allow a null entry in field 3 (unique_site_id) for data type 'rinex_nav' to accommodate merged files; Wholesalers should publish these files instead of files constructed with navigation data from a single station.

Site information: Should there be an IGS-format site log for each station, field monuments as well as those used for continuous tracking? Or should there be a new file type similar to what processing programs use to override RINEX information? Should other site-related information, such as digital photos, scanned log sheets, and site descriptions be accepted into GSAC? Action item: Gordon Adams will chair a sub-group to design an XML format for site logs and recommend formats for GSAC records of image files. Adoption of these new data types should await full operation of GSAC and a more extensive revision (Version 2) of the specifications document.

Mirroring: GSAC specifications provide that the DHR for any file published by more than one Wholesaler should contain the name and unique_info_id of the original Wholesaler, as well as the unique_info_id of the mirroring Wholesaler. This protocol assures traceability of the data file so that if it is changed by the Data Provider, the modified or replacement file is propagated correctly to all Wholesalers and Retailers. The DHRs currently published by some Wholesalers often do not meet this requirement because DHRs were derived from existing data bases that do not contain information about the source of the file. Although we do not want to slow down the development of GSAC by requiring rigid adherence to the mirroring rules, we agreed that Wholesalers should make a diligent effort to comply. Action item: SOPAC and NCEDC will republish their DHRs with correct mirroring wherever it can be determined.

Monument names: Although the combination of the wholesaler and unique_site_id serves to identify unambiguously each monument in the combined Monument Catalogue, there is as yet no mechanism in place to associate identical monuments among Wholesalers. Action item: Duncan Agnew will develop such a scheme and propose it to the next meeting of the WG.

System testing: There are two levels of testing that need to be accomplished. One is internal integrity: whether GSAC returns correctly information known to be contained in DHRs from all Wholesalers. For this we will need to rely on debugging tools applied by SOPAC in developing the Retailer codes, and on queries for data in regions for which the testing user has personal knowledge. The second level is whether users with incomplete knowledge of data matching their research interest can obtain efficiently useful information. For this testing we will need to open up the system to a broad range of users and respond quickly to any problems they encounter. Action item: As soon as the Retailer tuning is satisfactory and the NCEDC DHRs are loaded at SOPAC, Bob King will send a message to the community via (at least) the unav_all mailing list to solicit user testing of GSAC.

Before adjourning, the Working Group discussed goals for the next six months. Realistic testing can begin as soon as the data base queries can be optimized to allow bounding-box searches over the full time span. SOPAC is uncertain how long this will take, but hopes to have it acccomplished within two months. With CDDIS, NCEDC, SOPAC, and UNAVCO DHRs loaded, the list of GPS data will be nearly complete for California, which could serve as a test region for user success. We hope to add PANGA, NGS, and several international archives by October or November, and have GSAC functioning publicly as a global archive by the end of the year. A meeting in October on the East Coast of the US may be useful to further these goals.

Comments or questions about this page? Send e-mail to Lou Estey (louunavco.org).

Last modified Thursday, 17-Nov-2005 04:21:00 UTC

Home | About Us | Contact Us | Support | Search | Facility | PBO | Education & Outreach

Comments: webmasterunavco.org
© 2008 UNAVCO, Inc.