Software Help with Software Data Management GSAC Architecture Installation System Requirements About Linux and UNIX Systems To Install GSAC Local Repository Implementation Code Database for GSAC About a GSAC Installation To Update GSAC Federation User Information Repositories GSAC Code Help with GSAC Dataworks for GNSS

Related Links

GSAC Installation, 2016

This site no longer maintained and here for archival purposes.

Read this page to install GSAC, and to clearly understand what is involved.

Version of 15 April 2016

Quick Install

For those who wish to read less, or for a reminder how to install GSAC in case you have done so already, you may see the brief GSAC Quick Installation guide (and in the GSAC package at gsac-code/GSAC_Quick_Install.txt) in place of this web page. If something is unclear in that guide, return here for details.

Java versions

As of 29 January 2015, GSAC can be compiled and run with either Java 1.6 or Java 1.7. Library files were updated from the older GSAC libraries. The Java 1.7 version has Java security updates. The Java 1.6 version will work with existing Tomcat web sites running at Java 1.6. If you use Tomcat with Java JRE 1.6 you will need to build GSAC with Java 1.6. Both versions use included Jetty for the web application container in place of Tomcat for local tests.

System Requirements

You can install GSAC web services for a data repository when you have:

  • A suitable operating system for GSAC, with Java JDK 1.6 or 1.7, subversion ('svn') a respository control tool, and 'ant' a Java compilation and build tool.
  • A database, with complete metadata about sites (stations or monuments), their instruments, and their data files (if any). See more details in GSAC Implementation Choices.
  • A web server for GSAC, and an application container. Running GSAC with the Tomcat application container is the most common, but GSAC can use its included application container, Jetty.
  • The GSAC software package provided by UNAVCO, which you download from SourceForge as detailed in the To Install GSAC section below.
  • Usually, data files from observing instruments, for remote users to download. If you offer data file downloads, an FTP / HTTP download server is needed; it may be different from the server for the GSAC web application.

To install and test preliminary working GSAC software, you do not need the web server, FTP server, or data files. You can implement and test your GSAC on a personal computer before dealing with web servers. GSAC will use Jetty, included with GSAC, for your browser.

Operating Systems for GSAC


Your operating system will need a Java 1.6 or 1.7 Development Kit (JDK), and the utilities 'ant' (a build tool for Java), bash a Linux shell (or similar shell), and subversion ('svn', a code repository manager).

A recommended operating system for GSAC is Debian. Debian with bash has simple installation of the software tools you need, using the apt-get utility. Ubuntu and OpenSUSE are similar. Debian is recommended by programmers for stable and secure operations.

You need Java JDK 1.6 or 1.7. Most Linux systems come with a Java runtime library (JRE), but may lack the JDK with javac. Try commands "java -version" and "javac -version" to see if you have both, and to make sure they both show the same Java version number.

To install ant on Debian or Ubuntu, do the single command 

sudo apt-get install ant

To install subversion ('svn') on Debian or Ubuntu, do command 

sudo apt-get install subversion

To install or use the Tomcat application container, see the Tomcat for GSAC guide, created and contributed by Marco Portugal, Space & Earth Geodetic Analysis Laboratory (SEGAL), Universidade da Beira Interior, Departamento de Informática, Covilhã, Portugal.

GSAC can work with MySQL and Oracle databases, but Postgres may need an improved Java library (a GSAC development matter). To install the MySQL server on Debian or Ubuntu, simply do the command 

sudo apt-get install mysql-server
This requests you to "enter the root password", which is a new password for the MySQL root account, not your Linux system root password.

GSAC has been installed on Debian, Ubuntu, OpenSUSE, RedHat Linux, MacBook Air (10.8), Windows 7, CentOS, and Free BSD, with no known installation errors due to GSAC code problems.

We have no reports of problems installing GSAC on any Linux-type operating systems other than CentOS and Fedora. GSAC has been installed on CentOS, but CentOS is the not first choice, since it lacks recent software and some operating system updates and additions are required. Fedora appears to have problems similar to CentOS.

For help with installation of GSAC on Mac OS, Windows 7, Free BSD, and CentOS see:

    On a MacBook Air, see Installing GSAC on MacBook Air, contributed by David Zuliani, CRS, Istituto Nazionale di Oceanografia e di Geofisica Sperimentale (OGS). This may work with other MacBooks as well.

    On Windows 7, see Installing GSAC on Windows 7, contributed by David Gómez, Rodríguez Department of Geodesy, Institut Cartogràfic i Geològic de Catalunya.

    On FreeBSD, see Installing GSAC on FreeBSD, created and contributed by Xanthos Papanikolaou, National Technical University of Athens, Dionysos Satellite Observatory, Higher Geodesy Laboratory.

    GSAC CentOS Installation Tips, contributed by James Matykiewicz and Susanna Gross of UNAVCO.

To Install GSAC


First read carefully the GSAC Implementation Choices, and decide which installation approach will be best in your case.

The database GSAC will read needs to be installed before you can build and test GSAC. The database need not be fully populated with data to test GSAC.

To install GSAC, first select or make a top-level directory for GSAC, and go there. For example:

mkdir ~/GSAC2015/
cd ~/GSAC2015/

Check out the GSAC code from SourceForge by entering this command: 


svn export svn://svn.code.sf.net/p/gsac/code/trunk gsac-code

This creates a new directory, /gsac-code/, and downloads all the files in the GSAC package into gsac-code/.

Go to the GSAC core code (GSL) area: 


cd gsac-code/src/org/gsac/

In that new directory is a file called README. This is the first part, Part 1, of two README files to complete GSAC installation, in the GSAC software package. Follow the instructions in gsac-code/src/org/gsac/README. Included are instructions about how to build GSAC with Java 1.6 or Java 1.7.

The end of the README Part 1 file tells where to find the README Part 2 file. It is in your "local GSAC code area", or for the Prototype GSAC at gsac-code/src/org/prototype/gsac/.) Follow the instructions in README Part 2, to complete an operational GSAC.

Having the README files inside the code package helps ensure that the installation instructions are consistent with the code package.

To install a Federated GSAC, complete instructions are part of the GSAC README file (in part 1, section 5). Installing a Federated GSAC is easier than installing a complete GSAC repository, since no database is needed. There is no README Part 2 for federated GSACs.

Anonymous FTP is a security problem. You might consider FTP accounts for your datafiles. FTP is not part of GSAC. GSAC simple provides FTP URLs where data files reside.

GSAC Implementation Choices

The simplest way to install GSAC is to use the Prototype15 GSAC database and related prototype GSAC Java code, starting with the MySQL Prototype15_GSAC.sql file in the GSAC package. See Choice 1 below. This is always the case if you do not already have a database which has all the information about sites (stations), instruments, and data files which GSAC uses.

Background

There is the GSAC core code, also called the GSAC Service Layer, or GSL. Every GSAC installation uses the same GSL. This provides all code for web services, making web pages, handing requests, formatting results, and other actions. The complete GSL is in the GSAC package you download during installation. In your installation it is mostly in and below GSAC/gsac-code/src/org/gsac/. Only one or two small file changes to the GSL are part of the typical GSAC installation. Other changes to the GSL are not advised until you are familiar with GSAC.

You need a database which will have all the information about sites (stations), instruments, and data files which GSAC reads. (GSAC does not write any database.)

In addition, each new GSAC installation needs some custom code, the "local GSAC code." The local GSAC code connects GSAC to your database. And local GSAC code specifies the site search and file search queries in your GSAC (in the web pages and with the API), that is, how to compose in Java the corresponding SQL queries to your database. Local GSAC code differs among different GSAC installations, as much as archive contents differ and as much as database schemas differ. One GSAC has RINEX GNSS obs files, another derived GNSS products such as site velocities, and another perhaps tide gage measurements.

In your installation your new local GSAC code is in and below a directory something like gsac-code/src/org/my_gsac/gsac/, depending of course on your local Java package name (like my_gsac). The local GSAC code includes a few small properties files, and always a new file Tables.java and two essetial and complex files named something like MygsacSiteManager.java and MygsacFileManager.java.

Before you can install GSAC you need to make a decision about the local GSAC code implementation approach for your GSAC. There are four approaches. The first listed here, at 1. below, is most commonly used.

Note that any installation of GSAC requires thorough knowledge of database use. The Existing Database approach (number 2 below) also requires real experience with Java programming, and some knowledge of GSAC Java classes which you may be able to gain through study of the Prototype GSAC Java files (Choice 1).

Choice 1. Use GSAC's Prototype Code and Database

    You can install GSAC with very little Java programming. You use ready-to-use GSAC prototype Java files included in the GSAC package, together with the associated GSAC's "Prototype15 database". This creates a complete and general-purpose GSAC installation.

    The advantage of this approach is that the Java code is ready to use. You do not need a skilled Java programmer to install GSAC. The key Java files for GSAC to use this database are PrototypeSiteManager.java and PrototypeFileManager.java, in gsac-code/src/org/prototype/gsac/ in the GSAC package you download during installation. You use them directly with no file name changes if your have a Prototype15 database.

    UNAVCO provides a prototype database schema called "Prototype15" which is specified in the MySQL database "Prototype15_GSAC.sql" file. There is also a document about the Prototype15 GSAC database schema, Prototype_GSAC_Database_MySQL_schema_notes.txt.

    All "Prototype" GSAC files, including Java files, the Prototype15_GSAC.sql and Prototype_GSAC_Database_MySQL_schema_notes.txt, are in the prototype code area (gsac-code/src/org/prototype/gsac/) in the GSAC package. You can download the two database files separately, for study, without installing the complete GSAC package, with these commands from the GSAC package on the SourceForge svn:
    svn export svn://svn.code.sf.net/p/gsac/code/trunk/src/org/prototype/gsac/Prototype15_GSAC.sql Prototype15_GSAC.sql
    and with:
    svn export svn://svn.code.sf.net/p/gsac/code/trunk/src/org/prototype/gsac/Prototype_GSAC_Database_MySQL_schema_notes.txt Prototype_GSAC_Database_MySQL_schema_notes.txt

    If you do not already have a database suitable to completely support GSAC, with the complete information expected by GSAC about your stations, instruments, and data files, this is a good approach to use. If you have no existing database, this is a reasonable approach since you need to make a database to run GSAC anyway, and you avoid writing and debugging Java code.

    Using the MySQL client "mysql," one way to create an initial empty database is, in the mysql utility, the command "source Prototype15_GSAC.sql". The Prototype database as provided by UNAVCO is empty and you must "populate" it with your metadata. This is a major part of installing an operationg GSAC.

    UNAVCO also provides two Python scripts with code to "populate" a Prototype15 database with your metadata. Input is flat (ASCII) files of metadata about your sites and data files. To get them from the GSAC package on the SourceForge svn:
    svn export svn://svn.code.sf.net/p/gsac/code/trunk/src/org/prototype/gsac/populate_GSAC_db_station_metadata.py populate_GSAC_db_station_metadata.py
    svn export svn://svn.code.sf.net/p/gsac/code/trunk/src/org/prototype/gsac/populate_GSAC_db_datafile_metadata.py populate_GSAC_db_datafile_metadata.py
    Instructions for use of these programs are in the program file headers.

    You will need to fully populate your new (empty) database with all the information about your stations, instruments at the stations, and about every data and product file to provide for download. The database you create may also be useful outside of GSAC, for monitoring and managing data holdings and operations. Databases are less error prone for managing metadata than, for example, file headers, file names, or site log files.

    If you have a user group collaborating in GSAC use, you can create and maintain your own Java files and an associated database schema for GSAC, without UNAVCO involvement.

    The largest GSAC derived from the Prototype GSAC has more than 14,000 stations and more than 6 million data files.

Choice 2. Existing Database

    If you already have a database which has all the information about sites (stations), instruments, and data files which GSAC uses, you can install GSAC to use that database.

    To use a database you have without modification, you will need to write new Java classes, especially subclasses of the GSAC classes SiteManager.java and of FileManager.java. These new class files (with names like MygsacSiteManager.java and MygsacFileManager.java) are typically about 2500 and 500 lines of Java repectively. To write these, you will need to make extensive use of Java classes and methods from the GSL. The new Java files are the bridge between your database on one hand and GSAC GSL code on the other. A considerable aid to writing new Java classes is provided by study of the prototype Java files mentioned in Choice 1 just above. Writing your custom ***SiteManager.java and ***FileManager.java class files may require days to weeks by a competent Java programmer who is new to GSAC code.

    The advantage of this method is that you use your complete and working database. You do not need to create a new database for GSAC. The disadvantage of this approach is you have to write some advanced Java.

    A disadvantage is that your database schema may not be well structured for GSAC SQL queries. In that case you must write more complex queries. There may be some delay in responses from large complex databases.

    Your database must have the parameters required to support all GSAC services (search queries and data in reponses). For that, compare your database contents to the Prototype15 GSAC database schema and review the schema notes file.

    Key files to help writing your local GSAC Java code are the prototype GSAC files PrototypeSiteManager.java and PrototypeFileManager.java, in gsac-code/src/org/prototype/gsac/ in the GSAC package you download during installation. The prototype GSAC Java files give complete examples of working GSAC JAVA code to interact with a database. Among other things, they indicate the Java .java file 'package' and 'import' lines styles to use. The prototype build.xml* files are also vital examples for making your own Java code.

Choice 3. Dual-database GSAC Installation

    As yet, this is only a proposal. You may have a database for your data center which is perhaps more complex than needed by GSAC, but you do not wish to write complex SQL in Java for GSAC to use that database. You could use a Prototype15 style database, populated from the existing database, and the associated set of GSAC prototype Java files. The trick is, you will need a way to automatically sync your existing database with the database for GSAC. UNAVCO has not devised code for this purpose, which would of course depend on the schema of your database which we do not know!

The "Prototype15" Database for GSAC

An essential part of GSAC installation and operations is a database with metadata about sites (stations or monuments) in your network, their instruments, and their instrument data files. The GSAC database contains information about sites which you wish to offer online, and about sites' data files which you wish to offer for download. The database must contain up-to-date, complete, and correct information if GSAC services are to represent your data repository correctly.

UNAVCO provides two GSAC database schemas which work with code in the GSAC package so that you need not do Java programming to read from a database. The "Prototype15" database and code is described next. Prototype15 is intended to be a general purpose GSAC installation (its Java files are also a guide to GSAC programming).

The GSAC database "Prototype15" is specified with the MySQL database ".sql" file, Prototype15_GSAC.sql. The files Prototype15_GSAC.sql and a document Prototype_GSAC_Database_MySQL_schema_notes.txt are in gsac-code/src/org/prototype/gsac/ in the GSAC package; this is the GSAC prototype code area.
You can download those files, separately from the complete GSAC package, with:
svn export svn://svn.code.sf.net/p/gsac/code/trunk/src/org/prototype/gsac/Prototype_GSAC_Database_MySQL_schema_notes.txt Prototype_GSAC_Database_MySQL_schema_notes.txt
and with:
svn export svn://svn.code.sf.net/p/gsac/code/trunk/src/org/prototype/gsac/Prototype15_GSAC.sql Prototype15_GSAC.sql

To create a new MySQL GSAC database using the Prototype15_GSAC.sql file:

  • Get the Prototype15_GSAC.sql file.
  • If you do not have MySQL, install it. On some Linux systems like Ubuntu you can simply do the command "sudo apt-get install mysql-server."
    • This requests a you to enter a "root" password, which should be a new password just for MySQL, not your Linux system root password.
  • Start the MySQL server, for example in Linux with "sudo /etc/init.d/mysql restart"
  • cd to the folder with the file Prototype15_GSAC.sql
  • Edit the .sql file to change the name of the database, before you use mysql to create the database. You can change all instances of `Prototype15_GSAC` to your new db name, something like MyCenter_GSAC_database; the name is not particularly important and will not be visible to GSAC users.

Once you have the mysql server installed and running on your system:

  • run mysql as mysql root and create a new MySQL account for GSAC, called for example gsacuser
  • run the mysql command line tool, such as, in Linux, 
    mysql -u gsacuser -p
  • in mysql (mysql>) run the command 
    source Prototype15_GSAC.sql;
(MySQL documentation is online, as at http://dev.mysql.com/doc/refman/5.1/en/index.html)

This creates a MySQL database which is empty of any information about your data repository. You must populate the database with information about your stations, instruments, and data files for download.

The database that GSAC uses may also be helpful in managing your data repository, aside from GSAC operations. To manage a data center, a well-designed database is much less error prone, and much more suited to computer operations, than text files such as IGS site logs or SINEX files.

Updating GSAC


UNAVCO makes improvements to GSAC. You may wish to update a GSAC installation. For example, beginning in January 2015 GSAC has Java library files and java code to support builds with either Java 1.6 or Java 1.7. After a period of numerous refinements in GSAC based on early use, in 2013 and 2014, GSAC is ready to become more stable and to concentrate on installations and operations.

31 March 2015

There are at the moment eight GSACs operating on public web sites. There are many improvements in the core GSAC code since a year ago, such as a fix for the error in the format of SINEX longitude values in the range -0.9999 to 0.0

All or some of those will be automatically used by any older local *SiteManager.java and *FileManager.java files. For example all the choices and formating of results is provided by GSAC core code.

In general an older working GSAC was designed to use its older style database. And because of how GSAC is designed, its *SiteManager.java and *FileManager.java files will (or should!) still work the same way with the latest core GSAC code, along with the older database. Many improvements in the core GSAC (such as using Java 1.7) are automatically available. However as detailed below you need to make a new GSAC core installation and modify the ant build of your local GSAC java code since GSAC uses new Java library files after 2014 (i.e. change import lines and the build.xml file).

Some new features enabled by new GSAC code/ new database contents will not be possible. Some new GSAC features depend on having new items in the new Prototype15 database schema, so in that case the new features will not be possible with all older databases and code. An example is that with the latest GSAC and with a new database you can (optionally) specify a terrestrial reference frame for each data file, and choose data files using a choice of TRF. Since older databases do not have TRF information, of course they can't do a GSAC search with terrestrial reference frames.

If you have an earlier version of GSAC the best way to update GSAC core code and use your older local GSAC code is first to make a complete, new, separate installation. Otherwise you can make a complete, new, separate installation of GSAC, and make a new-style (Prototype) database with data from your previous database from GSAC.

For all GSAC versions, the core GSAC code used by all GSAC installations is in gsac-code/src/ and in subdirectories of that directory. Let's say you have the older GSAC in directory GSAC/. You have your "local GSAC code" for your installation in a location such as GSAC/gsac-code/src/org/mygsac/gsac/ where in your case "mygsac" will be some other word, (or perhaps in a location more like GSAC/gsac-code/src/fr/renag/gsac/). Your local GSAC code will be there, for example, MygsacSiteManager.java. In these instructions we will use "mygsac" for the local GSAC code, both in the older code area, and in the new local GSAC code area to be installed now.

Make a new top level directory for the new GSAC, GSAC2015/.

Install an all-new GSAC according to the "To Install GSAC" section on this web page, above. You will do a new export from SourceForge of the main GSAC package, in the directory GSAC2015/. You follow the instructions in the README Part 1 file mentioned in that web page section. As usual, you edit the file
GSAC2015/gsac-code/src/org/gsac/gsl/htdocs/repositorymap.js
to set the longitude, latitude, and map zoom level for the center of the map GSAC which shown shows in site search results. You can see your old values in the older file like gsac-code/src/org/gsac/gsl/htdocs/repositorymap.js

In GSAC2015/gsac-code/src/org/gsac/, build the core GSAC code with 'ant.'

Next as detailed in the installation guide, use the command "ant makerepository" to create a new "mygsac/" local GSAC code area. Begin by making a new "my.properties" macros file.

Next, copy some existing files from your old local GSAC code area, such as GSAC/gsac-code/src/org/mygsac/gsac/ area.

Copy files from the 'old' mygsac/gsac/ directory to the new GSAC2015/gsac-code/src/org/mygsac/gsac/ area, for example with commands like this:

cp -r /home/GSAC/gsac-code/src/org/mygsac/*java /home/GSAC2015/gsac-code/src/org/mygsac/
cp -r /home/GSAC/gsac-code/src/org/mygsac/dbresources/* /home/GSAC2015/gsac-code/src/org/mygsac/dbresources/
cp -r /home/GSAC/gsac-code/src/org/mygsac/resources/* /home/GSAC2015/gsac-code/src/org/mygsac/resources/
cp -r /home/GSAC/gsac-code/src/org/mygsac/database/*java /home/GSAC2015/gsac-code/src/org/mygsac/database/
cp -r /home/GSAC/gsac-code/src/org/mygsac/htdocs/* /home/GSAC2015/gsac-code/src/org/mygsac/htdocs/
Do not copy the old build.xml file to the new area.

(Do not do the command "ant tables" )

Then you must make these changes in your code in GSAC2015/gsac-code/src/org/mygsac/gsac/:

1. make sure the new build.xml file in the new GSAC2105 package has lines something like this, corresponding to your GSAC Java package and file names:

property name="basename" value="mygsac"/
property name="repository_relative_dir" value="org/agency/gsac"/
property name="repositorypackage" value="org.agency.gsac"/
property name="serverclass" value="${repositorypackage}.MygsacServer"/
property name="repositoryclass" value="${repositorypackage}.MygsacRepository"/
java classname="${repositorypackage}.MygsacDatabaseManager" maxmemory="512mb"

2. Usually edit your new file mygsac/gsac/database/Tables.java by replacing import org.ramadda.sql.SqlUtil;
with
import org.gsac.gsl.ramadda.sql.SqlUtil;

3. In your local area edit the 3 files like MygsacFileManager.java MygsacServer.java and MygsacSiteManager.java so they match the "import" lines in the headers of the corresponding new GSAC2015 files PrototypeFileManager.java, PrototypeServer.java and PrototypeSiteManager.java in GSAC2015/gsac-code/src/org/prototype/gsac/. This allows use of the latest Java library .jar files in the new GSAC package. Also make sure the .java file 'package' lines are updated.

You will need to change the 'package' and 'import' lines in all your local Java files to work with the new Java 1.6 / 1.7 GSAC. Look at the corresponding lines in the Java files in src/org/prototype/gsac/ and src/org/prototype/gsac/database.

There may be other import lines in Java files which need to be revised. You can always look at the corresponding Java files in GSAC2015/gsac-code/src/org/prototype/gsac/ to see code that works.

Do a build of GSAC with 'ant' to look for errors indicating any problems. If ant succeeds, try 'ant runserver' to run your GSAC on your PC.

More about GSAC, and What GSAC is Not

GSAC is web services for discovery of instrumented site information, and of instrument data files, available in an archive, to provide site and instrument information in a variety of standard formats(csv, GAMIT, SINEX, Json), and to show where (URLs) to download instrument and derived-product data files. The GSAC User Guide gives complete details about GSAC services, and how to use GSAC to find site and data information and files.

GSAC is intentionally built to handle many kinds of Earth science data from instruments with Earth locations, and derived products from such data (including plot image files). GSAC is not "just for RINEX files!" GSAC can be used with observing networks other than GNSS stations, with observing instruments making data files. For example tide gages, met stations, tiltmeters, strainmeters and seismometers. GSAC has been used for RINEX files, time series data, plot images, VLBI and DORIS data, and GNSS position time series data and plot files. One agency's GSAC enables search and access across more than 12,000 stations for more than a million GPS time series solution files. The UNAVCO GSAC has several types of daily data files from more than 2500 stations, some for more than 20 years.

The disk space used by the GSAC package is less than 600 MB. The GSAC Tomcat "war" file to enable GSAC on your Tomcat web application container is about 10 MB. A database to support GSAC, using the prototype schema, is about 10 MB when it includes information about 40,000 data files.

Installation of GSAC will require 2 hours to 4 weeks or more depending on your situation and the skill of your staff. Installation of the GSAC code itself takes about 2 to 4 hours; the remainder is dealing with your database, and creating and/or revising Java code to use your database. GSAC can't know your database schema in advance, so new code needed to read from it. GSAC can't have a shrink-wrapped installer since GSAC does not know the schema of your database. We could provide a single GSAC installer if everyone used exactly the same database, but we have no expectation of seeing that soon.

GSAC writes detailed lines to the Tomcat catalina.out log file, which shows the IP of every user for every request, so you can count users. The actual requests (API) are shown as well, so you can tell what GSAC users are asking for, which reveals what they really want. That is very useful and revealing, for example, the UNAVCO GSAC service receives requests almost entirely from automated computer commands, not from the GSAC web human interface. The UNAVCO GSAC service received 30,174 requests from 11 Jan 2015 to 31 March 2015.

For security, GSAC uses Java 1.7 and recent versions of Java library (.jar) files. You can update the Java library (.jar) files anytime at your option; in that case GSAC code changes may be required by you.

What GSAC is Not:

GSAC is not a content management system. (GSAC shares information from a database.)

GSAC does not read, understand, or modify any kind of data files including RINEX or other types of GPS data files.

GSAC does not check data file quality or otherwise manage a data archive.

GSAC does not "know" or "understand" the contents of any data file it shows how to download. In fact data files can be on remote servers, where a GSAC could never read them.

GSAC does not "know geodesy:" about data, files, or formats. It can tell users the names of data types and formats in data files it offers, if you include that metadata about the files in the GSAC database.

GSAC does not read data file headers or file names to determine metadata about sites or files. File names and header formats vary enormously and headers often have no, incomplete, or incorrect information. Everything GSAC knows is in the database it reads. If that information is incorrect, GSAC will provide incorrect information to the GSAC users. (By the way, it is much easier to maintain one database than to maintain headers in thousands or millions of files.)

GSAC does not process or "correct" data files, or run teqc on data files. The very general nature of GSAC precludes it having code to process, "correct," or modify any particular kind of data. It is far better for knowledgeable scientists to provide this data processing for their data files, and then let GSAC users get the resulting files. GSAC can easily provide data files of most any kind from data processing, when you add metadata about the files to the GSAC database as part of the processing work flow. GSAC is a information service, not a framework for processing work flows which are best done by each agency.

GSAC does not include a user and password system. GSAC is designed for unrestricted data access, in the spirit of the European GEO initiative and following UNAVCO practices. GSAC is designed for federated data archive access, merging several GSACs into one service. If each GSAC had its own users and account logins, then federated archives would be impossible or cumbersome. You can install user logins in front of a GSAC, but then the GSAC cannot work with other GSACs, which is part of the big GSAC principle. GSAC does have flags in its database to embargo or hide any station and its data files from public view, if you need to do that.

Dataworks

    See the UNAVCO Dataworks web site.

    Dataworks is a UNAVCO project with open source software for running a repository of GNSSS RINEX data files, typically for one local network of GNSS receivers with tens of stations. Dataworks is not GSAC. Dataworks uses GSAC and other code.

 

Last modified: 2019-12-24  02:29:46  America/Denver