Bring back location tracking in Collector

[JakeJacobs]

The new collector (Aurora) no longer supports location tracking. ESRI has promised a new app with better tracking.  In the mean time we are using Workforce in the background, but it only works when connected.

The new functionality might be super but all my users are asking to see just their own breadcrumbs in Collector, not everyone else's, like they used to be able to do in ArcGIS Mobile for Windows.

In that app the breadcrumbs were visible to the user but were only synced up, never down from the server to the local map.  It actually worked out really nicely for everyone.

[JohnMDye]

Was toying with Tracker while at UC (sorry I couldn't track you down Jeff Shaner, but I did successfully make Craig Gillgrass cringe with a poorly thought out Workforce integration) and Aaron showed me that to connect tracks and create path, you basically have to leverage GeoAnalytics - which is obv. not available in AGOL and I know you guys are working on figuring out how to bring it to AGOL. 

All this to say, I get it. You collect a bajillion breadcrumbs and then you want to connect the dots to visualize the linear path of those tracks after the fact. That's going to take some horsepower, hence GeoAnalytics. But, I just wondered why Tracker is not just connecting the dots on the fly and producing a path layer as it goes along. Similar to the way many Esri apps rely on and manage multiple layers, it seems to me that Tracker should automagically be producing a 'Tracks' and 'Paths' layer, extending the path as new 'Tracks' are added.

The only reason I could see not to do this if you wanted to have the option to also ensure that the paths generated by connecting the dots also align with a road network, in which case that is certainly some heavier processing.

This didn't occur to me until later so I didn't get to ask anyone.

[PaulHoefflerGISS]

Jeff Shaner‌, two follow-up questions:

1) John Dye responded that because Tracker for ArcGIS is licensed at the Viewer and higher user type levels that it will be available at no cost. That would be great. According to our Esri account manager this is not the case, and that while it is licensed for those user types, it requires at-cost licensing for a premium app component (think ArcGIS Enterprise app, not the mobile app, correct?). It's not very obvious, but I believe that is mentioned in the documentation under the Track mobile user location section of this page: https://doc.arcgis.com/en/tracker/faq/requirements.htm Is this correct, that Tracker for ArcGIS will require additional licensing, at a cost? Actually, that refers to licensing a mobile app, and there is no mention of licensing that I see on the Enterprise setup page, which instructs to download, install, and go...: https://doc.arcgis.com/en/tracker/help/tracker-enterprise-support.htm

2) Do you have a rough timeline for integration of Tracker into Esri mobile apps? Specifically Collector. I heard that location tracking in Survey123 was announced at the UC, and assume this would be Tracker-based. I contactedCollector4ArcGIS@esri.com about the timeline, but have yet to hear back.

Thank you!

Paul

[JohnMDye]

So, Tracker is currently only available for ArcGIS Enterprise, so definitely you need that component. You also need the ArcGIS Spatio-Temporal Big Datastore. That's a free component, but it does require additional infrastructure deployments on your part.

Now for the mobile component, Tracker is a field app and as such, it requires the ability to "write" its tracks to the Spatio-Temporal Big Datastore. So, your Account Manager is correct. My previous comment that Tracker is licensed at the Viewer level is not accurate. It would be impossible for a Viewer to use Tracker as Viewers do not have permission to write features.

Rather, the Tracker has to be licensed with one of the User Types that includes the Field Apps bundle (Creator, Field Worker, GIS Professional). Alternatively, the Editor User Type is likely to have Tracker as a compatible Add-on App as well in the same way that it has Collector, Workforce, Survey123, Navigator and QuickCapture as compatible add-on apps. 

There is no mention of Tracker in the User Types page or anywhere else and I expect that is because the app is relatively new and the documentation hasn't been updated yet. Nonetheless, I would expect its licensing to align with that of the other Field Apps.

[PaulHoefflerGISS]

Thanks for the additional information/insight.

There does appear to a fair amount of confusion around this new app/functionality (and perhaps QuickCapture, too) - in the same email our account manager indicated "The app can be licensed for any USER TYPE that is VIEWER or higher."

[JakeJacobs]

We're interested in using the ArcGIS Online version, not the on premise Enterprise version and we've been told $60 per head per year from our account manager to use Location Tracking, on top of what we have in our Enterprise license for Field Workers.  Presumably that's to cover the cost of the spatio-temporal big data store?  I'm not sure.

[JohnMDye]

The app can be licensed for any USER TYPE that is VIEWER or higher.

That doesn't make sense. Maybe your Account Manager meant higher than Viewer. A Viewer couldn't possibly use Tracker. Certainly, they could view the tracks layer produced by Tracker on the web, but unless Esri has a Viewer experience in Tracker that allows them to see the tracks of others, I don't know what the point would be for a Viewer user type to have access to Tracker.

I'm sure Jeff Shaner‌ or Craig Gillgrass‌ will shed some light whenever they have recovered from UC.

[PaulHoefflerGISS]

We have yet to get firm pricing, and pricing for ArcGIS Online may be different than for Enterprise and yet to be determined. But that's very interesting, if that rate proved to be true it would add up for some organizations...

[JohnMDye]

$60/head? Oof.

[Anonymous User]

John Dye‌ There's a few reasons/concerns why we don't generate a polylines automatically.

1. With points we can just add points to the feature layer (at any frequency). With polylines we'd have to either wait until some criteria is met to "finish" a line and then upload it, or make update calls to update the existing line (which are more expensive).

2. How should we split lines? Every 1km, every 5 minutes,  every 100 points, a combination? It doesn't seem like there is one clear answer here. In the client apps we have logic for it I'm not convinced we'd want to do the same things to store polylines.

3. How do you determine which points to use as vertices in the lines? Should all points with accuracy less than 100 m be used? Should only points with "driving" activity be used? With the GA tool you can specify any filter criteria you want. Similarly in the client apps right now you can filter using the "smart rendering" toggle or additional accuracy filters and the lines are regenerated on-the-fly.

All that said, we have discussed the idea of having the server generate lines from the points. It's definitely not fully thought out and not planned at this time but the idea would be there could be a third layer, and when it's queried, the server could build lines that match the criteria and serve those out. We'd have to figure out some caching strategy for this as well.

There also is some work going on in the JS API to provide a renderer which can turn points into lines (based on some unique field) which might be useful when it's available.

[JohnMDye]

All valid considerations, Aaron. Given that context, it's difficult not to agree with the path the team is currently taking.

I really appreciate how engaged this team is and how open you all are about the rationale for these decisions. Certainly, this team has no obligation to justify the decisions being made behind the scenes but it's incredibly helpful for myself and other users to understand the context and details behind them so that we can explain why this app and others work the way they do when we get these same questions.

I've often found myself in a situation where an end users asks a really good question and I know there's a really good answer, but I simply don't have the context and can't lay it out for them. Thanks to this team for being so engaged!‌