Understanding the RINEX format for GNSS data transfer and storage

This paper provides a brief history of the RINEX format, presents examples of recent RINEX format versions and discusses the editing of RINEX observation files.

Dr Volker Janssen Senior Technical Surveyor in the Geodetic Operations team at DCS Spatial Services, NSW Department of Customer Service, in Bathurst, Australia.

The Receiver Independent Exchange (RINEX) format is the international standard for the storage and exchange of Global Navigation Satellite System (GNSS) data. It not only enables interoperability between receiver brands and processing software packages but also the generation of many valuable products and services to the GNSS user community by the International GNSS Service (IGS). The RINEX format allows efficient and unambiguous archiving of GNSS data and associated metadata in one place (in a human-readable form), while also facilitating the easy transfer and distribution of such data, independent of the equipment used to collect it and the engine employed for data processing.

RINEX files are universally used by international organisations, academia, national organisations, all levels of government and private industry. Online processing services, such as Geoscience Australia’s free online Global Positioning System (GPS) processing service, AUSPOS (GA, 2023), and the CSRS-PPP online Precise Point Positioning (PPP) service provided by Natural Resources Canada (NRCan, 2023), require the user to submit data in RINEX format. Consequently, it is important that users understand the contents and format of these files.

The Geocentric Datum of Australia 2020 (GDA2020) is Australia’s national datum and based on a single, nationwide least squares network adjustment that rigorously propagates uncertainty (Harrison et al., 2023). DCS Spatial Services, a unit of the NSW Department of Customer Service (DCS), is responsible for the establishment, maintenance and improvement of the survey control network in New South Wales (NSW), which comprises more than 250,000 survey marks on public record made available to users via the Survey Control Information Management System (SCIMS).

DCS Spatial Services uses RINEX files in providing services to its customers and the broader surveying profession as well as interacting with federal counterparts to support national initiatives. Focussing on GNSS observation files, this paper provides a brief history of the RINEX format, outlines examples of recent RINEX format versions and discusses the editing of RINEX observation files.

Brief history of RINEX

All manufacturers store raw GNSS (and most other survey instrument) data in proprietary, binary (non-human readable) data formats that are designed to be compact, optimise specific observations, enhance performance with their own algorithms and software modules (or complete software suites) and that lock users into their brand. As such, swapping raw survey data between brands was never intended. That was until RINEX was invented.

The RINEX format was initially developed in the late 1980s by the Astronomical Institute of the University of Bern, Switzerland, to facilitate the easy exchange of GPS data to be collected during the first large European GPS campaign, EUREF89, which involved more than 60 GPS receivers of four different manufacturers (Gurtner et al., 1989). It defined three different file types: observation data file, navigation message file and meteorological data file. The reader is encouraged to appreciate the complexity and delicacy of negotiations and confidence that was entrusted to this organisation to initially gain access, and then continued access over the decades, to the proprietary Intellectual Property (IP) of each of the major manufacturers and the very idea of championing interoperability.

Each RINEX file consisted of a header section containing metadata related to the station occupied and the equipment used, followed by a main body with the actual data. The files were designed to have a maximum line length of 80 characters, written in American Standard Code for Information Interchange (ASCII) to enable humans to read (and edit) the data and guarantee an easy exchange between different computer systems. The cost of being human-readable is that RINEX files are always larger in size than the raw format files. The observed GPS data included the carrier-phase measurement on one or two frequencies, the pseudo-range (code) measurement, the Doppler measurement, the signal strength and the observation time.

Through the RINEX format, it was possible to combine data observed by a multitude of receiver brands and models in order to be processed together. Over many years, and under the umbrella of the IGS, the RINEX format has since been modified, expanded and improved to allow multiGNSS data to be handled, thus becoming the international standard used for the transfer, archival and distribution of GNSS data by the IGS and countless other users in the GNSS community worldwide (IGS, 2023a). For example, this has resulted in the computation of the ever-improving International Terrestrial Reference Frame (ITRF – see Altamimi et al., 2023). Based on the collation and processing of globally collected GNSS data, the IGS provides a wide range of valuable products to the GNSS user community, including precise satellite orbits and clocks, terrestrial reference frame products (e.g. station positions and earth rotation parameters) and global ionospheric maps (IGS, 2023b). Without RINEX, this collaboration and its benefits, along with open, regional Continuously Operating Reference Station (CORS) networks such as CORSnet-NSW (Janssen et al., 2016; DCS Spatial Services, 2023), would have been impossible. The alternative would have been for each manufacturer to build and operate their own closed proprietary system. Understandably, the costs would have been prohibitive.

In the mid-1990s, the success of the RINEX format spawned a spin-off: the Solution Independent Exchange (SINEX) format, which is used by the geodetic community to store and transfer solutions of various parameters derived in various types of analysis (e.g. AUSPOS solutions containing more detailed information for advanced users). This was followed by a family of other RINEX-like file formats (IGS, 2023a) that are mainly used by the IGS, including exchange formats for satellite and receiver clock offsets determined by processing data of a GNSS network, for Space-Based Augmentation System (SBAS) broadcast data files, for ionosphere models determined by processing data of a GNSS network (IONEX), and for phase centre variations of geodetic GNSS antennas (ANTEX).

To date, the following four versions of RINEX have been developed and published (Gini, 2023):
• The original RINEX version 1 was presented at and accepted by the 5th International Geodetic Symposium on Satellite Positioning in Las Cruces, New Mexico, in 1989.
• RINEX version 2 was presented at and accepted by the 2nd International Symposium of Precise Positioning with the Global Positioning System in Ottawa, Canada, in 1990. It mainly added the possibility to include tracking data from different satellite systems (i.e. GLONASS, SBAS). Over time, it was modified via several sub-versions, culminating in version 2.11.
• RINEX version 3 was developed in the early 2000s and initially released in 2007 to support multi-GNSS and clearly identify the tracking modes of each of the observations by introducing 3-character observation codes for all GNSS constellations. Over time, it was modified via several sub-versions, culminating in version 3.05.
• RINEX version 4 was released in 2021 as a necessary step to support the modern multi-GNSS navigation messages by introducing and defining navigation ‘data records’ to hold both individual satellite navigation messages, constellation-wide parameters and global parameters as transmitted by the different GNSS constellations. It has since been updated to version 4.01.

Examples of recent RINEX versions

While it is recognised that the RINEX format encompasses observation data, navigation data and meteorological data, along with extensions such as satellite and receiver clock data and SBAS broadcast data files, this paper focuses on RINEX observation files as these are the most important for surveyors in practice (and the most likely to be edited). Apart from using the broadcast ephemeris data collected by their own receiver, surveyors can easily obtain precise orbit files from various sources if required (e.g. via IGS, 2023b), and the other files are generally not used in common surveying applications.

RINEX 2.11

Following several revisions for improvement and clarification, RINEX 2.11 (Gurtner and Estey, 2012) is the last official RINEX version 2 format. Its major difference compared to the original RINEX version 1 format is thatit caters for tracking data from different satellite systems in addition to GPS. This format is currently being used by DCS Spatial Services for archiving AUSPOS datasets for inclusion into the GDA2020 state adjustment, partly because AUSPOS remains GPS-only at present (Janssen and McElroy, 2022).

The RINEX file name must not contain any spaces, parentheses or symbols. It is beneficial to use the international RINEX 2.11 file naming convention XXXXDDDS.YYO consisting of 8 characters followed by a 3-character extension, where XXXX is a 4-character site name, DDD is the day of year (i.e. 001 to 365, or 366 during a leap year), S is the session identifier (i.e. 0 to 9, or A to X indicating the first observation epoch’s hour of the day with A = 0 hours and X = 23 hours), YY is the 2-digit year (i.e. 23 for the year 2023) and the letter O indicates that this is an observation file.

RINEX file name extensions are sometimes further refined to indicate the type of compression that may be used to reduce the ASCII file size. Hatanaka (2008) developed a compression scheme and related software tools that take advantage of the structure of the RINEX observation data by forming higherorder differences in time between observations of the same type and satellite (indicated by the extension .YYd). This compressed ASCII file is then often compressed again using standard compression programs, e.g. yielding a UNIX-compressed (.YYd.Z) or gzip-compressed (.YYd.gz) Hatanaka RINEX file.

The RINEX file consists of a header section (including mandatory and optional records) followed by a data section and ends with a blank line, each row being a maximum of 80 characters long. A single RINEX file should only include a single occupation on a single mark. The header section contains information for the entire file, including mandatory header labels in columns 61-80 for each line in the header, which must appear exactly as stipulated. The header information must also appear in the correct columns to be valid, e.g. antenna information and antenna height. This is of particular importance when the RINEX header is edited.

Figure 1 shows an example of a typical RINEX 2.11 header. It includes the following information:
• Line 1: RINEX version, specifying an observation file with mixed GNSS data (e.g. as opposed to GPS-only).
• Line 2: Program used to generate the RINEX file, who ran it (here blank) and when it was run.
• Line 3-4: Comments (can be placed anywhere between the first and last line in the header).
• Line 5: Marker name, in this case the 4-character ID issued to NSW by Geoscience Australia.
• Line 6: Marker number, here the SCIMS number.
• Line 7: Observer and agency, here NSW (i.e. DCS Spatial Services).
• Line 8: Receiver serial number, receiver type and firmware version.
• Line 9: Antenna serial number (for integrated antennas the same as the receiver serial number) and antenna type (using the IGS naming convention).
• Line 10: Approximate site position in WGS84 Cartesian coordinates (X, Y, Z).
• Line 11: Antenna height (measured vertically between ground mark and Antenna Reference Point, ARP) and any horizontal offset from the mark (i.e. small horizontal
eccentricities of the ARP to the marker, which are typically zero for all but some scientific applications).
• Line 12: Wavelength factor for the L1 and L2 frequency, in this case indicating full cycle ambiguities for both frequencies.
• Line 13: Number and types of observations, here L1, L2, C1, P2, S1, S2 – i.e. carrier phase measurements, code measurements and signal strengths on the L1 and L2 frequency, respectively.
• Line 14: Sampling interval, in this case 30 seconds.
• Line 15-21: Comments, here including the name of the raw binary data file.
• Line 22: Time of first observation epoch, here 00:37:30 hours (GPS time) on 1 June 2021.
• Line 23: Number of leap seconds between GPS time and UTC, in this case 18. GPS time started at 00:00:00 UTC (midnight) on 6 January 1980 (i.e. Sunday morning). Since then, several leap seconds have been introduced to UTC (but not GPS time), currently resulting in GPS time being 18 seconds ahead of UTC.
• Line 24: End of RINEX header indicator.

Figure 2 shows a typical RINEX 2.11 observation data block. It contains the following information:
• Line 25-26: Date and time of the observation epoch (receiver time of the received signals) in the format year, month, day, hours, minutes, seconds (here 00:37:30 hours on 1 June 2021), epoch flag (0 = OK, 1 = power failure between current and previous epoch, >1 = special event, e.g. 2 = start moving antenna), the number of satellites in the current epoch (here 18), followed by the system identifier (G = GPS, R = GLONASS, E = Galileo, S = SBAS or geostationary) and the 2-digit satellite number (i.e. Pseudo-Random Noise code, PRN, or GLONASS slot number). In this example, 8 GPS, 6 GLONASS and 4 Galileo satellites were observed.
• Line 27-28: Observations recorded for the first satellite listed (G01) – see line 13 in Figure 1 for the corresponding observation types in the RINEX header. In this example, six types of observations were recorded for all but the Galileo satellites (the L2 frequency is not used by Galileo) – L1 carrier phase measurement, L2 carrier phase measurement, L1 code measurement (C1), L2 code measurement (P2), L1 signal strength (S1) and L2 signal strength (S2). Each observation value is defined as a floating-point value of total length 14 with 3 decimals (F14.3). This is followed by two optional single-digit integer records (I1) pertaining to the Loss of Lock Indicator(LLI, range 0-7 or blank, phase observations only) and the Signal Strength Indicator (SSI, range 1-9 for increasing signal strength or blank).
• Line 29-62: Observations recorded for the other satellites in this epoch, with missing observations (or those not observed) indicated as blanks (e.g. no L2 observations to the Galileo satellites).The interested reader is referred to Gurtner and Estey (2012) for more detailed information on the RINEX 2.11 format.

RINEX 3.04 & 3.05

Following several revisions for improvement and clarification, RINEX 3.05 (Romero, 2020) is the last official RINEX version 3 format. Its major difference compared to RINEX 2.11 is that it fully supports multi-GNSS (G = GPS, R = GLONASS, E = Galileo, C = Beidou, J = QZSS, I = NavIC/IRNSS, S = SBAS) and clearly identifies the tracking modes of each of the observations by utilising 3-character observation codes for all GNSS constellations. In particular, the possibility to track frequencies on different channels required a more flexible and more detailed definition of the observation codes.

Some software currently supports formats up to RINEX 3.04 only, which has minor differences to the latest version (apart from missing signals and tracking codes to fully support the 2nd and 3rd generation of Beidou). RINEX 3.04 is also the format currently being used by DCS Spatial Services for archiving CORSnet-NSW datasets and providing them to Geoscience Australia (e.g. to be used by the AUSPOS service).

The RINEX 3.04/3.05 file naming convention (Figure 3) stipulates a much longer file name than RINEX 2.11, providing more detailed information about the dataset collected by being more descriptive, flexible and extendable (this was introduced with RINEX 3.02). In particular, this facilitates the efficient storage and exchange of RINEX data in large communities like the IGS. For practical surveying applications, this naming convention may appear to be too detailed to be adopted. However, it is important that users of IGS products or CORS data understand the long RINEX file names in order to obtain the desired data for their purposes.

The following examples illustrate the benefit of the long file naming convention, with data source, start time, duration, sampling rate and data type now easily visible as part of the file name:
• BATH00AUS_R_20230501200_03H_10S_MO.rnx indicates a RINEX observation file for Bathurst CORS (being the first monument [0] and the first receiver [0, unless additional receivers are connected to the same antenna] located at this site in Australia), sourced from a receiver (via vendor or other software), observed in 2023 on day of year 050 and starting at 12:00 hours, that contains 3 hours of data at a 10-second sampling rate and mixed GNSS observation data (i.e. from at least two satellite constellations). BATH00AUS_R_20230501715_15M_01S_GO.rnx also indicates a RINEX observation file for Bathurst CORS, being the first monument and receiver at this site, sourced from a receiver, observed in 2023 on day of year 050 but starting at 17:15 hours, containing 15 minutes of data at a 1-second sampling rate and GPS-only observation data.
• BATH00AUS_R_20230620000_01D_30S_MO.rnx indicates a RINEX observation file for Bathurst CORS, being the first monument and receiver at this site, sourced from a receiver, observed in 2023 on day of year 062, starting at 00:00 hours, containing 1 day of data at a 30-second sampling rate and mixed GNSS observation data.
• Accordingly, BATH00AUS_R_20230620000_01D_MN.rnx. gz indicates a compressed (the added gz extension indicates compression using the standard GNU zip, or gzip, algorithm) RINEX navigation file collected at Bathurst CORS, being the first monument and receiver at this site, sourced from a receiver, observed in 2023 on day of year 062, starting at 00:00 hours and containing 1 day of mixed GNSS navigation data.

As in the older versions, the RINEX observation file consists of a header section followed by a data section and ends with a blank line. While each row in the header continues to have a maximum length of 80 characters, this limitation has been removed for the data section (as explained below).

Figure 4 shows an example of a typical RINEX 3.04 header. It includes the following information:
• Line 1: RINEX version, specifying an observation file with mixed GNSS data (e.g. as opposed to GPS-only).
• Line 2: Program used to generate the RINEX file, who ran it (here blank) and when it was run.
• Line 3: Marker name, in this case the 4-character ID issued to NSW by Geoscience Australia.
• Line 4: Marker number, here the SCIMS number.
• Line 5: Marker type, here geodetic (i.e. an earth-fixed, high-precision monument). Selecting an attribute other than GEODETIC or NON_GEODETIC (i.e. a low-precision monument) indicates that the data was collected by a moving receiver (e.g. on a person, car, ship, aircraft, space vehicle, glacier, floating ice or even an animal).
• Line 6: Observer and agency, here indicating an organisation external to DCS Spatial Services.
• Line 7: Receiver serial number, receiver type and firmware version.
• Line 8: Antenna serial number (for integrated antennas the same as the receiver serial number) and antenna type (using the IGS naming convention).
• Line 9: Approximate site position in Cartesian coordinates (X, Y, Z) – ITRF (not WGS84) recommended.
• Line 10: Antenna height (measured vertically between ground mark and ARP) and any horizontal offset from the mark (if applicable).
• Line 11-14: For each satellite system, the number and types of observations, here specifying eight observation types for GPS, four for GLONASS, six for QZSS and four for Galileo. The 3-character observation codes include observation type (C = pseudo-range, L = carrier phase, D = Doppler, S = signal strength, X = receiver channel number), band/frequency (range 1-9) and attribute (tracking mode or channel, e.g. C, P, W, I, Q). For instance, for GPS, L1C and C1C are the L1 carrier phase and pseudo-range derived from the C/A code, while L2W and C2W are the L2 carrier phase and pseudo-range derived from Z-tracking (an effective method to acquire the encrypted P(Y) code under Anti-Spoofing conditions). This example only contains code and carrier phase measurements in order to keep the file width manageable.
• Line 15: Signal strength unit (DBHZ = signal-to-noise ratio given in dbHz).
• Line 16: Sampling interval, here 30 seconds.
• Line 17: Comment, here the raw binary data file name (can be placed anywhere between the first and last line in the header).
• Line 18-19: Time of first and last observation epoch, in this case 01:46:00 hours and 05:15:30 (GPS time) on 29 June 2023, respectively.
• Line 20: Receiver clock offset applied (0 = no, 1 = yes).
• Line 21-22: GLONASS slot and frequency numbers, indicating the number of satellites in the list followed by each satellite number and its frequency number (range -7 to +6).
• Line 23-25: Phase shift correction used to generate phases consistent with respect to cycle shifts, stated for each affected satellite system and carrier phase observation code. Here, three observation codes include a correction of -0.25 or +0.25 cycles (blank = none).
• Line 26: Number of leap seconds between GPS time and UTC, here 18.
• Line 27: End of RINEX header indicator.

Figure 5 shows a typical RINEX 3.04 observation data block. It contains the following information:
• Line 28: Date and time of the observation epoch (receiver time of the received signals) in the format year, month, day, ours, minutes, seconds (here 01:46:00 hours on 29 June 2023), epoch flag (0 = OK, 1 = power failure between current and previous epoch, >1 = special event, e.g. 2 = start moving antenna), and the number of satellites in the current epoch (here 15). The special character ‘>’ preceding the epoch information was introduced as an identifier to enable reading programs to easier detect the next epoch in case of a corrupted data file or when streaming observation data in a RINEX-like format.
• Each following line contains the observations from a single satellite, starting with the system identifier and satellite identifier (PRN). In this example, 2 Galileo, 7 GPS, 1 QZSS and 5 GLONASS satellites were observed. The previous length limitation to 80 characters per row no longer applies as this now depends on the observation type list declared in the RINEX header and the available observables per satellite per epoch.
• Line 29: Observations recorded for the first satellite (E02, i.e. Galileo satellite 02) – see line 14 in Figure 4 for the corresponding Galileo observation types in the RINEX header. Each observation value continues to be defined as a float value of total length 14 with 3 decimals (F14.3), followed by two optional single-digit integer records (I1 or blank) representing the Loss of Lock Indicator (LLI) and the Signal Strength Indicator (SSI).
•Line 30-43: Observations recorded for the other satellites in this epoch, with missing observations (or those not observed) indicated as blanks. The interested reader is referred to Romero (2020) for more detailed information on the RINEX 3.05 format.

RINEX 4.00 & 4.01

As the necessary next step for maintaining the suitability of the RINEX format to store GNSS data and measurements into the future, RINEX 4.00 (Romero, 2021) was adopted by the IGS at the 59th Governing Board Meeting on 7 December 2021. This new version is necessary to accommodate the modernised navigation messages from all the different GNSS constellations. Once fully implemented, RINEX version 4 future-proofs the format of the navigation messages, enabling RINEX to properly store GNSS observations, navigation messages and station meteorological data files for the long-term future.

The RINEX 4.00 observation files are backward compatible with RINEX 3.0X and hence there is no issue in the storage and usage of RINEX 4.00 observation files. It provides a few minor extensions in observation types and extended header lines but no major format change, making adoption a minor evolution.

However, RINEX 4.00 navigation files are not backward compatible with RINEX 3.0X files. This is the reason why the RINEX version number was increased rather than utilising another RINEX 3.0X sub-version. But no change is necessary in file naming and storage because navigation files of all types can be stored together in different RINEX versions without any issue. All RINEX files state the version number in the first line and most reader programs will skip over unknown navigation file versions until they are ready to process them. Development has since continued to add some necessary clarifications and new observation codes for upcoming GPS satellites and for L1 NavIC signals, resulting in RINEX 4.01 (Gini, 2023) being released in July 2023. This development has been conducted in collaboration with equipment manufacturers and software generators, ensuring that equipment and software tools able to produce and process RINEX 4.00 & 4.01 files will be available to the GNSS community in due course to enable implementation and broader adoption. More details about the RINEX version 4 format can be found in Gini (2023).

Editing RINEX observation files

Regardless of the RINEX version used, it is important to note that the RINEX header often contains incorrect or incomplete information when initially generated (e.g. the manufacturer’s receiver and antenna names not following the IGS naming convention, a default antenna type or a zero antenna height), so thorough editing is very important in order to avoid confusion further down the track. This particularly applies for data archival, data sharing or submission to third parties (especially where machine-to-machine processes are likely to be employed). Ensuring the correctness of the information in the RINEX header s not only good practice but also very valuable when mining data for purposes that were not envisaged when the data was originally collected.

The RINEX format stipulates the antenna type as a 20-character name (see columns 21-40 of line 9 in Figure 1 and line 8 in Figure 4), including several spaces and ending with a 4-character indication of the radome (antenna cover) used (NONE meaning that no radome is present). The authoritative source for resolving antenna queries are the frequently updated IGS files rcvr_ant. tab and antenna.gra (IGS, 2023c).

The file rcvr_ant.tab details the international naming conventions for GNSS receivers, antennas and radomes, which are also used by online processing services such as AUSPOS. The file antenna.gra provides graphs with physical dimensions of GNSS antennas, including the position of the ARP (generally the bottom of the antenna) and vertical offsets to other features such as the centre of bumper or bottom of choke ring. As an aside, the file igs20. atx, containing the IGS antenna models recommended for baseline processing, can be found at the same location (it is frequently updated to include new antennas). If still in doubt, users should contact their equipment provider for the required antenna information.

If the antenna height was not measured directly and vertically to the ARP in the field, e.g. when using a vertical height hook measurement or a slant measurement to the bumper or the Slant Height Measurement Mark (SHMM) on the instrument, then it must be converted to the vertical distance between the ground mark and the ARP using the offsets and method (generally applying Pythagoras in conjunction with a vertical offset) specified in the GNSS equipment manual or provided by the manufacturer – see Janssen and McElroy (2022) for examples. The correctness of antenna height and antenna type is crucial to allow the correct antenna model to be applied correctly in processing. An incorrect antenna type can introduce significant bias (more than 10 cm in the vertical component) and noise into the computed coordinates. An error in the antenna height will directly translate into an error in the resulting GNSS-derived ellipsoidal height and thus the derived physical (orthometric) height.

If session length is critical to contractual arrangements and/or data acceptance by a third party, it is recommended to always extend session lengths by a few minutes. The start and end of the GNSS observation section in the RINEX file should be visually inspected, particularly to ensure that the first and last few epochs contain reasonably complete data blocks. If epochs at the start/end of the observation are deleted, the time of the first/last observation in the RINEX header should be modified accordingly.

Frequent dropouts of satellite signals from epoch to epoch in the RINEX file may indicate bad data quality due to poor sky view conditions (e.g. tree cover or other obstructions). A longer observation session generally improves processing results in this regard. Note that the raw observation files in their native (binary) proprietary format collected by the GNSS receiver are compact and should always be permanently archived – they can be re-converted to RINEX and edited again if required.

Conclusion

The widely used RINEX format is the international standard for the storage and exchange of GNSS data. It allows efficient and unambiguous archiving of GNSS data and associated metadata in one place, while also facilitating the easy transfer and distribution of such data, independent of the equipment used and the data processing software employed. Over the years, and through several versions and sub-versions, the RINEX format has continually been improved and expanded to cater for modern satellite positioning data collected by a growing number of satellite constellations and their signals.

This paper has presented a brief history of the RINEX format and explained recent RINEX format versions using examples relevant to the surveying profession. This included outlining the short and long RINEX file naming conventions and the editing of RINEX observation files to ensure correctness of the header information. It is hoped that this contribution has helped the surveying profession to better understand the RINEX format, the philosophy behind it, and its benefits to users.

References

Altamimi Z., Rebischung P., Collilieux X., Métivier L. and Chanard K. (2023) ITRF2020: An augmented reference frame refining the modeling of nonlinear station motions, Journal of Geodesy, 97(5), 47.

DCS Spatial Services (2023) CORSnet-NSW, http://www.corsnet. com.au/ (accessed Nov 2023).

GA (2023) AUSPOS – Online GPS processing service, https:// www.ga.gov.au/scientific-topics/ positioning-navigation/geodesy/ auspos (accessed Nov 2023).

Gini F. (2023) RINEX – The Receiver Independent Exchange format version 4.01, https://files.igs.org/pub/data/format/ rinex_4.01.pdf (accessed Nov 2023).

Gurtner W. and Estey L. (2012) RINEX: The Receiver Independent Exchange format version 2.11, https://files.igs.org/pub/data/format/ rinex211.txt (accessed Nov 2023).

Gurtner W., Mader G. and McArthur D. (1989) A common exchange format for GPS data, CSTG GPS Bulletin, 2(3), May/June 1989, National Geodetic Survey, Rockville, Maryland.

Harrison C., Brown N., Dawson J. and Fraser R. (2023) Geocentric Datum of Australia 2020: The first Australian datum developed from a rigorous continental-scale adjustment, Journal of Spatial Science, https:// doi.org/10.1080/14498596.2023. 2184429 (accessed Nov 2023).

Hatanaka Y. (2008) A compression format and tools for GNSS observation data, Bulletin of the Geographical Survey Institute, 55, 21-30, https:// www.gsi.go.jp/ENGLISH/Bulletin55. html (accessed Nov 2023

IGS (2023a) IGS formats and standards, https://www.igs.org/formats-and-standards/ (accessed Nov 2023).

IGS (2023b) International GNSS Service products, https://www.igs. org/products (accessed Nov 2023).

IGS (2023c) IGS file access for rcvr_ant.tab, antenna.gra and igs20. atx, https://files.igs.org/pub/station/ general/ (accessed Nov 2023).

Janssen V., Haasdyk J. and McElroy S. (2016) CORSnet-NSW: A success story, Proceedings of Association of Public Authority Surveyors Conference (APAS2016), Leura, Australia, 4-6 April, 10-28.

Janssen V. and McElroy S. (2022) A practical guide to AUSPOS, Proceedings of Association of Public Authority Surveyors Conference (APAS2022), Leura, Australia, 21-23 March, 3-28.

NRCan (2023) CSRS-PPP, https://webapp. csrs-scrs.nrcan-rncan.gc.ca/geod/tools-outils/ppp.php (accessed Nov 2023).

Romero I. (2020) RINEX – The Receiver Independent Exchange format version 3.05, https://files.igs.org/pub/data/format/ rinex305.pdf (accessed Nov 2023).

Romero I. (2021) RINEX – The Receiver Independent Exchange format version 4.00, https://files.igs.org/pub/data/format/ rinex_4.00.pdf (accessed Nov 2023).

Who am I? I was conceived in 1973, in the lonely halls of a government building in North America. I have a loving father and many uncles, all of them very smart but not known to the general public. I am not your average person. I’m everywhere but invisible to the naked eye. First it was just me, then I had a troubled brother. Now I have several siblings. We don’t always see eye to eye, but we do work well together for the benefit of all. I didn’t have an easy childhood, but now I’m living the American dream… from humble beginnings to world domination. I have a huge ego and enjoy telling people where to go. They say that money makes the world go round, but really it is me because my timing is so good. I was embraced during the 1st Gulf War and have never looked back. As I grew more mature, I lost weight and now I fit into almost anything. This year I’m celebrating my golden jubilee… and I’m not done yet. I’m here to stay. I love being sky-high and on top of the world. I am GPS. Dr Volker Janssen DCS Spatial Services NSW Department of Customer Service Bathurst, Australia