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
Use this mode to add an additional field to a record to identify its location at a given time.
Hangouts
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:
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 eventstn - t1>= minimum dwell time- All events
e1, ..., enoccur in the same STB
- 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.