The SSP All Edits Report & QA Tool (AKA "All Edits Report") answers some of the most common questions for GIS or QA managers: "who" did "what", "when" and "where" in the GIS. Popular with larger utilities, this tool provides users the ability to track edits that were made within a version in an Esri versioned geodatabase. It accomplishes this by analyzing the version before it gets posted to create a textual and graphical report of all the edits (additions, changes and deletions) that have occurred within the version. The end result is far fewer "bad" edits are posted, providing a more realistic, healthy and safe dataset, ultimately bolstering utility efficiency.
Hi I'm Skye Perry with SSP Innovations, and I'm here to talk to you today about one of our products called the SSP All Edits Report & QA/QC tool. It's one of my favorite tools here. It's really focused on helping users who use a versioned geodatabase. Versions allows multiple users to edit the geodatabase at the same time in the same area, even the same record in many cases. When we look at this Esri geodatabase which many of us use with a lot of versions in there. So the keys here are in the utility/telecom setting we have a lot of different users editing, and one of our challenges in the QA, the quality assurance side of the geodatabase is to ensure that the users are editing the things they're supposed to be editing and not touching anything else.
So this tool is really focused on telling us who did what, when, and where did they do it as far as the editing. Allowing us to review the edits ahead of time before they are posted or now even in arrears, after the edits have been posted. So let's break this down and talk about the different areas that the all edits tools focus on. So we have these versions, users are editing these versions within the geodatabase on an on-going basis, we're talking daily, maybe several versions per user per day. So the very first thing that we do here is allow for an interactive report. An interactive report here can be run on a version before the version is posted.
So if you imagine I've added some poles, some conductors, or if I've been doing gas: gas valves or some gas main. Before this version is posted, I can run the all edits report in the interactive mode which will show me the edits within the versions. I can see the additions in blue, I can see the deletes in red, and my updates orange and green including shape updates, all right within the version before it's posted. So that helps a ton, but the tool that advanced over the years truly adds some additional functionality. As much as the geodatabase we need to create an all edits schema.
So I'm just going to abbreviate this to all AE for all edits, and inside of this all edits schema we use tables and feature classes. The key with these tables and feature classes is that these are non-versioned. Why is that so important? As you might have guessed we are going to track your all edits over time, and this can get rather large. Now we're aware of that but by keeping them non-versioned we really minimized the versioning impact to the data within the database. But on the flip side we want to keep these things and segregate them within the geodatabase. It is Its own database and own set of tables. While it does grow, space is cheap, so we can store things. That allows us to do a few more cool things within the geodatabase. First and foremost, in the interactive mode, if you want to save your edits off from the interactive report into the geodatabase, you can do that with a click of a button. This allows you to go ahead and post a version interactively. The versions gone of course, but we have saved off the edits (the adds, the updates, the deletes) directly into the geodatabase so we can view them at a later point in time. But we can take a few steps forward.
Many of our utilities are using what we call a BRP and that rule simply stands for Batch, Reconcile, and Post. Now this can be Schneider Electric to geodatabase manager, it could be an old custom BRP, or many clients own their own custom BRP's that interact with the geodatabase. Now the entire point of the BRP is to handle these versions. It handles the posting of them, most importantly, into the geodatabase. Now again, we can only have one user posting at any given time which is why BRP is used. If we are posting some large utility, if you imagine post 200 to 250 versions a day, it'll be way too hard for a single user to be doing that. So the BRP handles that. So what can we do in the automated fashion with all edits? The key here is that we are able to run the same BRP here on the post event which is then going to understand the version’s edits that have occurred. Interactively, or should say automatically, take those edits and put them into the all edits schema.
Just as we did it interactively, we now have a number two down here, the BRP (on post) can automatically pull those edits out and put them into the tables. Now we are running it unattended. So we have additional value there in an automatic fashion. Either way, we got all your edits stored into our all edits schema. So the final piece that we have that is really important, is that I'll draw that here to the side. The third most important piece of this functionality is what we call the search and report. As we are searching and reporting it allows us to interactively query the all edits tables. We can query those on things like the actual name of the version, the owner of the version, and now with some of the advance functionality we are able to query on actual attributes. Imagine an attribute like a financial work order. It's shared across many different versions within the system across many different edits. We can now plug in that financial work order into an attribute and find any versions with any edits that have been used against the financial work order across all the versions that have been posted or interactively run, so we can find those. The same report can then be visualized within the database and shown back to the user.
So we take the case here, easy to find these versions and view them, even after the post has occurred. We now have the ability to track these versions and take that case of 200+ versions a day, as those are posted by the editor, extracted and stored, the versions are posted, the versions are cleared out. After the fact we're still able to come in to do a search and report on the name, the attribute, the owner, find those versions, replay the edits so you can see them visually and do the QA/QC after the fact.
So it solved a very important problem and that's again finding what, when, and where. And now it's doing it even after the versions have been posted. So we have a lot more information on the website, please check that out.