Field work season is fast approaching. Are you getting ready to deploy a new data collection approach with a paperless workflow to save time and money? If so, have you considered how you will track who changed what feature and when, to ensure accuracy? Let’s take a look at tracking edits settings you can leverage for various ArcGIS deployment models.
As soon as the snow melts, your field workers will be out there to collect data – on things such as asset conditions and their locations, species stock, water quality and others. This means multiple hands will be touching the data you maintain year-round. Have you considered the impact editing conflicts could have when multiple users are working on the same data at close interval or at the same time? What about tracking who did the last edit to improve quality control? ArcGIS has tools at your disposal that can help you maintain accountability and enforce quality control standards in your organization.
Tracking edits in ArcGIS Desktop (for office and field users)
While some of you are doing field work on a laptop using only ArcGIS Desktop, other users in your office may be performing routine data edits daily using the same application and accessing the same geodatabase. Since version 10.1, ArcGIS Desktop users can enable “editor tracking”, which is available at all license levels.
Editor tracking records the creator’s name, the created data and time, the editor’s name and the date and time of the last edit on any existing dataset. This information is added to the attribute fields of the dataset when edits are made in ArcGIS Desktop for personal, file and enterprise geodatabases. This enables you to follow changes to your data.
When this setting is enabled, note that you can track changes for existing datasets only. If fields are deleted or created within a dataset, the tracking values will not reflect it unless you are working in a multiuser geodatabase, which will be covered later in this blog post.
Also, the archiving tools mentioned above are not available with basic desktop licenses.
A good rule of thumb is to coordinate who’s working on which dataset in the same geodatabase each day to avoid editing conflicts like locked datasets or lost edits. Good communication among team members is required to assure quality control is maintained.
Tracking edits made with ArcGIS field apps
If your team will use Collector or Survey 123 for ArcGIS to collect or edit data in the field, did you know that there are several tracking settings available, depending on your deployment model?
No matter which environment you choose, our instructor-led course Field Data Collection and Management using ArcGIS, coming up in May, can provide you with the workflow to deploy the full suite of field apps efficiently, so you can coordinate your field crews and gather project status updates in an easy-to-configure dashboard.
Let’s look at the different tracking options.
Tracking edits in the ArcGIS Online environment
One editing rule applies in ArcGIS Online: the last edit wins!
If this could be problematic for assuring data quality in your team’s workflows, you will need to define tracking settings for each hosted feature layer on you own. This needs to be considered when you get ready to share your content. As the owner, when you choose to allow others to edit your layer, you need to record all login information, including the time when edits were done on features. You can choose one or both of the following options during the sharing process:
- Keep track of created and updated features
This option lets you see changes made to spatial and non-spatial attributes. It tracks what was added, updated or deleted, and it disables overwriting.
- Keep track of who creates and updates features
If you want to track editors’ logins and have control over what they can see and do, you can choose one of the following options under “What kind of editing is allowed?”
- Add, update and delete features
- Add and update features
- Add features
- Update features
- Update attributes only
You can also limit the features editors see with these options:
- Editor can only see their own features
- Editor can only edit their own features
In general, field crews do not usually edit the same feature at the same time without noticing it. However, if unrelated workflows bring users to edit the same feature on the same day (for example, when communication between teams is missed), the last recorded edit wins and overwrites the edit that could be the most important, without anyone noticing. With these tracking settings in place, you can prevent a user from editing a feature, or you can go back and figure out after the fact whose edit should have been kept and make the appropriate corrections.
Read more about tracking settings in ArcGIS Online.
Tracking edits in the ArcGIS Enterprise environment
With ArcGIS Enterprise, the same tracking settings listed above for ArcGIS Online are also available for Portal for ArcGIS. In addition, other options are available for all feature services published with ArcGIS Server. See Portal online help and ArcGIS Server online help for details.
In this environment, a multiuser geodatabase is deployed. This usually comes into play when many users create and maintain large amounts of GIS data in a central location. It goes without saying that this scenario increases the possibility for conflicts and corruption of the master geodatabase. Therefore, database administrators need to leverage all advanced tracking and data access settings to achieve data quality control.
To protect your master (default) geodatabase from deletion mistakes and unauthorized edits, geodatabase administrators can implement versioning.
Versioning your geodatabase lets you isolate editors, by allowing them to use only a version of the master geodatabase without duplicating the data. This enables them to securely complete edits before the changes are reconciled and posted to the master geodatabase and become visible to everyone. This conflict management feature reduces and, in some cases, eliminates time-consuming manual validations. To take it a step further, your organization could set up a quality assurance (QA) version where all project versions would go before getting posted to the master geodatabase. It is recommended that you determine early on what versioning model would best fit your organization to keep it simple and efficient.
Three examples of versioning workflows. Read this ArcUser article for more on versioning.
Read more about versioning. You can also sign up for our instructor-led course Implementing Versioned Workflows in a Multiuser Geodatabase coming up in May and June to learn how to implement versioning in your organization.
After your geodatabase is versioned, you can now deploy it to your field workers with peace of mind. At this point, you should consider performance and synchronization. Have you ever waited for data to upload from a server in your office while you’re in the field? If yes, you will like geodatabase replications.
Regardless of remote users’ connection to the web, this option offers the ability to create a regional or local copy of the data, retrieve data quickly or save local copies on mobile devices. This sounds like doing a “copy and paste” of your data, but it’s much more. After users have completed their edits, the synchronization process starts. During this phase, related replicas send changes from one to the other for reconciliation and posting before it reaches the master geodatabase. This option uses versioning, so it tracks all changes made in each replica for full control over who and when, and it automatically manages conflicts when predefined rules are in place.
Check out our instructor-led course Distributing Data Using Geodatabase Replication coming up in May and August.
I’ve just covered the three main deployment environments in this blog post; if you have questions about a specific scenario, please leave a comment below.