location_timestamp vs. created_date

[JamesCrandall]

Need some clarification on the two columns: location_timestamp vs. created_date

If there is a large gap between these two values, does that mean the app user was stationary for that period of time and then at some point the ESRI Tracker service was updated with features later?

For example, we can see in some point features the two date values are quite close (here they are only 2 mins apart):

In other instances the two dates are hours apart:

I'm asking because we are processing tracks at the top of each hour by querying the location_timestamp values from the last known location_timestamp value we maintain.  However, if the point features were added at a much later time then they'll be missed if recent tracks have already been processed.  That is, we don't look back in time for points added after the top of each hour.

I'm pretty sure I'm assessing this correctly but hoped to get some confirmation so that I can implement something to process the missed features.

Thanks!

[Anonymous User]

Thanks for that info, if you query those two points and look at the returned json, are the location_timestamp values exactly the same down to do the millisecond? What about the geometry are the x,y values exactly the same?

Do you know if this was an Android or iOS device that recorded the tracks?

Was it only those two points in this instance or is there a series of seemingly identical points?

[JamesCrandall]

Edit: I will have to determine OS.  Also, I cannot find any significant pattern on when this occurs but it can be as much as a few hundred points.

They do look like true duplicates but created at different datetime values, same location_timestamp values in milliseconds.  This is from a different instance than in my screenshots above but all the same example in every way,

  "features" : [
    {
      "attributes" : {
        "objectid" : 780399, 
        "location_timestamp" : 1592092364993, 
        "created_user" : "x", 
        "created_date" : 1592092528672, 
        "globalid" : "e8344433-d21e-469e-aa92-59c99df1ae56"
      }, 
      "geometry" : 
      {
        "x" : -80.821906594999973, 
        "y" : 25.762405908000066
      }
    }, 
    {
      "attributes" : {
        "objectid" : 781743, 
        "location_timestamp" : 1592092364993, 
        "created_user" : "x", 
        "created_date" : 1592093778509, 
        "globalid" : "e0e22585-ae08-4406-81cb-243e36fcb829"
      }, 
      "geometry" : 
      {
        "x" : -80.821906594999973, 
        "y" : 25.762405908000066
      }
    }
  ]‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

I also have a post-processing step that identifies discrepancies after I have moved points from the ESRI tracker service to another hosted feature service that creates local feature classes from the json result of queries against both services.  Once they are FC's I run a selectByLocation for identical features as well as using Find Identical GP tool.

When I run the Find Identical GP tool on the ESRI Tracker service results, they are definitely identical in every way except for the Created_date values.

[JamesCrandall]

Like I mentioned, I don't have a sense of frequency just yet but I do have some monitoring tools setup.  This duplicate issue has only happened about 7 or so times since I started monitoring about 50 ESRI Tracker users collecting roughly 30,000 tracks each 24hrs.

I have a daily summary metrics that I am querying against the ESRI Tracker Service and the Hosted service I have moved points into from the tracker service.  In the instances where there's both a "actualDiscrepancies" and "possibleDiscrepancies" values then these are cases where valid ESRI Tracker features were created much later after the copy process ran and these are true discrepancies that I recover those points.

Whenever "actualDiscrepancies" = 0 and "possibleDiscrepancies" > 0 these are all instances where the ESRI track points were created later but already had created a point at the earlier time, hence it's a duplicate feature.

I'm only interested in the actualDiscrepancies and have a process in place to move these into the destination feature service after-the-fact.

(the -1 values are likely due to a missing ">=" somewhere in my programming that queries the feature services but I consider this quite minor and I simply ignore at the moment until I can find time to remedy it).

[JamesCrandall]

EDIT: would a single user logged into ESRI Tracker app across multiple devices simultaneously be a source to any of this?  I'm still skeptical even that would produce the same features with the exact same location_timestamp values but perhaps there's another process that is being affected by the simultaneous logins.

Aaron,

To reiterate, I'm not worried about the duplicates issue only because I'm handling them in an after-the-fact process that I can identify these instances.  But wanted to provide more info to you and your team.  Let me know if you'd like me to open a premium ticket to setup a more formal interaction outside of GeoNet, I would be able to remote session with you all if you need.

I now see some triplicates.  

[
  {
    "attributes": {
      "objectid": 886296,
      "globalid": "cf208275-3d97-4f07-aa59-89dfe72d8f0a",
      "activity": 0,
      "altitude": -22,
      "app_id": "tracker",
      "battery_percentage": 87,
      "battery_state": 1,
      "course": 96.2351684570312,
      "device_id": "04ba83a0-09b0-4b4a-b87e-2be331924053",
      "floor": null,
      "horizontal_accuracy": 3.90000009536743,
      "location_source": "fused",
      "location_timestamp": 1592434582000,
      "session_id": "7aa745ba-42be-4b23-acc8-11a65d511740",
      "signal_strength": null,
      "speed": 26.8384494781494,
      "vertical_accuracy": 100,
      "created_user": "zzz",
      "created_date": 1592434625398,
      "last_edited_user": "zzz",
      "last_edited_date": 1592434625398
    },
    "geometry": {
      "x": -81.03567099999998,
      "y": 25.857096300000023
    }
  },
  {
    "attributes": {
      "objectid": 886297,
      "globalid": "dbabadd9-9d46-43eb-b42b-05836c94e46e",
      "activity": 0,
      "altitude": -22,
      "app_id": "tracker",
      "battery_percentage": 87,
      "battery_state": 1,
      "course": 96.2351684570312,
      "device_id": "04ba83a0-09b0-4b4a-b87e-2be331924053",
      "floor": null,
      "horizontal_accuracy": 3.90000009536743,
      "location_source": "fused",
      "location_timestamp": 1592434582000,
      "session_id": "7aa745ba-42be-4b23-acc8-11a65d511740",
      "signal_strength": null,
      "speed": 26.8384494781494,
      "vertical_accuracy": 100,
      "created_user": "zzz",
      "created_date": 1592434625398,
      "last_edited_user": "zzz",
      "last_edited_date": 1592434625398
    },
    "geometry": {
      "x": -81.03567099999998,
      "y": 25.857096300000023
    }
  },
  {
    "attributes": {
      "objectid": 886298,
      "globalid": "f7c56f5c-5d20-4772-9f28-2f5ba4e90640",
      "activity": 0,
      "altitude": -22,
      "app_id": "tracker",
      "battery_percentage": 87,
      "battery_state": 1,
      "course": 96.2351684570312,
      "device_id": "04ba83a0-09b0-4b4a-b87e-2be331924053",
      "floor": null,
      "horizontal_accuracy": 3.90000009536743,
      "location_source": "fused",
      "location_timestamp": 1592434582000,
      "session_id": "7aa745ba-42be-4b23-acc8-11a65d511740",
      "signal_strength": null,
      "speed": 26.8384494781494,
      "vertical_accuracy": 100,
      "created_user": "zzz",
      "created_date": 1592434625398,
      "last_edited_user": "zzz",
      "last_edited_date": 1592434625398
    },
    "geometry": {
      "x": -81.03567099999998,
      "y": 25.857096300000023
    }
  }
]‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

[JamesCrandall]

Hi Aaron -- hope all is well.

Is there any update regarding the documentation on this issue?

We're now seeing a much larger lag/delay in some instances and trying to determine if this is an app setting, device/OS type, connectivity issue or if there's something on the ESRI side of things that may cause this?  Recently we noticed a specific instance with a 4 day delay between location_timestamp and created_date:

[Anonymous User]

We just updated the doc today:

Use tracks—Tracker for ArcGIS | Documentation 

4 days is definitely abnormal. It's most likely a connectivity issue.