Utility Network Versioning
In today’s Utility Network article, we will examine the technology, principles and practices associated with database versioning.
Before we delve into the topic, perhaps the most important point for new or intermediate GIS users to take away from this article is what versioning is not – it is not a copy of data. Throughout this discussion, and along with visual support, there will be a tendency for many GIS users who are unfamiliar with versioning to frame the discussion as a copy of data – viewing database versions as a copy of data will lead to an incorrect understanding of the technology. It will also diminish what this author views as one of the most advanced components in ArcGIS.
Versioning is a data editing scenario that allows multiple users to simultaneously edit the same data without applying locks or duplicating the data. Versioning accommodates long transactions, which allows data editors to work in isolated versions (not copies) of the geodatabase and across many edit sessions. When the editor has completed all of their edits, they can merge their changes back into the parent (default) version from which their version was created. Versioning is only available in an enterprise database and administration of versions requires ArcGIS Pro.
All of these changes that data editors make within a version are still within the single parent database. The process does not create copies of the layers or copies of the assets or create another database. These changes to the data are all tracked in a comprehensive set of system tables that work to retain the data integrity and functionality of the database at any of its state of changes. “State” is a keyword in that these system tables literally track the state (representation) of the database at every change. Since there is only one database involved, it requires quite a level of sophistication to track, manage and reconcile all the data edits (including data deletes).
A good example of the need and use of database versions, and long transactions, would be a new subdivision within a city or town. A new subdivision takes time to implement in the real world; a variety of planning related documents are required, surveys are implemented, parcel boundaries are set, lots are developed, roadways are developed, utilities such as sanitary sewer, water distribution and electricity are developed. It is a significant undertaking with many different disciplines and fields taking place.
Let’s say I work in a water distribution utility as a GIS editor. I will be tasked with implementing the as-built representation of the water distribution network (perhaps the design representation as well, but that is another article), if it is a large subdivision - it could take many days, perhaps weeks, to implement. Rather than GIS viewers seeing the ebb and flow of this process the GIS editor can create a new named version, perform all the data editing required, deal with any problems encountered, and when completed, post those changes to the default version for all users to see. From the user’s perspective they will receive all this data at once as a finished product. They will not endure the steady progression of editing and changes, rather, they will receive a complete and final representation with complete integrity. The GIS editor can post their changes when the subdivision is complete or at any interval required (phase 1, phase 2, phase 3, etc.).
Another example would be a neighborhood which is scheduled to undergo a voltage conversion in an electrical distribution system. Since this sort of activity in GIS may take some time for the editor to implement, it can also be viewed as a long transaction. Other GIS users may be adversely impacted by the editor working directly with the default version. In this case, the editor can create a named version, implement the voltage conversion parameters with integrity and then post back to the default version when it is complete. GIS viewers of the default version are provided the new voltage conversion data in real time when it is posted by the editor, saving them from the confusion or incomplete data necessary during the data editing process.
These are just two examples of versioning scenarios; the technology allows for many sophisticated work processes to be implemented.
Branch Versioning
While users familiar with geometric networks may be familiar with versioning, they should be aware that ArcGIS Enterprise has implemented a new type of versioning – Branch Versioning. Branch versioning works with the ArcGIS Enterprise web GIS model and uses a services-based architecture to extend multi-user editing and long transaction support to the web, via feature layers. This advancement should be appreciated by senior and advanced users of geometric networks – versioned editing is extended to web maps, truly a remarkable advancement in GIS! Branch versioning comes with its own requirements and parameters, GIS administrator need to become familiar with them.
While editing in a named version can go extremely far in providing data editing integrity, there will always be potential for multiple editors to edit the same asset differently and the versioning engine in utility network will flag such edits as conflicts during the reconcile and post process. Included in the version technology is a sophisticated conflict management resolution environment. When a user reconciles against another version and an asset containing a conflicting edit is discovered, it will present the user with an overview of all edit states: the user’s own edits, the second person’s edits, and the default version of the asset. This allows the user to investigate and confirm what the proper state is (it may not be their own edits) and then proceed to accept one of the other states or override with their own state.
When planning a versioning work process users should be aware that there is no ability to do partial reconciles/posts of data. The version engine works across an entire database and a subset of data within an active versioned edit session cannot be parsed out as a type of limited, or targeted, reconcile and post. Such a process could end up compromising the integrity of the database.
Compression
Finally, for GIS administrators in geometric networks and versioned work process, we should discuss compression. Database compression is a part of a database administrators, or GIS administrators, regular maintenance routines. In short, this is done to remove unnecessary states and improve database performance. As the GIS administrator of a very large municipal and utilities database for more than two decades, I can attest that there are times when this can be a time consuming, and stressful task, even when automation is utilized. With branch versioning these days are over, the premise of branch versioning is that the state tree is not compressed as a regular administration process.
It should be noted that at the time of writing this article, there is still an open discussion on ESRI’s “Ideas forum” regarding whether there should be a tool in ArcGIS Enterprise for ‘pruning’ the state tree. Readers can access the thread here to monitor this discussion which has been on-going for many years - perhaps compression will be re-introduced.
Final thoughts
Database versions is a comprehensive GIS subject, but represents one of the most powerful aspects of an advanced corporate GIS. There are many more aspects to this technology that users will need to learn about and use, while GIS administrators involved in migrating to utility network will be required to understand changes such as branch versioning.
Acorn Information Solutions launched its MonARC Data Migration platform to help corporations implement, or migrate to, a Utility Network. We have decades of experience in creating and administering municipal and utilities based Geometric Networks combined with knowledge and experience in Utility Network migrations.
About the Author
Craig Martin is Acorn’s Municipal and GIS Manager and has over 25 years of experience in the field of GIS. Craig has extensive experience in data modeling, data capture, administration, solutions architecture, and smart data networks in a variety of engineering disciplines. Connect with one of our experts at info@acorninfosolutions.ca
Be sure to take a look at our
Terms of Use and Privacy Policy.
The Sault Ste. Marie Innovation Centre is committed to providing an accessible website. If you have difficulty accessing content, have difficulty viewing a file on the website, or notice any accessibility problems, please contact SSMIC to specify the nature of the accessibility issue and any assistive technology you use.
SSMIC will strive to provide the content you need in the format you require.
SSMIC welcomes your suggestions and comments about improving ongoing efforts to increase the accessibility of this website. Please contact us at
info@acorninfosolutions.ca