Overview of Tracking Services

Introduction to Tracking Services

Data messages streaming out of Tracking Server can be organized into a logical representation of data called a tracking service. These services are published via the Tracking Server Connector Data Link. The Tracking Server Connector Data Link operates like a pipe carrying water, where the tracking services are the “water.”

Tracking services are created, edited, and deleted in Tracking Server Manager on the Tracking Services tab. Tracking services rely on message definitions that accurately describe the event data. You must first have message definitions in place before using them to create your tracking services. If the message definition that the service is based on is removed, the tracking service will also be deleted. A tracking service must be defined for event data to be available to the Tracking Server Connector data link.

In general, tracking services contain observations of entities through time, as the entities move or change. Observations of these entities are events, which can take any of the following forms:

• Dynamic: Events that move such as airplanes, vehicles, animals, storms, and satellites
• Discrete: Events that occur independently from a string or series such as lightning strikes, crime incidents, and automobile accidents
• Stationary: Events monitored from a nonmoving entity such as a weather station or traffic sensor
• Changing: Events indicating change or growth such as population studies or money distribution

Observations and Objects

Events are organized into observations and objects. An observation records an event and contains the date and time, attributes, and possibly the geometry or shape information. In some cases, the attribute and geometry information is contained separately, in an object component. An object describes an event and contains attributes and possibly the geometry information.

If all the necessary information for an event is contained in the observation, it is called a simple event. When static information is stored separately from the observation, the observation is joined with the object to define a complex event. In the case of a complex event, the observation and object are combined in a single message using a join field, which is typically a unique identifier, such as a TrackID or EventID.

Simple and Complex Services

A tracking service can be composed of either simple events or complex events. For simple data messages, the service will use only an observation message definition. For complex data, the service will use both an observation and an object message definition. When data messages enter as simple events, all of their attributes—including their geometry—are contained in the observation message definition. When they come in as complex events, their persistent information is contained in the object message definition. If your data messages contain complex events, you must choose both an observation and an object message definition.

A complex event uses two message definitions: an observation message definition that provides temporal information and an object message definition that provides persistent attribute information. A complex event can join static tabular information to a real-time (dynamic) message in cases where the message contains the real-time position and the attribution is joined from a static source. For example, a moving vehicle position can be joined with static driver and model information. Complex events can also combine real-time attributes with static geographic feature information. For example, real-time traffic sensor observations are joined with static geographic feature and attribute information.

A table containing simple events.

Two tables containing complex dynamic events.

Two tables containing complex stationary events.