topic Re: Geoevent Point Logging Parody in ArcGIS Velocity Questions

Geoevent Point Logging Parody

AKRRMapGuy — Tue, 14 Jul 2026 21:24:36 GMT

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?

Re: Geoevent Point Logging Parody

JeffSilberberg — Wed, 15 Jul 2026 14:17:10 GMT

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

Re: Geoevent Point Logging Parody

AKRRMapGuy — Wed, 15 Jul 2026 16:31:52 GMT

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

Re: Geoevent Point Logging Parody

JeffSilberberg — Wed, 15 Jul 2026 16:39:48 GMT

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.

Re: Geoevent Point Logging Parody

AKRRMapGuy — Wed, 15 Jul 2026 16:54:53 GMT

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.

Re: Geoevent Point Logging Parody

JeffSilberberg — Wed, 15 Jul 2026 16:58:05 GMT

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.

Re: Geoevent Point Logging Parody

AKRRMapGuy — Wed, 15 Jul 2026 18:56:32 GMT

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.

Re: Geoevent Point Logging Parody

JeffSilberberg — Wed, 15 Jul 2026 19:17:10 GMT

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.

Re: Geoevent Point Logging Parody

AKRRMapGuy — Wed, 15 Jul 2026 20:10:39 GMT

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.

Re: Geoevent Point Logging Parody

JeffSilberberg — Wed, 15 Jul 2026 21:04:06 GMT

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.

Re: Geoevent Point Logging Parody

AKRRMapGuy — Wed, 15 Jul 2026 21:33:59 GMT

Nothing. Yeah, the geofences and GPS data is good. These are the same exact input and output services I use in Geoevent Server and it works fine there.

I added a filter after the join to filter out the 'null' joins. It keeps logging points every 10 seconds like before. It does the join fine for the stops part of it.

Re: Geoevent Point Logging Parody

JeffSilberberg — Thu, 16 Jul 2026 01:47:13 GMT

Sorry, I am out of ideas.

I suggest you open a case with Esri Support.

Re: Geoevent Point Logging Parody

Jeff_G — Fri, 24 Jul 2026 17:17:57 GMT

Hi @AKRRMapGuy, @JeffSilberberg is correct in saying that Join Features is the equivalent tool to GeoTagger. Only difference right now is that it evaluates the enter/exit logic against the entire geofence dataset instead of each geofence individually. This probably explains why you weren't getting any records coming through for Detect Incidents. The Velocity team currently reviewing an enhancement for all geofencing tools that will allow this.

You could use Intersects or Within, but that would give you the unwanted behavior of having a feature get logged every time the train is within that polygon.

Re: Geoevent Point Logging Parody

JeffSilberberg — Mon, 27 Jul 2026 14:04:29 GMT

@Jeff_G

So, Incident Detection using an intersect and filtering for Start and End only would probably be the best answer to this issue given the state of Velocity joins?

Re: Geoevent Point Logging Parody

AKRRMapGuy — Tue, 28 Jul 2026 18:45:28 GMT

That makes sense kind of, but I guess I don't get why it wouldn't generate a record from the Polygon that does meet all requirements. All of the Features in the whole Feature Service have to evaluate to true for the relationship in the join? You can't just return the 'join value' from the polygon that correctly hits like in Geoevent?

On a related note, this doesn't really explain why the stops keep generating records on every data input that is 'within' the polygon, even though the tool is set to 'enter' and the gps point never 'exited' the polygon to create the conditions for it to validly log a new 'enter' point.

I do think most if not all of my issues with Velocity is the 'stateful' logic isn't working at all or not working like it does in Geoevent. My input feeds and output feeds are the same exact sites and services Geoevent successfully consumed and fed to.

Re: Geoevent Point Logging Parody

AKRRMapGuy — Tue, 28 Jul 2026 18:48:04 GMT

Thanks for asking this Jeff, I am a little unsure about this as well. If this is the solution, I don't think this will work for us though due to the logic not being representative of what we are modeling. It also seems like it might only fix half of the process.

Re: Geoevent Point Logging Parody

JeffSilberberg — Tue, 28 Jul 2026 18:58:18 GMT

@AKRRMapGuy wrote:
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?

My experience has been that there is no one-to-one relationship between the two products. But Velocity does work; it just takes some effort to change your thought process. The real fun, though, is if you have to go back to geoEvent for a project after working in Velocity for a while. 🙂

Re: Geoevent Point Logging Parody

AKRRMapGuy — Tue, 28 Jul 2026 19:15:08 GMT

The good news is that I left Geoevent alive alongside Velocity for this reason. Velocity is handling every other portion of our Production processes like a champ.

This might actually be the first product replacement from ESRI in my whole career I was excited about and felt it was overdue, and here we are.

Re: Geoevent Point Logging Parody

Jeff_G — Wed, 29 Jul 2026 01:06:39 GMT

@JeffSilberberg Detect Incidents would still give us a similar behavior to Join Features since its built-in Enter/Exit logic treats the polygon layer as a single dataset. For example, if geofences A, B, C, and D are connected to each other, a point moving from geofence A to geofence C may not trigger a new Enter event because the train never actually exits the overall states dataset.

@AKRRMapGuy I'm not sure why your Join Features logic is giving you a feature for every observation with your current configuration. I'd have to take a look at your analytic configuration and feed/source datasets to see what's going on. Feel free to send me a direct message with your contact info, and I'd me more than happy to get on a call with you.

As a workaround for the current Detect Incidents/Join Features Enter/Exit behavior, I was able to use an Arcade expression in a Calculate Fields tool.

In this example, I have a point moving from Florida to Virginia. The point is geotagged with the state name using Join Features. It uses an Intersects operation.

After the Join Features, I have a Calculate Field configured with the following Arcade expression. If our point moves from Florida to Georgia, it will detect that change and the expression will return true in new field I called "state_changed".

// 1. Fetch the previous state name array from the history cache var priorStateArray = TrackFieldWindow('STATE_NAME', -1, 0); // 2. If it's the initial record (no history), mark it true so we keep it if (IsEmpty(priorStateArray) || Count(priorStateArray) == 0) { return true; } // 3. Extract the previous text value from the array and grab the current one var previousValue = priorStateArray[0]; var currentValue = $feature.STATE_NAME; // 4. Returns true if it changed, false if it is identical return previousValue != currentValue;

Downstream I have a Filter by Expression to only give me records where state_changed = true:

With this setup, I'm able to get point data every time our moving point enters a new polygon or exits the polygon dataset altogether.