Triggering Time-Elapsed Events Without Persistent Location Storage and calculate time

Moi_Nccncc

If a car enters a geofence area at 1:00 PM, I want to trigger an event (such as an email or SMS) if it stays for more than 10 minutes. The car may stop sending location updates, and I want the event to be triggered 10 minutes after the car initially entered the geofence. I do not wish to persistently save the car's location; it should only be temporarily stored in a cache upon entering the geofence and deleted upon exiting. How can I achieve this?

RJSunderman

@Moi_Nccncc -- Data from sensors, such as the GPS supporting automated vehicle location (or AVL) solutions, is not generally held in-memory by GeoEvent Server. GeoEvent Server was designed around assumptions of frequent observational data reported from sensors and reliable periodic data reports. Whether that is data being sent to GeoEvent Server via HTTP/POST requests or GeoEvent Server polling a REST API via HTTP/GET requests, the processors and filters in a GeoEvent Server can generally only act upon data that is actively being received. Vehicles which cease to send location records generally cannot be included in any sort of real-time notification because there is no input to process.

You might think to try configuring an Incident Detector to do what you want to do. An Incident Detector is used when you want to monitor the duration of some condition, such as a tracked asset's location detected "inside" an area of interest (or geofence). An Incident Detector will emit an event record, whose status is 'Ended', if the processor observes at least one event record satisfying its opening condition and does not receive an event record it can use to update its status before the processor's configured expiry time. The default expiry time is 300 seconds.

So, it is possible to receive exactly one event record whose geometry is inside a given geofence, route that event record through an Incident Detector to create a new incident (whose status is 'Started') and then stop receiving any additional input from tracked assets (e.g. vehicles). The Incident Detector by default will update its incident's duration until it sees 300 seconds have passed without receiving any additional data and signal this by emitting an event record with the vehicle's TRACK_ID and a status 'Ended'. The administratively ended incident will have a duration 300,000 milliseconds greater than the '0' duration recorded when the incident was opened (when the vehicle was first detected 'Inside' the geofence).

This really is not how an Incident Detector processor was intended to be used however. The processor expects to process event records it receives and update its incident's status. It will emit an event record when it "gives up" having not seen any new data within its expiry window, but this is part of its error handling not nominal use. You must also consider that the processor is configured with both an "opening condition" and a "closing condition". The "closing condition" is only checked if the "opening condition" is false. It is not obvious, but given a number of non-overlapping and adjacent geofences you might guess that a single event record routed to an Incident Detector can be used to satisfy either its opening or its closing condition. In other words you cannot use an Incident Detector to process a single AVL data record and detect both that the vehicle's location has "exited" a geofence to the left of an adjacent geofence that the vehicle has just "entered". This nuance is one example of conditions you have to think about when using processors to evaluate spatial conditions such as "enter" and "exit" when simultaneously trying to monitor conditions used to "open" and "close" incidents.

It is far better to record observations such as "entry" and "exit" and the date/time these observations are made in a geodatabase rather than trying to hold the information in an in-memory cache and evaluate future conditions based on data cached from prior observations. There's lots of reasons why GeoEvent Server is not designed to cache and hold onto data from event records it has received.

I'll try to mock-up an approach to show you what I'm thinking, but you will want to consider a solution which relies on an RDBMS trigger configured to run every couple of minutes to look for data records which have an "entry_time", but do not have an "exit_time", and identify those records whose date/time entered is at least 10 minutes relative to "now". Have the RDBMS trigger flag the data record as one which needs to have an notification sent. You can then use GeoEvent Server to query the flagged records. You can configure the GeoEvent Server input to delete the flagged records from the database as they are queried, so e-mail or SMS notifications are only sent once.