GNSS Vector Exchange File Format (GVX)

Narrative Description of GVX Data Types and Elements

Version 1.0 (February 4, 2021)
Revision History
Version 1.0
04 Feb 2021 Final release of original version of GVX
Authors: Daniel Gillins, Ira Sellars

Introduction
In the late 1980s, researchers recognized the need to develop a standardized file format for static
Global Positioning System (GPS) raw data. The reason for this need was that GPS receivers from
different manufacturers were outputting raw GPS data in varying file formats. It was felt that a
standard file format would make post-processing more efficient.
As a result of this need, the original Receiver Independent Exchange Format (RINEX) was
developed. Since then, RINEX has been modified and undergone two new major format versions.
It primarily involves carrier-phase, pseudorange, and observation time measurements and has
become an industry and academic standard for exchanging static Global Navigation Satellite
System (GNSS) data. It’s a safe bet that all GNSS post-processing software can parse RINEX data.
Although RINEX has a mature history, a well-known and standard file format for GNSS vectors
does not exist. A GNSS vector is derived from two GNSS receivers, one placed at each end of a
baseline to be measured. During baseline processing, common satellite observables collected
simultaneously at each receiver are differenced, producing a vector with Earth-Centered, Earth-
Fixed differential components (as well as their variances and covariances). GNSS vectors are
computed to represent a measurement of a baseline, and they are commonly used in a survey
network (usually with other GNSS vectors; sometimes with other direct measurements, such as
EDM-based distances) for the determination of coordinates (usually within a least squares
adjustment). A GNSS vector is sometimes referred to as a “baseline solution” because it is a
mathematical representation of the post-processing and differencing of the raw GNSS data
collected at the receivers.
In addition to post-processing, GNSS vectors can also be computed in real-time during the course
of a real-time kinematic (RTK) survey. Conventional practice is to set a single GNSS receiver,

GVX Narrative Description, Version 1.0 Page 1 of 20

known as a “base” station, over a known point. The second GNSS receiver, or “rover”, is then
used to make measurements on unknown point(s). Wireless communication is established between
the base and rover, and baselines are processed in real-time in order to derive GNSS vectors from
the base to the rover. Today, rovers can be set up to communicate and receive correction messages
from a real-time network (RTN) consisting of multiple base stations.
RTK-derived vectors are frequently uploaded in software for evaluation, quality assessment, and
least squares adjustment. However, this proves burdensome because, just as in the case of raw
GNSS data, each vendor has chosen to output vector data in their own data formats. Like RINEX
for raw GNSS data, a standardized file format for GNSS vector data of all sorts would enable the
exchange of this common survey data, thereby enhancing the usefulness for all.
To this end, this document proposes a new standardized file format known as the GNSS Vector
Exchange Format (GVX). GVX aims to provide a standard format for exchanging GNSS vectors
derived from varying GNSS survey methods and manufacturer hardware. The file format includes
all of the necessary data of a GNSS vector for inclusion in a survey network for least squares
adjustment, as well as metadata which describes the vector. The format is meant for any type of
GNSS vector, whether it was derived in real-time or from baseline post-processing. GVX has been
written in extensible markup language (XML). XML was chosen because it was designed to carry
and store data in plain text format, it is easy to expand and/or upgrade to new operating systems,
and it can be read by both humans and machines.
Hyperlinks are given below to a simple data file in the proposed GVX format as well as to the
schema (XML Schema Definition, XSD).
● Link to the GVX example file: https://geodesy.noaa.gov/data/formats/GVX/sample_gvx.xml
● Link to the GVX schema: https://geodesy.noaa.gov/data/formats/GVX/schema_gvx.xml

In addition to providing the above links, this document gives a detailed description of each of the
elements of the proposed GVX file format. It also describes the data types, options, and restrictions
for a valid GVX file.

Description of GVX Data Types

Note that in this document, data types are shown in italics. The GVX file format involves elements
with various simple or complex data types. Several simple XML data types are used, including
Double, String, Integer, anyURI, Boolean, and unsignedInt. Descriptions are not given for these
basic types. Details for other specific types are given below.

GVX Narrative Description, Version 1.0 Page 2 of 20

CODEtype: a code assigned to any element. Each code shall contain only 0-9, a-z, A-Z,
underscore (_), and colon (:) characters
Date: format as YYYY-MM-DD
Datetime: format as YYYY-MM-DDThh:mm:ss.ss in GPS Time only.
EMAILtype: a string with a pattern restricted to a valid email address.
IDtype: an identifier assigned to any element. Each identifier must be unique throughout the file
and shall only contain 0-9, a-z, A-z, stop (.) and underscore (_) characters. Example:V00001.
It must have at least one character.
LATITUDEtype: a double value for latitude, restricted to negative 90 to positive 90 degrees.
LONGITUDEtype: a double value for longitude. Values are restricted to negative 360 degrees to
positive 360 degrees. Negative longitudes indicate a position west of the prime meridian, and
positive longitudes indicate east of the prime meridian.

Description of GVX Elements

Each parent and its child element(s) for the GVX file structure are described in the list below.
Names for each element are given in capital letters and in bold. Assigned types for each element
are in italics. All elements are required for a valid GVX file except those noted as “<optional>”.
All required elements must occur at least once for a valid GVX file, unless otherwise noted.

1. SOURCE_DATA: Information on the original survey data file containing the points and
vectors. Only one SOURCE_DATA record allowed per file.
a. NAME: String for the original data file name, such as the survey job file name or
project file name. Typically, this is the name of the file in the data collector or for
the project on the computer.
b. CREATED_DATE: Datetime when the original data file was created.
c. APPLICATION: Information on which application was used to record the data.
i. NAME: String for the name of the application software that was used to
record the data. Examples are Trimble Access, Leica Captivate LandXML
Export, or Magnet Field.
ii. VERSION: String for the version of the APPLICATION.
iii. MANUFACTURER: String for the name of the manufacturer of the
APPLICATION. <optional>
iv. MANUFACTURER_URL: anyURI for the website of the
MANUFACTURER. <optional>

GVX Narrative Description, Version 1.0 Page 3 of 20

 d. CONVERTED_BY: Information on which software was used to convert the
original data file into GVX format. If the APPLICATION is capable of directly
outputting a GVX file without conversion, then provide its NAME, VERSION,
and URL as the converter software.
i. SOFTWARE_NAME: String for the name of the software used to
convert the original data file into GVX format.
ii. VERSION: String for the version of the conversion software. <optional>
iii. SOFTWARE_URL: anyURI for the website of the conversion software.
<optional>
iv. CONVERTED_DATE: Datetime when the original data file was
converted to the GVX file or the date the GVX file was output directly
without conversion.

Figure 1. Example of the SOURCE_DATA element

2. PROJECT_INFORMATION: Information on the surveying project, points of contact,

and start and end date of the survey. Only one PROJECT_INFORMATION record is
allowed per file.
a. TITLE: String providing a name or title for the survey project.
b. EMAIL_ADDRESS: EMAILtype for the email address of the point of contact.
<optional>
c. PARTY_CHIEF: String providing the name of the party chief of the survey
project.
d. AGENCY: String providing the name of the agency or company.
e. START_DATE: Date of the earliest vector in the file.
f. END_DATE: Date of the oldest vector in the file.

GVX Narrative Description, Version 1.0 Page 4 of 20

 g. REMARK: String providing any notes or a description of the project. <optional>

Figure 2. Example of the PROJECT_INFORMATION element

3. REFERENCE_SYSTEM: Defines the units and 3-D reference frame(s) utilized for all
of the points and orbits utilized during processing in the GVX file. A file may contain
multiple REFERENCE_SYSTEM records if points or orbits in the file are in more than
one system.
a. ID: IDtype for setting a unique identifier for the 3-D reference frame. The value
shall be set to equal the ID for a geodetic datum in the International Organization
of Standardization (ISO) Geodetic Register (see https://geodetic.isotc211.org/ for
full details). As examples, some of the ISO Geodetic Register IDs and geodetic
datums are:

ID ISO Geodetic Datum

126 NAD 83 (2011)
101 NAD 83 (MA11)
188 NAD 83 (PA11)
724 IGb14
153 IGS14
159 IGb08
106 IGS08
131 WGS 84 (G1762)
196 WGS 84 (G1674)
114 WGS 84 (G1150)

b. CODE: Codetype allows assignment of a code for the REFERENCE_SYSTEM,

if needed. <optional>
c. NAME: String for the name of the REFERENCE_SYSTEM, meant to aid a
human reading the file. Example is “NAD 83(2011)” or “IGS14”.

GVX Narrative Description, Version 1.0 Page 5 of 20

 d. LINEAR_UNIT: Defines which linear units are used for all distances, heights,
Cartesian coordinates, and lengths in the file.
i. NAME: String for the name of the linear units; for a valid GVX file, this
string is restricted to meters.
ii. SIGNIFICANT_DIGITS: unsignedInt listing the number of significant
digits for the linear distances. <optional>
iii. CONVERSION_FACTOR: double providing the conversion factor from
the linear units in the original data file (if not in meters) to meters for the
GVX file (if a conversion was necessary). <optional>
e. ANGULAR_UNIT: Defines the angular units for all angles, latitudes, and
longitudes in the file.
i. NAME: String for the name of the angular units; for a valid GVX file, this
string is restricted to decimal degrees.
ii. SIGNIFICANT_DIGITS: unsignedInt listing the number of significant
digits for the angles. <optional>
iii. CONVERSION_FACTOR: double providing the conversion factor from
the angular units in the original data file (if not in decimal degrees) to
decimal degrees for the GVX file (if a conversion was necessary).
<optional>
f. REMARK: string providing any notes or a description. <optional>

Figure 3. Example of the REFERENCE_SYSTEM element

4. EQUIPMENT: Defines a pair (antenna and receiver) of GNSS equipment utilized

during the GNSS survey. A valid GVX file must contain a minimum of two

GVX Narrative Description, Version 1.0 Page 6 of 20

 EQUIPMENT records (one record each for the initial and terminal point of a GNSS
vector).
a. ID: IDtype for setting a unique identifier for the equipment pair.
b. RECEIVER: Defines the GNSS receiver.
i. TYPE: String providing the name of the GNSS receiver. Recommend
using official IGS names, if they exist, or following the IGS receiver
naming style if they do not, for all GNSS receivers. See
ftp://igs.org/pub/station/general/rcvr_ant.tab for details on IGS naming
conventions.
ii. SERIAL_NUMBER: String for the receiver serial number.
iii. FIRMWARE_VERSION: String for the firmware version utilized by the
receiver.
c. ANTENNA: Defines the GNSS antenna.
i. TYPE: String for the official name of the GNSS antenna. Recommend
using names accepted by NGS under its antenna calibration program,
which include all official IGS antenna names. For details on IGS antenna
names, see ftp://igs.org/pub/station/general/rcvr_ant.tab. For names from
the NGS antenna calibration program, see
https://www.ngs.noaa.gov/ANTCAL/. If the antenna is not on the NGS or
IGS calibration lists, then recommend following IGS naming styles.
ii. CALIBRATION_TYPE: String for naming the type of antenna phase
center calibration model under use. Values are restricted to either
“Absolute” or “Relative” models. <optional>
iii. CALIBRATION_SOURCE: String for naming the source of the antenna
phase center calibration model under use. Examples include “IGS”,
“NGS”, “Trimble”, “Leica”, “Geo++”, etc. <optional>
iv. SERIAL_NUMBER: String for the antenna serial number. For integrated
antennas/receivers, this serial number will be identical with the
RECEIVER SERIAL_NUMBER.

GVX Narrative Description, Version 1.0 Page 7 of 20

 Figure 4. Example of the EQUIPMENT element

5. SURVEY_SETUP: Information on how the GNSS vectors were collected or derived. A

GVX file may contain multiple SURVEY_SETUP records if varying methods of data
collection were used or if the equipment OPERATOR changed during the course of the
survey.
a. ID: IDtype for setting a unique identifier for the setup of the survey.
b. SOLUTION_TYPE: String for describing the method for how the GNSS vector
was derived. Only the following strings are allowed: (1) “Single-baseRTK” for a
vector from a real-time kinematic (RTK) survey using only a single base station;
(2) “NetworkRTK” for a vector from an RTK survey using full network
correctors from a real-time network; (3) “Post-processed” for a vector from
baseline post-processing.
c. OPERATOR: String providing the name of the person operating the RTK rover
receiver or running the post-processing software.
d. PROCESSING_SOFTWARE: Information on the baseline processing software
used to derive the vector.
i. NAME: String for the general or simple name of the baseline processing
software. An example is “PAGES” or “TBC”.

GVX Narrative Description, Version 1.0 Page 8 of 20

 ii. VERSION: String for the detailed name or version number of the baseline
processing software. An example is “PAGE5 V1603.24”.
iii. SOFTWARE_URL: anyURI for the website of the baseline processing
software. <optional>
e. CORRECTOR_FORMAT: String describing the format of the corrector, if the
vector resulted from an RTK survey. Examples are “RTCM v2”, “RTCM v3”,
“CMR/CMR+”. <optional>
f. NETWORKRTK: Information on the real-time network (RTN), required if one
was used to derive the vector (whether using a single-base station in the RTN or
using the full network corrector from multiple base stations in the RTN). If an
RTN was not used for the vector, then it is not required. <optional>
i. NAME: String for the name of the RTN. Example is “Oregon Real-time
GNSS Network”. <optional>
ii. MOUNT_POINT: String for documenting the name of the mount point
under use. RTN providers will assign a “mount point” or name for its
unique settings for providing corrections, and a user will connect a rover
to this mount point. An example is “VRS_RTCM3” which likely indicates
the RTN is providing VRS solutions with correctors broadcast in RTCM
version 3 format.
iii. TYPE: String for the method of network corrector, if SOLUTION_TYPE
is “NetworkRTK”. Values are restricted to “VRS”, “MAC”, “MAX”, “i-
MAX”, “FKP”, “RTX”, or “Other”.
iv. IP_ADDRESS: anyURI for IP address of the RTN.
v. IP_PORT: unsignedInt for the IP port.
g. REMARK: string providing any notes or a description of the survey setup.
<optional>

Figure 5. Example of the SURVEY_SETUP element

GVX Narrative Description, Version 1.0 Page 9 of 20

 6. POINT: Data for each set of coordinates (i.e., latitude, longitude, and ellipsoid height)
for any point in the GVX file. A file will contain multiple POINT records.
a. ID: IDtype for unique identifier within the GVX file assigned to every unique set
of coordinates for any point.
b. NAME: String giving the name assigned by the surveyor for the coordinates of
the point. This is also often called the “point name”, and it is typically entered by
a surveyor in a data collector or in computer software.
c. CODE: CODEtype for allowing entry of a code. <optional>
d. EQUIPMENT_ID: IDtype for referencing its EQUIPMENT record,
documenting what equipment was utilized to derive or key-in the coordinates of
the point.
e. ARP_HEIGHT: Double for providing the vertical height from the observed mark
to the antenna reference point (ARP) of the GNSS antenna.
f. POINT_TYPE: String for describing how the coordinates of the point were
derived. Restricted values are: (1) “Keyed-in” for coordinates that were keyed in
or entered to the file; (2) “Code” for coordinates that were derived from only the
GNSS pseudorange codes; (3) “Float” for coordinates that were derived from
GNSS phase angles without integer ambiguity fixing; (4) “Fixed” for coordinates
that were derived with GNSS phase angles with fixed integer ambiguities; (5)
“PartialFixed” for coordinates that were derived with GNSS phase angles with
partially-fixed integer ambiguities; (6) “Adjusted” for coordinates derived in the
office from a least squares adjustment of a survey network; (7) “PPP Solution” for
coordinates derived from precise point positioning.
g. NETWORK_LOCATION: String for describing if the coordinates were derived
inside or outside the footprint of the real-time network, if used. Restricted values
are “Inside”, “Outside”, or “Unknown”. <optional>
h. TILT_COMPENSATOR: Boolean for specifying a value of “1” (TRUE) if the
coordinates were derived with the EQUIPMENT and a tilt compensator or “0”
(FALSE) if a tilt compensator was not used. <optional>
i. COORDINATES: Coordinates of the POINT.
i. REFERENCE_SYSTEM_ID: IDtype for referencing the
REFERENCE_SYSTEM record of the coordinates of the POINT.
ii. EPOCH: Double for the epoch of the coordinates (in decimal years;
recommended to at least 4 digits right of the decimal point).
iii. GEODETIC_COORDINATES:
1. LATITUDE: LATITUDEtype for the latitude. Value must be
provided to a minimum of ten digits right of the decimal point

GVX Narrative Description, Version 1.0 Page 10 of 20

 2. LONGITUDE: LONGITUDEtype for the longitude. Value must
be provided to a minimum of ten digits right of the decimal point.
3. ELLIPSOIDAL_HEIGHT: Double for the height above the
ellipsoid. Value must be provided to a minimum of four digits right
of the decimal point.
iv. GEOCENTRIC_COORDINATES: Earth-Centered, Earth-Fixed
(ECEF) Cartesian coordinates for the stated axes. Values must be provided
to a minimum of four digits right of the decimal point. <optional>
1. X: Double.
2. Y: Double.
3. Z: Double.
v. CORRELATION_MATRIX_LOCAL: Standard deviation and
correlation coefficient estimates in a local geodetic horizon. Standard
deviation values must be provided to a minimum of four digits right of the
decimal point, and correlation values must be provided to a minimum of
six digits right of the decimal point. <optional>
1. SDN: Double for the standard deviation in northing.
2. SDE: Double for the standard deviation in easting.
3. SDU: Double for the standard deviation in up.
4. PNE: Double for the correlation in northing and easting.
5. PNU: Double for the correlation in northing and up.
6. PEU: Double for the correlation in easting and up.

vi. CORRELATION_MATRIX: Standard deviation and correlation

coefficient estimates in the Cartesian axes and REFERENCE_SYSTEM of
the point. Standard deviation values must be provide to a minimum of four
digits to the right of the decimal point, and correlation values to a
minimum of six digits to the right of the decimal point. <optional>
1. SDX: Double for the standard deviation in X.
2. SDY: Double for the standard deviation in Y.
3. SDZ: Double for the standard deviation in Z.
4. PXY: Double for the correlation in X and Y.
5. PXZ: Double for the correlation in X and Z.
6. PYZ: Double for the correlation in Y and Z.

GVX Narrative Description, Version 1.0 Page 11 of 20

 Figure 6. Example of the POINT element

7. GNSS_VECTOR: Data for each GNSS vector in the GVX file. A file may contain
multiple GNSS_VECTOR records.

GVX Narrative Description, Version 1.0 Page 12 of 20

 a. ID: IDtype for unique identifier for the GNSS vector.
b. INITIAL_POINT_ID: IDtype for referencing the POINT record for the initial or
starting point of the vector.
c. TERMINAL_POINT_ID: IDtype for referencing the POINT record for the
terminal or ending point of the vector.
d. SURVEY_SETUP_ID: IDtype for referencing the SURVEY_SETUP record,
providing information on how the vector was derived.
e. OBSERVATION_TIME:
i. START: Datetime of the beginning time of the observation. Must be in
GPS time.
ii. END: Datetime of the ending time of the observation. Must be in GPS
time.
iii. UTC_OFFSET: Double for providing the offset from UTC time to the
local time of the observation. Local time equals UTC time plus the
UTC_OFFSET. <optional>
iv. LEAP_SECONDS: Integer for providing the number of leap seconds
between GPS time and UTC time. GPS time equals UTC time plus the
LEAP_SECONDS. <optional>
f. QUALITY_CONTROL:
i. EPOCHS_USED: Integer for providing the number of epochs used to
compute the vector. <optional>
ii. MASK:
1. ELEVATION: Double for documenting the setting in the GNSS
equipment for the minimum acceptable elevation angle (in decimal
degrees) prior to masking satellite observables. If a mask was not
used, enter zero. <optional>
2. PDOP_MASK: Double for documenting the setting in the GNSS
equipment for the maximum acceptable position dilution of
precision (PDOP) prior to masking satellite observables.
<optional>
iii. RMS: Double for the root-mean-square error of the baseline solution, to a
minimum of three significant figures. <optional>
iv. DILUTION_PRECISION: Dilution of precision values computed for the
GNSS vector. <optional>
1. GDOP: Double for geometric dilution of precision. <optional>
2. HDOP: Double for horizontal dilution of precision. <optional>
3. PDOP: Double for position dilution of precision. <optional>
4. TDOP: Double for time dilution of precision. <optional>
5. VDOP: Double for vertical dilution of precision. <optional>

GVX Narrative Description, Version 1.0 Page 13 of 20

 v. SATELLITE_USED: Counts both the total number of satellite vehicles
used to derive the GNSS vector as well as a count of the subtotal of
vehicles from each GNSS. <optional>
1. TOTAL: Integer.
2. GPS: Integer.
3. GLONASS: Integer.
4. GALILEO: Integer.
5. QZSS: Integer.
6. BEIDOU: Integer.
vi. ORBIT: Information on the type of orbits used during baseline
processing.
1. TYPE: String for naming which orbits were used when deriving
the GNSS vector. Restricted values are “Final”, “Rapid”, “Ultra-
rapid observed half”, “Ultra-rapid predicted half”, and
“Broadcast”.
2. SOURCE: String for naming the source of the orbits. An example
is “IGS” or “Broadcast”.
3. REFERENCE_SYSTEM_ID: IDtype for referencing the
REFERENCE_SYSTEM record of the ORBIT. <optional>
4. DOWNLOAD_DATE: Datetime when the ORBIT was
downloaded from its SOURCE. <optional>
vii. CORRECTOR_AGE: Integer for the number of seconds of delay in the
real-time corrector, if the vector was derived in real-time. <optional>
g. ECEF_DELTAS: Differential, Earth-Centered, Earth-fixed mark-to-mark vector
components in the Cartesian axes and reference system of the ORBIT (from the
initial point to the terminal point). Values must be provided to a minimum of four
digits right of the decimal point.
i. DX: Double.
ii. DY: Double.
iii. DZ: Double.
h. CORRELATION_MATRIX: Standard deviation and correlation coefficient
values for the vector components, in the Cartesian axes and reference system of
the ORBIT. Standard deviation values must be provide to a minimum of four
digits to the right of the decimal point, and correlation values to a minimum of six
digits to the right of the decimal point.
i. SDX: Double for the standard deviation in X.
ii. SDY: Double for the standard deviation in Y.
iii. SDZ: Double for the standard deviation in Z.
iv. PXY: Double for the correlation in X and Y.
v. PXZ: Double for the correlation in X and Z.

GVX Narrative Description, Version 1.0 Page 14 of 20

 vi. PYZ: Double for the correlation in Y and Z.

Figure 7. Example of the GNSS_VECTOR element

GVX Narrative Description, Version 1.0 Page 15 of 20

 8. SESSION: Record for vectors derived from simultaneous baseline processing. A file
may contain multiple sessions, one for each set of vectors processed together with
simultaneous observations to common satellites. <optional>
a. Attributes:
i. ID: IDtype for unique identifier for the GNSS session.
ii. TOTAL_VECTORS: Integer count of the total number of vectors in a
session.
b. SESSION_TIME:
i. START: Datetime of when the session began. Must be in GPS time.
ii. END: Datetime of when the session ended. Must be in GPS time.
iii. UTC_OFFSET: Double for providing the offset from UTC time to the
local time of the session. Local time equals UTC time plus the
UTC_OFFSET. <optional>
iv. LEAP_SECONDS: Integer for providing the number of leap seconds
between GPS time and UTC time. GPS time equals UTC time plus the
LEAP_SECONDS. <optional>
c. CROSS_CORRELATION_MATRIX: All correlation coefficients between
every pair of vectors in the session, in the Cartesian axes and reference system of
the ORBIT. Each SESSION will have one CROSS_CORRELATION_MATRIX
element. See Appendix A for an example of how to build this matrix.
i. Attributes:
1. ORDER: String for describing the order of the listed correlation
coefficients, in terms of the Cartesian axes. An example is “XYZ”.
ii. CCM_BLOCK: A 3x3 block of correlation coefficients between a pair of
vectors in a session. For a session containing n TOTAL_VECTORS, there
must be [n (n – 1)]/2 blocks to describe a complete cross-correlation
matrix.
1. Attributes:
a. VECTOR_ID_COL: IDtype for referencing the
GNSS_VECTOR in the columns of the 3x3 block.
b. VECTOR_ID_ROW: IDtype for referencing the
GNSS_VECTOR in the rows of the 3x3 block.
2. CORRELATIONS: String listing the 9 correlation coefficients
from the 3x3 block of values between the identified pair of vectors.
Values are expressed to at least 6 digits to the right of the decimal,
separated by commas, in the identified ORDER.

GVX Narrative Description, Version 1.0 Page 16 of 20

APPENDIX A. Example for Handling a Full Correlation Matrix

Figure A1 presents an example correlation matrix for a simultaneously processed session of 5

GNSS vectors. The diagonal contains standard deviations for each vector differential component
(yellow cells), and all other values are correlation coefficients (green and blue cells).

The standard deviations (yellow cells) and correlation coefficients (green cells) along the 3x3
band-diagonal of the matrix are stored in the CORRELATION_MATRIX for each individual
GNSS_VECTOR. For the data presented in Figure A1, the CORRELATION_MATRIX for each
of the five vectors would be populated like shown in Figure A2.

The other correlation coefficients (blue cells) off of the 3x3 band-diagonal of the matrix are
considered “cross-correlations”. A 3x3 block of these cells represents correlations between two
vectors in the session. For instance, the values in columns 4 to 6 and rows 1 to 3 of the matrix
represent the correlations between vector 2 and vector 1. Each off-diagonal 3x3 block of values
is stored as a comma delimited list in the CCM_BLOCK of the
CROSS_CORRELATION_MATRIX record for the SESSION. For a session containing n
vectors, there must be [n (n – 1)]/2 blocks (i.e., CCM_BLOCK) to fully describe all values. So,
for Figure A1 consisting of five vectors, the CROSS_CORRELATION_MATRIX will have ten
CCM_BLOCK records. Figure A3 presents a populated CROSS_CORRELATION_MATRIX
for the data in Figure A1.

By combining the CCM_BLOCK records of the CROSS_CORRELATION_MATRIX with the

CORRELATION_MATRIX of each of the individual GNSS_VECTOR records, it is possible to
construct a full correlation matrix for the session.

GVX Narrative Description, Version 1.0 Page 17 of 20

 VECTOR 1 VECTOR 2 VECTOR 3 VECTOR 4 VECTOR 5
X Y Z X Y Z X Y Z X Y Z X Y Z
X 0.000405 -0.674221 0.775253 -0.509209 0.298034 0.257034 0.253795 0.791754 0.193256 -0.639295 0.597485 -0.610140 0.523686 0.099108 0.984302
Y 0.002328 -0.202975 -0.652557 0.043531 0.116217 -0.908680 -0.080583 -0.629678 0.321014 -0.052642 -0.299856 0.987440 0.403217 0.416175

Z 0.005467 0.228385 0.583920 0.580984 -0.239217 0.768268 0.313219 0.686572 -0.193054 -0.805117 0.418503 0.215832 0.320711

X 0.001822 -0.642737 0.343691 0.782238 0.734354 -0.984808 -0.328404 0.905440 -0.025916 -0.730406 -0.078659 -0.635347

GVX Narrative Description, Version 1.0

Y 0.003746 -0.073597 0.456162 0.433486 -0.814330 0.428120 0.275459 0.910117 -0.611051 0.944213 -0.289733
Z 0.009820 -0.690216 0.835892 0.262298 -0.281938 0.544641 0.737189 0.347740 -0.908073 -0.086859

X 0.008301 -0.266955 0.665920 0.511132 0.510525 -0.237698 0.528545 0.326278 0.387525

Y 0.002328 0.959702 0.911129 0.757233 -0.819999 0.256224 0.710261 -0.455859

Z 0.001923 0.472967 0.306437 0.753184 -0.491392 0.371125 -0.696796

X SYMMETRIC 0.006783 -0.985821 0.735367 0.443609 -0.269284 -0.390866

Y 0.001721 -0.498073 -0.706717 -0.029156 -0.305930

Z 0.008807 0.202469 0.228891 0.793981

X 0.004353 0.838423 0.169365

Y 0.003442 -0.715525

VECTOR 5 VECTOR 4 VECTOR 3 VECTOR 2 VECTOR 1

Z 0.003847

= standard deviation
= correlation coefficient
= cross-correlation coefficient

Figure A1. Example full correlation matrix for 5 vectors in a session, post-processed simultaneously.

Page 18 of 20
Figure A2. Example CORRELATION_MATRIX records for the standard deviation and
correlation coefficients along the 3x3 band diagonal of the matrix in Figure A1.

GVX Narrative Description, Version 1.0 Page 19 of 20

Figure A3. Example CROSS_CORRELATION_MATRIX records for the correlation
coefficients for the off-diagonal 3x3 blocks of the matrix in Figure A1.

GVX Narrative Description, Version 1.0 Page 20 of 20