Simple and complex temporal events

Temporal data includes information about temporal events, which describe an observation or a set of observations of a particular object or group of objects. Therefore, the event includes information about the observation, such as when or where the observation took place and what activity was observed, as well as information about the object itself.

ArcGIS Tracking Analyst organizes this information into simple and complex temporal events. A simple temporal event contains all necessary information in one message or record, referred to as the temporal observation component. A complex temporal event includes a second component, the temporal object component. In the case of fixed-time data, these components may appear in separate files or tables. For real-time data, these components appear in data messages and are automatically combined by Tracking Analyst.

Simple events

For simple events, the temporal observation component is the only component of the data. It must include at least the date and time of the observation. Fixed-time data containing simple events can be organized in one table, which includes the date and any other attributes that are present. Simple events contain in a single component all the elements necessary for Tracking Analyst to process and display them.

An example of a simple event table

Complex events

Complex events include two components, an observation component and an object component. The temporal observation component does not include all the necessary information for the object, so the additional information is stored in the object component. The exact contents of the object component depend on whether the tracked objects are moving or static. Ideally, the object component should include all attributes that are static. Therefore, the object component may contain the shape field for stationary events. At a minimum, it must include an ID field that can link it to the observation component.

The merger of the temporal observation and object components creates a complex event record or data message. A unique ID field that exists in both components is used to join the two and create a complete picture of each event's information. In the case of real-time data, this merging occurs automatically.

Complex stationary events

An example of a complex stationary event is input from a weather station. The sensor's geographic location doesn't change, so its geographic position, as well as other static information, is stored in the temporal object component. The temporal object component also includes the sensor’s ID so it can be linked to the observations for the correct sensor. The following illustrates a table join for complex stationary temporal events.

Complex dynamic events

An example of a complex dynamic event is information from an airplane. Its geographic location is changing constantly, so it must be stored in the observation component, along with the date and time information. In this case, the temporal object table may include information such as the make and model of the aircraft, pilot and crew information, and the age and capacity of the fuselage. The following illustrates a table join for complex dynamic temporal events.

Adding complex events from fixed-time data

When you add complex events from fixed-time data, the Add Temporal Data Wizard asks you to provide the two components described above. The wizard, however, uses the terms input feature class and input table to define how and where the data is stored. Both the feature class and the table must reside in the same personal geodatabase.

The input feature class must always contain the geographic features and the ID to join to the input table. The other attributes depend on whether you're adding dynamic or stationary events. If you are adding dynamic events, the input feature class will contain the date and time information for the events, and it should not include any static attributes. If you are adding stationary events, the input feature class should contain static attributes, but not the date and time information for the events.

The input table must contain at least the ID to join to the feature class, but it should also include other attribute information. For dynamic events, the input table should contain only static object information. For stationary events, the input table should also contain the date and time information.