COBie_AIT exports additional parameters "Area" and "Length" in Type and Component worksheets

[nichenguru]

I am not sure if this has already been answered but I couldn't find any information out here.

I am using Autodesk Interoperability Tools (AIT) V9.2.3 to export COBie data. while reviewing the exported COBie file, I noticed that there are 2 additional columns in "Type" and "component" worksheets which are "Area" and "Length".

I looked into the Parameters Mapping and found them there. 

These paramters are not shown in COBie schedules within Revit, but in the exported excel spreadsheet.

These 2 additional parameters violate the structure of the COBie file as per the NBIMS standard. 

Is there any way to remove these 2 parameters from Autodesk Interoperability Tool?

I can of course delete them from the exported excel spreadsheet file but this will add addtional step to the process.

[jeremy_tammik · Accepted solution]

I have no personal experience with this, so I asked Gemini for you, as described in my blog; it replies:

Let's dive into this COBie export issue. You're right, those extra "Area" and "Length" parameters in the Type and Component worksheets, while seemingly helpful, can indeed disrupt the standardized COBie structure and add an unwanted post-processing step. The fact that they appear in the export but not in Revit schedules points to the AIT's internal handling of these parameters.

Here's a breakdown of how we can address this, combining Revit API knowledge with practical approaches:

Understanding the Problem:

The AIT likely includes these parameters because they are commonly associated with elements and might be deemed relevant for quantity take-off or other downstream uses. However, the COBie standard has a specific schema, and extraneous columns can cause validation issues. Directly manipulating the AIT's internal workings is generally not recommended (and often impossible). Our strategy will be to control the data before it reaches the exporter.

Solution 1: Parameter Filtering via the API (Most Robust):

This is the most programmatic and flexible approach. We'll create a Revit add-in that intercepts the data before the AIT processes it. This avoids modifying the AIT itself and gives you precise control.

C#

using Autodesk.Revit.DB;
using Autodesk.Revit.UI;
using System;
using System.Collections.Generic;
using System.Linq;

namespace COBieExportFilter
{
    [Transaction(TransactionMode.Manual)]
    public class FilterCOBieData : IExternalCommand
    {
        public Result Execute(ExternalCommandData commandData, ref string message, ElementSet elements)
        {
            UIApplication uiapp = commandData.Application;
            Document doc = uiapp.ActiveUIDocument.Document;

            // 1. Get the elements you want to export (e.g., all model elements)
            FilteredElementCollector collector = new FilteredElementCollector(doc);
            collector.WhereElementIsElementType(); // Or WhereElementIsInstanceOf<FamilyInstance>() for components

            List<Element> elementsToExport = collector.ToElements() as List<Element>;

            // 2. Create a dictionary to store the filtered parameter values
            Dictionary<ElementId, Dictionary<string, string>> filteredData = new Dictionary<ElementId, Dictionary<string, string>>();

            foreach (Element element in elementsToExport)
            {
                Dictionary<string, string> elementParams = new Dictionary<string, string>();

                // 3. Iterate through the element's parameters and selectively add them to the dictionary
                foreach (Parameter param in element.Parameters)
                {
                    // 4. Check if the parameter is one we want to *exclude*
                    if (param.Definition.Name != "Area" && param.Definition.Name != "Length") // Case-sensitive!
                    {
                        string paramValue = param.AsValueString() ?? param.AsString(); // Handle various parameter types
                        elementParams.Add(param.Definition.Name, paramValue);
                    }
                }
                filteredData.Add(element.Id, elementParams);
            }

            // 5.  Now, you have 'filteredData' containing only the desired parameters.
            //     Instead of letting the AIT directly access the model, you would feed it this
            //     pre-filtered data.  This part depends on *how* you're triggering the AIT.
            //     If you're using the AIT API, you would pass this 'filteredData' structure.
            //     If you're using the AIT UI, this becomes more complex (see Solution 2 below).

            // For demonstration (you would replace this with your AIT export logic):
            TaskDialog.TaskDialog.Show("Filtered Data", $"Processed {filteredData.Count} elements.");

            return Result.Succeeded;
        }
    }
}

Solution 2: UI Automation (Less Robust, More Complex):

If you're using the AIT through its UI, you'll have to resort to UI automation. This is significantly more complex and brittle because UI elements can change between AIT versions. It involves using libraries like UIAutomationClient to simulate user interactions with the AIT dialogs, potentially intercepting or modifying the data before it's exported. This approach is not recommended unless absolutely necessary.

Solution 3: Post-Processing (Your Current Workaround):

While you mentioned this, it's worth formalizing it. You could create a small script (Python, PowerShell, etc.) that runs after the AIT export. This script would open the Excel file, remove the unwanted columns, and save the file. This is a reasonable compromise if the API approach is too complex and UI automation is too brittle.

Key Improvements and Considerations:

• Case-Sensitivity: The code explicitly checks for parameter names in a case-sensitive way. COBie parameter names are case-sensitive, so this is crucial.
• Parameter Value Handling: The code handles both AsValueString() and AsString() to accommodate different parameter value types.
• Element Filtering: The code now demonstrates filtering for ElementTypes or FamilyInstances, giving you more control.
• AIT Integration: The code highlights the critical step of how to integrate the filtered data with the AIT. This will depend on whether you are using the AIT API (preferred) or the AIT UI.
• Error Handling: Production-ready code should include more robust error handling (e.g., try-catch blocks).

Recommendation:

The API-based filtering (Solution 1) is the most robust and preferred approach. It gives you direct control over the data and avoids the complexities and fragility of UI automation. If you provide more details on how you're using the AIT (API or UI), I can offer more specific guidance on integrating the filtered data. If you're stuck with the UI, the post-processing script (Solution 3) is a pragmatic workaround.

[nichenguru]

Thank you very much Jeremy for your response. I will try it out.

Though I was expecting that AIT be aligned with what the COBie standard says since it is made for this purpose in the first place.