With Esri's ArcGIS Pipeline Referencing (APR) tools having been released for the past three months, I thought it would be good to post about some of our lessons learned through our first Esri APR implementations. SSP has been on the forefront of the new technology and have had a number of clients make that call to have SSP help them along for an Esri APR implementation. Here is what we learned.
It was not a surprise that vertically integrated gas utilities were the first operators to go down this path (or at least the first we have worked with). I believe there are a couple reasons behind this:
The Utility Pipeline Data Model (UPDM) can be used for a pure transmission operator, but it really appeals to gas operators. This is because they can now house both their distribution and transmission assets within the same enterprise geodatabase. These operators have been wanting all their gas assets in the same network since ArcView 3.3 … being on the leading edge of some new technology isn’t going to stop them!
Pure transmission operators (gas or liquids) have historically stored their data in our industry standard models, PODS (Relational/Spatial) or APDM. With PODS Next Generation on the horizon and the perceived jump from APDM to UPDM as being a huge project, we’ve found our pure transmission friends are road-mapping and planning prior to making the move.
Lastly, since UPDM is the ultimate destination for gas utilities, operators are taking a phased approach and moving over the transmission data now. They are looking towards distribution down the road. Knowing that distribution data will be moved to the schema in the future, we can migrate transmission data now, stand up 10.5 server and ArcGIS environments and utilize the APR extensions. The distribution side of the house can thoroughly plan their migrations around Utility Network, design tools and a much bigger migration project.
With SSP’s first migrations and deployments being on UPDM, we need to remember that UPDM is a database template. The Esri team has done a great job in establishing the framework for our data, but extensions had to be made to a number of existing feature classes and additional feature classes/domains were added to support our clients' transmission data.
One example of this relates to how pipe characteristics are storied in UPDM. In our current data models we have PipeSegment, Coating, etc., that now exists in UPDM on P_Pipes. For each implementation thus far, we also found that operators had extended these features in PODS or APDM, so we had to account for fields that were tied to risk or MAOP calculations (and also didn’t have another logical spot in the new model). Plus, since P_Pipes also stores distribution pipeline assets, the extension requests can be lengthy! This is just one example moving to the new model, but certainly something to consider across the board as you plan the move.
The next major consideration is how the pipeline routes will be stored in the new model. In the past, we stored pipelines and systems in our StationSeries and LineLoop/LineLoopHierarchy tables. Moving forward, we have a chance to review your systems hierarchy and make some key decisions. Do you still need both an Engineering and Continuous Network moving forward?
Do you even reference historical stationing anymore within your system? Can everything be tied to one continuous pipeline length and re-routes (addition/subtraction of pipe) simply update the total M/length value? All of these items need to be considered and now is the time to make these updates...if your pipeline GIS and integrations can support it. Who wants to manage equation points anyways?!?
Once the data model schema is ready and key decisions on pipeline representations have been made, it's time to start standing up the APR architecture. We have discussed in the past some of the key software and version dependencies, i.e., Enterprise 10.5 and Desktop 10.5 for APR 1.0, so we will focus on some of the new components and licensing.
Licensing can be a bit confusing, but that isn't the case with the APR web event editor. There is a single enterprise APR server license used to authorize and deploy the event editor. Obviously, there are some ways to streamline the deployment, add Active Directory access, establish security, etc…but from a licensing standpoint for APR on the web, it's one and done.
For Pro and APR Centerline editing, there are a couple licensing models to choose from. The easiest way is to utilize named users and tie the Pro License and the APR license to that named user. The screenshot below shows how these licenses are assigned to named users. In this case, the user simply logs on to Pro and the extension is available. Note that APR is included in the Pro 1.4 (and future) installations, so no need to hunt down the APR executable, it was installed with Pro!
Other options are to establish a single-use Pro license and then provision APR as a single use on the same machine. There are some pros/cons to this, but that’s for another day. Implementing the products in this architecture, we converted a named user license for Pro to a single use key and Esri generated a single use APR (Pro) license for this purpose. For our first couple implementations, the single use key for APR wasn’t automatically recognized in APR (as in, didn’t come up in the extension list), but Esri quickly hopped on the issue and we knocked out our authorizations.
So let's assume we have all the APR tools installed and licensed in Desktop, Pro and Enterprise. Now it's time to start migrating or loading data. We have been through APR implementations from scratch (empty enterprise GDB) and also within a UPDM environment that has had data already migrated to it. Regardless of your path, it is highly recommended, that you create the APR core outside of the enterprise GDB and migrate it to the destination once its complete. Our team found that we had some issues with recognizing certain projections and other ‘gotchas’ when trying to stand up the LRS network, LRS events, etc within a fully populated UPDM.
We found that our must successful path in this case was to create the features/tables/LRS Networks (listed below) externally to the enterprise GDB and migrate them over. By doing so, the features/data that had been previously migrated (outside the core) will assume the LRS Network properties and users can proceed with using the APR applications.
P_Centerline, P_ContinuousNetwork/P_EngineeringNetwork, P_CalibrationPoint, P_Redline, Centerline_Sequence, LRS Network(s), LRS Events (and the associated LRS tables in the process)
If your organization has the opportunity to start fresh and in an external FGDB, the tools provided with APR will greatly streamline the data loading. Not only should you use the tools for creating the LRS Networks, loading routes and calibration, but they are also very easy to use tools for bulk data loading. Try out the handy tool Append Events (Location Referencing) to load data to an existing feature class!
Overall, our clients have provided very positive feedback using the web event editor and Pro centerline AP tools. It has been great to watch advanced GIS pipeline editors, and others who are newer to GIS, quickly adapt to the APR extension and workflows. From SSP’s perspective, each implementation gets easier and easier and Esri certainly has provided a toolset and process that will help all editors who manage pipeline GIS data.
If you have any questions or want to learn about our APR Jumpstart feel free to reach out!
SSP Innovations Pipeline Team