[IGSMAIL-0816] A possible candidate for SINEX

[Jeff]

******************************************************************************
IGS Electronic Mail      Tue Dec 20 16:12:21 PST 1994      Message Number 0816
******************************************************************************

Author: Jeff Freymueller
Subject: A possible candidate for SINEX

I have a possible candidate for SINEX, a Solution INdependent EXchange
format. This format has been developing slowly over a long period of
time, beginning about 1.5 years ago. It has been in an almost-finished
state for quite some time, and a number of people have commented on it.
Although it is not quite in a finished form, I want to announce it now
so that it may be considered by the IGS -- quite a bit of work has
gone into it, so I thought it better to announce it now since I know
that some people within the IGS have been given the task of devising
such a format. Those who are interested can contact me directly and
we can discuss it when I return. For their potential benefit, I am
making more information available by ftp even though it is not quite
polished, and even though there are some inconsistencies. If the
general outline is thought to be good, we can work out the details.

Fortran code already exists (and is being tested) which can create
files from Gipsy solutions, and read the resulting solution files.
This code is available by ftp, but it should be recognized that it
is a work in progress and still being tested. I make it available at
this point because it may be helpful for people who wish to evaluate
the format.

The detailed description of the format it is also slightly out of
date compared to the actual code used to write the format. Since I am
leaving for the holidays in about 10 minutes, I will describe the format
briefly and make a sample file available by anonymous ftp for people
who want to look at it. The fuller description is available by ftp
with the same caveats as the code.

The format already meets the general specifications laid out in the
IGS Workshop position paper. The brief description below is extracted from a file
which is available in the alpha-test subdirectory (see Sample files, below).
That file is a generally accurate definition, but not quite up to date
with the code.

Happy Holidays to all,

Jeff


Sample files
------------
anonymous ftp to arena.stanford.edu (36.51.0.56)
cd to /pub/sinex
The sample solution file is 94jan19.soln. Fortran code  and a full description
(with some inconsistencies, mainly in the examples) is in the alpha-test
subdirectory. I will replace that code with cleaner code when I get back;
for now treat this code like a Microsoft application with a version number
of x.0 (assume that major portions have not yet been tested! ;). There is
also a README file.


Brief Description
-----------------
Structure of the file
=====================

All lines in the file should be 80 characters or less. 

The file uses a block structure, with related pieces of information stored 
together in the same block. Blocks can be in any order. Blocks begin and end 
in an identifiable way, so that an entire block can be skipped easily by a 
reading routine that was not interested in the contents of that block. Also, 
additional blocks can be defined without requiring a new format definition. 
Blocks are named so that their contents are readily identifiable to a human 
reading the file.

Blocks
======

Blocks begin with a line that starts with the character "%" followed by a
block name. White space is permitted before the "%", and between the "%" 
character and the block name. A block is terminated by a line starting 
with the "%" character and the word 'end' (NOT case sensitive).

Comment lines
=============

All lines which has a '*' or '#' as its first non-blank character
will be a comment line, and will be ignored by the reader software.


Proposed blocks
===============

The following blocks are defined, and are listed in the order they would generally 
appear in the file. This order was chosen mainly to put information humans 
might want to read at the beginning of the file so they donUt have to wade 
through the covariance matrix to find it.

Comment lines are allowed in certain blocks, as noted below.

Table 2. Blocks
---------------
Block         What it stores
-----------   --------------
header        Useful information about the solution, mainly for documentation
              * Comment lines are allowed *

single-session (optional)
              Information needed for files which are based on a single "session"
              solution.
              * Comment lines are allowed *

multi-session (optional)
              Information needed for files which are based on more than one
              individual "session" solution. This would include information
              about station velocities and displacements if they are present in
              the file.
              * Comment lines are allowed *

stations      Relates station IDs used in the file to site name, monument 
              inscription, and antenna height.
              * Comment lines are allowed *

estimates     Estimated parameters and sigmas

apriori       Nominal values and a priori sigmas

covariance    Off-diagonal correlations of the estimated parameters.

apcovar       Off-diagonal a priori correlations for the estimated parameters 
              (optional)

software-specific <software-name> 
              Any software-specific information that 
              users of a particular software might want to store. This might
              include orbit estimates in some internal format, for example.


[Mailed From: jeff at cotopaxi.Stanford.EDU (Jeff Freymueller)]