Understanding Geodatabase Editing Workflows Advanced d Robert Rader & Tony Wakim ESRI Redlands
Prerequisites Attended the previous technical session: Understanding geodatabase editing workflows: Introduction or Working knowledge of multi-user geodatabases and Basic Working knowledge of multi user geodatabases and Basic knowledge of DBMS technology
Overview Review Planning Change Management Maintenance Resources
Review: Enterprise geodatabase Required software environment ArcObjects ArcSDE DBMS Enterprise Geodatabase Operating system A
Review: Multi-user geodatabase editing options Non-versioned editing Versioned editing with move to base Versioned editing Editable data types Simple feature classes Simple feature classes All data types Supported workflows Simple Simple & advanced with versions Archiving /replication not supported Simple & advanced with versions Archiving & replication supported DBMS transaction type Short (single edit session) Long (multiple edit session) Long (multiple edit session) Supports No Yes Yes undo/redo Feature class tables involved Base table Base & possibly delta tables Delta tables Supports archiving & replication No No Yes Supports DBMS data integrity features Yes Yes - when editing DEFAULT version; after save No when editing other versions No
Overview Review Planning Requirements Options / Scenarios With versioned data With non-versioned data Change Management Maintenance Resources
Business workflow requirements Process and time scale will differ for each organization Editing task/process may encompass Individual modification Group of modifications Time may span seconds, hours, months, and possibly years Editing workflow is often part of a larger business workflow May include versioned and/or non-versioned workflow Business workflow Reporting, making maps, etc. Editing workflow Business workflow
Business specifics Get Answers for Maintain different business needs, such as: Editing g source Non-ESRI client access Quality Assurance (QA) Ensure timely and accurate database changes Usability for editors
Editing Source Exclusively with ArcGIS applications ArcGIS understands versioned and non-versioned editing Edit simple and complex data structures ArcGIS and non-esri applications Non-ESRI applications do not recognize versioned editing May require implementing DBMS behavior Options: Non-versioned editing Versioned editing with move to base option Versioned editing with multiversioned views
Workflow strategies to support editors Multiuser geodatabase editing supports two data maintenance strategies Without versions* With versions, including: Multiversioned views* Geodatabase archiving* i Geodatabase replication move to base option* * Allows for Non ESRI integration
Editing Options Available (Versioned) Create version workflow Dependent on organization size and workflow Complex projects require more elaborate workflow Presents structure for departments and business cycle Can facilitate tracking of versions Parent Owner Parcels Creation date DEFAULT QA Zoning Different scenarios can increase management complexity Potential ti performance impact
Directly edit DEFAULT (published database) Simplest version workflow to manage Units of change modest in scale No workflow stages Saved changes committed immediately to the DEFAULT version Edits visible to the published database Saving user resolves conflicts Edits to DEFAULT (user 1) DEFAULT version User 1 saves User 2 saves edit session edit session Edits to DEFAULT (user 2)
Multiple editors editing same version Multiple users can simultaneously edit the same version Saving performs implicit reconcile and post on the version Saves happen without lock errors Resolve conflicts upon save Conflicts must be dealt with immediately Unable to reconcile to parent while others editing DEFAULT Edit
Multiple versions DEFAULT Editing children of DEFAULT version DEFAULT represents as-built One or more child versions exist
Multiple versions Editing children of surrogate DEFAULT version Surrogate used as target Protects DEFAULT version Prevents unauthorized/unintentional modifications Reconcile and post from surrogate to DEFAULT Can be used as QA tier DEFAULT
Multiple versions Versions can be based on projects Tasked with maintaining specific entity or project Tasks may be logically divided based on resource or location Supports complex projects Supports batch reconcile/post process B DEFAULT A C
Multiple versions Editing versions that represent business unique stage from design to approval Can bypass parent, post to DEFAULT A stage may have its own cycle Design DEFAULT 0 Proposal Approval 2 Alternativesti Construction ti Acceptance Maintenance
Version tree hierarchy Reconciling with common ancestor Serial process Must wait for ancestor to be available Conflicts must be resolved in sequence Reconciling in a separate lineage Non-serial process Performance degradation during concurrent reconciliations
Simultaneous reconcile actions Exclusive lock on target version during reconcile Prevents target from simultaneous reconciliation Held until reconcile operation is complete Dependent on number of states and hardware resources
Protecting versions and separating users Protecting versions and separating users DEFAULT version is considered current, asbuilt, state QA monitored with surrogate tier Example: Protect MANAGER.QA as reconcile and post target Separate users by responsibility Private versions can persist
Reconcile feature class privileges Reconcile copies edits from edit into target lineage User performing reconcile requires write privileges to feature classes modified in child lineage Edits inserted to A and D tables
Post to target that has been posted 1 Edit made to each child Child 1 reconciles 2 Child 1 reconcile finished Child 2 reconciles 3 Child 1 posts P 1 P 1 1 C1 2 3 C2 C1 2 3 C2 2 3 C2 AM 1 4 5 Child 2 attempts to post Post fails 5 7 AM 1 AM 2 P/C1 5 AM 1 7 AM 2 1 3 2 C2 A P/C1 5 7 Posts fails. The parent version was posted to state 5 before 2 nd child could post AM 1 AM 2
Unexpected conflicts Reconcile looks for common ancestor state All edits on lineage up to ancestor state are reviewed for conflicts Reconcile and post workflow will determine if unexpected conflicts occur
Unexpected conflict example DEFAULT, PARENT, and CHILD at same state DEFAULT 0 PARENT CHILD
Unexpected conflict example DEFAULT, PARENT, and CHILD at same state Edit DEFAULT (Object #10) 0 PARENT Edit CHILD (Object #11) DEFAULT 1 2 CHILD
Unexpected conflict example DEFAULT, PARENT, and CHILD at same state Edit DEFAULT (Object #10) Edit CHILD (Object #11) Reconcile and post CHILD with PARENT DEFAULT 1 0 2 4 PARENT CHILD
Unexpected conflict example DEFAULT, PARENT, and CHILD at same state Edit DEFAULT (Object #10) Edit CHILD (Object #11) Reconcile and post CHILD with PARENT Reconcile and post PARENT with DEFAULT Edit which occurred to Object #11 copied to state 6 Edit CHILD (Object #11) PARENT DEFAULT 1 6 0 2 4 7 CHILD
Unexpected conflict example DEFAULT, PARENT, and CHILD at same state Edit DEFAULT (Object #10) Edit CHILD (Object #11) Reconcile and post CHILD with PARENT Reconcile and post PARENT with DEFAULT Edit that occurred to Object #11 PARENT copied to state 6 6 4 CHILD DEFAULT 1 0 2
Unexpected conflict example DEFAULT, PARENT, and CHILD at same state Edit DEFAULT (Object #10) 0 Edit CHILD (Object #11) Reconcile and post CHILD with PARENT 1 2 Reconcile and post PARENT with DEFAULT Edit which occurred to Object #11 PARENT DEFAULT 6 4 copied to state 6 9 Edit CHILD (Object #11) Reconcile and post CHILD with PARENT Common ancestor is state 0 7 CHILD Conflict detected on Object #11 between edit at state 6 and state 7
Conflict Management: Simple Feature Classes Follow the logic outlined in the conflict dialog. Was it edited d by more than one person, if so raise a conflict. 30
Conflict Management: Relationship Classes Rule 1: Preserve referential integrity When edits are made such that the result of the reconcile will violate referential integrity in the relationship class, conflicts are produced. Rule 2: Preserve attribute and geometry value consistency between related objects The geodatabase logic is essentially that differences that are related to conflicts become conflicts. The conflicts may be due to normal editing conflicts or the result of rule 1.
Conflict Management: Networks With network features, changes to either the geometric features or logical elements may create conflicts How conflicts are handled within the Conflict Window impact the connectivity of features Geometric coincidence is considered during Reconcile and Conflict replacement Disconnected state of a feature is not Conflicts can be propagated due to changes within the logical network Features can be in conflict that were not directly edited 32
Conflict Management: Topology New topology errors may occur when versions are reconciled (i.e., potential conflicts occur), even if each edit version has been validated and is free of errors. Doc:Topology_and_versioned_geodatabases Doc:Topology_rules_poster 33
Conflict Management: Terrains Regular g Feature Classes: normally, as if they didn't participate in a terrain. Embedded multipoint feature classes: An edit is performed at a tile level. If a tile is edited in more than one version, it is a conflict. Doc: Multiuser_editing_and_versioning_of_terrain_dataseediting of terrain datase ts Note: Whether you modify data in regular or embedded d feature classes, you might need to rebuild the terrain after reconciling. 34
Conflict Management: Cadastral Fabrics Do not follow the logic outlined in the conflict dialog. Feature Level conflicts only, Child always wins Doc:Working_with_cadastral_fabric_jobs_and_versioning Doc:Adjusting_features_in_a_versioned_environment f t i i d i t 35
Conflict Management: Representations Same as simple feature classes, they are just fields Doc:Frequently_asked_questions_about_representation Doc:Working_with_representations_in_a_versioned_environment
Workflow without versions Supports simple workflow Uses underlying DBMS transaction model Edits are performed within standard DBMS transaction Edits within an edit session are saved as one transaction Once saved, edits are available to all other sessions DBMS behavior is permitted Triggers Readers: ArcGIS and 3 Unique indexes rd party Constraints ArcGIS 3 rd party Data
Non-Versioned Editing Workflow Demo
Overview Review Planning Change Management Schema Changes Data Changes Adding Functionality Scaling Maintenance Resources
Schema change Some changes are allowed on versioned data Adding a column Some changes require you Unregister As Versioned Creating Topology Creating Geometric Networks Knowledge Base Doc: 29885
Unregister As Versioned: Outstanding edits Warning: Edits remain in delta tables Option: Compress edits in DEFAULT lineage to base Edits in other versions are lost Not Necessary for Migration 0 71 DEFAULT 76 78 Zone_mgmt
Functional Change: Archiving GDB Archiving provides ability to Store changes that happen on data View data as it existed at a point in time Run Spatio-Temporal p queries on stored data Need to make sure to account to data storage space as Archiving is enabled
What is Geodatabase Replication GDB Replication is a data distribution method in ArcGIS Different than RDBMS replication Only Data changes detected since the last synchronize is replicated Can replicate between different RDBMS venders Ex: update object 1, delete object 1; only delete will be replicated. Requires versioning. Can be defined d on a spatial extent t 43
Using Geodatabase Replication to Scale Important to plan Schedule synchronizations for non-peak times Make sure that all changes have been acknowledged 2 way replicas make sure to occasionally send changes between replicas Compress after synchronize 44
Overview Review Planning Change Management Maintenance Versioned data Versioned and non-versioned data Resources
Maintaining Versioned Data Performance Impact Remove old / unnecessary versions Reconcile / Post your versions Compress Compress Compress
Maintaining Versioned and Non-versioned Data Performance impact Update statistics Will impact DBMS execution plans Before compress with versioned data Rebuild DBMS indexes Removes Fragmentation Backup
Alternative: Re-reconcile all versions DEFAULT Child 1 reconciles 0 Child 1 posts 0 Child 2 reconciles Child 2 posts 0 Child 2 reconciles Child 2 posts 0 Child 2 2 1 2 1 Child 2 2 1 2 1 reconcile Child 1 DEFAULT, Child 1 4 Child 1 4 4 4 DEFAULT, Child 2 6 DEFAULT, Child 1,Child 2 6 In this case Child 1 does not see the most recent updates to default vesion DEFAULT pointing i further down the state tree Re-reconcile every version with DEFAULT and save All version now point to the same state as Default (See same changes) Compress All rows compressed back to base tables DEFAULT, Child 1, Child 2 0
Example of including maintenance in your workflow Create versions Perform edits Update DBMS statistics, Rebuild Indexes Reconcile and post versions Resolve Conflicts Compress Versioning workflow
Overview Review Planning Change Management Maintenance Resources
Other Sessions Geodatabase Essentials Part 1 Wed 1:30 pm Room 6C \ Fri 8:30 am Room 10 Geodatabase Essentials Part 2 Wed 8:30 am Room 4 \ Thurs 8:30 am Room 3 \ Fri 9:00 am Room 4 - Managing Distributed Data with Geodatabase Replication Tues 3:15 pm \ Thurs 10:15 am Room 6D Topology in the Geodatabase Tues 1:30 pm \ Thurs 8:30 am Room 6C Geometric Networks in the Geodatabase Wed 1:30 pm Room 3 Working with Raster Data in ArcGIS Wed 1:30 pm Room 6D Editing with ArcGIS Tips and Tricks Wed 8:30 am \ Thurs 10:15 am Room 3 Geodatabase Editing Workflows An Introduction Wed 8:30 am \ Thurs1:30 pm Room 6C Geodatabase Editing Workflows Advanced Wed 10:15 am \ Thurs 3:15 pm Room 6C
Other Geodatabase Resources Geodatabase Resource Center - http://resources.esri.com/geodatabase/ Inside the Geodatabase Blog - www.esri.com/geodatabaseblog
Questions? Thank you for attending UC2008 Technical Workshops