Episode 99: PODS Technical Discussion with Jackie Smith and Christopher Moravec

This week’s Pipeliners Podcast episode features Jackie Smith and Christopher Moravec of PODS discussing the technical aspects of the Pipeline Open Data Standard.

In this episode, you will learn the importance of the PODS organization to the oil and gas industry, what to expect with the upcoming release of PODS 7, the importance of a common data modeling system, and the implications of the new PHMSA safety rules.

Show Notes, Links, and Insider Terms

Jackie Smith is the president of PODS and a GIS IT Architect for Williams. Connect with Jackie on LinkedIn.
Christopher Moravec is the Chair of the PODS Data Modeling Team and the CTO of dymaptic. Connect with Christopher on LinkedIn.
PODS (Pipeline Open Data Standard) supports the growing and changing needs of the pipeline industry through ongoing development, maintenance and advancement of the Data Model and Standards. PODS also serves as a member association to maintain the PODS Data Model.
The Pipeline Open Standard is a database schema (architecture) for pipelines. It functions by creating populated database information relevant to the life-cycle of a pipeline.
- PODS 7 is the latest version of the Pipeline Open Data Standard, released in May 2019. [Members-only access]
- The PODS Association is a not-for-profit industry standards association that develops and maintains the PODS Data Model — the pipeline data storage and interchange standard for the oil & gas industry.
APDM (ArcGIS Pipeline Data Model) is a pipeline data modeling system. Eagle Information Mapping (Eagle) is a group of pipeline data modeling experts.
- APR is core spatial database structure.
- ArcGIS Pro is the latest professional desktop GIS application from Esri.
- ArcGIS Pipeline Referencing provides GIS-based capabilities to effectively and efficiently perform pipeline linear referencing data management.
- ArcMap is the main component of Esri’s ArcGIS suite of geospatial processing programs, and is used primarily to view, edit, create, and analyze geospatial data.
FME (Feature Manipulation Engine) is a platform that streamlines the translation of spatial data between geometric and digital formats.
ISAP (Information Security Automation Program) is a U.S. government multi-agency initiative to enable automation and standardization of technical security operations.
SQL server is a relational database management system developed by Microsoft.
SDO (Service Data Objects) is the name of a specification designed to streamline the processing of SOA (service-oriented architecture) data from diverse sources such as XML documents, relational databases, and web services.
ST is used by programmers to construct a geometry from a well-known text representation.
QSQL is a standardized query language for requesting information from a database.
SQLite is a relational database management system that is embedded in the end program, as opposed to a client-server database engine.
ESRI is an international supplier of geographic information system software, web GIS, and geodatabase management applications.
UPDM is the product of an Object Management Group (OMG) initiative to develop a modeling standard that supports both the USA Department of Defense Architecture Framework (DoDAF) and the U.K. Ministry of Defence Architecture Framework.
GIS (Geographic Information System) is a system designed to capture, store, manipulate, analyze, manage, and present spatial or geographic data.
Cathodic Protection (CP) is a technique used to control the corrosion of a metal surface by making it the cathode of an electrochemical cell.
AGA 3 (and API 14.3) describe the design and installation parameters for measurement of fluid flow using orifice meters and other devices, and provide a reference for engineering equations, uncertainty estimations, construction and installation requirements, and standardized implementation recommendations for the calculation of flow rate through orifice meters.
Orifice Plate is a device used for measuring flow rate, for reducing pressure, or for restricting flow.
TVC (Traceable, Verifiable, and Complete) records support pipeline integrity management by verifying the condition of pipelines.
HCA (High-Consequence Areas) are defined by PHMSA as a potential impact zone that contains 20 or more structures intended for human occupancy or an identified site. PHMSA identifies how pipeline operators must identify, prioritize, assess, evaluate, repair, and validate the integrity of gas transmission pipelines that could, in the event of a leak or failure, affect HCAs.
ERD is an entity-relationship model that describes interrelated things of interest in a specific domain of knowledge.

Full Episode Transcript

Russel Treat: Welcome to the Pipeliners Podcast, episode 99, sponsored by EnerSys Corporation, providers of POEMS, the Pipeline Operations Excellence Management System, SCADA compliance, and operations software for the pipeline control center. Find out more about POEMS at enersyscorp.com.

[background music]

Announcer: The Pipeliners Podcast, where professionals, Bubba geeks, and industry insiders share their knowledge and experience about technology, projects, and pipeline operations. And now, your host, Russel Treat.

Russel: Thanks for listening to the Pipeliners Podcast. I appreciate you taking the time, and to show that appreciation, we are giving away a customized YETI tumbler to one listener each episode. This week, our winner is Scott Hardin with Shawcor Inspection Services. Congratulations, Scott, your YETI is on its way. To learn how you can win this signature prize pack, stick around until the end of the episode.

This week, we have Jackie Smith returning and Christopher Moravec on for the first time to talk about PODS and to give us a technical overview of the Pipeline Open Data Standard.

Chris, Jackie, welcome to the Pipeliners Podcast. We are sitting here at the gorgeous Embassy Suites Hotel in Downtown Houston, Texas. Actually, it is a pretty nice hotel. We’re looking at the pool and wishing we were having this conversation at the pool, but it’s too windy, right? Mess up the mic. [laughs]

Anyways, thanks for inviting me out. I’m really excited to have this conversation, because PODS is something I’ve been looking to learn about. Maybe we’ll just start with some brief introductions. Jackie, you were on recently. Why don’t you remind the listeners?

Jackie Smith: Sure, I’m Jackie Smith with Williams. I’m an IT architect there, and I’m also serving as the PODS president, doing that role, and been in the database NGIS realm for about over 20 years now.

Russel: Chris, why don’t you do likewise? Maybe a little bit more, because you haven’t been on before. You’re the technical geek. Well, we’re all technical geeks. You’re just more geeky in this domain than the rest of us.

Christopher Moravec: Yeah, databases. Databases are one of my things. Christopher Moravec, I have been a software developer for about 10 years, mostly in the pipeline space, although now, I do a lot more things than that. I’m the CTO of a company called dymaptic.

One of my roles now is to be the technical coordinator for PODS, which means I help make sure that all the volunteers are getting things done, and have what they need, and fill in all of the technical gaps that they have.

Russel: Awesome. What kind of projects have you done in pipelining?

Christopher: Pipelines. I used to maintain an entire set of maintenance tools for PODS and APDM back in the day when I worked for Eagle Information Mapping. We had software that did all of this.

Russel: Have you grown up more as a GIS guy than as a relational database guy? Or some of both?

Christopher: Actually, my first job was writing stored procedures in an Oracle database.

Russel: Oh my gosh.

Jackie: That’s relational.

Russel: That’s relational. Yeah, cool. For anybody who’s out there that’s never written a stored procedure for an Oracle database, that’s…I don’t even know how to describe that. It’s a pretty arcane language. I’ll put it that way.

Christopher: Yes, definitely.

Russel: It’s pretty arcane. They’re tough to work with but very powerful.

We talked recently about what PODS is. What I want to do is take a little bit of a deeper dive. To do that, set a little context. PODS is obviously a data standard. Why do you need a whole committee to work on a data standard?

Christopher: It’s basically because engineers are obsessed with standards. I don’t think it matters what kind of engineer you are, you’re obsessed with those standards.

Russel: Chris, what do you mean by obsessed?

Christopher: We all know that engineers like rules of thumb. We all like something to follow. I’m technically an electrical engineer, although I’ve never practiced. We’re just as obsessed with standards and rules of thumbs as all other types of engineers.

Software developers, although may not be technically engineers, are just as obsessed.

Jackie: Correct, and while we need a committee, as well, we don’t want just one entity telling us what those standards are. We’d like a collaboration to answer the question of companies, of organizations. That’s what PODS has been around since ’98.

It’s been a group of individuals from companies, and from organizations, and from service providers or vendors that have volunteered their time to build this data standard.

Russel: I’m picking on Chris a little bit, trying to have a little fun. Obsessed is maybe not the word I would pick.

[laughter]

Russel: Certainly, engineers are, we’re driven by standards. If we end up in a new discipline or a new technology, we all experiment with it, but we really don’t start using it until we have standards around it.

We need standards to be able to use in a way that’s predictable, so we can get to a predictable outcome. It’s not like running an experiment, where the outcome is maybe not very predictable.

Christopher: Right.

Russel: Standards allow you to get to a predictable outcome. “I do A, B, C, D, E, and I get to result F,” that kind of thing. We’re obsessed with getting to result F. That’s the way I would say it, Chris.

Christopher: Yeah, I think that’s a totally fair way to put it. It’s important that pipelines have standards for stuff like this, because we need to make sure they’re safe.

Russel: What standards does PODS address in the pipeline domain?

Christopher: Basically, its goal is to standardize data storage and organization so that…

Russel: That’s every standard.

Christopher: That’s probably true.

[laughter]

Christopher: PODS standard doesn’t dictate how you operate a pipeline. It’s really just, how do I store it, and how am I storing that data so that I can retrieve it in an organized way, and then I can do other things with it?

How can I do my federal reporting? How can I do my risk assessments? How can I do my HCAs? You’re storing it in a standard way so that you can then power those other types of analyses, so that you can then make better decisions.

Russel: When I ask the domain of standards, you’ve got…I’ve been doing a lot of reading, researching, and talking about pipeline SMS. You’ve got your cathodic. You’ve got your right of way. You’ve got your HCA stuff. You’ve got your leak detection and your control room.

All these various groups have data. I guess what I’m trying to get is, what is the boundaries of the data that PODS is trying to standardize?

Christopher: At its core, location.

Russel: Basically, pipe, ground, things around the pipe, things in the ground.

Christopher: Yep.

Russel: That way.

Christopher: Yeah, if you didn’t use it for anything else, storing its location, and even if you didn’t put any attributes about that pipe, you stored that in some other system, you store the location in PODS.

Jackie: That’s how it started. It’s really morphed and evolved into an asset system of record for all of your infrastructure pipeline. Your appurtenances or assembly’s tied to that, your locations, your crossings, which we’re calling locations, your conditions, your operations, all those type of things. We can go into that more if we need to.

Russel: Well, we might want to. I think this is interesting. You’re talking about location, and then you talk about all the information about that. Before we got on the mic, we were talking about how PODS started as a transmission company.

You guys are now coming out with PODS 7, which is more than just transmission. Tell us a little bit about PODS 7, what it covers, and what are the challenges. What technically made that hard?

Christopher: PODS 7, which I guess maybe obviously, is the seventh release of PODS. PODS has a long history of several versions, one through six, but they’re all very similar, just extensions of each other. Seven is a complete rebuild from the ground up, starting from scratch, essentially.

It wanted to solve several problems, but the main ones are, we wanted one place where we could have gathering, transmission, and distribution. You can have one database, where you can model everything from the wellhead all the way to the house.

We also wanted to have a new set of core location tables, so that I don’t have to always use linear referencing. Before PODS 7, the only way you put it in PODS was using linear referencing. With PODS 7, you can have things located just by a point on the Earth, by X Y, or you can have them located by measure on a linear reference center line.

You can even mix those together in the same database. You can really…

Russel: Being a guy who’s done some database design, that’s starting to sound really hard.

Christopher: Hard, maybe, but it’s all documented now. The model’s built for this. All of the attributes are already there and everything’s defined. It probably is hard, but you can do it now.

Russel: Figuring out how to do that…This raises a question for me as I’m thinking about this. If I’m somebody who was on PODS 6 and I want to migrate to PODS 7. You said that’s…I would call that a big lift. It’s not an incremental change. It’s a transformational change in what you’re doing with the data model. How big a deal is it to migrate from 6 to 7?

Jackie: We’re trying that at Williams right now. We’re actually migrating from a previous version to PODS 7. It has really been an effort of relying on our service providers and our IT staff to assist in making that transformation. Just the regular Bubba geek may not be able to go in there and do that without a little help and assistance.

What we’ve had to do is write scripts to take that data. You map a field to what it’s supposed to be in the new model. You do a script, if you will. We use FME. I don’t know if anyone in the audience has heard about that tool. We use that tool. That’s getting into the weeds, but that’s how we did it.

The good thing about PODS 7 is there is something called a data exchange standard, which…I don’t know if Chris wants to speak more about that, but it’s actually a container, if you will, that you can program to get your data from one version of PODS to another with the help of a IT developer or a service provider.

Christopher: From a service provider point of view, when I used to do this kind of stuff, it’s not going to be unlike moving from ISAP, which was a data model before PODS for storing pipeline data, to PODS because you’re going to be mapping a lot of attributes.

If you’ve got a pipe segment in PODS 6, it’s going to map into PODS 7 pretty easily because we’re still storing diameter, and wall thickness, and all of those things because it’s the same stuff. Getting that core out of PODS 6 and into PODS 7 is a little bit more complex. It’s not as bad as having to go back to paper and digitize paper alignment sheets or something like that.

Russel: The other thing is it’s for my core data I would expect that to be relatively straightforward. For things that are outside of my core data, like I’m…If I had an old PODS and I’m taking that data and moving it into the new PODS, that’s one problem.

If I had an old PODS and then several other databases that had several other things, that I can now put all that into the new PODS, that’s more complex.

Christopher: Totally. I guess, probably, one of the other problems is that, right now, the initial PODS 7 release is kind of limited. It doesn’t have all of the same modules, and tables, and extensions that we have in PODS 6. We’re still working on things like the ILI extension. We’re still working on a lot of those to try to get them migrated into PODS 7.

There aren’t always destinations yet for every piece of data.

Russel: Oh, that’s even a bigger problem.

Christopher: If you have a really full PODS 6, very rich PODS 6, it will be harder to get there today. Those modules are coming soon.

Russel: You just have to wait until the model’s more mature.

What database platforms are you supporting?

Christopher: You pick one, almost. We’re actually doing a really good job of managing this because we’ve built one logical model. We can support multiple physical databases.

Right now, we’re supporting SQL Server, Oracle with both an SDO and an ST geometry type, a post-QSQL database, and an Esri geodatabase, and now SQLite, which is a very lightweight, single file database that you could use for field data collection or something like that, maybe, in the future.

Russel: Interesting. I would assume that there would be some ability to even do PODS across several of those platforms. Could somebody do that if they chose to? Is that starting to limit what you can do with PODS?

[crosstalk]

Russel: I’m fortunate. I’m sitting here with Chris. You should see the look on his face when I asked this question.

Christopher: Yeah, sure. You could do that.

[laughter]

Russel: You would question whether you would want to.

Christopher: I would definitely question why a person would want to do that, but totally if you had different divisions and different IT structures.

Russel: I’m even thinking about different use cases. You mentioned doing field work. Field work lends itself to doing something in SQLite.

Christopher: Yes.

Russel: In terms of that data and the way it’s structured, it’s pretty simple. Looking at all of my pipe and all of my reporting, it doesn’t lend itself to SQLite at all.

Christopher: Not if you’re a big operator.

Russel: True.

Christopher: If you’re a big operator, I’m not going to put the whole thing in SQLite. You could, but I wouldn’t.

Russel: Where’s the line between big and little?

Christopher: That’s a good question. I don’t have an answer to that one.

Jackie: Another way to think of it is single use versus multi-use. If I use a file geodatabase, if I’m at one service provider or one contractor to put data into it to transform and to migrate into my final PODS database, we’re building a new project.

I’m going to give them a one file geodatabase. They’re going to populate it with the PODS information. We’re going to take it and put it into our enterprise geodatabase which sits in Oracle.

Russel: Being a guy that knows a little bit about data, you’re not talking about an application. You’re talking about a repository. That’s a big distinction. It raises some questions about, do you have in the PODS standard things like triggers or queries or any kind of data processing? Is that all completely outside of the data standard?

Christopher: That’s basically all completely outside the data standard. Traditionally, PODS has steered really far away from trying to step into building software to manage this. Service providers and vendors have done the bulk of that.

With PODS 7, we’ve taken some extra steps here. We’re debuting at the conference this week the idea of having business rules, which is our way to express things like triggers that might process data or protect your database from…

Russel: Maybe you could unpack it a little bit. What’s a business rule? If I’m not a software guy, what is a business rule?

Christopher: My favorite example in the pipeline space is making sure the diameters match. If I put a valve in, my outlet diameter better match the pipe segment next to it, because if it doesn’t something’s wrong. I shouldn’t be able to put that in the database.

Russel: That’s an example of a rule where something physically couldn’t happen. What are some other kinds of business rules?

Christopher: It’s really anything that I want to protect in that database or that I want to happen a certain way in that database.

Russel: I’ll use a measurement example because it’s a little clearer to me. If I have an orifice meter, the size of my orifice plate hole cannot be larger than the physical internal diameter of the pipe I’m in because that’s just nonsense. It physically can’t exist.

Christopher: It just wouldn’t work.

Russel: There’s also a standards based rule, which says the standard says if you’re going to measure according to AGA 3, then it should be…Your beta ratio, the ratio between your orifice plate size and your internal diameter pipe, should be between 0.25 and 0.75.

I can physically install a plate that’s 0.8 or 0.2, but it’s outside the standard. That’s a business rule that you probably also want to flag, but you’d want to be able to diverge from.

Jackie: We want to capture those things in the database. Those things may be in a manual. They may be in a company standard or on your engineering drawing. We want to capture those things in the database where it’s important and where it necessitates things like TVC where you have to trace and verify something in your pipeline if, for example, there was ever an incident.

Russel: That sounds simple. No, it’s not simple. It actually doesn’t sound simple at all.

As I’m thinking about this and I’m thinking about all the various technical domains…Maybe I don’t know a good way to tee this question up, but we had talked before you all were on the mic about APIs and how you have to have your business rules clear before you can build your API. API, being an Application Programming Interface, a way to get data in and out of the model.

What are you all doing around APIs?

Christopher: We’re just at the beginning of APIs right now. It’s been something that PODS has talked about for a long time, but with PODS 7 we actually have a standard that’s documented really well. One of the things we’re talking about at the conference this week is what should an API look like? What structure should it take?

The proposal that we’re making to the organization is that an API should be how do I interface with this database? How do I load data? If I’m going to load the data, what format should it be in? What should be in the database when I’m done?

We’re trying to avoid this middle ground where we tell a vendor exactly what insert statement to run, but just what goes in and what comes out.

Russel: Being a software guy, I understand how challenging it is to define that. Where is that line? If you’re just a data structure, well, you’ve already got that in PODS. What’s the difference between defining a data structure outside and a data structure inside? How is that unique or different?

Christopher: For PODS, it’s really challenging because we’re not just talking about loading data. We’re talking about the ongoing maintenance of a pipeline, which includes doing things like, well, now I need to do a reroute because I’m physically moving the middle of this pipeline.

Having API constructs that describe this is the information I need to be able to do a reroute, this is what should happen. There’s a lot of moving bits in here that we’re trying to figure out how to describe.

Russel: I think one of the things that many people might not understand is that the location of a pipeline is dynamic. It’s not static. Ground moves. Water flows. Rocks tumble. Things happen. Over time, the center line of that pipeline moves.

You’ve got to know how has that occurred over time. All of a sudden, I have a mental framework in my mind. It’s just I’ve got an endpoint, and endpoint, and a straight line between the two. No, not really. That’s not actually what’s going on. What’s actually going on is I’m starting there when I drop it in the ground, maybe. I’m not going over a hilltop or something.

Over time, it looks nothing at all like that. Anybody’s that seen a picture of the Alaskan Pipeline above ground knows that it’s all in…It’s not a straight line. It looks like a little zig saw, right? The reason is, well, it expands and it contracts. It moves. It gets hot and cold.

All these things are occurring and all those things have to be recorded. That makes this seem kind of challenging for me.

One of the things I want to talk about… is the new gas gathering rule. I haven’t had a chance to look at it, but somebody in my office has scanned through it and said, “I didn’t see anything new or different.” That’s, at least…I don’t know if that’s comforting or not.

Jackie: New or different from what you expected?

Russel: From what was expected, yeah. I was going to say I don’t know if that’s comforting or not, depending on what’s…

Anyway, the gathering rules in there…There’s going to be a lot more need to start capturing data about gathering. Even if it’s not regulated, there’s going to be reporting requirements, even for the pipe that’s not regulated. That may include, likely will include in the not too far future, flow lines all the way down to two inches, at least in terms of having a record of they’re there.

What are you guys doing at PODS to address that impending reality?

Christopher: From a technical point of view, the model can handle this already. Even just putting in a table saying, “This pipeline exists.” We have places where you can do just that, even if you don’t know where it is right now.

Also the model can, if you know where it is and all you have is somebody who walked it with a GPS. You know where this piece of pipe is on the ground. We can handle that in the model today so you don’t have all of the overhead that you used to. Just load that one little center line and go on.

Russel: I can start with a very small data set and then build on it later as I collect more information.

Jackie: Meaning you don’t have to have a linear reference pipeline. Most of the gathering lines we work with at Williams, for example, they’ve never done linear referencing in that…

Russel: You find the same thing in the utilities, too. It’s all georeferenced.

Jackie: This model accommodates that.

Russel: They walk out with a GPS and they go, “Here’s a point. Here’s a point. Here’s a point.” It goes right into the database.

How do you work with the software vendors that are building tools that need to be able to shove data into this format or this standard?

Jackie: Currently, there are service providers that do have software that will hit the PODS 7 model. I think where we’re lacking, where we have a gap, is that we’ve built this structure and this architecture. We are needing service providers and vendors to write the applications and data maintenance tools on top of it.

That’s where the API comes in. That will assist in that development and open that up. I don’t know if that makes sense.

Russel: It makes sense. Again, when I’m thinking my eyes go back and to the right. I look like I’m spacing out. I’m thinking about what you’re saying. Intersys, one of the companies that we operate, is a software development company. We focus more on the control room, but when you talk about…

Here’s this data standard. It can be implemented on any database tool. I’ve got to build an application. I’ve got to build an application on a database. How does that relate?

Jackie: That’s where your physical implementation comes in. If I have an IT staff that can write a program, I’m going to do a relational implementation. If I am an ESRI shop, which is a proprietary software that…Maybe I shouldn’t have mentioned ESRI. We can scratch that part.

Russel: ESRI’s a big player in the space, obviously.

Jackie: They’ve written software. If you implement a geodatabase implementation, you have software already that can maintain that data because it’s in a geodatabase format.

Russel: I know nothing about ESRI. I know who they are.

Jackie: One of the implementations we talked about was a geodatabase. We say that in our documentation. How you edit a geodatabase right now, easily, I can buy software called ESRI GIS software. If I’m a shop that does that…

Russel: ESRI has lots of partnership with people who build apps that put that data into their model. Is the ESRI implementation PODS 7?

Christopher: It’s a little bit more complicated than that, but yes, qualified.

Russel: Yes, qualified. See, now…Anybody who’s a software person’s going to say, “OK. Tell me about the constraints.”

Christopher: Going back just a minute is that almost all of the software providers that are active in building software against PODS have participated in the process of building PODS 7. They’ve all been in there from the beginning and have all helped influence the way this is built.

Everybody’s been around. We all understand it. I think, for the most part, the vendors at least have a good understanding of the way the model works. Nobody’s really behind. It’s just a matter of getting software built.

Where it gets complex with ESRI is we actually provide two different ESRI implementations of PODS 7. One is a regular old ESRI geodatabase. I’m going to open up ArcMap or ArcGIS Pro. I’m going to edit things, move my lines around. I’m going to do stuff, just like I might do with SQL, although I wouldn’t try to manage this by typing SQL into my computer but I could, I guess, if I wanted to.

Russel: There are plenty of people who think that’s a good idea.

Christopher: Maybe that’s a whole different podcast.

Russel: Yes, it is.

Christopher: You can do that from the ESRI point of view, but ESRI also has a tool called APR, ArcGIS Pipeline Referencing, which itself is actually a tool to manage pipeline data in a data model. ESRI has their own data model called UPDM, which has the same core, a very similar core, to PODS 7.

That was all done on purpose because we wanted all of this to be interoperable. The PODS 7 core is compatible with ESRI’s APR. If you’re an ArcGIS shop, you can go and pick up ESRI APR and install all of the PODS 7 stuff and it will work.

Russel: The TLAs [three-letter acronyms] are overwhelming.

Jackie: We’ve done a lot of it.

Russel: Everybody knows what a TLA is, right? That’s a three-letter acronym. We will definitely unpack all this in the show notes so you guys can go back and translate what Christopher just said into something that most of us can understand.

I’m pretty geeky and I’m pretty technical. I got lost in that conversation. Let me try to play it back, I’ll try to simplify it.

Basically, ESRI, which is one of the major vendors in this space providing a geocentric database and the ability to interact with that data already has some implementations that support PODS 7. The trick is picking the implementation and understanding the limitations.

I want to wrap this up. I want to ask a question. It’s this. If you’re a gatherer and you’re getting hit with this new requirement to produce information, would you recommend using PODS? What would you recommend to them as how to start to do that?

Christopher: I would say yes, they should probably use PODS. There’s a free version of PODS called PODS Lite which has the bare minimum. You don’t have to be a complete database geek. Probably, I would say, you should just use the ESRI software, and you should just load information that you have into it.

If that’s just location, then just load the location of the center lines and start there.

Russel: Why do you make that recommendation, versus something else?

Christopher: Because I am a firm believer that you should be able to, and you can, start at a very basic level. You don’t have to implement a big, complex system to get started recording the location of your assets.

Russel: Then, over time, you can learn and get more detail as it makes sense?

Christopher: Yeah, you can always build up to a bigger version of PODS.

Jackie: Right, and you’re thinking ahead. This is a standard that most of the industry is using that, if you’re a company with any kind of future profit margin, you want to grow. You want to build something that’s a standard and that you can extend as you go along.

The PODS standard is something that has that industry backing and that has a long term plan. It’s not a template, if you will, built for a software. It’s a data standard built for an industry.

Russel: That’s exactly right. I’m looking at, these guys shared with me a copy of their data model. I’m trying to look at it on my screen. My screen’s not near big enough to be able to make sense out of what I’m looking at.

Christopher: You’re supposed to print it, put it on your wall.

Russel: Yeah, I think that’s probably what I’m going to do, because I think I need to understand all this.

Jackie: We’re going into the wallpaper business soon. We’re bringing it back.

[laughter]

Jackie: We’re bringing back wallpaper.

Russel: Oh, that would be just awesome.

Jackie: Real wallpaper.

Russel: Do an office, and paper it in the PODS data model.

Jackie: Yeah.

Russel: Oh, my gosh. OK, now, I know you guys are really geeks.

[laughter]

Russel: That’s hilarious. It’s obvious that there’s been a lot of thought. You’ve got a pretty complex ERD. I’ll throw out my own TLA.

[laughter]

Jackie: ERD, very good.

[crosstalk]

Russel: Entity relationship diagram, for those that don’t know.

Christopher: Technically, this is only a conceptual model.

Jackie: Ah.

[laughter]

Jackie: If we really want to get geeky, this isn’t really an ERD. Oh, boy.

Russel: No, I know.

[laughter]

Russel: Yeah, good. Good one. Nice comeback.

[laughter]

Russel: All right, we’re coming to the end here, guys. I think the thing that’s interesting to me about this is that, while the model itself is pretty robust, I think my key takeaway…I don’t think I have enough intellectual horsepower to get to three key takeaways on this one.

My key takeaway is there’s a fairly big leap from the data model to actually interacting with the data. You guys are not really addressing interacting with the data. You’re leaving that to the operators, the vendors, and all of that to figure out what’s the best way to interact.

Then you’re trying to make it easy for people to share the data, so that, as assets are bought and sold, as time marches on, the data becomes more consistent.

Christopher: Yeah. I view it as we need to have a way to store this data. We need to have a way to transfer this data from one person to another, and we need to have a standard way to do it, because we have to do a good job of tracking this stuff. Pipelines can be dangerous things.

Russel: Oh, yeah.

Christopher: They’re operated very safely, but we have to be responsible about storing all that data.

Russel: We can really only operate as safely as the data will allow us to operate, because we’re making decisions based on this information. That’s why having a well understood, industry common data model is so important, because it creates an ability for engineers to work on different assets, and yet have a common understanding about the state of things.

That’s a huge deal. It goes right, straight to safety. When you start bringing in things like your cathodic protection, your integrity management, and your other kinds of programs that are part of safely operating pipelines, it’s really, really very important.

What you guys are doing is important work, and I’m not sure I’m a big enough geek to hang with you guys.

[laughter]

Russel: I think I’m a pretty big geek, but I’m not sure I’m that big a geek.

Jackie: Oh, hey, I listened to your last podcast on Raspberry Pi and data analytics.

[laughter]

Jackie: I was like, “Whoa, these guys are cool.”

Russel: [laughs] Well, that’s just me talking in my domain. This is me talking outside of my domain.

Jackie: Well, hey, yeah, it’s interesting.

Russel: I’m going to wrap this up, just for the listeners. We’re going to be doing a couple of other episodes while this conference is going on. They’re going to release over time, but I think the PODS guys will be organizing this stuff and getting it on their website.

Hopefully, this is useful, and if you want to learn more, go to pipelinepodcastnetwork.com. Go to the episode page, read through the show notes, and you’ll find lots of opportunities to go even deeper into the geekdom.

Jackie: Thanks.

Russel: I hope you enjoyed this week’s episode of the Pipeliners Podcast and our conversation with Jackie and Christopher. Just a reminder before you go. You should register to win our customized Pipeliners Podcast YETI tumbler.

Simply visit pipelinepodcastnetwork.com/win to enter yourself in the drawing. If you’d like to support the podcast, the best way to do that is to leave us a review. You can do that on iTunes or Apple Podcasts, Google Play, Stitcher, SoundCloud, whichever podcast application you use on your smart device. You can find instructions at pipelinepodcastnetwork.com.

[background music]

Russel: If you have ideas, questions, or topics you’d like to hear about, please let me know on the Contact Us page at pipelinepodcastnetwork.com, or reach out to me on LinkedIn. Thanks for listening. I’ll talk to you next week.

Transcription by CastingWordsRussel Treat: Welcome to the Pipeliners Podcast, episode 99, sponsored by EnerSys Corporation, providers of POEMS, the Pipeline Operations Excellence Management System, SCADA compliance, and operations software for the pipeline control center. Find out more about POEMS at enersyscorp.com.

[background music]

This week, we have Jackie Smith returning and Christopher Moravec on for the first time to talk about PODS and to give us a technical overview of the Pipeline Open Data Standard.

We are recording. Chris, Jackie, welcome to the Pipeliners Podcast. We are sitting here at the gorgeous Embassy Suites Hotel in downtown Houston, Texas. Actually, it is a pretty nice hotel. We’re looking at the pool and wishing we were having this conversation at the pool, but it’s too windy, right? Mess up the mic. [laughs]

Russel: Awesome. What kind of projects have you done in pipelining?

Christopher: Pipelines. I used to maintain an entire set of maintenance tools for PODS and APDM back in the day when I worked for Eagle Information Mapping. We had software that did all of this.

Russel: Have you grown up more as a GIS guy than as a relational database guy? Or some of both?

Christopher: Actually, my first job was writing stored procedures in an Oracle database.

Russel: Oh my gosh.

Jackie: That’s relational.

Christopher: Yes, definitely.

Russel: It’s pretty arcane. They’re tough to work with but very powerful.

Christopher: It’s basically because engineers are obsessed with standards. I don’t think it matters what kind of engineer you are, you’re obsessed with those standards.

Russel: Chris, what do you mean by obsessed?

Software developers, although may not be technically engineers, are just as obsessed.

It’s been a group of individuals from companies, and from organizations, and from service providers or vendors that have volunteered their time to build this data standard.

Russel: I’m picking on Chris a little bit, trying to have a little fun. Obsessed is maybe not the word I would pick.

[laughter]

We need standards to be able to use in a way that’s predictable, so we can get to a predictable outcome. It’s not like running an experiment, where the outcome is maybe not very predictable.

Christopher: Right.

Christopher: Yeah, I think that’s a totally fair way to put it. It’s important that pipelines have standards for stuff like this, because we need to make sure they’re safe.

Russel: What standards does PODS address in the pipeline domain?

Christopher: Basically, its goal is to standardize data storage and organization so that…

Russel: That’s every standard.

Christopher: That’s probably true.

[laughter]

All these various groups have data. I guess what I’m trying to get is, what is the boundaries of the data that PODS is trying to standardize?

Christopher: At its core, location.

Russel: Basically, pipe, ground, things around the pipe, things in the ground.

Christopher: Yep.

Russel: That way.

You guys are now coming out with PODS 7, which is more than just transmission. Tell us a little bit about PODS 7, what it covers, and what are the challenges. What technically made that hard?

You can even mix those together in the same database. You can really…

Russel: Being a guy who’s done some database design, that’s starting to sound really hard.

If I had an old PODS and then several other databases that had several other things, that I can now put all that into the new PODS, that’s more complex.

There aren’t always destinations yet for every piece of data.

Russel: Oh, that’s even a bigger problem.

Christopher: If you have a really full PODS 6, very rich PODS 6, it will be harder to get there today. Those modules are coming soon.

Russel: You just have to wait until the model’s more mature.

What database platforms are you supporting?

Christopher: You pick one, almost. We’re actually doing a really good job of managing this because we’ve built one logical model. We can support multiple physical databases.

Right now, we’re supporting SQL Server, Oracle with both an SDO and an ST geometry type, a post QSQL database, and an ESRI geodatabase, and now SQLite, which is a very lightweight, single file database that you could use for field data collection or something like that, maybe, in the future.

[crosstalk]

Russel: I’m fortunate. I’m sitting here with Chris. You should see the look on his face when I asked this question.

Christopher: Yeah, sure. You could do that.

[laughter]

Russel: You would question whether you would want to.

Christopher: I would definitely question why a person would want to do that, but totally if you had different divisions and different IT structures.

Russel: I’m even thinking about different use cases. You mentioned doing field work. Field work lends itself to doing something in SQLite.

Christopher: Yes.

Russel: In terms of that data and the way it’s structured, it’s pretty simple. Looking at all of my pipe and all of my reporting, it doesn’t lend itself to SQLite at all.

Christopher: Not if you’re a big operator.

Russel: True.

Christopher: If you’re a big operator, I’m not going to put the whole thing in SQLite. You could, but I wouldn’t.

Russel: Where’s the line between big and little?

Christopher: That’s a good question. I don’t have an answer to that one.

Jackie: Another way to think of it is single use versus multi use. If I use a file geodatabase, if I’m at one service provider or one contractor to put data into it to transform and to migrate into my final PODS database, we’re building a new project.

I’m going to give them a one file geodatabase. They’re going to populate it with the PODS information. We’re going to take it and put it into our enterprise geodatabase which sits in Oracle.

Russel: Maybe you could unpack it a little bit. What’s a business rule? If I’m not a software guy, what is a business rule?

Russel: That’s an example of a rule where something physically couldn’t happen. What are some other kinds of business rules?

Christopher: It’s really anything that I want to protect in that database or that I want to happen a certain way in that database.

Christopher: It just wouldn’t work.

Russel: There’s also a standards based rule, which says the standard says if you’re going to measure according to AJA 3, then it should be…Your beta ratio, the ratio between your orifice plate size and your internal diameter pipe, should be between 0.25 and 0.75.

I can physically install a plate that’s 0.8 or 0.2, but it’s outside the standard. That’s a business rule that you probably also want to flag, but you’d want to be able to diverge from.

Russel: That sounds simple. No, it’s not simple. It actually doesn’t sound simple at all.

What are you all doing around APIs?

We’re trying to avoid this middle ground where we tell a vendor exactly what insert statement to run, but just what goes in and what comes out.

All these things are occurring and all those things have to be recorded. That makes this seem kind of challenging for me.

Jackie: New or different from what you expected?

Russel: From what was expected, yeah. I was going to say I don’t know if that’s comforting or not, depending on what’s…

What are you guys doing at PODS to address that impending reality?

Russel: I can start with a very small data set and then build on it later as I collect more information.

Jackie: Meaning you don’t have to have a linear reference pipeline. Most of the gathering lines we work with at Williams, for example, they’ve never done linear referencing in that…

Russel: You find the same thing in the utilities, too. It’s all georeferenced.

Jackie: This model accommodates that.

Russel: They walk out with a GPS and they go, “Here’s a point. Here’s a point. Here’s a point.” It goes right into the database.

How do you work with the software vendors that are building tools that need to be able to shove data into this format or this standard?

That’s where the API comes in. That will assist in that development and open that up. I don’t know if that makes sense.

Here’s this data standard. It can be implemented on any database tool. I’ve got to build an application. I’ve got to build an application on a database. How does that relate?

Jackie: That’s where your physical implementation comes in. If I have an IT staff that can write a program, I’m going to do a relational implementation. If I am an Esri shop, which is a proprietary software that…

Russel: Esri’s a big player in the space, obviously.

Jackie: They’ve written software. If you implement a geodatabase implementation, you have software already that can maintain that data because it’s in a geodatabase format.

Russel: I know nothing about Esri. I know who they are.

Russel: Esri has lots of partnership with people who build apps that put that data into their model. Is the Esri implementation PODS 7?

Christopher: It’s a little bit more complicated than that, but yes, qualified.

Russel: Yes, qualified. See, now…Anybody who’s a software person’s going to say, “Okay. Tell me about the constraints.”

Where it gets complex with Esri is we actually provide two different Esri implementations of PODS 7. One is a regular old Esri geodatabase. I’m going to open up ArcMap or ArcGIS Pro. I’m going to edit things, move my lines around. I’m going to do stuff, just like I might do with SQL, although I wouldn’t try to manage this by typing SQL into my computer but I could, I guess, if I wanted to.

Russel: There are plenty of people who think that’s a good idea.

Christopher: Maybe that’s a whole different podcast.

Russel: Yes, it is.

Christopher: You can do that from the Esri point of view, but Esri also has a tool called APR, ArcGIS Pipeline Referencing, which itself is actually a tool to manage pipeline data in a data model. Esri has their own data model called UPDM, which has the same core, a very similar core, to PODS 7.

That was all done on purpose because we wanted all of this to be interoperable. The PODS 7 core is compatible with Esri’s APR. If you’re an ArcGIS shop, you can go and pick up Esri APR and install all of the PODS 7 stuff and it will work.

Russel: The TLAs are overwhelming.

Jackie: We’ve done a lot of it.

I’m pretty geeky and I’m pretty technical. I got lost in that conversation. I get…Let me try to play it back, I’ll try to simplify it. Basically, Esri, which is one of the major vendors in this space providing a geocentric database and the ability to interact with that data already has some implementations that support PODS 7. The trick is picking the implementation and understanding the limitations.

Christopher: I would say yes, they should probably use PODS. There’s a free version of PODS called PODS Lite which has the bare minimum. You don’t have to be a complete database geek. Probably, I would say, you should just use the Esri software, and you should just load information that you have into it.