/interoperability

title: Interoperability
description: File format encyclopedia, data exchange strategies, API integration patterns, Grasshopper-to-Revit pipelines, Rhino.Inside workflows, Speckle data streams, and schema mapping for AEC computational design
version: 1.0.0
tags: [interoperability, IFC, gbXML, glTF, DXF, STL, OBJ, Speckle, Rhino-Inside, data-exchange, API, format-conversion]
auto_activate: true
user_invocable: true
invocation: /interoperability

Interoperability for AEC Computational Design

1. The Interoperability Challenge in AEC

1.1 Why Interoperability Matters

Interoperability -- the ability to exchange data between software tools without loss of meaning, geometry, or relationships -- is the single most critical infrastructure problem in the AEC industry. Every building project involves dozens of software tools, hundreds of files, and thousands of data exchanges. When those exchanges fail, the consequences are measured in millions of dollars and months of delay.

The AEC industry loses an estimated $15.8 billion annually in the United States alone due to inadequate interoperability (NIST GCR 04-867). This figure accounts for redundant data entry, manual format conversion, error correction from data loss, and delayed decision-making caused by information silos.

Unlike the manufacturing or aerospace industries, which converged on STEP/IGES decades ago, the AEC sector remains fragmented across proprietary ecosystems. Autodesk, Bentley, Trimble, Nemetschek, and dozens of smaller vendors each maintain walled gardens with varying degrees of openness. The result is a landscape where a single design decision may need to be re-entered into five or more tools before it reaches a construction site.

1.2 Single-Source-of-Truth vs. Federated Model Approaches

**Single-Source-of-Truth (SSOT)**:

• One authoritative model from which all views and deliverables derive
• Revit-centric workflows often attempt this, with one central model containing architecture, structure, and MEP
• Advantages: no synchronization burden, clear ownership, simpler version control
• Disadvantages: tool lock-in, performance limits at scale, inability to leverage best-of-breed tools
• Practical limit: SSOT breaks down beyond approximately 200-300 MB models or when disciplines require specialized solvers

**Federated Model Approach**:

• Multiple discipline-specific models linked through coordination mechanisms
• Each discipline uses its optimal tool (Revit for documentation, Rhino for complex geometry, Tekla for steel detailing, ETABS for structural analysis)
• Coordination via shared coordinates, reference planes, and clash detection (Navisworks, Solibri, BIMcollab)
• Advantages: best-of-breed tooling, team autonomy, distributed workload
• Disadvantages: synchronization overhead, version mismatch risk, coordinate alignment complexity
• Industry trend: federated approaches are winning, especially with Speckle and IFC enabling richer exchange

1.3 Open Standards vs. Proprietary Formats

**Open Standards**:

• IFC (Industry Foundation Classes) -- ISO 16739, the only truly open BIM exchange standard
• gbXML (Green Building XML) -- energy simulation exchange
• CityGML / CityJSON -- urban-scale 3D models
• LandXML -- civil engineering survey and design data
• BCF (BIM Collaboration Format) -- issue tracking tied to model viewpoints
• Governed by buildingSMART International, OGC, and other standards bodies

**Proprietary Formats**:

• RVT/RFA (Revit), DWG (AutoCAD), 3DM (Rhino), SKP (SketchUp), PLA/PLN (ArchiCAD)
• Offer full fidelity within their ecosystem
• Risk: vendor lock-in, obsolescence, licensing dependencies
• Some are partially documented (DWG via Open Design Alliance) but reverse-engineered support is always incomplete

**Pragmatic Reality**: Most production workflows use a hybrid. Native formats for authoring, open formats for exchange, and lightweight formats (glTF, PDF) for communication. The goal is not eliminating proprietary formats but creating robust translation layers.

1.4 Data Loss Taxonomy

When data moves between tools, losses occur in four categories:

| Loss Type | Description | Example | Impact | |-----------|-------------|---------|--------| | **Geometry Loss** | Shape information degraded or missing | NURBS surface exported to STL loses curvature continuity | Visible faceting, dimensional inaccuracy | | **Metadata Loss** | Properties, parameters, classifications stripped | Revit wall type info lost when exporting to OBJ | Downstream tools lack decision-critical data | | **Relationship Loss** | Connections, hosting, spatial hierarchy broken | Wall-floor join lost in IFC export | Manual rework to re-establish element logic | | **Appearance Loss** | Materials, textures, colors not transferred | PBR materials from Blender not mapping to Revit | Re-application of visual properties in target tool |

Additional nuanced losses:

• **Precision loss**: floating-point truncation at large coordinates
• **Semantic loss**: a "wall" becomes a generic "extrusion" in target tool
• **Topological loss**: solid body becomes disjoint surfaces
• **Behavioral loss**: parametric constraints become fixed geometry
• **Unit loss**: implicit unit assumptions cause scaling errors (mm vs. ft is a classic)

---

2. File Format Encyclopedia

2.1 Geometry Formats

OBJ (Wavefront Object)

| Property | Value | |----------|-------| | **Extension** | `.obj` (geometry), `.mtl` (materials) | | **Version** | Originally 1992, no formal versioning | | **Geometry** | Polygonal mesh, free-form curves/surfaces | | **Metadata** | Minimal -- group names, material references | | **Max Size** | No hard limit; practical ~500 MB | | **Typical Use** | Mesh exchange, visualization, 3D printing prep | | **Read/Write** | Rhino, Blender, 3ds Max, SketchUp, Unity, Unreal, MeshLab, CloudCompare | | **Strengths** | Human-readable ASCII, universal support, simple specification | | **Limitations** | No BIM data, no solid topo