Data accountability and transparency are well-established principles most organizations embed in their business plan. Having a framework that ensures the accountability requirements are met helps increase the trust and credibility of your data.
In ArcGIS, you can use the editor tracking tool to track edits made in a geodatabase. It helps track details such as who created or edited a feature class and when.
In the following scenario, the Swiss Federal Office of Energy uses editor tracking to enforce quality control standards between their public office and private turbine manufacturing companies.
Context
The Swiss Federal Office of Energy (SFOE) has announced a sustainable energy strategy in which their primary goal is to increase domestic wind energy production by 7 percent.
To plan for this change, each wind facility is required to perform base assessments for all the country’s wind turbines. Part of the base assessment includes turbine condition checks, current production assessments, and operational status updates. These are important factors to accurately predict the potential increase in energy.
During this assessment period, the manufacturers will send system operators into the field to test and compile a report for these base assessments.
To enforce quality control standards on the field assessments and maintain transparency between the private turbine manufacturers and the SFOE, all data edits and information about the editor must be recorded. The project manager is wondering how they can record these changes in the database. The GIS specialists recommended enabling editor tracking on the Wind Turbines feature class.
How can editor tracking help maintain data accountability?
Editor tracking is a data management tool that records information about any additions and updates made in a geodatabase. It records who created or modified the data and a time stamp of when the edit occurred.
Editor tracking helps maintain data accountability by automatically tracking the following information:
- User who created a feature
- Date and time that the feature was created
- User who last edited a feature
- Date and time that the feature was last edited
How the editor tracking capabilities adapt to this project?
Editor tracking recorded values
Information recorded by the editor tracking |
Your project details
Associated details from the project feature class (e.g.,the Wind Facilities feature class) |
User who created a feature | Manufacturer company who built the wind turbine |
Date and time the feature was created | Year of construction of the wind turbine |
User who last edited a feature | System operator who performs the base assessment in the field |
Date and time the feature was last edited | The timestamp of when the last edit was made for the base assessment |
What edits aren’t recorded | How this affects project goals |
– Changing the schema without modifying column values
– Adding or deleting fields – Copying and pasting a feature class |
The system operators performing the base assessment are database users with editing privileges. They can only make changes to the wind turbine attributes and are not allowed to make any schema changes. |
After reviewing how editor tracking can benefit our project, how do we implement it?
Implementing Editor Tracking
In ArcGIS Pro, you can enable editor tracking on your data using the following methods:
- Check the Editor tracking option on the Manage tab in the Properties dialog box.
- Use the Enable Editor Tracking geoprocessing tool.
For this workflow, you use the first option, the Manage tab.
1. Access the Manage tab from the context menu of the Wind Turbine feature class.
Once the Editor tracking option is checked, the page populates with the default fields and data types designated to track the edits.
- created_user (Text)
- created_date (Date)
- last_edited_user (Text)
- last_edited_date (Date)
When editor tracking is enabled in ArcGIS Pro, these fields will automatically be created and added to the feature class.
Since there are already fields that store the manufacturer and creation date in the feature class, you will adjust the default fields for editor tracking to better fit your geodatabase schema.
2. Building on the table above, for each role and recorded value, map the appropriate field to store the edit information.
Editor tracking recorded values | Geodatabase default fields that store recorded values | Your project details | Editor tracking fields for the feature class schema (Wind Facilites feature class) |
User who created a feature | Creator Field | Manufacturer company that built the wind turbine | Assign existing field: Manufacturer field |
Date and time the feature was created | Created Date Field | Year of construction of the wind turbine | Assign existing field: Year of Construction field |
User who last edited a feature | Editor Field | System operator who performs the base assessment in the field | Add New Field: System Operator field |
Date and time the feature was last edited | Edit Data field | The date when the last edit is made for the base assessment | Use Default field: Last Edited Date field |
3. Back to the Manage tab, on the Creator Field drop-down menu, choose manufacturer field.
4. On the Create Date Field drop-down menu, choose yearOfConstruction.
5. On the Editor Field drop-down list, select the Add new field. Name the new field system_operator.
6. For the Edit Date Field, leave the default field.
When done, the Editor tracking fields should look like this:
Notice the fifth option, Time standard. The date and time will be recorded in either UTC or database time.
- UTC (coordinated universal time) is the default and recommended setting. UTC is required for datasets registered as branch versionedor for any data that will be shared through services with editor tracking enabled. As a best practice, use UTC when your workflow involves data distributed across time zones.
- Database time is based on the local time zone in which your database resides and should only be used when your data is confined to the same time zone. In this scenario, it is Central European Time (CET).
Because the data will be shared through services, keep the default value of UTC.
Test the editing experience
Before the editors start making changes, it is important to test the editing workflow.
In the example below, Wind Turbine #3 has the following attributes:
- The feature creator is the Aventa manufacturer.
- The creation date is 12/31/2001, which is the construction year.
- The system operator and the last edit field are currently null. This is because no edits have been made to the feature since editor tracking has been enabled.
If a change is made to one of the attributes—for example, increasing the Rated power value from 6.5 kilowatts to 7 kilowatts—and the change is applied, edit tracking will record the following:
- The system_operator is OWNER, the user who made the edit.
- The last_edited_date field is 10/18/2022, the date of the edit.
But who is the user OWNER and how does editor tracking record usernames?
In this example, OWNER is the database user who loaded and manages the wind turbines feature class; therefore, they are the data owner. This is the GIS specialist connected to the SwissEnergy enterprise geodatabase as the data owner user using database authentication.
In general, editor tracking records the name of the user who creates or edits a feature based on the authentication method used to access the file, mobile, or enterprise geodatabase.
- When a user connects to a file or mobile geodatabase to edit data with ArcGIS Pro, editor tracking records the username based on the login name used to sign into the operating system. This remains valid when a user connects to an enterprise geodatabase through operating system authentication.
- When connecting to an enterprise geodatabase using database authentication, the username recorded by the editor tracking is the valid database username stored in the database. When using database authentication, an employee can connect as different database users, depending on the task needed to perform. For example, the GIS specialist can connect as an editor and make edits to the Wind Turbines feature class on behalf of one of the manufacturing companies.
In this scenario, the base assessment process has started, and several system operators have already made edits to the Wind Turbines feature and updated the operational status.
Editor tracking successfully recorded all the important edit information. It recorded who created a feature, who last updated an existing feature, and when they did so.
You now know what editor tracking is and its benefits. You followed a scenario-based workflow, where the Swiss Federal Office of Energy successfully used editor tracking as a solution to maintain wind turbine data accountability during the base assessment process performed by the system operators. Editor tracking helped record the username of each system operator and the timestamp when they made edits.
But what happens when the same feature is edited by multiple editors? For example, a wind turbine feature is edited by system operator Elena, and then Gigi redoes the base assessment and determines one of the metrics is incorrect and it changes the operation status. Editor tracking will only record the edit made by Gigi, as she is the last editor. But what happens to Elena’s edit and how can it be accounted for? More importantly, can editor tracking keep a record of multiple edits, or is a different data management tool needed? These questions will be addressed in a follow-up blog.
Acknowledgments: Swiss Federal Office of Energy (SFOE) and Esri Suisse for the Wind Energy Plants dataset.
Photo by Waldemar Brandt on Unsplash
Commenting is not enabled for this article.