Select to view content in your preferred language

Best Practices for Storing data outside of the Utility Network

562
5
03-28-2025 04:16 AM
BogdanHristozov
Occasional Contributor

Hello everyone,

We are in the process of migrating to the Utility Network, and while we have successfully mapped all network classes to their respective asset groups and asset types, we still need to determine the best approach for storing non-network data.

In our current setup (ArcGIS 10.8.1 with geometric network), we store non-network data such as special property rights (polygons), landbase datasets, cadastral data, non-spatial tables for maintenance reports etc. All this in the same enterprise geodatabase but within separate datasets. As we transition to the Utility Network, we want to follow best practices for storing this type of data in the new environment.

Specifically, we are looking for guidance on:

  • Database structure: Should non-network data be stored in the same database as the Utility Network but in a separate dataset, or is it better to use a separate database?
  • Versioning: We plan to use branch versioning for all data, not just Utility Network feature classes. However, some of these non-network datasets require versioning, while others do not. What is the recommended approach for handling versioning in such cases?

Any insights or best practices from those who have handled similar migrations would be greatly appreciated.

Thanks in advance!

0 Kudos
5 Replies
RPGIS
by MVP Regular Contributor
MVP Regular Contributor

So it is best to keep it in the same database, or if needing to manage it separately, have a sql job only push copies to that database. Reasons being are as follows:

  1. Having all features in the same dataset or having a sql job that only updates a table with specific attributes will allow for you to utilize attribute rules. Otherwise a tool. process, or script will be needed to update certain attributes if those attributes are derived from the parcel layer.
  2. In addition to the answer above, if there are certain criteria that has to be met, such as automatic easements, identifying whether something is public or private, or any combination of things then it would be best to keep everything in the same database.

As for versioning, it all depends on the direction you plan on taking, branch works best if you are using small datasets and have a strong network connection, otherwise you will need to use the traditional versioning method. Any layers in a non-dataset do not have to be versioned unless there is a single layer in the non-dataset is versioned in which case the entire dataset will be versioned. Ideally you want to separate out your non-versioned feature classes and/or tables so that any non-versioned data is stored separately.

BogdanHristozov
Occasional Contributor

Thank you for your response. I plan to keep the data in the same database but organize it into different datasets based on data type and versioning strategy.

Initially, I hoped to use a single versioning approach for all data, but it now seems best to separate Utility Network-related data from the rest. To simplify management and improve scalability, I will likely create a separate user schema for non-UN data. However, I’m curious about how this will impact editing workflows.

I'm not sure if it's even possible to edit branch versioned and traditionally versioned data simultaneously, or if separate workflows will be required for each. This topic is turning out to be more complex than I initially anticipated, and new questions keep arising. I'll need to run more tests to fully understand the implications.

0 Kudos
RPGIS
by MVP Regular Contributor
MVP Regular Contributor

It is possible to use both branch and traditional but it mostly depends of how the datasets and/or feature classes are set up. You can have one set of features outside a dataset use a different editing version than features within a dataset. You can't edit simultaneous features within a dataset using different versioning methods. 

0 Kudos
CherylTrine
Frequent Contributor

I want to make sure I understand.  I know all feature classes within a dataset must use the same type of versioning.  Suppose I have a utility network which uses branch versioning, another dataset in the same database which uses traditional versioning (e.g., building info containing feature classes for footprint, levels, spaces, etc.) , and a feature class that is not within a feature dataset that uses traditional versioning.  Can I edit features from the utility network and building info simultaneously?

0 Kudos
RPGIS
by MVP Regular Contributor
MVP Regular Contributor

You can make edits to them simultaneously because the features are in different datasets using different versions.

To clarify, if a feature class in a dataset is versioned using traditional then the other feature classes in the same dataset cannot be set to batch. If there are feature classes in the same database but in separate datasets with one using traditional versioning methods and another using batch then both features can still be edited.