Latest Contributions by kmsmikrud

Hi Colin, Thanks for your reply. I had responded but I don't see my reply.  The biologists are working in an offline environment and the data is from AGOL. In talking more with my coworker, it sounds like it was what you said above in that the tracks were still there or will show again once the map is panned/zoomed/refreshed. They may have turned them off the layer in the process as well. Our understanding, is that the tracks would update in the map with the location since the surveys are taking place in a plane and we thought the tracks would update similar to your tracks in a boat chart plotter. It sounds like this is sort of true with the tracks in the Collector app but a person has to keep interacting with the map to view the updated tracks (pan, zoom, refresh). Regardless this is good information to consider when using the apps. Thanks, Kathy ... View more

Thanks Aaron for the quick reply. I understand on the tracks location layer having editing enabled but I thought the view could have different sharing privileges enabled for views different from the original feature layer and in this case the 'location layer'. However from your response it sounds like the track view that is created for an AGOL user collecting tracks is not a typical view.  Instead even though the track view created is called a view it is different than other views created in AGOL and will be restricted because of editor tracking enabled within the view and "view location tracks" privilege. I really wish there would be a way to eventually share the tracks with everyone. It sounds like we need a view of the tracker view? We are using the tracker app for surveys and the data being collected is public data on a fishery. The tracks layer is beneficial in showing the public where the survey took place. At the moment I was sharing for other coworkers to view survey results. We don't currently have Portal set up in our organization and not all staff have AGOL licenses. We were excited to share the data in an interactive map but then realized on the error after I had sent it out web app link since I do have privileges to view and I didn't get an error on the tracks layer when I shared with everyone. Thanks, Kathy ... View more

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