Objectives:

1. GSAC tables are automatically generated at SOPAC
2. A tool needs to be developed to automatically retrieve corresponding tables from all the GSAC ftp sites
3. A straightforward database scheme needs to be developed that contains all the metadata extracted from the GSAC tables (i.e. monument locations, names, data file names, epochs of data, etc)
4. Development of a tool that gives users an ftp script, which automatically allows them to retrieve data from the GSACs to their machines. For offline data or data requiring special permission to be downloaded; a script would automatically send a request to the appropriate GSAC archive
5. Design a simple web tool for choosing an area on a map which can then be used to obtain a listing of the station locations in a particular region and a list of the GPS data from that region by time and location) which a user can then use to select data - this would be similar to the tool already in place at SOPAC but including the data from all the other GSAC participants as well. At this stage, this is all we need but if implementation of the foundation of the GSAC is successful, then development of more sophisticated tools would be warranted.
6. The above software tools should be easily exportable to be run at other 'retail centers'. This is essential is we are to encourage the participation of other archive centers around the world. It is relatively easy for users to figure out what is in the archives at SOPAC and UNAVCO. It is finding and retrieving the data in other archives that is more of a problem.
7. We'd like you to support and improve the existing tools that are used by some archives to automate the generation of the GSAC table from their ftp directories. Other GSACs will have to customize their own database management systems to generate these reports.
8. As mentioned above, we are in the process of finding a GSAC coordinator that will help to oversee the GSAC development and ensure that the products will have widespread utility.

Timeline:

1. GSAC Retailer/Wholesaler Database Schema
• Database schema will be extremely basic, containing the smallest amount of vendor-specific functionality possible. A simplified schema will provide wholesalers and retailers alike with the flexibility to incorporate GSAC database functionality into any database of their choosing...provided they develop the appropriate GSAC Database Agent. The Agent will act as the broker through which a given wholesaler or retailer can interact with their GSAC database schema in a natural manner. The idea behind the GSAC Agent is that a common programming language (Perl) can be used as the gateway for information into and out of a database with a GSAC schema component.



• The schema shall not require functionality such as transactions, triggers, procedures, sequences (native), although other Agents may be created/modified to deal with different databases. Instead, GSAC applications will rely solely on the Agent, for both functionality and integrity maitenance, allowing for flexible database proxying and platform independence.



1. Design and plot schema, with comments and description, and publish on GSAC development web site.
2. Get schema, comments and description approved by development advisory team
3. Implement schema at SOPAC (does not infer use)



2. All GSAC Wholesaler Tables Published At SOPAC
• SOPAC will incorporate automated publishing of GSAC information/records for each data file it "provides" and/or is the initial wholesaler of, as well as for each site it is responsible for.
• This objective includes DHF & MC record creation/maintenance?initial wholesaler only, no mirroring.



3. GSAC Retailer Database - GSAC Syncronizer
• This tool will:
• be Perl-based
• rely completely on GSAC::Agent and the Retailer's GSAC database
• use GSAC::Agent and GSAC database to visit each registered wholesaler, retrieve their incremental list files and any needed incremental DHF or MC records, and synchronize it's own database holdings with what it finds, or, perform a full sync with a specified wholesaler.
1. Complete initial required components of GSAC::Agent.
2. Write executable (Perl) to utilize GSAC::Agent and allow flexible execution and optional functions, such as:
• -full <wholesaler>
• -inc <wholesaler>
• -v {verbose}
• -report {report only, no database writing}
• -status <wholesaler> {last interrogated, etc}



4. GSAC Web Client 0.1
• This objective is based on development of an attribute-only web-based client tool to be used for constructing/acquiring a list of URLs. The resulting URLs can then be incorporated into a script and given to the user, or can simply be saved/used directly by the user in their own chosen means.
• This initial client will contain zero spatial querying functionality?apart from that contained in attribute information for data such as GPS sites.
• The attribute querying capabilities will be very basic (most likely just a CGI forms-based page), yet powerful enough to drive home the meaning of the GSAC to any given user.
• Web Client 0.1 will require the existence of a functioning Apache web server and set of GSAC modules from one or more Retailers.
• Web Client 0.1 will be a read-only client to GSAC database of corresponding Retailer.
1. Continue required development of the GSAC::Agent Perl module as required.
2. Begin development of Apache GSAC module(s).
3. Construct initial GSAC Web Client 0.1 (CGI/HTML forms-based).



5. GSAC Web Client 0.5
• Web Client 0.5 will build on the functionality of version 0.1 through the addition of spatial querying capabilities and other, more advanced, graphical user interface functions to be decided.
• Like version 0.1 this version will also be a read-only client to the GSAC database of the corresponding Retailer and will also depend on the existence of a functioning Apache web server and GSAC modules.
• Spatial querying functionality will be provided by translating spatial constraints, context information and other attribute parameters into a URL. The constructed URL can then be fetched from the corresponding Retailer, whose Apache GSAC modules will deconstruct, execute via the DAL and return a set of URL?s matching the users request. Accordingly, the same URL request can be sent entirely without the aid of the Web Client. From any command-line HTTP GET utility a user can issue the exact same request and receive the exact same result.
• My current inclinations for realizing Web Client 0.5 is to utilize ESRI?s ArcIMS map service tools. In concert with the developing Geography Network, headed by ESRI, I believe a rather sophisticated, and modifiable, GSAC Web Client could be constructed faster and will far less expense than building one from scratch in a 3^rd-gen language like Java.
1. Begin development of GSAC::Spatial Perl module.
2. Add spatial support to Apache GSAC module(s).
3. Implement version 0.5 Web Client with spatial functionality.

Missing Objectives:

1. Retailer/Wholesaler Database Management Tools
2. Integrity Checking Scripts (Database - GSAC Flatfiles)
3. Integrity Repair Scripts
4. GSAC Administration Notification Features

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.