A couple months ago I wrote about a piece of project-ware SSP built that gives the user a report of every edit that occurred in a GDB version/session/design - both textually and graphically. You may recall the module will save a detailed list of these edits - in a flat file or DB table - for searching later on. Alternatively, the tool could be plugged in to a BRP for automatic capture and save of those edits, for audit and search purposes.

Since then, some smart clients have made some interesting requests for additional functionality that I thought I'd share with you.

Saving QA/QC Failures

An idea was brought up that made a lot of sense to me: if you're going to put the All Edits Report into a BRP to run automatically and save the version edits off for easier QA later, what else can you do to make QA easier?

Along that line of thought, the QA Officer (for Telvent shops) will eventually have to fire the ArcFM QA process - which uses up valuable time and processing resources - and work through any failures that arise. Could we automatically fire the QA process and save a list of failures to a table - all during BRP?

To make the change worth it, the failures would need to be viewed easily later on, so we'd need to create some type of simple viewer for failures. This interface will allow the user to display a historical list of the failures and zoom to/highlight the related GIS features/objects - without running the QA/QC task again.

Historical Edit Viewing

Now we're getting our hands dirty. The next question we got was about viewing the edit log later on, after the design is posted. Then we said, if we're going to want to view the edit log, we might also want to see the edits on the map too.

 So, now we're talking about essentially building the functionality of the original interactive All Edits software, but for historical viewing. Turns out, this functionality can be quite useful for some larger utilities, for a variety of reasons.

The first job is no walk in the park - we'd need to capture and save the All Edits graphics, with all related features/objects, corresponding attributes, geometry changes and spatial positioning information. You might be thinking "that's going to take up some space, man!" and you'd be right. So we're also going to need to build in an auto-delete after a specific period of time.

The second task is to build another user interface which would allow the full functionality of the original All Edits Report (view of all the edits that occurred both textually and on the map) to be used after posting.

Thus, the Extended Custom Auto-All Edits Report was conceived. (It's a working title, ok?) We're working on requirements now, and I personally can't wait to see this thing in action! It's this type of out-of-the-box thinking that can make your GIS department hum like a well-oiled machine.

So I ask you: what other functionality would be helpful in a BRP edit/QA capture-and-display like this? E-mail me your thoughts and I'll share the good stuff next month. (dean dot perry at sspinnovations dot com)