Space-Time-Boxes (STB) are an extension of Geohashed spatial locations. More
specifically, an STB is an alphanumeric string that represents a regularly shaped region of space
and time.
For example, the STB dr5ru7|2013-01-01 00:00:00|2013-01-01 00:15:00 is
made up of the following three parts:
The geohash dr5ru7
The start timestamp 2013-01-01 00:00:00
The end timestamp 2013-01-01 00:15:00
As an example, you could use space and time information to improve confidence that two entities
are the same because they are virtually in the same place at the same time. Alternatively, you could
improve the accuracy of relationship identification by showing that two entities are related due to
their proximity in space and time.
In the node properties, you can choose the Individual Records or
Hangouts mode as appropriate for your requirements. Both modes require the
same basic details, as follows:
Latitude field. Select the field that identifies the latitude (in WGS84
coordinate system).
Longitude field. Select the field that identifies the longitude (in WGS84
coordinate system).
Timestamp field. Select the field that identifies the time or date.
Individual Records
Copy link to section
Use this mode to add an additional field to a record to identify its location at a given
time.
Hangouts
Copy link to section
A hangout can be thought of as a location and/or time in which an entity is continually or
repeatedly found. For example, you can use a hangout to identify a vehicle that makes regular
transportation runs and identify any deviations from the norm.
The hangout detector monitors the movement of entities and flags conditions where an entity is
observed to be "hanging out" in the area. The hangout detector automatically assigns each flagged
hangout to one or more STBs, and uses in-memory entity and event tracking to detect hangouts with
optimum efficiency.
Following is more detail about what qualifies as a hangout:
Let e1, ..., en denote all time ordered events that are
received from a given entity ID during a time duration (t1,
tn). These events qualify as a hangout if:
n >= minimum number of events
tn - t1 >= minimum dwell time
All events e1, ..., en occur in the same STB
Notes:
The hangout detector's in-memory event data is not shared across processes. Therefore, a
particular entity has affinity with a particular hangout detector node. That is, incoming motion
data for an entity must always be consistently passed to the hangout detector node tracking that
entity, which is ordinarily the same node throughout the run.
The hangout detector's in-memory event data is volatile. Whenever the hangout detector is exited
and restarted, any work-in-progress hangouts are lost. This means stopping and restarting the
process might cause the system to miss reporting real hangouts. A potential remedy involves
replaying some of the historical motion data (for example, going back 48 hours and replaying the
motion records that are applicable to any node that was restarted).
The hangout detector must be fed data in time-sequential order.
About cookies on this siteOur websites require some cookies to function properly (required). In addition, other cookies may be used with your consent to analyze site usage, improve the user experience and for advertising.For more information, please review your cookie preferences options. By visiting our website, you agree to our processing of information as described in IBM’sprivacy statement. To provide a smooth navigation, your cookie preferences will be shared across the IBM web domains listed here.