Replicate geoEvent Idle Detection Functionality in Velocity.

JeffSilberberg

After many many attempts, I am unable to replicate the functionality of idle Detection in geoEvent within Velocity.  We have tried any number of  nodes and combination of nodes with no luck.   CalaculateMotionStatics comes the closest but does not really provide the same functionality and the documentation for this node is ambiguous at best. 

Has anyone else found any good solutions?

https://hub.arcgis.com/documents/5d8e3446736d4df299c7c96bc275d561/explore

The Track Idle Detector Processor is a supported add-on processor that can be added to a GeoEvent Service that detects if a unique TRACK_ID has moved more than a specified amount within a given time. For example, if a delivery van is expected to make delivery stops that will not exceed 120 seconds, a Track Idle Detector could be used to alert dispatch personnel if a van is stuck in a single location for more than two minutes (e.g. if they are stuck in traffic or the vehicle has mechanical problems).

 

MuneerMajid

The solution provided by Joanna has worked well for me thus far. I think it is safe to conclude that you can tweak Motion Statistics do exactly what it promises, although we agree the documentation may not be easy to apply right off the bat. 

There were several tricks that I learned along the way during my discussions with Joanna for effectively putting motion statistics to good use. In my case, I was looking to flag vehicles which were Idle for more than 60 minutes. How you translate 'IDLE' is of great importance here, and my definition of it can be different than yours or ESRI's. I will try to elaborate on this a bit for the greater cause - 

For starters, IDLING detection within a custom time span is not reported by the tool in a way that's straight forward and easy to transcribe. Lets say in my case, I wish to detect vehicles which have traveled less than 500 Meters Geodetic over a 5 minute time span while I am gathering vehicle locations at every 30 second intervals. That implies that my distance tolerance is 500 Meters, but time span tolerance cannot be 5 minutes. If you put this combination in the tool, you are always going to get IDLING = FALSE. So rather than visualizing Idling over a 5 minute span, we viewed this as 10 individual observations each 30 seconds in duration. And also split our distance tolerance into 50 Meters. All in all you are trying to come up with a strategy to ensure that the following two conditions are always met for IDLING to be TRUE - 

1) Distance < Distance Tolerance (50 Meter)
2) Timespan Tolerance < Timespan (30 seconds)

I ended up putting my Timespan tolerance to a arbitrary number of 28 seconds for it to satisfy condition#2 at all times. I still dont agree with the way Timespan Tolerance is factored into the tool, for you can have more real time situations where the timespan is lot shorter (for eg. A Fleet of Vehicles sending their location at a timespan of every 1-2 seconds). In such cases I dont think your motion statistics IDLING output will be reliable if you are to ensure that Time span tolerance is as small as 0.5 seconds or so. For a more precise implementation of IDLING detection, we should have the capability of not comparing just the last observation, instead over a history depth. In other words, I should be able to get the tool to spit IDLING status over a time interval of 1 minute inspite of the observations being just seconds or milliseconds apart. Motion Statistics IDLING would be a little more powerful in my opinion if it can do cumulative IDLING analysis over the history depth rather than just 2 observations. What's also another interesting finding is that IDLING seems to be the only attribute in Motion Statistics that ignores the history depth for calculations and relies on the most recent observation, all other properties are reported over the history depth like speed, acceleration etc. IDLE duration and IDLE Percentage it must be stated do consider history depth which is understandable. 

Joanna however provided an alternate approach as well to factor in my above concerns. She demonstrated the use of track functions in arcade to calculate instantaneous speed and I like this approach as well. All in all, I was able to achieve what I needed with a combination of a few different checks and balances. I wouldn't have been able to tackle this requirement without Joanna's help though for I wasn't getting far by solely referring the documentation. 

I am happy to share any further insights shall anyone have questions about Motion Statistics.