How to create a location aging policy using Location Engine Config

Summary

This article shows how to create a location aging policy in order to remove old locations using Location Engine Configuration.

Prerequisites

You should know the information in the following articles:

• How to detect object presence using Location Engine Config
• How to get a list of types

Guide

Before you start, remember to:

• Make sure you have a valid dataset with the "UPresence" module installed.

• Set managed_base_type (see section 3 here for details) to UBase::Object before starting Location Engine Config.

• Start the Location Engine Configuration tool and check that the "Presence" tab is shown.

• Set some sensors to forward uplinks and/or chirps.

Setting up the policy

In Location Engine Config, create a policy as follows:

The following dialog appears:

Click OK and the policy is added to the list:

In versions after and including 2.1.5, you can choose whether to apply location aging policies depending on whether the object is in the site activity schema. You can use this option in conjunction with a presence aging policy to age out locations only for objects that can no longer be heard by any presence sensors.

Rules about location aging

Location aging policies (and presence aging / location injection policies) are inherited according to the normal inheritance semantics, and can be overridden at descendants. If a policy is defined for a type T it will be inherited by any descendant U of T, unless U defines a policy, in which case the policy for T will be invisible to U and its descendants.

Location aging policies can be defined for different cells. In general, smaller cells will take precedence over larger ones, but only after inheritance has been taken into account.

Example

If you have 2 Location Engine cells A and B, both containing uplink-forwarding sensors, define:

1. A location aging policy for UBase::Object, Site, 90 seconds.
2. A location aging policy for ULocationEngine::Tag, Cell A, 45 seconds.