Quality assurance/quality control process - HxGN EAM - 11.07.01 - Feature Briefs - Hexagon

Important: Any reference to a local geodatabase or local data below, only applies to when the map is being operated in offline mode. When operating the map in online mode, any edits to the data are immediately posted to the GIS server and are not stored locally on the device.

In the context of EAM Mobile Transit, the Quality Assurance/Quality Control Process (or QA/QC) refers to the process by which user uploaded edits are validated, checked for accuracy, and approved. ESRI supports multiple workflows for this process, which are outside the scope of this document.

See ESRI’s official documentation to learn more about this process.

Below are links you may find helpful:

• https://blogs.esri.com/esri/arcgis/2010/09/15/developing-a-quality-assurance-plan/

• http://desktop.arcgis.com/en/arcmap/10.3/manage-data/editing-fundamentals/synchronizing-local-edits-with-the-server.htm

• http://desktop.arcgis.com/en/arcmap/10.3/manage-data/editing-fundamentals/about-editing-data-from-feature-services.htm

• http://resources.arcgis.com/en/help/main/10.2/index.html#/Preparing_data_for_offline_use/0154000006m1000000/

When the initial GIS Sync operation is performed in the EAM Mobile Transit Application, a Geodatabase file is created on the local iOS Device. This Geodatabase is specific to the current user. If multiple users share the device, then each user will have their own local Geodatabase where data is stored.

After user’s have edited their local data, they will want to sync their changes back up to the Feature Server. Feature Server changes are pushed down to the device on each manually initiated sync. Every time the GIS Sync operation occurs, if any local edits are present, they are uploaded to the Feature Server.

If any local edits are pending, users are notified of the number of pending edits each time they log in to the Map View screen. Additionally, if any errors occurred while attempting to upload local edits during a previous sync operation, the user will be notified of the count of errors. Users can see the details of any sync errors by visiting the Sync Errors item in the GIS Map Settings menu.

Feature servers can be created with two different types of sync support: PerLayer and PerReplica.

In the PerReplica scenario:

• Any GIS edits performed by the user on their local device will be synced to the user’s version on the server. From there, administrators can incorporate whatever QA/QC process they prefer to sync the changes into their production geodatabase.

• In addition, a choice can be made as to how versions are created during sync. Create a version for each 1) Downloaded Map {the default selection} 2) User. See the screenshot below for details.

ArcGIS server Manager < Service < Capabilities < Advanced Options

The table below details replica (version) handling on the GIS server during sync based on the Downloaded Map/User selection and whether the feature server is secured or not:

Over time, if the GIS administrator does NOT manually perform a ‘reconciliation’ process on the GIS server or clean-up outstanding versions on the GIS server, these DB versions will continue to grow in number. If this process will not be performed manually on a periodic basis, ESRI recommends using a script to do so automatically. Here is a link to their recommendations on this subject and some sample code:

• https://desktop.arcgis.com/en/arcmap/latest/manage-data/geodatabases/automate-reconcile-post-after-sync.htm

  Supporting documentation:

• https://support.esri.com/en/technical-article/000011719

• https://enterprise.arcgis.com/en/server/latest/publish-services/windows/offline-maps-and-versioned-data.htm

• https://enterprise.arcgis.com/en/server/latest/publish-services/windows/editor-permissions-for-feature-services.htm