Overview

This is an area where a couple people are working up what they would like as a way to access the GPSTk from other languages. The first two use cases are python and octave though we see others would also appreciate java, Fortran, and MatLab™.

Some basic desired functionality

1. The ability to use an manipulate time in standard GPS systems should be available. This would include, but is not limited to: MJD, GPS Week SOW, GPS Z count, GPS full week.
2. The ability to read a RINEX Obs Header and recover and field from the header. The ability to easily recover a "list" of SVs contained in the file.
3. The ability to: create an empty RINEX header, populate it with data and then write a valid RINEX header to a file. The ability to copy a RINEX header to a new header. The ability to access and manipulate any header element.
4. The ability to read RINEX obs data (including extensions for alternate measurement types) into usable data structures.
   • Get all obs
   • Get all observations for a single SV
   • Get all obs for a single system (G, R, E,...)
5. The ability to write valid RINEX obs data, including the extensions to other types.
6. The ability to read RINEX Nav file formats and generate SV positions at a specific epoch. Generally, I think we would want all functionality in these classes.
7. The ability to read and use RINEX met data. The ability to write a RINEX met file.
8. The ability to read an SP3-xx file into an internal data structure that can be used. The ability to use the Lagrange interpolation routines to generate a position at a time not in the SP3 file.
9. The ability to access all Ellipsoid information for any system (so PZ-90, WGS84, etc). The ability to handle these entities as python objects would be nice.
10. The ability to use all the ICD classes as objects, or data structures.
11. The ability to generate a PR solution from a set of RINEX Observations.

-- Contributors: JonLittle - 03 Mar 2010

Basic Python Interface (JonLittle)

I want this interface to be common across target languages. That means finding a lowest common denominator. It certainly means that the basic interface will not use language specific concepts. That may be semantics because there is nothing to prevent bindings to a specific language to have features that don't exist in the bindings to other languages. I am just trying to define the scope of the 'Basic' interface. This means limiting the interface to functions, structures, and arrays.

Time

The basic time representation will be a MJD stored in the most capable native floating point that the language supports usually this is at least 64 bit IEEE double precision.

Definitions:

• MJD: modified julian date; julian date - a big number, a floating point number
• week: GPS week, does not reset at 10 bits
• sow: GPS seconds of week, floating point value
• z: GPS z-count, == int(sow/1.5), integer value
• gpstk_tm: a struct with year, month, day, hour, minute, second

Functions:

• gpst_tm | week,sow | week,z -> MJD
• MJD -> gpstk_tm | week,sow | week,z

Constants:

• MJD of GPS epoch
• MJD of unix epoch

Rinex Obs I/O

Two ways of accessing a rinex obs file; as a sequence of epochs and as an array

• rinex_obs_header: struct with all elements of a rinex header
• rinex_obs_epoch: struct with all elements of a rinex obs epoch block

• rinex_obs_header read_rinex_obs_header(fh)
• rinex_obs_epoch read_rinex_obs_epoch(fh)
• long double[][] read_rinex_obs_array(fh)

• void write_rinex_obs_header(fh, const rinex_obs_header roh)
• void write_rinex_obs_epoch(fh, const rinex_obs_epoch roe)
• void write_rinex_obs_array(fh, const rinex_obs_header roh, const rinex_obs_array roa)

Discussion