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 · Accepted solution]

Hi James,

The location_timestamp field is the date and time when the location was recorded on the device.

The created_date field is the date and time when the location was successfully uploaded to the location tracking feature layer.

Our next doc update at the end this month or early July will provide more information about each of the fields.

[JamesCrandall]

Thank you for the quick reply Aaron!

It does sound like my assessment is somewhat correct and point features can be uploaded/added at a much later (hours) time, not necessarily in succession.  

We are processing the tracks each hour, enriching them with some other attributes and copying them into another destination feature service that has a similar schema to the tracker service.  This is essentially what occurs at the top of each hour:

1. To identify "new" track features, query the destination feature service to get the most recent feature location_timestamp value for a particular username. Query parameters include: orderByFields': 'location_timestamp DESC',  'resultRecordCount' : '1'
2. With that location_timestamp value, query the ESRI Tracker service to see if there are any feature >= that value, if so then execute the process on those features.

As you can see, if new point features were created in the ESRI tracker service after the process had executed then subsequent executions would not pickup those in the past.

I'll have to implement a secondary post-processing that identifies these "missed" tracks that were created after the location_timestamp values and pull them into the destination feature service.

Take care,

j

[JamesCrandall]

Aaron -- one last question on this as I've got it worked out to post-process tracks that are created after the location_timestamp that my initial processing misses....

How much later in the future could a Created_date value actually be?

I guess I really just need to know if that is more than a 24 hours / 1 calendar day.  This would really help me to solidify recapturing those missed points.

Thanks for any info!

Take care,

j

[Anonymous User]

It really depends on how often your field workers have connectivity. If they come back to the office every night then 24 hours should be more than enough time. If they are out in areas with no connectivity for multiple days, then you'd need to back further in time.

You may want to checkout the Query Top Features API. You could use this to find the most recent track points for each user within a period of time.

Parameters would be something like this:

[JamesCrandall]

Good stuff  Thanks a bunch!

[JamesCrandall]

There is one other item that I cannot understand: Why are there some duplicate ESRI Track points?

I can see that in those after-the-fact times created_date is after the location_timestamp, there may be instances of the same point even though it was created around the location_timestamp.  The location_timestamp values are exactly the same.

(edit: it's not a huge issue and I can identify/account for these pretty easily in my post processing tools, but would be good to fully understand.)

j

[Anonymous User]

Hmm that sounds like a bug. Do you have an example of that?

One way this can happen is that an upload is triggered and the points get inserted into the backend database but the response never makes it back to the app, so the app may try to upload those points again. This should be very rare so if you are experiencing this fairly often, we should probably look into it more.

[JamesCrandall]

Yep, will find some of those instances for asap.

Thanks again!

j

[JamesCrandall]

Hopefully this will do, I can get you the globalid's and service url if needed too.  Bascially, you see there are 2 tracks on top of each other, identical location_timestamp and username, all of the same attributes altogether (except for OID and GlobalID).  The difference is the created_date, which seems to show that they were created at later datetimes.

The takeaway is that location_timestamp and username is exactly the same.  I couldn't fit the full popup so just pay attention to the (1 of 2).  Here are 2 images of point 1:

Here's the second point: