By: Kenneth Crawford
Playing nice with others: The importance of Data Interoperability
One of the primary complaints I often hear from practitioners in the realm of file and data sharing is “I can’t use the information in the form they gave it to me!” Indeed, this “us vs. them” attitude is also one of the chief reasons for so much of the competitive zeal we’ve all experienced between adherents of one particular solution compared to another. Consider for an example the eternal war between Mac and PC users (I’m a Mac guy myself, but I do like to live in the bigger world when required, plus, I can run any Windows app on my Mac with a simple swipe of the fingers! But that’s for another day . . .). It doesn’t get much more contentious than this, similarly with the AutoCAD vs. Microstation (or any two apps will do) argument, always which is better, impassioned diatribes on the whys and wherefores accordingly . . .
The reality is approaching where we will one day consider the data interoperability as the important component of any type of interchange, and the application to use will simply be the interface. We’re already seeing it in such applications as Bentley’s new “Open Roads” technology, a lingua franca for the design of typical civil objects such as roadway alignments, surface models, superelevation rules, drainage networks, etc. that brings all the good parts of three previously very distinct technologies once native—and exclusive to—the three flagship civil design products from Bentley Systems, InRoads, GEOPAK, and MXRoads. Now, all available from within the core Microstation platform. Likewise, Carlson Software is bringing the ability to work with the native (stored in the DWG file as extended object data) vertical civil design objects stored in AutoCAD Civil 3D DWG files, without external intermediary files or import/export and clunky translators. In other words, we’re starting to blur the lines more and more between interfaces, leaving it up to the user’s choice as to the interface she wishes to put in play to work with the common core data structures.
Tower of Babel: Some Problems . . .
So what are some of the pitfalls with all this Tower of Babel style work product? We quite often work on projects with multiple consultants, where typically the surveyors are charged with depicting the existing conditions, topography, planimetry, key points, etc., to hand over to the design engineers. Quite often this is a separate firm, with separate software and design processes. Sometimes, even a single firm will experience this same handoff on a department level, with the surveyors prepping the upfront base information and handing it over to the engineering department, again, sometimes performed with different application software. Even if survey and engineering both may use the same product, often the techniques are going to be different, and the way the deliverables are packaged will affect the downstream efforts.
Consider the surveyor (firm or department) who makes it a policy to never give out digital data for fears that the next user will modify the data in some detrimental way and cast liability back on the original provider. In some cases, this results in a delivery of a PDF–only drawing document that may show basic planimetry, contours for elevations, and a smattering of annotation. Or a “dumbed–down” base CAD file with simple drawn elements only. This then puts the burden of recreating all the original work on the recipient who now has to develop a design base model to include elements at their proper elevations, contiguous terrain models, and so forth. While this may seem like a prudent choice to the surveyor in terms of limiting liabilities, it will introduce errors that were never intended. For example, rebuilding a terrain model from contours will by necessity ignore all the data that exists “in between” the contours, since it was never delivered. This then will propagate further when the engineer delivers PDF–only to the contractor for him to build a site, often creating a third site model so he can use automated machine control for grading and excavating, etc. It’s sort of like making a
photocopy of a photocopy of a photocopy, with information loss at ever step along the way.
Besides the liability issues, I’ve observed cases where the delivery of PDF–only information is used as a means of disguising some doubt on the surveyors’ or the design engineers’ part where they may not be entirely sure that they’ve done things absolutely correctly, but the resulting paper map “looks good enough.” This might hide some oversights or omissions that may be made evident if someone else examines the data deeply enough.
Playing on the same team: Solutions to Consider . . .
Imagine a process where everyone plays on the same team (isn’t this what we are ultimately doing, anyway?) . . . If the surveyors provide the actual data standing behind the paper map, the engineers can be confident of a solid design base without any holes in it. Likewise, when the engineer then delivers a completed design model to the contractor, the contractor can then proceed to build the site with the confidence that everything is accounted for. We’re starting to witness this type of thinking over in our brother–architects’ world with such technology as Revit which delivers a three dimensional building or structure model rather than just flat drawings; which can be used further along the process for such things as building maintenance and continuing operations by the project owner.
We can do the same thing in our world if we can get past the liability and confidence issues. And one of the strongest arguments against both of these is the simple fact that the survey or design professional maintains a consistent and reproducible record of transmittals that holds a snapshot of the information delivered.
Ah, but the confidence thing . . . the very best way to make sure that what we are doing is the absolute correct way to do things is to make sure we are all well trained in our work products. That means that we must understand what goes into making the deliverable products. Things like points and breaklines that govern surface generation, roadway alignments and profiles that are equation–based and not just “drawn,” piping networks that are interconnected hydraulically and not just pen on paper representations of the same . . . if we all step up our game and really grasp what it is we are working with, the tools that we use to do that work, and the implications—and benefits—of sharing this work with others down the line in the process, we will all benefit, the owner most of all.
Coming Up . . .
The next installment will take a look at some of the may ways we can start to share our data, making sure that the work is not lost between stages. Some of it’s even fun!
I’l leave you with the thought that the day is here, now, when the old way of doing things where we deliver paper (or PDF) drawings which may look fine is coming to an end. It is time to embrace the notion that “good enough” isn’t.
Click here: Data Interoperability [Pt. II]