Latest Contributions by ScottPrindle

Hello Pete, Just to reiterate what Praveen asked, could you share some more context around what you are trying to accomplish, or what your end goal is? Is it not possible to use the Smart Map Search workflow noted by Praveen, or does this workflow not quite fit your needs? Thanks, Scott ... View more

Hello Ulf, Thanks for submitting this idea! Would it be possible to share a high level overview of the data you have in file/enterprise geodatabases, and how you would like to view them in ArcGIS Earth? In regards to the second half of this idea, it may be more beneficial to separate this out into another idea and expand upon the request. We would like to keep every idea limited to one functional/thematic request for one product, so votes, comments, and implementation do not get lost on all of your suggestions. Please message me if you have concerns or questions on this process. Thanks, Scott ... View more

Hey Stan, The beta for the next generation of Collector is coming soon. You can email collectorbeta@esri.com to be included when it is released. I don't have a timeline for your particular request, but I do appreciate the clarification you were able to provide. As more varied workflows are shared in the comments, we can get an idea of how else this functionality would benefit our users. Thanks, Scott ... View more

Hey Stan, The beta for the next generation of Collector is coming soon. You can email collectorbeta@esri.com to be included when it is released. I don't have a timeline for your particular request, but I do appreciate the clarification you were able to provide. As more varied workflows are shared in the comments, we can get an idea of how else this functionality would benefit our users. Thanks, Scott ... View more

Hello Brett, Thanks for submitting this idea! Others, When voting for this idea, consider leaving a comment to share how multi-part geometries would be beneficial to your current or possible workflows. Thanks, Scott ... View more

All, When voting for this idea, please consider commenting to share how this would fit into your workflows. What are you doing currently to manage identity with your replicas, and how do you envision this idea improving your projects. Thanks, Scott ... View more

All, When voting for this idea, please consider commenting to share how this would fit into your workflows. What are you doing currently to manage identity with your replicas, and how do you envision this idea improving your projects. Thanks, Scott ... View more

Hey Joe, I don't believe the workaround I provided is a suitable one for a production environment where editor tracking or security are very important. The reason I mentioned this workaround is because it's one way to generate a replica that isn't associated with a logged in user. This would allow you to then secure the service, and continue synchronization with the replica, as long as the user attempting to do so has permission to access the service. The current replication workflows appear to rely on the identity of the creator pretty heavily, as you've clarified previously. This can be helpful if a single replica might end up on multiple devices, to provide some limitations on who is able to sync that dataset. It seems like the core of your idea is to have the option to create replicas with the intent that they can be used by any named user in a specified Portal group. In this scenario you'd be handling distribution and management of these replicas, but depending on who is working with a device that day, the replica must allow "User A" or "User B" to make edits and sync. This would expand the current functionality to associate the replica with a group, while not opening it up for anyone to use (replicas generated anonymously). Please let me know if this understanding of your request is incomplete. Thanks, Scott ... View more

Hey Joe, I don't believe the workaround I provided is a suitable one for a production environment where editor tracking or security are very important. The reason I mentioned this workaround is because it's one way to generate a replica that isn't associated with a logged in user. This would allow you to then secure the service, and continue synchronization with the replica, as long as the user attempting to do so has permission to access the service. The current replication workflows appear to rely on the identity of the creator pretty heavily, as you've clarified previously. This can be helpful if a single replica might end up on multiple devices, to provide some limitations on who is able to sync that dataset. It seems like the core of your idea is to have the option to create replicas with the intent that they can be used by any named user in a specified Portal group. In this scenario you'd be handling distribution and management of these replicas, but depending on who is working with a device that day, the replica must allow "User A" or "User B" to make edits and sync. This would expand the current functionality to associate the replica with a group, while not opening it up for anyone to use (replicas generated anonymously). Please let me know if this understanding of your request is incomplete. Thanks, Scott ... View more

Hello Joe, Thanks for submitting this idea! Currently, if a secure feature service is accessed and a replica is created, it is owned by the user that was signed in at the time. This is closely tied to the identity of the field worker, which has presented the behavior you've encountered. However, if a service is unsecured when the replica is created, then there is no identity associated with said replica. This could be a potential workaround if you are able to give it a test. Could you expand on your use case? Beyond sharing a single device and large data footprints, what other uses would you have for multiple field workers being able to sync the same replica? Could you outline how you envision the workflow panning out if this idea were implemented? Would a replica be created with a set list of users it is shared with, or open for any logged in user to sync? Please feel free to add any notes you feel may clarify your request. Thanks, Scott ... View more

Hello Joe, Thanks for submitting this idea! Currently, if a secure feature service is accessed and a replica is created, it is owned by the user that was signed in at the time. This is closely tied to the identity of the field worker, which has presented the behavior you've encountered. However, if a service is unsecured when the replica is created, then there is no identity associated with said replica. This could be a potential workaround if you are able to give it a test. Could you expand on your use case? Beyond sharing a single device and large data footprints, what other uses would you have for multiple field workers being able to sync the same replica? Could you outline how you envision the workflow panning out if this idea were implemented? Would a replica be created with a set list of users it is shared with, or open for any logged in user to sync? Please feel free to add any notes you feel may clarify your request. Thanks, Scott ... View more

Hello Danielle, Thank you for submitting this idea! This is likely expected behavior, since the area chosen at the time the data was downloaded is the bounding box for the offline dataset (and its associated replica maintained in the database). How often does this present a problem for you? Did you encounter any issues collecting the data or saving your edits on the device? Or did you only encounter error messages when you attempted to sync? Thanks, Scott PS: when voting for this idea, please consider sharing your perspective on this workflow. Is this something you've encountered in the past? ... View more

Hello Brian, Thank you for submitting this idea! There are a few options today that might help you avoid orphaning data that may not have been handled before any modifications were applied. A resource like the AGO Assistant can be used to quickly see which services are included in a particular web map. If you are aware of all feature services your modified data is included in, the Replicas resource will show every current replica that is checked out. In most cases, this will show the identity of the user that created the replica, and when they downloaded or last synchronized their offline edits (Replica Info). The information above is meant to share how you can manage this issue today. The information is out there, but there is no tool covering the task you've outlined with this idea. Thanks, Scott PS: when voting for this idea, please consider commenting to share how you are currently handling offline data and change management. ... View more

Hello Stanislav, Thanks for submitting this idea! I've modified the title of your idea a bit to better convey your request. To clarify, are you looking to collect a simple point feature, but allow the additional geometry collection for spatial attributes for that feature? In your example, it looks like this is the case: where the feature will have one location on the map, but the additional attribution is collectible through the editing form. I like the screenshot you've mocked up. This really helps clarify what you would like to see in the app. Thanks, Scott PS: when voting for this idea, please consider leaving a comment to share how this would be beneficial in your workflows or projects. ... View more

Hello Stanislav, Thanks for submitting this idea! I've modified the title of your idea a bit to better convey your request. To clarify, are you looking to collect a simple point feature, but allow the additional geometry collection for spatial attributes for that feature? In your example, it looks like this is the case: where the feature will have one location on the map, but the additional attribution is collectible through the editing form. I like the screenshot you've mocked up. This really helps clarify what you would like to see in the app. Thanks, Scott PS: when voting for this idea, please consider leaving a comment to share how this would be beneficial in your workflows or projects. ... View more