Latest Contributions by kmsmikrud

Thanks Aaron for the info info on the pagination and limit but hopefully we should be okay exporting after surveys. Thanks also for the documentation link! ... View more

That's great it "just works" but still have a setting within the app that actually shows which GPS provider the app is using would still be my preference. I don't like to just make assumptions. So far in our group the lack of settings in the tracker user interface doesn't have folks feeling that comfortable with the Tracker app compared to the Collector settings. ... View more

Thanks Aaron for the response. I have other feature layers configured to the local time zone for use in the Collector app.  We then have scripts to query the feature layers post-survey to both calculate field values based on survey data and then download records based on the most recent survey data. Having the dates configured with local time zone is preferable as it just makes more sense to the surveyors in viewing their data than translating from UTC and for the local dates to be stored in the downloaded files. We have also noticed that with UTC during the workday we can values for 2 different days in UTC versus 1 survey day in local time which adds errors to the queries. Adding the tracks layer to our current script post-survey process is the same, just makes more sense to look at the date/time in local time zone to be able to download that day's survey data. Since we can't add fields to the tracks layer view, we will have a translate UTC to local time zone in the script before querying the tracks layer to download the most recent survey data and then add in a field after the data is downloaded I guess. The feature class to feature class conversion tool does export the tracks layer as a feature class using Pro/arcpy so the fields are all there. I know you mentioned shapefiles but feature class downloads do work. Folks in our office have most commonly used handheld GPS to collect survey tracks and import into GIS. They are used to having the local date/time as the field not UTC or having to translate in between. We work in natural resources and this has been a very common workflow. I'm sure as more folks start using Collector and Tracker there will be similar requests. I do have the tracks feature layer added into Pro currently and it shows the tracks recorded. It recognizes the Location Timestamp as the Time Field but nothing else is configurable as if its just locked even with an advanced pro license. Also is there documentation in the Tracker for ArcGIS resources for all the fields created and what they are? I've seen some of your replies to other posts that some fields are only populated by Android devices and accuracy nuances but it would be great if it was just documented in one place. Thanks for your time, Kathy ... View more

I also now see a field in the tracks feature layer view named 'location_timestamp' and I was hopeful this field would be in our local time zone. It has the right date compared to the created_date but the time is not correct for when the tracks were recorded. How does the 'location_timestamp' field differ from the 'created_date' field? For example one record in a tracks layer shows. location_timestamp: 3/9/2020 11:21:14 PM  (correct date, but time is 8 hours off should be 3:21:14 PM) created_date: 3/10/2020 12:46:50 AM My hope is to create a field in a downloaded copy of the tracks to have values in our local time zone. I would also like to configure the pop-up for the feature layer service. I have a view of the tracks but it still does not allow me to create to a new field in AGOL which I thought was mentioned in another post as a work around. Thanks, Kathy ... View more

I apologize I meant to add post a question, not a discussion!  ... View more