A Generic, Extensible Data Model for Trajectory Determination Systems

Jos

e A. Navarro

, M. Eul

alia Par

, Ismael Colomina

and Marta Bl

azquez

Centre Tecnol

ogic de Telecomunicacions de Catalunya (CTTC/CERCA),

Av. Carl Friedrich Gauss, 7. Building B4, 08860 Castelldefels, Spain

GeoNumerics, S. L., Av. Carl Friedrich Gauss, 11. Building B6, 08860 Castelldefels, Spain

Keywords:

Data Model, Generic, Extensible, Trajectory Determination System.

Abstract:

Trajectory Determination Systems (TDS) use the measurements delivered by sensors to estimate trajectories.

Many are the types of sensors that may be used already by such systems and new ones appear constantly in

the market. Variety and fast change pace pose a problem for the maintenance of any kind of software system,

including TDSs. Some data models and / or standards dealing with sensor data exist, but these are either too

generic (and ambitious) or, on the contrary, targeted at very speciﬁc types of observations (as, for instance,

GNSS.) This paper introduces a compact but complete, generic and extensible data model powerful enough as

to deal with the kind of observations involved in trajectory determination and able to alleviate or even eliminate

the software maintenance toll derived by constant changes in data sources. Two materialization of this data

model, its ﬁle and network interfaces are brieﬂy presented here as well as a portable C++ library implementing

such interfaces.

1 INTRODUCTION

Trajectory Determination Systems (TDS) (Titterton

and Weston, 2004), at least in the context of this pa-

per, are software applications that compute trajecto-

ries using the measurements provided by one or, more

usually, several sensors, being a trajectory the path of

a moving object. TDSs are becoming more and more

used in several areas, as for instance precision agricul-

ture (Karpowicz, 2016; GSA, 2015), unmanned air-

craft navigation (Colomina and Molina, 2014), indoor

positioning (Zhu et al., 2014) or even autonomous ve-

hicle driving (Minh, 2014), among others. Normally,

these applications need not a single sensor but a set

of these to deliver satisfactory results because of the

degree of complexity that some navigation scenarios

may reach.

At the same time, sensors, the data sources used

by TDSs, evolve very quickly (Groves et al., 2014a;

Groves et al., 2014b). New ones appear on the mar-

ket, others are improved. TDSs must adapt quickly

too to these changes to maximize their potential to

derive quality trajectories; this is especially true in

very competitive markets. These new or improved

sensors must be modelled and integrated into the TDS

minimizing delays as much as possible. This poses a

problem showing different facets: scientiﬁc, software

engineering and interfaces. Although this applies to

any software system in general, one possible solution

is to develop TDSs that may be extended easily, as

for instance NAVEGA (Par

es and Colomina, 2015).

In this TDS, the internal estimation engine or exter-

nal data interface have been designed in such a way

that including new models or data types implies no

changes in the software. RIFE (Soloviev and Yang,

2013) uses a similar approach. Another example of a

generic TDS is the FLY and SPIDER suite (Marietta

et al., 2015).

Extensibility has long been the target of several

contributions in Geomatics (Tscherning, 1978; Elas-

sal, 1983; Sarjakoski, 1988; Crippa et al., 1989;

Colomina, 1992). However, it is surprising to see

how little the problem of generic data interfaces

has been treated. The works on ISO standards in

this area (Kresse and Fadaie, 2004) are loosely re-

lated to the problem tackled here. Very recently,

though, the UAID generic sensor interface for plug-

and-play navigation systems (Soloviev et al., 2016)

refers to the Defense Advanced Research Project

Agency’s (DARPA) ”ASPN Interface Control Docu-

ments” whose aim is the development of techniques

to integrate low cost sensors under the umbrella of a

plug & play architecture. DARPA’s interest in this

topic should conﬁrm its relevance.

There exist several standards covering sensor and

observation data models as those from the Open GIS

Navarro, J., Parés, M., Colomina, I. and Blázquez, M.

A Generic, Extensible Data Model for Trajectory Determination Systems.

DOI: 10.5220/0006258400170025

In Proceedings of the 3rd International Conference on Geographical Information Systems Theory, Applications and Management (GISTAM 2017), pages 17-25

ISBN: 978-989-758-252-3

Consortium (OGC, 2007; OGC, 2013). The scope,

however, of these is too wide, their proposal too com-

plex to achieve efﬁciently the goals of this work. Data

or metadata ﬁles written according to these recom-

mendations would be far too complicated for the reg-

ular TDS user. On the other side, standards covering

data for speciﬁc sensors also exist, as the RINEX for-

mat (and its relatives, ANTEX, IONEX and SP3) for

GNSS measurements (IGS, 2013) or the LAS format

for point clouds derived from laser scanning (ASPRS,

2009). But since these formats are targeted at speciﬁc

sensors, it is not possible to use them as the base of a

generic data model.

The aim of this paper is to introduce ASTRO-

LABE, a generic, extensible and complete but con-

cise data model speciﬁcally targeted at TDS data and

metadata, able to cope with change and innovation.

The development of ASTROLABE started in 2009

at the former Institute of Geomatics and, since 2014,

it has been continued at the Geomatics Division of

CTTC with the cooperation of GeoNumerics. There

exist two translations of this data model that are ma-

terialized as a ﬁle and a network interfaces as well as

a portable library written in C++ implementing these.

Further sections of this work will describe these com-

ponents.

2 THE ASTROLABE DATA

MODEL

ASTROLABE means to be complete. In this con-

text, this means that all the aspects related to data

must be taken into account so no assumptions about

their properties need to be done. We are talking about

metadata, a very important facet that, unfortunately, is

often neglected. ASTROLABE takes care of deﬁning

both data and related metadata. Examples of metadata

might be the units used in measurements or the coor-

dinate reference systems these are referred to. The

following sections will describe (1) how data is mod-

elled to achieve genericity and extensibility and (2)

how metadata is speciﬁed to fulﬁll the completeness

goal.

2.1 About Data

The determination of a trajectory, as any other pro-

cess, takes some inputs, performs some kind of pro-

cess and then delivers some outputs. (Previous) states,

observations and instrument data are the inputs in the

case of ASTROLABE. Models represent the process

while (new) states are the outputs. More formally

these are the pillars on which the data model relies:

• Instrument (a.k.a. sensor.) Device used to mea-

sure some observable, thus delivering observa-

tions. ASTROLABE deﬁnes an instruments as the

set of constants that characterizes it. A GNSS re-

ceiver is a typical example of instrument.

• Observable and observation (a.k.a. measure-

ment.) An observation or measurement is one of

the values that an observable may take. An ob-

servable is a numerical property of a physical sys-

tem that may be measured. Technically, it is a ran-

dom variable. An example of observable in this

context is a linear acceleration; the corresponding

observation or measurement could be 12 m/s

• (Mathematical) model. Mathematical description

of a process. The logic that transforms previous

states and observations into new states (see be-

low.) Mathematical models are not data by them-

selves, but are included here for the sake of com-

pleteness and coherence in the description of the

data model. Model identiﬁers, however, are used

in observation equations (see below) to relate ob-

servations, instruments and models themselves to

describe how to estimate states.

• States. States are also random variables that have

to be estimated from known (former) states and

observations, instruments and mathematical mod-

els. Typical states in the context of TDSs are po-

sition or attitude random vectors.

• Observation equations. These relate observa-

tions, instruments, models and states. Observa-

tion equations describe how a new state is ob-

tained, specifying both the necessary inputs (for-

mer states, observations and instruments) and the

necessary procedures (the mathematical model.)

From the structural standpoint, observations and

states are identical in ASTROLABE. The obvious dif-

ference is that while observations contain measure-

ments, states hold the result of a computation. There-

fore, the description of observations below is valid for

these two entities.

These are the components integrating an obser-

vation (in fact, any kind of observation in ASTRO-

LABE:)

observation: (event tag, active ﬂag, identiﬁer, instance

identiﬁer, time stamp, tags, expectations, covariance matrix)

The event tag is a marker to tell apart the different

data entities making the ASTROLABE data model, as

observations or observation equations; the active ﬂag

is used to activate (or deactivate) the observation so

it is taken or not into account when computing states

(this is the way to avoid the actual removal of the ob-

servation from a data ﬁle, for instance, and still be

GISTAM 2017 - 3rd International Conference on Geographical Information Systems Theory, Applications and Management

able to ignore it.) The identiﬁer is an unique code stat-

ing the type of the observation (is this an IMU model

x or an odometer model y?) The instance identiﬁer

is used to tell apart different instances of observations

of the same type—sharing the same identiﬁer; for in-

stance, if two or more identical sensors (e.g., odome-

ter model w) are used in an observation campaign, the

observations coming from these will share the same

identiﬁer (since all of them come from the same kind

of odometer) but will have different instance identi-

ﬁers (to tell apart the different odometers.) The time

stamp contains the time when the observation was ob-

tained. The tags are a set of values that, despite not

being an intrinsic part of the observation, help to com-

plement it. For instance, some barometers may be

affected by temperature; collecting the value of this

observable at the moment the pressure was measured

will improve the estimation of the output state. Ob-

viously, barometers do not measure temperature; this

is the reason why such magnitude plays the role of a

tag in this observation. Note that tags are optional. Fi-

nally the values of the observation themselves (the ex-

pectations) and their covariance matrix complete the

deﬁnition of the observation.

Providing that the error distribution of (whatever

the) observations adheres to a Gaussian distribution, it

will be possible to model them using the above struc-

ture. To be precise, Gaussian error distributions are

a requisite set by CTTC’s TDS, NAVEGA. ASTRO-

LABE, in fact, supports a broader range of error prob-

ability distributions including all those for which the

ﬁrst and second moments exist.

The following is an example of observation:

l imu1 1 124.88 0.01 0.02 0.015 0.32 0.43 9.95

1e-3 1e-3 1e-3 1e-2 1e-2 1e-2

The ”l” marker denotes an observation; imu1 is

the identiﬁer of the observation, pointing to some kind

of inertial measuring unit; 1 is the instance identi-

ﬁer for this observation; if there were data coming

for more (identical kind of) IMUs in the dataset, this

instance identiﬁer would tell these apart. The value

124.88 is the time tag. There are no tags. The re-

maining values in the ﬁrst line above stand for the

linear accelerations and angular velocities typically

measured by IMUs. All the values in the second line

stand for the covariance matrix of the observation (in

this case, only standard deviations, no correlations.)

Note that the active ﬂag is not shown in the example.

In the next example, the following could be two

valid observation corresponding to two identical tem-

perature compensated barometers used simultane-

ously:

l tc_baro 1 124.88 25.4 1020.003 1.3

l tc_baro 2 124.88 25.3 1020.532 1.3

Focusing on the ﬁrst of these two observations, the

identiﬁer tc baro indicates the new kind of obser-

vation. Again, 1 is the instance identiﬁer; the time

stamp is again 124.88. Note that this observation

has a single tag, a temperature value, which for this

case is 25.4. The actual pressure value is 1020.003

and its standard deviation is 1.3. The values for the

second barometer (second observation) differ slightly

from those provided for the ﬁrst one. The important

thing, however, is that the instance identiﬁer for the

second barometer is 2 and not 1, so it is possible to

tell apart the observations originating in different sen-

sors.

To ﬁnish, the following could be an example of a

position observation (longitude, latitude, height) re-

trieved from a GNSS receiver. No explanations (be-

sides the fact that there are no tags in the observa-

tion) are given; all the components of the observation

should be now clear to the reader.

l gnss_b 3 124.88 2.0003 41.0008 32.4

3e-2 3e-2 2e-1

Note how easily three completely different kinds

of observations have been represented using the AS-

TROLABE data model.

As stated above, states adhere to the same struc-

ture just described, so this issue will be no further

discussed. Instruments are deﬁned using the same

structure too. The main difference in this case is that

instruments are considered as constants and their val-

ues, therefore, immutable. Their covariance matrices

are interpreted as a mere indication of the quality of

the constants deﬁning the instruments.

The structure of an observation equation is the fol-

lowing:

observation equation: (event tag, activation ﬂag, time

stamp, model identiﬁer, list of state instance identiﬁers, list

of observation instance identiﬁers, list of instrument

instance identiﬁers)

The meanings of the event tag, activation ﬂag and

time stamp ﬁelds have already been deﬁned above.

However, the event marker for observation equations

is a lowercase letter ”o” (instead of ”l”.) The model

identiﬁer points to the actual mathematical method to

use to estimate a state out of the previous states, ob-

servations and instruments involved in the equation.

Note the use of instance identiﬁers instead of mere

identiﬁers. Doing so it is possible to refer to observa-

tions that, despite being of the same type, come from

different actual sensors. The following could be an

example of observation equation involving the imu1

and gnss b observations seen in the examples above:

o 124.88 compute_position 101 1 3

Again, the active ﬂag has been omitted. o is the

event marker and compute position corresponds to

A Generic, Extensible Data Model for Trajectory Determination Systems

the name of the model that will perform the transi-

tion from observations to states. The state that will be

computed is the one pointed by the instance identiﬁer

101 and to do it, the model will use the observations

whose instance identiﬁers are, respectively, 1 and 3.

There are no instruments constants involved in this

observation equation (these are optional.)

Observation equations may be seen as triggers, or

the call to methods / routines specifying the set of in-

put parameters needed to derive the output ones.

Finally, data is organized in different datasets (ei-

ther disk ﬁles or network data streams.) Observations

and observation equations go together in the observa-

tions data set; instruments constitute a separate one;

output states are stored in their own dataset too.

2.2 About Metadata

The different examples shown in section 2.1 are

clearly incomplete. The values related to time stamps,

tags, expectations or their covariance matrix are not

well deﬁned. For instance, there is no information

about the units used to express these magnitudes. Still

further, there is no hint about reference frames or co-

ordinate systems. Consequently, for instance, it is im-

possible to know if the temperature tag that accom-

panies the pressure reading delivered by the compen-

sated barometer in the examples above is expressed in

degrees Celsius or Fahrenheit.

ASTROLABE provides with metadata for all the

data entities described in section 2.1—but observa-

tion equations, since these merely relate data entities.

Additionally, metadata for time values (necessary for

time stamps) are also provided. Metadata are always

stored in XML ﬁles.

Below, the description of the several ﬁelds in-

cluded in metadata are presented, separated by the dif-

ferent kinds of data entities found in the data model.

Note that mathematical models are also characterized.

Observations and States. Metadata for these two

data entities are identical. These are the items in-

cluded:

Identiﬁer. Unique code used to tell apart differ-

ent kinds of observations or states. By means of

this code, it is possible to relate actual observa-

tion or state data (which include the identiﬁer)

to the metadata that characterize them.

Dimension. Number of elements in the observa-

tion or states expectations vector.

Referencing. Code (or pairs of codes) identify-

ing either the coordinate reference frame or ref-

erence frame plus coordinate system to which

data is referred to.

Units. Used to state the units of each of the ele-

ments in the expectations vector (for observa-

tions or states.)

Default Covariance Matrix. Default covariance

matrix for the expectations vector (observations

or states.) Used when an observation (or state)

includes no explicit covariance matrix values.

This happens when a sensor does not provide

covariance information and a default nominal

value (usually stated by the manufacturer) must

be used instead. The units are those of the ex-

pectations vector (for the standard deviations.)

This is an optional metadata ﬁeld.

Scale Factors. This optional ﬁeld contains a list

of positive scale factors for the standard devia-

tions. When not present, all scale factor values

default to 1.

Tag Metadata. This ﬁeld is optional, as tags are.

When present, the following items must be de-

scribed:

• Number of tags.

• For each of these tags, the units and the ref-

erencing information (see above) must be in-

cluded.

Instruments. Some of the metadata ﬁelds charac-

terizing an instrument have already been deﬁned

when describing observation and state metadata.

Therefore, these will not be described again.

Identiﬁer. See observation / state metadata.

List of Instruments Constants. For each con-

stant used to characterize the instrument, the

following items must be clearly stated:

Type. The constant may be either a scalar or a

matrix. In the case of matrices, their dimen-

sions must also be speciﬁed.

Referencing. See observation / state metadata.

Units, Default Covariance, Scale Factors.

See observation / state metadata.

Models. When describing a model in ASTROLABE,

the speciﬁcation of its signature (input and output

parameters) is given. In other words, the descrip-

tion of models exactly corresponds to the structure

of observation equations (see section 2.1,) where,

besides the model identiﬁer, the list of observa-

tion, instrument and state identiﬁers are provided.

The metadata items that must be speciﬁed are:

Identiﬁer. Unique code identifying the model.

List of States. The identiﬁers pointing to the

states that will be needed by the model. Each

state includes a sub-item, namely the role, to

deﬁne whether the state will be just read (con-

stant role) or estimated (free role.)

GISTAM 2017 - 3rd International Conference on Geographical Information Systems Theory, Applications and Management

List of Observations. The identiﬁers of the ob-

servations used by the model to derive one or

more states.

List of Instruments. The identiﬁers of the in-

struments that intervene in the estimation of the

output states. This list is optional (as it is when

writing observation equations.)

Time. All the time stamps in ASTROLABE datasets

refer to the same coordinate reference frame and

use the same units for simplicity reasons. A single

speciﬁcation for time stamps is therefore needed.

The items to describe are:

Units. See observation / state metadata.

Referencing. See observation / state metadata.

Figure 1 depicts the actual speciﬁcation of meta-

data for an observation (lines 1–28, l spec XML tag,)

a state (lines 29–52, p spec XML tag,) a model (lines

53–72, m spec XML tag,) and an instrument (lines

73–105, i spec XML tag.) No metadata for time

(stamps) has been included in this example.

3 THE FILE AND NETWORK

INTERFACES

The data model described in section 1 has been ma-

terialized in two different interfaces, namely the ﬁle

and network ones.

3.1 The File Interface

The ﬁrst materialization of the ASTROLABE data

model uses ﬁles to store datasets. There are several

kinds of ﬁles included in this interface. The most im-

portant ones are observation, instrument and state data

ﬁles as well as metadata ﬁles (see section 2.2.)

Observation ﬁles contain a sequenced series of ob-

servation and observation equations records. In the

context of the ﬁle interface, observations are referred

to as ”l-records” (due to the event marker, ”l”, used to

tell them apart of observation equations.) Observation

equations are referred to as ”o-records.” Figure 2 de-

picts a text, XML materialization of an observations

ﬁle (note that line numbers are not part of the ﬁle.)

In this example, the event tag corresponds to

the XML tag name; therefore, <l> tags describe l-

records (observations) while <o> tags correspond to

o-records (observation equations.) Only one of the

records in the ﬁgure show the active ﬂag. It is the

”s” (status) attribute (see line 1.) It may take two val-

ues, ”a” (active) or ”r” (removed.) If the active ﬂag is

omitted, the l- or o-record is assumed active.

Both the observation and model identiﬁers used

in observations and observation equations are repre-

sented by the ”id” attribute. For instance, in line 1

the observation identiﬁer is ”baro1”. The observation

equation in line 6 involves the model whose identiﬁer

is ”pva1 d”.

In this dataset the observations collected by two

different barometers of the same type are shown. The

observations in lines 1, 10 and 19 correspond to a

kind of observation whose identiﬁer is ”baro1,” so

they share the same type. But the ones in lines 1 and

19 come from one speciﬁc barometer whose instance

identiﬁer or ”n” attribute is 32, while the observation

in line 10 was obtained from a different one, with an

instance identiﬁer equal to 33.

The observations related to (temperature compen-

sated) barometers have one tag each (the temperature)

whose values are 23.44, 23.45 and 23.45 respectively.

The remaining kind of observations have no tags. In

all cases, the covariance matrix includes the standard

deviations only (so the assumption is that correlations

are equal to 0 in all cases.)

Three different models are used by means of ob-

servation equations. See for instance lines 6 to 8,

where three observation equations may be observed.

There, it may be seen that the models used are

those whose identiﬁers are, respectively, ”pva1 d”,

”imu1 bias d” and ”height update.” The observation

equation in line 6 involves two states whose instance

identiﬁers are respectively 27 and 11. To do it, it uses

only an observation of type ”imu1” whose instance

identiﬁer is 41; no instruments are included in this

equation.

Instrument Files. Contain the data deﬁning the

characteristics of the different instruments used in a

dataset. Since the structure of the instrument data en-

tity is the same than the one used for observations,

l-records are employed to materialize instrument in-

formation. Thus, an instrument ﬁle contains a series

of l-records. Although no example is provided to de-

pict such ﬁles, Figure 2, showing observations, may

be used as reference. Note, though, that o-records do

not exist in instrument ﬁles.

State Files. The output, estimated trajectory

which consists of a sequenced series of states, im-

plemented as l-records once more. No o-records are

present in state ﬁles.

Metadata Files. These are used to fully character-

ize the different entities integrating the ASTROLABE

data model. See Figure 1 for an actual example of a

metadata ﬁle.

Metadata ﬁles are always stored in XML format;

on the contrary, data ﬁles may be stored in either text

(XML) or binary formats. Binary ﬁles are recom-

A Generic, Extensible Data Model for Trajectory Determination Systems

001 <l_spec s="a">

002 <type> baro </type>

003 <lineage>

004 <id> baro1 </id>

005 <name> Baro measurements </name>

006 </lineage>

007 <dimension> 1 </dimension>

008 <ref>

009 <ref_frame_VC>

010 QNH

011 </ref_frame_VC>

012 <coor_system_VC>

013 cartesian

014 </coor_system_VC>

015 </ref>

016 <units> hPa </units>

017 <c> 1 </c>

018 <s> 1 </s>

019 <t_spec>

020 <dimension> 1 </dimension>

021 <ref>

022 <coor_ref_frame_VC>

023 Celsius

024 </coor_ref_frame_VC>

025 </ref>

026 <units> C </units>

027 </t_spec>

028 </l_spec>

029 <p_spec s="a">

030 <type> pva </type>

031 <lineage>

032 <id> pva1 </id>

033 <name>

034 Position, velocity and

035 attitude in WGS84

036 </name>

037 </lineage>

038 <dimension> 9 </dimension>

039 <ref>

040 <ref_frame_VC> WGS84 </ref_frame_VC>

041 <coor_system_VC>

042 geodetic, geodetic, geodetic,

043 Lned, Lned, Lned,

044 Bfrd-Lned, Bfrd-Lned, Bfrd-Lned

045 </coor_system_VC>

046 </ref>

047 <units>

048 rad, rad, m,

049 m/s, m/s, m/s,

050 rad, rad, rad

051 </units>

052 </p_spec>

053 <m_spec s="a">

054 <type> RW_6_d </type>

055 <lineage>

056 <id> imu1_bias_d </id>

057 <name>IMU biases as random walk</name>

058 </lineage>

059 <l_list>

060 <dimension> 1 </dimension>

061 <item n="1">

062 <id> imu1_bias_pn </id>

063 </item>

064 </l_list>

065 <p_list>

066 <dimension> 1 </dimension>

067 <item n="1">

068 <id> imu1_bias </id>

069 <role> free </role>

070 </item>

071 </p_list>

072 </m_spec>

073 <i_spec s="a">

074 <type> baro_p0_h0 </type>

075 <lineage>

076 <id> p0_h0 </id>

087 <name>Initial pressure+altitude</name>

078 </lineage>

079 <c_list>

080 <dimension> 2 </dimension>

081 <item n="1">

082 <type> scalar </type>

083 <ref>

084 <ref_frame_VC> QNH </ref_frame_VC>

085 <coor_system_VC>

086 pressure

087 </coor_system_VC>

088 </ref>

089 <units> mBar </units>

090 <c> 1.2 </c>

091 <s> 1 </s>

092 </item>

093 <item n="2">

094 <type> scalar </type>

095 <ref>

096 <coor_ref_frame_VC>

097 WGS84-ellipsoidal-height

098 </coor_ref_frame_VC>

099 </ref>

100 <units> m </units>

101 <c> 0.15 </c>

102 <s> 1 </s>

103 </item>

104 </c_list>

105 </i_spec>

Figure 1: Metadata: observation, state, model and instrument.

mended when big amounts of data need to be handled;

these are more efﬁcient in terms of space and process-

ing time. l- and o-records also exists in the binary ver-

sion of data ﬁles; obviously, these are represented in

a different (more compact) way.

3.2 The Network Interface

The second materialization of the ASTROLABE data

model is the network interface, which relies on TCP

/ IP sockets. This interface implements, at least up to

GISTAM 2017 - 3rd International Conference on Geographical Information Systems Theory, Applications and Management

01 <l id="baro1" s="a" n="32"> 124.88 23.44 1023.44

02 0.3 </l>

03 <l id="imu1" n="41"> 124.88 0.01 0.02 0.015 0.32 0.43 9.95

04 1e-3 1e-3 1e-3 1e-2 1e-2 1e-2 </l>

05 <l id="imu1_bias_pn" n="17"> 124.88 0.0 0.0 0.0 0.0 0.0 0.0 </l>

06 <o id="pva1_d" > 124.88 27 11 41 </o>

07 <o id="imu1_bias_d" > 124.88 11 17 </o>

08 <o id="height_update" > 124.88 27 34 32 51 </o>

10 <l id="baro1" n="33"> 124.90 23.45 1023.45

11 0.3 </l>

12 <l id="imu1" n="41"> 124.90 0.01 0.01 0.014 0.33 0.44 9.95

13 1e-3 1e-3 1e-3 1e-2 1e-2 1e-2 </l>

14 <l id="imu1_bias_pn" n="17"> 124.90 0.0 0.0 0.0 0.0 0.0 0.0 </l>

15 <o id="pva1_d" > 124.90 27 11 41 </o>

16 <o id="imu1_bias_d" > 124.90 11 17 </o>

17 <o id="height_update" > 124.90 27 35 33 52 </o>

19 <l id="baro1" n="32"> 124.92 23.45 1023.45

20 0.3 </l>

21 <l id="imu1" n="41"> 124.92 0.01 0.01 0.013 0.30 0.42 9.95

22 1e-3 1e-3 1e-3 1e-2 1e-2 1e-2 </l>

23 <l id="imu1_bias_pn" n="17"> 124.92 0.0 0.0 0.0 0.0 0.0 0.0 </l>

24 <o id="pva1_d" > 124.92 27 11 41 </o>

25 <o id="imu1_bias_d" > 124.92 11 17 </o>

26 <o id="height_update" > 124.92 27 34 32 51 </o>

Figure 2: An observations ﬁle in text (XML) format.

the moment, a subset of the data model. Only the

transmission of observation data is available nowa-

days. This means that two software components shar-

ing ASTROLABE data through the network interface

must agree on the metadata characterizing the infor-

mation to avoid misunderstandings.

The network interface deﬁnes a very reduced

set of messages to exchange information; these

comprise the l-record, o-record, end-of-data and

acknowledgment-of-reception messages. Obviously,

the information conveyed by the l- and o-record mes-

sages correspond to that included the l- and o-records

described in the ﬁle interface. In spite of being so

limited, the network interface has proven to be very

useful in real-time systems, where different software

modules cooperate to estimate a trajectory; the data

collector components may exchange data easily with

the component(s) responsible for the actual computa-

tion. No intermediate ﬁles are needed to implement

such architecture.

4 THE ASTROLABE LIBRARY

The CTTC has implemented a portable C++ library

composed of reader, writer (ﬁle interface), sender and

receiver (network interface) classes. In short, it in-

cludes all the necessary tools to process ASTRO-

LABE data and metadata. This comprises dealing

with the different formats (text versus binary, obser-

vations versus other kind of ﬁles, for example,) or the

ability to read observation ﬁles either in forward or

backward directions. This is specially important for

TDSs, since one typical approach to estimate trajec-

tories is to process data in forward direction ﬁrst, in

backward direction then, and ﬁnally combine the two

solutions thus obtained to derive a ﬁnal trajectory.

Performance is another issue that has been ad-

dressed in this library. All readers and writers in

the ﬁle interface implement a technique known as

”buffered reading (writing)” to reduce the amount

of input / output operations, thus increasing speed.

The use of this technique doubled the performance

of CTTC’s TDS, NAVEGA. Finally, the network in-

terface always transmits data in binary format for ef-

ﬁciency reasons.

5 ASTROLABE IN REAL-LIFE

The ASTROLABE data model, through its two inter-

faces and library, has been put to the test in several

projects since 2009 (see the Acknowledgements sec-

tion.) The contact with real-life situations helped to

improve ASTROLABE so it became what it is nowa-

days. Section 2.1 states that any kind of observable

with error distributions with ﬁrst and second moments

may be supported by ASTROLABE. This statement,

A Generic, Extensible Data Model for Trajectory Determination Systems

which is true from a conceptual standpoint, is rein-

forced by the successful results obtained in real situa-

tions where ASTROLABE has been used. Here, a list

of the observations modelled for the aforementioned

projects is presented: GNSS raw data, GNSS position

(x,y, z) IMU (linear accelerations, angular velocities,)

EGNOS corrections, magnetic ﬁelds, pressure, time

tagged distances, coordinates of tie points, ranges and

angles.

6 CONCLUSIONS

For several years now, the ASTROLABE data model

and its ﬁle and network interfaces, materialized in an

Interface Control Document (ICD) (Par

es et al., 2016)

and in a portable C++ library, have been put success-

fully to the test in the ﬁeld of trajectory determina-

tion systems. Real-life projects incorporating differ-

ent kind of sensors and observations have served to

improve it and validate it. The genericity and ex-

tensibility goals have been achieved, so change and

innovation challenges may be properly faced at no

software maintenance costs. ASTROLABE exposes a

terse, compact interface, simple but powerful enough

to make it practical in the speciﬁc ﬁeld it has been

targeted at: data for TDSs.

The authors are considering putting ASTRO-

LABE in the public domain.

ACKNOWLEDGEMENTS

The research reported in this paper started around

seven years ago at the former Institute of Geomatics

and has been funded by means of several European

projects. We would like to highlight ENCORE (Silva

et al., 2011; Colomina et al., 2012), IADIRA (Silva

et al., 2006), CLOSE-SEARCH (Molina et al., 2012),

GAL (Skaloud et al., 2015) and ATENEA (Fern

andez

et al., 2011).

REFERENCES

ASPRS (2009). LAS Speciﬁcation. Version 1.3 R11.

Available online: http://www.asprs.org/a/society/

committees/standards/LAS 1 3 r11.pdf. Accessed:

2016-11-22.

Colomina, I. (1992). Discrete Mathematical Techniques in

the Analysis and Adjustment of Hybrid Networks. In

XVIIth International Congress of the ISPRS, Washing-

ton DC, USA.

Colomina, I., Miranda, C., Par

es, M. E., Andreotti, M., Hill,

C., da Silva, P. F., Silva, J. S., Par

es, T., Galera, M.

J. F., Camargo, P. O., Fern

andez, A., Palomo, J. M.,

Moreira, J., Streiff, G., Granemann, E. Z., and Aguil-

era, C. (2012). Galileo’s Surveying Potential. GPS

World, 23(3).

Colomina, I. and Molina, P. (2014). Unmanned Aerial Sys-

tems for Photogrammetry and Remote Sensing: a Re-

view. ISPRS Journal of Photogrammetry and Remote

Sensing, 92:79–97.

Crippa, B., de Haan, A. A., and Mussio, L. (1989). The For-

mal Structure of Geodetic and Photogrammetric Ob-

servations. In Tutorial on Mathematical Aspects of

Data Analysis, ISPRS, Intercomission WG III/VI, Pisa,

Italy.

Elassal, A. A. (1983). Generalized Adjustment by Least

Squares (GALS). Photogrammetric Engineering and

Remote Sensing, (49):201–206.

Fern

andez, A., Diez, J., de Castro, D., Dovis, F., Silva,

P., Friess, P., Wis, M., Colomina, I., Lindenberger,

J., and Fern

andez, I. (2011). ATENEA: Advanced

Techniques for Deeply Integrated GNSS/INS/LiDAR

Navigation. In 24th International Technical Meeting

of The Satellite Division of the Institute of Naviga-

tion (ION GNSS), pages 2395–2405, Portland, Ore-

gon, USA.

Groves, P. D., Wang, L., Walter, D., Martin, H., and Vout-

sis, K. (2014a). Toward a Uniﬁed PNT Part 1, Com-

plexity and Context: Key Challenges of Multisensor

Positioning. GPS World, 25(10):18–49.

Groves, P. D., Wang, L., Walter, D., Martin, H., and Vout-

sis, K. (2014b). Toward a Uniﬁed PNT Part 2, Am-

biguity and Environmental Data: Two Further Key

Challenges of Multisensor Positioning. GPS World,

25(11):18–35.

GSA (2015). GNSS market report 4. Technical report, Eu-

ropean GNSS Agency, Prague, Czech Republic.

IGS (2013). RINEX. The Receiver Independent Ex-

change Format. Version 3.02. Available online:

ftp://igs.org/pub/data/format/rinex302.pdf. Accessed:

2016-11-22.

Karpowicz, J. (2016). Above the Field with UAVs in Preci-

sion Agriculture. Technical report, Commercial UAV

Expo, Las Vegas, USA.

Kresse, W. and Fadaie, K. (2004). ISO Standards for Geo-

graphic Information. Springer, Berlin and Heidelberg,

Germany.

Marietta, D., Smearcheck, M., and Racket, J. (2015). SPI-

DER and FLY: Navigation Data Simulation and Post-

Processing Software Suite. In ION GNSS, Tampa,

USA.

Minh, V. T. (2014). Trajectory Generation for Autonomous

Vehicles. In Mechatronics 2013: Recent Technologi-

cal and Scientiﬁc Advances, pages 615–626. Springer.

Molina, P., Colomina, I., Vitoria, T., Silva, P. F., Skaloud,

J., Kornus, W., Prades, R., and Aguilera, C. (2012).

Searching Lost People with UAVs: The System and

Results of the CLOSE-SEARCH Project. In In-

ternational Archives of the Photogrammetry, Remote

GISTAM 2017 - 3rd International Conference on Geographical Information Systems Theory, Applications and Management

Sensing and Spatial Information Sciences, volume

XXXIX-B1, pages 299–306, Melbourne, Australia.

OGC (2007). OpenGIS



Sensor Model Language

(SensorML) Implementation Speciﬁcation. Avail-

able online: http://portal.opengeospatial.org/ﬁles/

?artifact id=21273. Accessed: 2016-11-22.

OGC (2013). Geographic Information Observations

and Measurements. Available online: http://portal.

opengeospatial.org/ﬁles/?artifact id=41579. Ac-

cessed: 2016-11-22.

Par

es, M. E. and Colomina, I. (2015). On Software Archi-

tecture Concepts for a Uniﬁed, Generic and Extensi-

ble Trajectory Determination System. In ION GNSS,

Tampa, USA.

Par

es, M. E., Navarro, J. A., and Colomina, I. (2016). AS-

TROLABE. Interface Control Document (in prepara-

tion). Technical report, CTTC & Geonumerics, S. L.,

Barcelona, Spain.

Sarjakoski, T. (1988). Object-oriented Approaches in the

Design of More Capable (Adjustment) Systems. In

XVIth International Congress of the ISPRS, Kyoto,

Japan.

Silva, P., Silva, J., Caramagno, A., Wis, M., Par

es, M. E.,

Colomina, I., Fern

andez, J., Diez, J., and v. Gabaglio

(2006). IADIRA: Inertial Aided Deeply Integrated

Receiver Architecture. In 19th International Techni-

cal Meeting of the Satellite Division of The Institute of

Navigation (ION GNSS 2006), pages 2686–2694, Fort

Worth, USA.

Silva, P., Silva, J., Peres, T., Colomina, I., Miranda, C.,

Par

es, M. E., Andreotti, M., Hill, C., Galera, J., Ca-

margo, P., Diez, J., Palomo, J. M., Barbin, S., Mor-

eira, J., Streiff, G., Granemann, E., and Aguilera,

C. (2011). ENCORE: Enhanced Galileo Code Re-

ceiver for Surveying Applications. In 24th Interna-

tional Technical Meeting of The Satellite Division of

the Institute of Navigation (ION GNSS 2011), pages

3679–3689, Portland, USA.

Skaloud, J., Colomina, I., Par

es, M. E., Bl

azquez, M.,

Silva, J., and Chersich, M. (2015). Progress in Air-

borne Gravimetry by Combining Strapdown Inertial

and New Satellite Observations Via Dynamic Net-

works. In IUGG 2015, Prague, Czech Republic.

Soloviev, A., Veth, M., Yang, C., and Miller, M. (2016).

Plug and Play Sensor Fusion for Navigation in GNSS-

challenged Environments. Inside Unmanned Systems,

pages 58–65.

Soloviev, A. and Yang, C. (2013). Reconﬁgurable Integra-

tion Filter Engine (RIFE) for Plug-and-Play Naviga-

tion. In ION GNSS+, Nashville, USA.

Titterton, D. H. and Weston, J. L. (2004). Strapdown In-

ertial Navigation Technology. The American Institute

of Aeronautics and Astronautics & The Institution of

Electrical Engineers, Reston, USA & Herts, UK, 2nd

edition.

Tscherning, C. C. (1978). Deﬁning the Basic Entities in a

Geodetic Data Base. Bulletin G

eodesique, (52):85–

92.

Zhu, L., Yang, A., Wu, D., and Liu, L. (2014). Survey

of Indoor Positioning Technologies and Systems. In

Life System Modeling and Simulation: International

Conference on Life System Modeling and Simulation

(LSMS 2014) and International Conference on Intelli-

gent Computing for Sustainable Energy and Environ-

ment (ICSEE 2014).

A Generic, Extensible Data Model for Trajectory Determination Systems