Latest Contributions by PeterNasuti

@MuneerMajid Can you log an Esri Support case for assistance with this? If you have identified a Track ID and Start Time fields in your schema the Track functions should be returning prior values if configured correctly. Remember that the first observation for a track will return null values as there are no prior values when an analytic starts processing. This will require a screenshare to review your settings and configuration to assist. ... View more

@MuneerMajid Can you please log an Esri support case with the questions you are still facing with this tool? We will also get a Velocity product engineer to further assist as needed. @JeffEismanGIS  ... View more

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 ... View more

@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. ... View more

@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 ... View more

I would configure a Filter by Expression tool ($feature.IncidentStatus == 'Ended') followed by a Calculate Fields tool. In the Calculate Fields tool expression, you can use a TrackFieldWindow function to obtain the prior IncidentDuration value as well as the joined field value.   var lastInsideDuration = TrackFieldWindow('IncidentDuration', -1,0) var lastIntersectFeatureName = TrackFieldWindow('YourGeofenceIdentifierField', -1,0)   Use Track Functions documentation for additional reference. Let me know if there are questions on this. ... View more

@ArmstKP I can envision two ways to achieve this: First, as @JeffSilberberg suggested you can use the Detect Incidents tool and set an attribute expression that identifies the incident criteria. Then, add a Filter by Expression tool following to only let pass incidents where $feature.IncidentStatus == "Started" || $feature.IncidentStatus == "Ended" (if desired) Another option is to use the Calculate Fields tool followed by a Filter by Expression. Your Calculate Fields tool can calculate a numeric or boolean value to indicate if the prior value was in the defined range. This would leverage the TrackFieldWindow track function. Then the Filter by Expression tool could follow to filter out unwanted values. Additional doc on track functions. ... View more

@MuneerMajid Thanks for posting your use case and this scenario. What you are requesting regarding a point leaving one spatial feature and entering another without an observation triggering the closure of the old incident and the creation of a new incident is something we have heard requested from other users as well. There is a planned tool parameter to be added in a future release for the Detect Incidents tool that will do exactly this. Basically it would take an observation and split it into two observations. One that "closes" the first incident detected, and another that "opens" the next incident with the new geometry. This does not yet have an anticipated release date. While there is not a workaround for this at the moment with the Detect Incidents tool to do exactly what you are asking, a combination of the Join Features tool and the Calculate Field tool using track functions (TrackFieldWindow) and Filter by Expression could be used to filter an alerting pipeline whenever a worker changes from not-in-a-work-area to in-a-work-area OR from in-a-work-area to not-in-a-work-area OR from in-one-work-area to in-another-work-area. Basically I would envision this flow as: Use the Join Features tool to enrich point worker/vehicle observations with an attribute from your well pad polygons Keep all features in the join so the value is null if the worker/vehicle is not inside a well pad Lets say this field is called "InsideWellPadName" Add a Calculate Fields tool and use the TrackFieldWindow function to obtain the prior value for "InsideWellPadName" for the feature in that Track that came before the current feature var priorWellPadName = TrackFieldWindow('InsideWellPadName', -1,0) Compare the prior value to the current value and then take your desired action using Arcade conditionals For example, if prior value is null and current value is populated, the worker/vehicle entered a well pad If prior value is populated and current value is null, the worker/vehicle exited a well pad If prior value is one well pad and current value is another well pad, the worker/vehicle moved from one well pad to another Use the Filter by Expression tool (or multiple instances of it) to split analytic pipelines for desired handling ... View more

@ArmstKP If the layer in question is an ArcGIS Online hosted feature layer (this is what is created when unchecking "Store data in spatiotemporal feature layer"), the query performance in dashboards would be better suited to be reviewed with the ArcGIS Online team and an Esri Support Services case. In that configuration, ArcGIS Velocity is simply writing the data out to an ArcGIS Online hosted feature layer.  You are correct that currently ArcGIS Velocity spatiotemporal layers cannot add fields. This is an enhancement we are considering for the future of the product to enable this capability. ... View more

@Teresa_Blader I agree with @JeffSilberberg's suggestion above. Using the Map Fields tool for a field calculation depending on string length (or just using the text slicing to grab the correct elements) would be a better solution and can assign the "Start Time" tag. This could be a combination of the IIf function, Date function, etc. to parse the date correctly  The Velocity feeds and sources "date format" is expecting a single consistent date format. The behavior you are seeing is as designed where if the string can't be parsed to the date format the value is nulled. ... View more

@MuneerMajid We were just reviewing this internally on the Velocity team. This was a software defect specific to feeds with spaces in the title. When these feeds are edited, there is a URL issue introduced (the spaces are originally replaced with underscores, however the issue is that this is changed when it should not be. This bug will be resolved with the 5.2 release that will go live tomorrow evening 6/25/24. Unfortunately in the case of existing feeds, the feed will need to be recreated to revert to having a correct URL. The support analyst on your case will be reaching out with additional details. ... View more

@MuneerMajid Please make sure to log an Esri Support case for this issue for tracking from our side. Is this issue appearing with just one feed/stream service or multiple? ... View more

@Teresa_Blader We are targeting a Velocity 5.2 release of this functionality which should go live around mid-June and enable you to ingest this data. If there are any unforeseen delays to a later release I will update this thread. ... View more

Hi Teresa, We have this written up on our end to implement as an enhancement to add support for custom headers in WebSocket connection from the Velocity backend. Please test the workaround provided by @JeffSilberberg and let me know if that works for you or not? ... View more