As location becomes an increasingly important aspect of our lives, and as location-sensing devices become ubiquitous, there is an increasing demand for applications to be able to monitor subscriber location data continuously. The monitoring of the location data may translate into alerts being generated in the system.

For example, a trucking company may want to monitor its network of 10,000 trucks as they move along their specified routes towards their destinations. They may want to track the movement of trucks within a specified range of the route and expect notifications to be generated to detect undesirable deviations the vehicles from their desired routes. Proactive location-based services (LBSs) generalize such applications that track locations of subscribers inside or outside a specified region of interest for various purposes, such as location-based advertising and notifications about friends nearby.

The Oracle Spatial and Graph location tracking server provides:

• A simple framework for setting up a location tracking network within the database through a PL/SQL interface

• An API for continuous location monitoring of objects within a tracking network

• A queuing mechanism for incoming location updates and tracking requests and for outgoing relevant notifications, using Oracle Advanced Queuing

• Efficient, continuous location monitoring for thousands of relevant objects within the database

The location tracking server tracks a set of moving objects against a known set of regions of interest and generates notifications as required. In this framework, the set of regions of interest is referred to as the location tracking regions.

In the database these are managed in a table with two columns: roi_id INTEGER, roi_geom SDO_GEOMETRY. ROI_ID is the primary key for this table, and ROI_GEOM is the geometry of the tracking region.

Several additional structures are created when you create a tracking region set. You can create any number of tracking region sets, and each set typically can have thousands of regions that are tracked. When a region is no longer of interest for tracking purposes, it should be deleted from the tracking regions table.

You also need to insert the set of location objects to be tracked. Locations objects must specify an ID for the object and an ROI_ID to specify the target tracking region for this object. That is, each location object can be tracked against one or more tracking regions. These objects are created by inserting TRACKER_MSG (tracker message) objects into the tracking queue.

A tracker message object specifies the object_id, roi_id, and two flags.

• The isTrackInside flag specifies whether to track the object as it is inside the region or outside the region. If isTrackInside is set to Y, the object will be tracked to see its location stays inside the target ROI; and if the object ever leaves the ROI, then a notification message is generated. If isTrackInside is set to N, the object will be tracked to see its location stays outside the target ROI; and if the object ever enters the ROI, then a notification message is generated.

• The isActive flag specifies whether this location object is active or not. If it is set to Y, the location object will be tracked. If it is set to N, tracking will be turned off for the object. This allows the actual location object to persist, while the tracking of the object can be turned on or off based on the application context.

After location objects created and tracking options configured, you can start inserting new locations for tracking objects. That is, as the objects move in space, the location changes. And every time a new location is acquired, it can be inserted into the location message queue, to be processed by the tracking server. Depending on the isTrackInside flag and ROI_ID, these location messages are processed and notifications are generated as required. User application can monitor the notification queue and process the notifications whenever a new notification is generated.

The following additional grants are required for a user to run the tracking server.

grant aq_administrator_role, create job, manage scheduler to <USER>;
grant execute on dbms_aq to  <USER>;
grant execute on dbms_aqadm to  <USER>;
grant execute on dbms_lock to  <USER>;
grant execute on dbms_aqin to  <USER>;
grant execute on dbms_aqjms to  <USER>;

The PL/SQL subprograms associated with location tracking can have parameters of data types that are specific to the location tracking server.

These subprograms are documented in the SDO_TRKR Package (Location Tracking). The specific data types have the following definitions:

• LOCATION_MSG

  (object_id INTEGER,
   time      TIMESTAMP,
   x         NUMBER,
   y         NUMBER)

• LOCATION_MSG_ARR

  VARRAY(1000) of location_msg

• LOCATION_MSG_PKD

  object(arr location_msg_arr)

• NOTIFICATION_MSG

  (object_id INTEGER,
   roi_id    INTEGER,
   time      TIMESTAMP)

• PROC_MSG

  (object_id     INTEGER,
   time          TIMESTAMP,
   x             NUMBER,
   y             NUMBER,
   roi_id        INTEGER,
   isTrackInside CHAR(1))

• PROC_MSG_ARR

  VARRAY(1000) of proc_msg

• PROC_MSG_PKD

  object(arr proc_msg_arr)

• TRACKER_MSG

  (object_id     INTEGER,
   roi_id        INTEGER,
   isTrackInside CHAR(1),
   isActivate    CHAR(1))

The location tracking server requires the user to specify a tracking region name (TR_NAME) when the server is initialized. Based on this name, some additional data structures are created.

• Table <TR_NAME>_TRACKING_REGIONS (roi_id INTEGER, roi_geom MDSYS.SDO_GEOMETRY) contains the tracking region polygons defined in the server for the TR_NAME.Users directly insert the tracking polygons into this table after the server is initialized.

• Table <TR_REGION>_TRACKER (object_id INTEGER, 'roi_id INTEGER, isTrackInside CHAR(1)) contains the tracking objects (objects that are tracked). This table is managed by the tracking server, and users should not update this table directly.

• Table <TR_REGION>_NOTIFICATION_TABLE and <TR_REGION>_TRAJECTORY are two auxiliary tables used by the server and not to be updated by the user directly.

In addition to these tables, the server also creates a set of Advanced Query (AQ) objects for managing the location objects and notifications. All of these will have a prefix of <TR_REGION>.

The normal workflow for tracking objects is as follows:

1. A tracking region set is created using the SDO_TRKR.CREATE_TRACKING_REGIONS procedure.

2. The regions are activated by the SDO_TRKR.START_TRACKING_REGIONS procedure.

3. Location objects are created using the SDO_TRKR.SEND_TRACKING_MSG procedure. This call creates tracking objects and specifies whether to track the objects to be inside their target regions or outside the target regions.

4. The actual tracking of the moving objects is done using the SDO_TRKR.SEND_LOCATION_MSGS procedure. This procedure inserts moving location information about the tracked objects in the location tracking queue and about the location tracking server that processes them.

5. Users monitor the <TR_REGION>_NOTIFICATION_Q queue for alerts that are generated from the tracking server.