Select to view content in your preferred language

Replicate geoEvent Idle Detection Functionality in Velocity.

570
15
07-31-2024 10:54 AM
JeffSilberberg
Frequent Contributor

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).

 

0 Kudos
15 Replies
MuneerMajid
Occasional Contributor

Thanks Peter, I have logged the below ticket via the support site -
https://my.esri.com/#/support/cases/tech-cases?caseNumber=03707071

0 Kudos
JeffSilberberg
Frequent Contributor

@MuneerMajid 

Sorry, I am still struggling with this as well.   If there is a magic trick, I have not found it either. 

 

0 Kudos
MuneerMajid
Occasional Contributor

I have had a ticket open with ESRI support since 8/20. There has been no movement on it all this while and the designated analyst has only told me that the product team has been reviewing this internally. Pretty disappointed at this point at the inability of the Motion Statistics to deliver what's expected. 

0 Kudos
JeffSilberberg
Frequent Contributor

@MuneerMajid  @PeterNasuti 

Sorry, I do not have an update from them either at this time -- 

 

 

0 Kudos
Joanna_Nishimura
Esri Contributor

I wanted to provide an update on this issue.  I worked with MuneerMajid to further investigate this issue with the Calculate Motion Statistics tool.  The original question was around getting the Calculate Motion Statistics tool to output Idling values that were True.  We took a closer look at the workflow and clarified some of the tool parameters.  For Calculate Motion Statistics to output Idling status of TRUE, the following 2 statements must both be true:

  1. TimeSpan  > TimespanTolerance
  2. Distance < DistanceTolerance

Where TimeSpan is the time elapsed between the previous and current observation and TimespanTolerance is the Timespan Tolerance value entered in the tool.  Distance is the distance travelled between the previous and current observation and DistanceTolerance is the Distance Tolerance value entered in the tool.  If either of the above statements is false, then the tool will output an Idling status of FALSE for that point. 

We talked through the end goal of the workflow and decided that with some fine-tuning of the parameters, it may be possible to get the Calculate Motion Statistics tool to output the desired results or there could be an alternative workflow using Calculate Fields tool with TrackFunctions and the Detect Incidents tool.

MuneerMajid
Occasional Contributor

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. 

0 Kudos