Geoevent Point Logging Parody

[AKRRMapGuy]

I am trying to achieve parody with Geoevent Server so we can migrate fully to Velocity for Enterprise(12.1). 

The lack of a geotagger is really causing a problem for me. The issue I am having with Velocity is the join keeps logging points every 10 seconds(source refresh rate) despite the join criteria being set to 'enter'. It keeps logging points even though the train never 'exited' the geofence. I need it to log one point for entering and one for exiting just like Geoevent does. I tried using 'incident' detection but I can't get that to log anything at all using the same logic, but on a stop even the 'closing' event is enters and speed == 0.

Here is what I am trying to replicate. The Geotaggers are using 'enter any' and 'exit any' respectively. They correctly only generate one point a piece. The filters you see on the geoevent process after the feed are combined into one filter in the velocity process after the feed. 

Here is what I have for just stops:

It's worth noting I am using the same exact sites and services to input and output between the 2 products for these processes. What am I missing, or can Velocity just not do what Geoevent can?

[JeffSilberberg]

----  geoTagger and Join are basically the same in the way they behave. 

But your geoEvent RTA and your Velocity RTA do not look even vaguely similar in the limit flow picture you were able to cut and paste-  

Route by Expression and Split by Attributes may help, and if you just want to find the start and End of a condition, then look at the Incident detect module.

Not sure why you think you need to project the nodes in your new flow.  

[AKRRMapGuy]

They clearly aren't working the same way for me. This Velocity feed is only showing the stops line(top row and before) on the Geoevent feed. I removed the 'starts' portion since Velocity can't seem to handle one of these operations, much less two. I am trying to fix one and then the other. 

The first 'filter by expression' in the Velocity feed combines the first 4 operations after the input in the Geoevent feed. The speed is 0 filter on the geoevent feed is rolled into the Join as a condition. As far as the projects go, Velocity refused to run if I didn't add them since the Real Time input is WKT 4326 and the geofence layer is WKT 102392, then the output points are WKT 4326 so I have to transform them back. 

The heart of the issue is Velocity does not seem to honor when something 'enters' a geofence and stays there it shouldn't keep logging a point everytime it receives data without 'exiting'. It's acting like a 'within' or 'intersects' rather than a one and done 'enter' since it logs a new point over and over again everytime the point is 'within' the geofence. 

The speed is zero portion is rolled into the join criteria on the Velocity feed. The logic is supposedly identical if the 'join' actually acted like a geotagger set to 'enter'.

[JeffSilberberg]

 Well, this is UC week, so not sure who from Esri is available to respond - 

Incident Detection gives you "Start", 'Ended," and "Ongoing," and you could then add the necessary filters. 

If you want to look at this live, send me a DM, and I can do so, but no promises. 

[AKRRMapGuy]

I appreciate that. I may take you up on that. I am suspicious of the 'time' settings on the input feed. Velocity isn't telling me it can't parse the text string(I have seen that error, and I am not getting it now), but it's almost acting like it isn't able to sequence things by time to do 'stateful' things. 

[JeffSilberberg]

I believe you are correct === Feeds are processed on a FIFO basis. 

That said, if this is an event-driven feed, then inputs should be in the correct order - 

Either output your raw data to a file or use the data sampler to determine this. 

[AKRRMapGuy]

The good news is that the data received is definitely in order. Weather or not Velocity is honoring that for purposes of the stateful spatial analysis/relationship I can't tell. It would seem it's not since every point that meets the join criteria after the first point is received is treated as if it is the first one that was received. 

[JeffSilberberg]

  So both inputs to the Join have a Track ID?  

  Can you post/screen capture the Join Details?  

  https://doc.arcgis.com/en/velocity/analyze/join-features.htm

• Checking First observation can trigger enter or First observation can trigger exit indicates that the first target feature received satisfies the filter condition if it is inside (in the case of enter) or outside (in the case of exit) any join feature, despite having no previous target feature to compare the active target feature's location to. The default is false (not checked).
• Target Time Window?

    Also, consider changing your Join to a Detect module -- 

https://doc.arcgis.com/en/velocity/analyze/detect-incidents.htm

• In a real-time analytic, this tool operates in a stateful manner when Enter or Exit are used for the Spatial relationship option in the Open condition or Close condition parameters. While operating in a stateful manner, the tool can compare sequential observations to detect a change in state between observations. This tool runs in a stateless manner when using other spatial relationship options because it does not need to compare active to previous observations. Running in a stateless manner is much less resource intensive.

[AKRRMapGuy]

Yes, one is a locomotive number, and the other one is the station name. I did try a Detect Incidents configuration for both stops and starts. I couldn't get anything to generate at all from that.

Here is the join on the stops currently:

The starts has never generated any events using either a join or detect incidents analytic. The stops version of it was similar, and never generated anything either. I also tried not having a 'close' condition on either one. The speed logic was of course different between the stops and starts as well.

[JeffSilberberg]

I would make two changes to the Detect ===

Using the Sample data tool, what are you seeing output from the Detect?  

Are you sure the Passenger Stop Areas has good data?  

Maybe try the join but pass all the data instead of just the matches.