Currently, ORD cannot process more than two attributes from a survey data file into their own unique attribute column. The workaround is tedious and unintuitive: First, modify the CSV file from the data collector (not good practice to modify a surveyors data extract without their consent) by placing an attribute name in front of the actual attribute column in the CSV file. Next, add a command line to your workspace survey properties to enable VBA Macros to interact with the imported survey data. Next, create an Item Type to properly read and parse out the custom attributes. Then set up the Text import Wizard (TIW) to read the attribute name as "Attribute Name" and its corresponding value as "Attribute Value". Upon import, all of the attributes are then placed into one property line, "Attribute Pair", where each pair are pipe delimited. Apply the Item Type to your newly processed survey graphics. Note that if you have any spaces in your attribute name or value, the next step will not work; load and run the SmartObjects.mvba and use Chainage or Point commands to take the pipe-delimited values and place into an Item Type that properly reads the field attribution.

This is a very time consuming and tedious workflow just to maintain valuable field attribution that should be read natively by ORD. The industry would like to see more attention paid to maintaining the attributes from data acquisition without jumping through multiple hoops to process and use in ORD. Eventually, state DOTs will require extensive attribution from field objects, either from existing topo survey, or from digital as-built collection. The workflow for processing this in ORD should be closely studied and streamlined to eliminate multiple macros and unnecessary steps to not lose object attribution.