Project InRoads Data Management

Most projects will have more than one designer using InRoads (in parallel or in series). Good data management is critical for effective collaboration.

Data Quality

Data tends to be

1. GOOD and ACTIVE or
2. Various Stages of Crap.

There should never ever ever be any confusion as to what is GOOD and what is crap.  This is true at a file level and at the internal InRoads data object level.

File Management

The Primary Data folder

In theory the files in the primary folder should be only the latest good data.  In practice they should have an absolute minimum of crap and a minimum of confusion.  The use of explicit naming and the use of subfolders makes this very manageable. 

Keep EVERY InRoads file that is stored in the project InRoads folder (or any other multi-user area) obviously-labeled.  Eliminate or make extremely explicit all crap files or crap data.  Any stranger should be able to figure out from the file names what is going on.  Quasi-crap should go in a quasi-crap folder so that it doesn't confuse or detract form the good stuff.

In theory at the end of an InRoads project, there should only be a single .alg and .dtm (or one existing, one proposed), a Template Library and a Roadway model file.  Support or component files (mainline, ramp, etc.) files should be in well-named subfolders. During the project the latest "finished" dtms should be in one place, working files somewhere where they are not confused with "finished" files.

Temporary working files should be in users temporary working folders

Multiple Files of the same Type

If you have multiple files of the same type (say, *.alg files) there should be a reason that you've segregated them into separate files.  The names should make that distinction very clear. 

Archives

Archived data, to the designer working on a deadline, is crap.  Archives should be stored outside of the InRoads data folder so that searches don't bring up old data.  The point is to avoid confusion.  A file called "xOLD_Archive*" shouldn't create much confusion and can remain in the folder.

Searching a folder called "xArchivesInRoads" (outside the InRoads folder) may bring up files will good names, but the user will know that he is working with data that is probably obsolete.  Confusion is minimized.

Temporary/Working Files

Temporary or Working files should be in a temporary or working folder, most often the users folder in the "temp" or "working" folder.  Temporary, working or intermediate files should not be in the main folders.

Data Object Naming

Use explicit names and descriptions.  If you are doing something non-intuitive, unique, for a specific modeling purpose, or due to some unusual factor it really helps collaborators if you include that in the InRoads object name or description.  External references and documentation are nice but right there in the file is the best.  We can create new levels in MicroStation, we can move things to 1-63 later if necessary.

InRoads File Naming

DGN file names are often dictated by a client's convention or sometimes by KHA's conventions, but InRoads file names are seldom dictated.

InRoads Styles

It is critical to use appropriate Styles for objects in InRoads:

• it allows appropriate symbolization (correct level, color, etc.)
• it allows functional segregation.

A broad suite of object types (Feature Styles) have already been set up in InRoads.  If you need to track an object type that does not have a Feature Style already defined for it create a new one, it could take less than a minute and save hours (go to InRoads>Tools>Style Manager.  Find a similar, copy it, rename it.  Use the result).  There is absolutely no excuse for having an "Uncontrolled" feature style in your model or an edge of pavement alignment with a Style of "Default" or "cl_alt_tiny".

Note: DTM's and XIN's can vary dramatically in their "Style Lists."  It's far better to have explicit and specific Feature Styles that are non-standard than to have no Style or incorrect Styles.

Proposed v. Existing.  Our InRoads XIN is set up with Existing prefixed by "x" and no prefixes for Proposed Styles.

InRoads Object Names

Avoid two or three letter acronyms where possible.  InRoads can handle 255 (?) characters in names and descriptions and seldom do clients dictate those names.  Avoid using "PR1" when "Plaza NB On" can be used.  If you think you are saving time by calling an object "TOB" or "BOB" you're wrong.  It takes 10 seconds to key in "Top of Barrier."  It takes each confused collaborator at least 10 minutes to figure out what a "TOB" is.

Using proper InRoads Styles eliminates a lot of guesswork.  Other fields in the InRoads data structure (Names, Descriptions, [DTM Feature] Parent [DTM Feature] Alignment) can then be used for object specific information such as region, location, etc.  For example when doing interchange clean up, it really helps to have the various ramps each have a consistent and filter-able property (NBON).  Names, in particular, are visible in almost all the modification commands.  A "struc_wall_bottom" feature named "SB Genesee Wall #3" makes editing more error free than "3".

Hint: Prior to Merging (or Copying Features to) Surfaces it helps to use Surface>Features>Feature Properties to bulk assign the alignment name to every feature's "Alignment" feature.

More on InRoads Internal Self-Documentation