SBC Online Help
SBC Online Help
Breadcrumbs

Data Storage

X-pos Data Repository

The X-pos Data Repository is the place where RINEX data of all reference sites and network correction data, as well as the results of RINEX Data and Virtual RINEX Requests, Coordinate Computations, and Coordinate Transformations are stored. Each set of results is organised in its own dedicated folder. The naming convention for such folders follows the NATO phonetic alphabet starting from z.

Folder Name

Structure

Content

zulu

zulu\{Date}\{SiteId}

Zipped RINEX files of 15-minute file length generated by the X-pos file products configured in Spider Site Server and pushed to the X-pos Data Repository.

Data requested by users via the RINEX request service is taken from this folder.

yankee

yankee\{Date}\{UserID}\{CoordComputationID}\Result

Results of the requested Coordinate Computations, i.e. a Computation.txt file summarizing the point, occupation and baseline results after the post-processing.

If the “Keep coordinate computation project files” slider is toggled in SBC Portal > Settings > X-pos > General, the Infinity project file (.iprj) used for the computation is contained in the {CoordComputationID} folder.

xray

xray\{DateOfRequest}\{UserID}\{VRINEXRequestID}

Results of the requested Virtual RINEX files:

  • Requested zipped Virtual RINEX file.

  • Log folder containing the Processing.log file, which summarizes all steps and information regarding the request.

whiskey

whiskey\{Date}\{ClusterID}

NetCorrection data pushed to X-pos*. This is made of two elements for each of the sites participating to the network processing:

  • zipped folder containing the actual netcorrection data (hatanaka-compressed) and the navigation files;

  • gzipped xml file informing about the network fixing status, for each GNSS constellation.

*each cluster gets a new ID not only when created from scratch, but also every time the network processing is restarted on the Spider Network Server.

victor

victor\{Date}\{UserID}\{RequestID}

Zipped concatenated RINEX created consequent to a RINEX Request with the Merging option enabled.

Log folder containing a logfile with information about the processing (required for the merging and, if applicable, for the decimation of the observation rate).

uniform

uniform\individual\X-pos_{SiteID}_SiteName_MarkerName\{Date}\{SiteID} AND uniform\web

If the Leica SpiderQC integration is enabled by System Administrators on Spider Business Center, this folder is contained in the X-pos Data Repository and is made of the following subfolders:

  • individual folder: only populated if the "Store individual QC report files" option is enabled in Leica SpiderQC settings for the automatic quality check; otherwise blank. If populated, it contains site-specific quality check reports generated by Leica SpiderQC, for all X-pos sites.

  • web folder: contains the quality check output from Leica SpiderQC. Supported languages and type of output depend on the automatic quality check and web output settings, configured on Leica SpiderQC before enabling the integration with Leica SpiderQC on Spider Business Center.

The repository location is initially set during the installation of the X-pos service. Information will be exchanged between the X-pos server and SBC once the connection is established. Hence, it is possible to redefine the X-pos Data Repository location by changing the settings through the SBC Portal Settings > X-pos > Data Storage.

Editing the Storage Type or Root Path will change the push location. Files created before the change will still be available at the old location, but will be no longer be considered for any X-pos service requests. The data migration to a new X-pos Data Repository is not supported.

The X-pos Data Repository can be managed using three different Storage Types:

  • Local Disk

  • Windows Network Drive

  • S3 Compatible Storage

  • Azure Blob Storage (with different authentication modes)

Depending on the Storage type different settings have to be adjusted. (see details below).

The “RINEX data retention” available in the “X-pos Data Repository” section controls the availability over time of RINEX Data in the X-pos Data Repository. This also includes the so-called network correction data required for Virtual RINEX generation. A retention period of 1 to 390 days can be set: data older than the retention date will be removed from the X-pos Data Repository. A message displayed under the retention bar informs about the oldest date for which data will be available. The default data retention is 90 days.

Local Disk

The “Root Path of X-pos Data Repository” when choosing Local Disk option has to be expressed as an absolute path on the machine running the X-pos Server, e.g., “c:\GNSS Spider\X-pos\Data\”. The account under which the X-pos service is running (default: Local System) needs to have full access rights on this path.

Windows Network Drive

The “Root Path of X-pos Data Repository” when choosing the Windows Network Drive option has to be expressed as a Universal Naming Convention (UNC) path. A UNC path requires the full name of the machine on which the X-pos Data Repository is located and the path as it is expressed in the following example: “\\mycors-nas\x-pos\”.

Once this format is recognized, the checkbox “Connect using different credentials” appears. The username and password, which are often required to authorize access to network folders, can be entered here.

Please refer to the “Leica Spider Suite – Installation Guide” for best practice advices on using Network Drives”.

S3 Compatible Storage

S3 Compatible Storage is a storage solution that allows access to and management of the data it stores over an S3 compliant interface. The storage is called bucket. Various cloud service providers offer such S3 compliant interfaces, e.g., Amazon Web Services.To use S3 Compatible Storage an account at the service provider is required. The service provider will have to provide the following four pieces of access information:

  • Host: The hostname/endpoint required to access the storage bucket, e.g. http://10.60.10.102:9000

  • Key: Equivalent of a Username

  • Secret: Equivalent of a Password

  • Root Path: Path of the X-pos Data Repository within the bucket

The Host, Key, and Secret are required to gain authenticated access to the bucket. The Root Path is then required so that the specific file location of the X-pos Data Repository is known.

When selecting the S3 Compatible Storage option, Leica SpiderQC integration with X-pos cannot be used. A corresponding warning message will be displayed. As soon as the S3 storage option is saved, the SpiderQC integration is automatically disabled if it was enabled before.

Azure Blob Storage

Azure Blob Storage is a storage solution that allows storing data within the Microsoft Azure Storage Account services. Blob Storage offers three types of resources: the storage account, a container, and a blob. For more details, see the Microsoft page.

When selecting the Azure Blob Storage related options, Leica SpiderQC integration with X-pos cannot be used. A corresponding warning message will be displayed. As soon as any of the Azure Blob Storage options are saved, the SpiderQC integration is automatically disabled if it was enabled before.

All interactions from X-pos to write, read and cleanup files in this storage will result in API calls against the service which are also billed by Microsoft beside the stored data itself. The number of operations directly correlates with the number of sites providing data, and the usage of X-pos itself. To avoid unexpected costs, setting up cost monitoring in Azure is highly recommended.

To ensure all users can download files from the Azure storage directly, you need to configure "Resource sharing (CORS)" correctly: Add rules for the "Blob service" with:

  • Allowed Origins: Set it to the public domain or IP downloads should be possible (typically your SBC Domain. Use "null" to allow downloads from localhost. Use "*" to allow downloads from all domains.

  • Allowed Methods: Select "GET", "OPTIONS", and "HEAD"

  • Allowed headers: *

  • Exposed headers: *

  • Max age: 60

X-pos supports different means of authenticating against Azure to provide most flexibility.

Shared Key

Shared Keys, or Access Keys, are one of the simplest ways to ensure access to the storage account.

The following settings are needed for this configuration:

  • Service URI: A Uri referencing the blob service. This is likely to be similar to "https://{account_name}.blob.core.windows.net". It can also be customized.

  • Storage Account Name: This name is used to authenticate against Azure. This is not a personal credential but must be the "Storage account name" as listed in the "Access Keys" section in the Azure Portal.

  • Key: This is the key used to authenticate against Azure.

  • Container: The name of the container within the Azure Storage Account to be used to write files. This container must exist and will not be created automatically to avoid misconfigurations.

Access to the shared key grants a user full access to a storage account’s configuration and data. Therefore, it should be carefully limited and monitored. For security reasons, using Azure Key Vault to manage access keys is recommended, along with regularly rotating and regenerating keys. Manual key rotation is also possible. This means that the key should be updated regularly.

In general, it is advisable to grant granular access to data with the least privileges necessary. For this reason, using Managed Identity is more favorable.

Managed Identity

If your Virtual Machine where X-pos is running, has a Managed Identity assigned, this identity can also be used to authenticate against the storage account.

The identity must be visible to the whole Virtual Machine as the X-pos Windows Service is running under the "Local System" account and changing this setting is not recommended.

Ensure that this service principal has the full access to manage all the files within the containers which is typically granted by the "Blob Storage Contributor" role.

The following settings are needed for this configuration:

  • Service URI: A Uri referencing the blob service. This is likely to be similar to "https://{account_name}.blob.core.windows.net".

  • Container: The name of the container within the Azure Storage Account to be used to write files. This container must be existing and will not be created automatically to avoid misconfigurations.