Harnessing distributed collaboration for forest restoration

In the Differences view, the portal administrator confirms that 58 tree activities have been recorded in the first synchronization, 57 new features and one update to an existing feature.

After reviewing some of the attributes of the newly collected features, the next step is the QA/QC process. The portal administrator reconciles, reviews possible conflicts, and posts the named version.

First, the portal administrator reconciles the collaboration version using the Reconcile option on the Versioning tab of the ribbon.

A pop-up appears with the message that conflicts have been detected. The portal administrator will next review the conflicts.

The Conflicts view appears. It lists any feature classes that are in conflict. In this case, the Trees activities feature class is listed. The (1) after its name indicates that it contains one Update-Update conflict. This type of conflict means that the feature was updated in both the current and target versions.

The information grid displays the attribute values for all representations of the feature. In the current version the tree condition is listed as Poor and the maintenance status is set to Plantation required. In the target version, which is the default version, the same tree feature has the attribute Healthy as the tree condition and Routine check as the maintenance status.  

After expanding all the fields, the portal administrator looks at the Ownership_Code field and confirms that the edits in the target version are made by an organization employee who reconciled and posted their edits to the default version. Whereas in the named version the edits were made by a volunteer.

The portal administrator resolves the conflict in favor of the target version and keeps the edits made by the employee.

Finally, the version administrator marks the conflict as reviewed and saves the edits made in the Conflicts view.

The edits in the collaboration version can be posted to the default version.

The default version now has the most up-to-date edits, and this version becomes available to the entire USFS organization.

Note: To learn more about performing version administration and quality control on branch versioned data, follow the  Reconcile and post versions  tutorial.

The above process—make edits in ArcGIS Field Maps, send edits to ArcGIS Online, sync the workspace to make the edits available to ArcGIS Online, reconcile and post—will be performed multiple times until the entire area of interest is assessed by the field volunteers.

When the project is complete, the collaboration between these two organizations comes to an end. The guest, the ArcGIS Enterprise organization, leaves the collaboration.

The host then deletes the collaboration.

On the guest side, the named branch version is not contingent to the collaboration. The version can be further used to make edits in ArcGIS Pro, reconcile, and post.

On the host, ArcGIS Online, the Collective Forest Restoration hosted feature layer is not deleted and can be further used by the organization. In this example, the D&J Forestry Initiative is utilizing the hosted web layers to power a publicly accessible dashboard. The purpose of this dashboard is to showcase the work they do and inspire volunteers to get involved.

This story illustrates a workflow example where two organizations are sharing data to support forest restoration using distributed collaboration. Now that you learnt the ins and outs about how you can share data with other organizations using distributed collaboration, it’s your turn to apply this approach in your own workflows.