The Settings > X-pos > General page of the Administrator Portal allows administrators to manage the main general settings related to the X-pos services provided to Users through SBC.
In section “X-pos Server”, the configured X-pos server is displayed next to the section title (to edit it, Settings > Preferences > Infrastructure). In this section, administrators can decide whether to make RINEX, VRINEX, Computation and Transformation Services available to users on SBC User Portal. Service activation also triggers the checkout of related X-pos licenses. Please check help page Software License Options for further details. Moreover, the retention times for the results of each of these services can be set, and some other service-specific parameters can be set. Four checkboxes are provided in the Settings > X-pos > General page of the Administrator Portal, one for each of the X-pos services: RINEX Download, Virtual RINEX, Coordinate Computation and Coordinate Transformation. By flagging the corresponding checkbox, an X-pos service can be enabled for usage and made available in SBC User Portal, as long as a suitable license exists for it. Each of the X-pos services can be independently provided to Users. The availability of the Virtual RINEX service is tied to the availability of the RINEX one: if the RINEX Download service is disabled, then the Virtual RINEX one cannot be enabled. Another prerequisite for Virtual RINEX is the so called Netcorrection data which is derived from Spider Network processing and pushed the X-pos repository as well. The forwarding of Netcorrection data from Spider to X-pos can be configured on the Spider Network Server under Tools > Configuration > Status. Refer to the Spider help for further details.
Each service also has a dedicated retention bar, through which Administrators control the availability over time of the X-pos results. A retention period of 1 to 390 days can be set: results older than the retention date will be removed from the Results page of SBC User Portal. A message displayed under each retention bar, and also on the X-pos Result pages on the User Portal, informs about the oldest date for which results will be available, according to the position of the cursor in the bar. The retention date can be different for each of the X-pos services. For this reason, the additional message is displayed under each Results tab in the User portal, so that users are aware of the retention date which was set by the administrator for each of the X-pos services.
In addition to what illustrated so far, the Settings > X-pos > General page of the Administrator Portal also allows administrators to choose basic processing parameters which will be used in the Coordinate Computation. First, the GNSS constellations considered in post-processing can be set, choosing between GPS, GLONASS, Galileo, BeiDou and QZSS. As default, GPS and GLONASS are checked.
If no box is selected, then all constellations contained in the rover data uploaded by users will be automatically used.
Also, the minimum cut-off angle can be controlled via the Coordinate computation related settings section; valid range is from 0 to 90°. The default value is 10°.
In case some satellites are known to be unhealthy or other issues come up, it is possible to disable certain satellites, by simply listing them separated by commas (e.g.: G02, G05, R09, C21, E11) and these will not be involved in the coordinate computation. QZSS constellation is not supported at this time.
Changing the Satellite Systems and cut-off angle, as well as disabling certain satellites, are actions to be recorded and displayed in the Audit Log.
Settings "Minimum Number of Reference Sites", "Maximum Number of Reference Sites" and "Maximum Distance to Reference Sites" can be used to customize the selection rules for reference sites involved in a Coordinate Computation, so that the site selection algorithm is more adaptive to the real characteristics of the used reference network.
The “Keep coordinate computation project” files checkbox can be used to decide if the computation project files should be saved or discarded. By default, the computation project file is deleted after coordinate computation is done. If the checkbox is flagged, the project file and results folder are kept in the X-pos Repository, to a path structured as follows: [file repository root]/yankee/[userid]/CoordinateComputation_[Timestamp]_[ccid].Please consider that this option requires more disk space and it is only recommended in cases where advanced post processing (e.g. with Leica Infinity) is necessary. If the administrator unmarks the "Keep" checkbox, the "yankee" directory will be present anyway, but empty.
If the “Enable Coordinate Computation Service” checkbox is not flagged, the Coordinate Computation related settings are not visible either.
The X-pos Repository is the place where RINEX data of all reference sites and network correction data, as well as the results of RINEX and Virtual RINEX Requests, Coordinate Computations, and Coordinate Transformations are stored. Each set of results is organized in its own dedicated folder. The naming convention for such folders follows the NATO phonetic alphabet starting from z.
| Folder Name | Stucture | Content |
|---|---|---|
| zulu | zulu\{Date}\{SiteId} |
Zipped RINEX files generated by the X-pos file products configured in Spider Site Server and pushed to the X-pos 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” checkbox is flagged in Administrator 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 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 Spider QC. 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 Administrator Portal Settings > X-pos > General, in the “X-pos Repository” section.
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 repository can be managed using three different Storage Types:
Depending on the Storage type different settings have to be adjusted. (see details below).
The “RINEX data retention” available in the “X-pos 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.
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.
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 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:
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 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 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:
X-pos supports different means of authenticating against Azure to provide most flexibility.
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:
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.
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: