Electronic Data Managers: Roles and Responsibilities

• Provide some documentation for the content.
• Know and be responsible for all the files in the Project Folder.
• Manage the directory structure of the Project Folder.
• Know who is accessing the data or adding content.
• Make sure that those accessing data or adding content are coordinating with you.
• Make sure that whoever is messing with your data understands how he/she will conform to your management scheme when they add new data.
•  
• Keep a primary "tree" of good data.  Keep the old/archive/obsoleted/garbage on a different branch.
• Make sure that there are backups of critical data (burn the Design folder onto a DVD occasionally).
• Make sure that any project-specific settings are saved so that updates to standards don't clobber the customizations. 

InRoads Internal Self-Documentation

Documentation takes time.  The documentation that takes the least amount of time is explicit and clear naming conventions and the use of clear descriptions within the InRoads data files.

Universal rule: there should never be ambiguity about what's good and what's bad in an InRoads file.  If it's good part of the time but bad part of the time, that can and should be made clear.

InRoads provides a number of opportunities for being self-documenting.  Almost all Objects have Names and Descriptions. Geometry has Styles, Surfaces have Types and Preferences.  Inputting a clear Description takes little time and having a good one can save a lot of time later.

The test should not be "Are the data organization and each object's purpose clear to me?"

The test should be "Would the data organization and each object's purpose be clear to someone unfamiliar to the project?"

Keep in mind that quality assurance policies will have outsiders looking at the data.  Other designers and engineers will be collaborating.  Bad data management, shared, leads to worse data management.

Drew, Don, and Jeff will be popping into the data files to "help out" and do QC.  We will more than likely be unfamiliar with the latest data.  Any assumptions we have to make may lead to bad results.

Alternates must be clear

Using 805 as an example, engineering alternates create strong opportunities for confusion. 

Assuming that we have to alternates, a 10+2 and a 10+4, alignments will have four "accuracies":

• correct for 10+2, invalid for 10+4
• correct for 10+4, invalid for 10+2
• good for both
• bad for both

First, if it's bad for both, it shouldn't be in the primary .alg (you can put it in a "to be trashed.alg" in some "to be trashed" folder, if you don't want to get rid of it completely).

There should never be ambiguity as to what is good and what is invalid.  If you don't feel like putting a "both..." in every description (or name) then every single instance of a "single-alternative" object must have the Alternative as part of the name.

There are two options for managing alternative geometries:  a single, combined Geometry Project and two separate geometry files.

The primary disadvantage of two files is that you cannot get around the need to have duplicate data for common geometry (you'll always have to have, say, the primary centerline, in both files).  This requires a plan and everybody knowing the plan.  Do you have a primary for creating and editing and a secondary for copying the duplicates?  You must designate which file is the primary and clear division to the secondary (followed by a delete when done).  Otherwise, you end up with two massive .alg's with unclear up-to-datedness.

In any case, the occasional user should know, by looking at the Name and Description (and Style), the location and engineering purpose (CL, ETW, etc.) of the alignment, and for which alternative(s) it is good for.

Again the test should be: if an "outsider" has to help out in a crunch, does he have to make a phone call to understand what's going on (or make a trip, or find some external documentation)?