GSAC Meeting at Scripps Institution of Oceanography

18-19 January 2001

Participants:

Duncan Agnew, SIO/SCEC
Yehuda Bock, SIO/SOPAC
Fran Boler, UNAVCO Boulder
Brent Gilmore, SIO/SOPAC
Bob King, MIT
Tom Herring, MIT
Chuck Meertens, UNAVCO Boulder
Michael Scharber, SIO/SOPAC
 

The primary purpose of this meeting was to review the plans and progress of SOPAC in developing modules for the GSAC Retailer interface. The meeting also served as a first opportunity for the new UNAVCO Community Coordinator (King) and new SOPAC personnel (Gilmore) to share perspectives with long-time participants. Though all key GSAC participants were not present, the representation was sufficiently broad that general goals and policies could be discussed and proposals developed for presentation to participants at NCEDC/BARD, CDDIS, JPL, NGS, and PANGA.

Michael Scharber presented an updated work outline and architecture  for the GSAC Data Base Schema being developed by SOPAC. The key element is an "Agent" module which acts as a broker between the data base and other GSAC elements. By adapting the Agent to its own data base, a wholesaler or retailer can make full use of the GSAC modules being developed by SOPAC. Thus far Scharber has implmented a first-cut GSAC schema at SOPAC (Objective 1), published SOPAC Data Holdings and Monuments for new data (Objective 2), and begun development of the Retailer Database - GSAC Synchronizer (Objective 3). He expects to complete the database synchronizer by the end of March and to have an attribute-based Retailer interface available for testing by June. Enhancement of the Retailer interface to include spatial querying and a graphical interface is targeted for the end of September.

Fran Boler indicated that she has been using the GSAC modules developed by Chris Roelle and could now return to Scharber a list of changes she had made to fix bugs and improve functions. Scharber indicated that Mark Murray at BARD has also been using the modules and should be included in the synchronization of the code.

Tom Herring and Bob King indicated that their check of the /pub/GSAC directories for CDDIS, BARD, SCEC, SOPAC, and UNAVCO suggests that each of these wholesalers is maintaining complete and up-to-date Data Holdings Files (DHFs) and Data Holdings Records (DHRs), except that SOPAC has included only RINEX files for which it is the originator, principally SCIGN. Yehuda Bock indicated that this was a conscious decision since the GSAC protocols require that the originator of a RINEX file be identified in any backup holding, and for many of the IGS files determining the originator would require considerable effort. CDDIS has made a different decision and includes in GSAC records all of the IGS data. After some discussion, the participants agreed that SOPAC should consider itself the original wholesaler for any data (IGS, CORS, and others) not listed by another GSAC wholesaler. SOPAC (and CDDIS) should try as best they can to record in the "provider" field of the DHR the identity of the institution that created the RINEX file, but in cases where this is not available, they could use a generic descriptor such is "IGS" for this field. All agreed that for the GSAC to be useful and successful, it must provide access to the complete holdings of all of the participating archives.

An important question for SOPAC was how quality control should be maintained over the data distributed through GSAC. One issue was incorrectly written RINEX files. We agreed that Retailers should develop a system to check for problems and to receive complaints from GSAC users, but that repair of the files is the responsibility of the Wholesaler or originator. Another is inconsistent use of 4-character codes for monuments. In this case, the Retailer has the responsibility of resolving conflicts in a way that suits his user interface. (Wholesalers must, of course, maintain unique [full] ids for monuments in their archive.) The Community Coordinator can also be helpful by monitoring the communications on data problems and, if necessary, communicate directly with Wholesalers or originators to resolve conflicts.

The only substantive changes to the Data Exchange Formats discussed was future inclusion of strainmeter data. The Working Group should consider this when a specific format is suggested. King suggested that there are a few places in the current (Version 1.0) documentation where the descriptions of some of the fields could be edited for clarification; the group agreed that he could do this and post the revised document without a change in version number.

Tom Herring suggested that the GSAC Working Group and/or the UNAVCO Steering Committee consider recruiting a GSAC Advisory Committee of outside users to provide feedback to the Working Group.

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

Last modified Wednesday, 16-Nov-2005 21:21:00 MST

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

Comments: webmasterunavco.org
© 2008 UNAVCO, Inc.