3 Pillars for Vertical Asset Management Success

The once common saying “GIS is a fast-growing field” is quickly becoming outdated.

It’s now widely apparent that utilizing advanced Geographic Information Systems (GIS) technology to represent spatial data is vastly superior to the once-mighty pen and paper. GIS is quickly establishing itself as a critical tool for organizations to catalog, inventory, and manage their programs and assets.

However, a major functional gap in standard two-dimensional GIS data (consisting of points, lines, and polygons) is how to represent data oriented in a small, concentrated, or vertical configuration in a three-dimensional (3D) setting. Complex facilities such as power plants, water treatment plants, and wastewater treatment plants, which often contain many floors and complex arrays of concentrated assets stacked directly on top of each other—are notoriously difficult to map and represent using GIS data. This can greatly limit the effectiveness of GIS in these large and often mission-critical facilities.

A solution to this gap is the use of vertical assets—a technique that links non-spatial tables to GIS spatial data, greatly increasing the ability to store and represent large amounts of data in a small geographic area. While creating, implementing, and maintaining an effective vertical asset program requires considerable time and resources, this does not exclude smaller organizations from creating and launching successful programs of their own. Here are some essential components to consider when thinking about creating a vertical asset program for your organization, large or small.

Pillar 1: The Map

Setting up the map and deciding how, where, and what layer the vertical assets will start from is a very important decision that shapes the flow, direction, and user interaction of the entire program.

Vertical assets enable you to efficiently organize and identify records in tables by geographic features that you define. Polygons are good for encompassing large areas such as buildings, rooms, or process areas within a facility. Points can represent more granular or specific features such as control panels or pump assemblies. If a polygon is too big and encompasses too many assets, then it becomes more difficult to find what you’re looking for. If it’s too small, it can become tedious and difficult to manage, maintain, and interact with. An empty warehouse may have 10 related records, and a control panel may have 100. Defining the type and scope of the geographic feature needs to be addressed on a case-by-case level.

Park City uses a polygon layer called “Water Facilities,” which represents everything from pump stations to rooms of treatment plants. Pump stations are comprised of fewer assets and can be represented by individual polygons. Conversely, treatment plants contain immensely more assets and are more adequately represented by several different polygons pushed together.

Pillar 2: The Database

If the map is the facade of the vertical asset program, the database is the foundation. The database structure dictates how the tables relate to each other and to the source feature

within the database. While there are countless approaches for setting up database structures, I’ve identified three simplified methods: simple assets, complex assets, and systems.

Simple assets is when a single table is directly related to the feature class and only goes one layer deep.
Complex assets involve multiple levels of nested related tables, where an object table has a hierarchical relationship to other object tables expanded in lower levels. This could be an asset that has component tables that can go as many layers deep as necessary.
The systems approach organizes object tables into thematic groups, such as “electrical system” or “mechanical system,” that contain all tables relevant to that group. Park City has developed a database structure consisting of 30 tables grouped and organized into 7 systems.

This is not an intuitive process and might take several iterations to get it exactly how you want it. There is no such thing as too much planning since changes can be more difficult to make after you implement them. A good approach for building your database structure is to think backwards by identifying what you want the data to look like and then building the structure from there.

Pillar 3: The Dream Team

Building, implementing, and maintaining a vertical asset program can be challenging and complex, especially for a small municipality. The most crucial factor to success is the team behind the effort. From the beginning, this effort should be a collaborative process involving individuals at all levels of the organization. Every team member, from the director to the end user, offers a unique perspective and can help ensure that the program being developed will work at all levels

One of the most successful aspects of Park City’s vertical asset program was the management team’s identification of the need to include all operators throughout the development and implementation process. This entailed reworking schedules to ensure adequate time for operators to train, learn, and participate in program utilization, which encouraged operators (end users) to more efficiently participate in the data collection process.

Creating an effective vertical asset program for your organization is no small undertaking; however, with the right resources applied, it is certainly not out of reach for small organizations. Determining the feature layer, developing the database structure, and ensuring a collaborative effort across the entire organization will lay the groundwork for a successful vertical asset program.