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]

Have you looked at Find Dwell Locations ?

[JeffSilberberg]

@MuneerMajid 

 No, I have not as it's not an option in my Velocity RealTime Analytic only in Big Data Analytics -- Find Locations - 

 https://doc.arcgis.com/en/iot/analyze/find-dwell-locations.htm

[PeterNasuti]

@JeffSilberberg Ideally the Calculate Motion Statistics tool would be the right choice at this point to achieve what I am understanding you are asking.

Assuming you have location updates coming in (people, vehicles, object in motion) and want to know when that entity is idle and not moving:

• Configure the Calculate Motion Statistics tool
  • Of key importance are the distance tolerance and timespan tolerance
    • "The units of the output motion statistics depend on the units specified for the Distance Tolerance and Timespan Tolerance parameters. For example, if you're specifying a Distance Tolerance value of 750 meters and a Timespan Tolerance value of 10 minutes, the output distance fields will be in meters, the output time span fields will be in minutes, and the output speed fields will contain values with units of meters per minute."
    • For another example, if you specify "1 mile" and "1 hour", if the feature movement drops below 1 mile per hour, that would be identified as a dwell by this tool and output units calculated by the tool would be in miles & hours.

This tool will generate the following attributes then related to idling:

Idling	Specifies whether the track is idle based on a distance and time threshold from the previous observation	Boolean
TotalIdleTime	Cumulative amount of time for which idling was detected	Float64
PercentageIdleTime	Percentage of time for which idling was detected	Float64

[JeffSilberberg]

@PeterNasuti 

I have been fighting with that node for almost a year now with zero success.  I was told that the documentation does not match the implementation.  This is why I posted to see if others have maybe found a better way.  

[PeterNasuti]

@JeffSilberberg The documentation for all Velocity tools matches the implementation - please feel free to reach out to me directly over email (pnasuti@esri.com) and we will get a member of the product team assigned to investigate your reported issues with the Calculate Motion Statistics tool directly.

[JeffSilberberg]

PM Sent -- 

[PeterNasuti]

To follow up on this thread for future community reference:

• From the Velocity perspective, we will enhance the Calculate Motion Statistics presentation of the tool parameters and user experience to make the settings more clear to the user (targeting 5.3 release late 2024)
• The History Depth parameter is of key importance for calculations
  • This parameter is "the number of event observations to evaluate per track (includes the current observation). Motion calculations will be done based on this information."
  • For example if you set a history depth parameter of 3, the min/max/sum/total/average/TotalIdleTime/PercentIdleTime calculations will be based on the current feature and the two prior features
• Relevant to @JeffSilberberg 's workflow, there was a goal to obtain the "Total Idle Time" since the beginning of idling, rather than just the total idle time relevant to the History Depth parameter
  • To achieve this, a Detect Incidents tool was configured following the Calculate Motion Statistics tool
    • An attribute open condition of "$feature.Idling == True" was utilized to detect and open an incident when idling had started
    • The "IncidentDuration" value generated by the Detect Incidents tool generated a stateful and accurate calculation of how long an entity had been idling
  • We will examine updating the Calculate Motion Statistics tool to adjust the Total and Percentage idle time values to be fully stateful beyond just the history depth