Problem with Location Tracking in Offline Mode

[NathanKoski]

Hi there,

I am trying to make use of the location tracking ability of collector to track users using the app and geoevent watches this activity using "Poll ArcGIS Server for Features."

So far it works great in online mode, however, when using it in offline mode there is a problem when it goes to sync the location tracking data. All of the location data syncs with correct timestamps and geometry, but the objectid's seem to be assigned randomly to each location track point. Normally this wouldn't be that big of a deal, however, geoevent polls these events in order based on objectid. Which results in my path looking completely wrong in the eyes of geoevent.

Attached is a screenshot of the feature with the OIDs labeled. You can clearly see them out of order of what the path was.

In online tracking, these results would have their OIDs climbing in order to match their respective timestamps.

Is there a way for me to sync my results in the correct order? Is this a bug? 

Thanks!

Nate

[RJSunderman]

Hello Nathan -

I am not familiar enough with ArcGIS Collector to comment on the behavior you are observing that OBJECTID do not increment along with the track points in the temporal order they were received. You're in the right GeoNet Subspace for questions on the application ... so I'll let someone from that team comment on whether or not what you're observing is considered a bug.

From a GeoEvent‌ perspective, I can tell you that https://community.esri.com/community/gis/enterprise-gis/geoevent/blog/2015/08/20/polling-feature-ser...‌ can be problematic when using OBJECTID as the key value for determining when new feature records have been added to the feature service you are polling for input. Most often we see the problem when multiple contributors are adding feature records to the geodatabase feature class. ArcGIS Server has a mitigation strategy which allocates OBJECTID in blocks of (I believe) 400 to each contributor to avoid race conditions in which two contributors ask for the next available OBJECTID, both are told that the ID 'X' is the next in line, and both attempt to create a new feature with the same OBJECTID.

What you'll see is feature records being created with OBJECTID values 1, 2, 3, 4 .... then the ID values will appear to jump to 401, 402, 403, ... and maybe later to 801, 802, 803, ...

The problem with this from a GeoEvent Server perspective is that the GeoEvent input is querying for feature records using the greatest-value of all the OBJECTID values observed in the last feature record set queried from the service. This means that once feature records with the 80x IDs start being created, the input will remember seeing values in the eight hundred range and will construct a query with a WHERE clause that excludes any feature records whose OBJECTID value is less than 803, 804, 805, ...

Then, when one of the other contributors operating within the block of OBJECTID values allocated to his/her operations, creates new feature records 6, 7, 8, 9, ... none of these are polled by the GeoEvent input because it is using a key value in the 800 range when querying for "new" feature records based on OBJECTID.

You'll be much better-off using a date/time field when querying using the GeoEvent input's "incremental update" capability. But even then, if ArcGIS Collector is adding feature records out-of-order, or is adding them as a batch without setting the date/time each track point was actually collected, you'll have trouble using the GeoEvent Server's polling input to identify feature records which are both "new" and get them in the order they were originally collected.

Also remember that the geodatabase only honors date/time resolution to the second, so even if ArcGIS Collector specifies sub-second / millisecond precision, that precision will be lost. The date/time values of the persisted feature records will either be truncated or rounded to the nearest whole second (I don't remember which).

I recommend taking a look at the blog I referenced above. Depending on how you've chosen to disseminate the event records you've processed, polling for incremental updates can cause you other problems when the GeoEvent Server service is restarted - which will happen if an administrator restarts the ArcGIS Server service or when the server is rebooted. 

Hope this information is helpful -
RJ

[NathanKoski]

Hi RJ,

Thanks for following up, I have read that blog post in detail, and it was quite helpful on a different project.

I did consider using the incremental updates with the date and time field, however, I am concerned that it will only create more bugs down the line.

Generally, our project goal is to have multiple people being tracked, online or offline. This means that if Person A is out in the field at 4pm and is online, and Person B is out in the field offline at 2pm but syncs their data at 5pm, that Geoevent will ignore Person B's updates because they did not take place after Person A? (If I am explaining the problem right?)

Do you happen to know if Geoevent will reset its incremental querying if I delete the past results? 

Right now the workaround is to receive all updates from the location track layer and to have each event stored in a new feature after Geoevent processes them. Then have the Geoevent use Delete Polled Features option to remove events it has processed off of the location track layer. This feels clunky, but it actually works out pretty well, because it means the location track layer gets cleaned up automatically.

It does not solve the issue we are having with events coming in out of order, however, so using spacial filters and geofences end up being really messy... In my above example, I entered/exited a Geofence twice, however, if I use the ENTER ANY filter I get 12 events stating I entered the Geofence. Very confusing!

Anyways, thanks for your followup! I hope that someone from the collector group knows why my collector syncs data out of order.

Nate