File Loading

File Loading interface

With RINEX-Cli, we support both simplistic and advanced operations.
As probably already mentioned, a single RINEX is not enough for the most advanced applications.
Therefore, this application supports several means to stack RINEX files to build a coherent context.
Only such context we will then process.

Command line interface

The tools support either

• -f to load a single file. File has to be locally accessible.
• -d to load a local directory.

When recursively searching a directory, we will use by default a maximal depth of 5.
This can be increased with--depth if need be.

Both -f and -d can be used any amount of times. This should let you load everything you need easily.

File naming conventions

Note that all our applications accept files that do no follow standard naming conventions.
We may propose interface that will help you generate data that follow naming conventions.

File compression

Our tools support CRINEX natively: you can load compressed Observation RINEX files directly.
For us, it's almost like you loaded readable Observation RINEX.

We also support Gzip compressed files but they must be terminated by .gz so we can determine the Gzip decompression algorithm needs to be applied.

Examples

When identifying RINEX data, it is sometimes easier to do it one file at a time.
In this case -f with a single file is how you do it:

rinex-cli -f test_resources/CRNX/V3/ESBC00DNK_R_20201770000_01D_30S_MO.crx.gz -i -a

When we stack state of the art data like these, we can access fairly advance operations rapidly.
In this example, we have context that is compatible with metric positioning:

rinex-cli \
  -f test_resources/CRNX/V3/ESBC00DNK_R_20201770000_01D_30S_MO.crx.gz \
  -f test_resources/NAV/V3/ESBC00DNK_R_20201770000_01D_MN.rnx.gz \
  -f test_resources/SP3/GRG0MGXFIN_20201770000_01D_15M_ORB.SP3.gz \
  -i -a

Special care when loading Observation Data ⚠️

RINEX-Cli does not really do differential processing yet.
That means, when dealing with Observation RINEX (GNSS signal sampling), the data should come from a unique GNSS receiver. That is uterly important, especially in positioning opmode.

It is not clear yet if RINEX-Cli will provide differential operations in the future.

Easy rule of thumbs to garantee to respect this point:

• either always load your observation files with -f individually
• always put your observations in dedicated folder (-d)

GNSS navigation context

A GNSS compliant context must contain raw signal information and orbital information.
In RINEX format, that means combining OBS RINEX and NAV RINEX.

RINEX-Cli allows loading almost all RINEX formats into the context pool, therefore allows forming navigation compliant context. You can do this by loading different kind of file formats with -f or -d. This is typically used in either QC opmode or Post Processed Positioning opmodes, basically scenarios where we're interested in solving precise positions.

Example:

rinex-cli \
  -f test_resources/CRNX/V3/ESBC00DNK_R_20201770000_01D_30S_MO.crx.gz \
  -f test_resources/NAV/V3/ESBC00DNK_R_20201770000_01D_MN.rnx.gz \
  -i -a

Directory and recursive loading

-d is most convenient when trying to overlap your RINEX Observations with Navigation, Meteo sensors or other datasets.

Being recursive, it is most likely compatible with well organized folders.
In this example, we overlap lazily one file 2023(DOY=254) with an entire set we downloaded from CDDIS

TODO

Process more than 24h of data

All our post processing apps accepts any amount of files.
This means you can load more than 24 hours of data from a given data provider or receiver.
There is not theoretical limitation to the amount of data you can load in a single session.

We have not tested or applied this possible application, we will do that once navigation based on 24h (one rinex set) is fully completed.

Precise Products

This ecosystems supports both Orbital precise products (SP3) and time domain (Clock RINEX) precise products. Loading them allows forming a PPP compliant context.

When loading files, you don't have to care about their nature, simply use the previous options.

⚠️ in theory precise products should never be mixed. You should always use precise products that were published by the same agency (using consistent algorithms). But that may truly apply only to the utmost precise applications.

SP3: precise orbital product

You can load SP3 products with -f or -d as previously described.

Adding SP3 to the context will enable several new possibilities

Clock RINEX: precise time domain product

You can load CLK products with -f or -d as previously described.

Adding CLK to the context will enable several new possibilities