The result of the data processing used to produce the estimate. If not success, ignore the remainder of the estimate information.

Estimate calculation source identifier. In multi-function engines like HPE, calculations can be handled by various calculation functions. This source identifier provides an analytical characterization that enbles a deeper understanding of how the data is processed. Identifiers can include terms like 'hybrid', 'agnss', 'celldb', 'ecid', tdoa, rf-base1, rf-base2, slam, etc. Terms are not constant and may be substantially different across systems using this XID struct.

The last observation type used to create the estimate. In multi-type observables, multiple estimates will be generated with the last estimate usually indicating the last estimate use. If estimated simultaneously, then the obstype will be the dominant observations (one with the most obversations and/or least uncertainty). If there is no dominance, then the observation type is 'undefined'.

Tic count of the estimate. For single transaction sessions, the tic count is always 0. For multi-transaction sessions, the tic-count will be monotonic increasing.

Epoch defines the point in time for which the estimate applies.

Veracity defines the validity of the measurement in the range between 0 and 1. A high score means the estimate is deemed valid and more reliable than a lower score. If no veracity scoring is performed, this will have a value of -1.

The estimate confidence. This is the confidence level associated with the uncertainties specified within the shape (e.g. Spheroid). Valid range is 0.0 to 1.0. Typical values are 0.5 (50% CEP), 0.6827 (1 Std. Dev.), 0.9545 (2 Std. Dev.), 0.9973 (3 Std. Dev.). For example, a confidence of 0.6827 and Spheroid horizontal uncertainty of 10 meters means the about 68% of the time the estimate will be within 10 meters horizontally to the true position.

The estimate shape result. In HPE, the particular shape is determined by the preferred shapes specified in the BeginCalculation. For other systems, the shape provided here is based on an external consideration. Typically only the common spatial types are used: Circle, Ellipse, Spheroid, and Ellispoid shape types.

Optional floor number if availble. Floor number are specified by local venue mapping floor index. As general guideline, 0 denotes the ground-level floor. Negative values denote floors underground. Ideally, numbers should be linear and not have jumps common with many building label schemes (e.g. floor 13 is not present). The floor number may be a calculated quantity derived from multiple data sources, which may result in partial floor estimtes (e.g. returns floor 2.5). The floor number is useful for indexing data. See floorLabel for a descriptive floor identifier.

Optional descriptive floor label if available. Floor labels are useful to provide a floor specifier not readily indexed like floor number. Examples include 'Lobby', 'Parking 1', 'Parking 2', 'Mezzannine 1', '12', '14', 'Observation Deck', etc. In cases where the result is between floors, the floor label may specify a compound label such as 'P1/P2' if supported.