Classification vs IFC

The US Roads Data Dictionary pairs bSDD classifications with the IFC entities used in infrastructure delivery. Keeping the relationship explicit makes it easier to hand off requirements between DOT owners, designers, and contractors.

Why both?

  • Classifications (for example, the AASHTO usRoad_RoadSection) describe what the asset is in the business taxonomy. They align with specification chapters, pay items, and DOT asset hierarchies.
  • IFC entities (for example, IfcAlignment or IfcRoad) define the digital representation and geometry carried in models and IDS deliverables.

Rely on classifications to anchor requirements to familiar DOT terminology, but couple them with the IFC entity that will host the data to ensure open exchange.

Mapping strategy

  1. Pick the governing classification for each IDS entity from bSDD. That classification becomes the applicability facet in IDS.
  2. Record the related IFC entity in the YAML source (entity.ifcEntity). If you export IFC, this provides traceability between the data dictionary and modeling environments.
  3. Extend property sets to cover IFC attributes (geometry, semantics) and DOT-specific metadata. The Alignments group demonstrates how we can blend alignment metadata with IFC 4.3 alignment concepts.

Tips

  • Use classification system values that resolve to real URIs so downstream teams can dereference them.
  • When IFC lacks a one-to-one match, document the rationale here so everyone understands how the IDS requirement maps to modeling tools.
  • Keep the YAML as the single source of truth—run uild_site.py and xport_ids.py after changes so this page and the IDS stay synchronized.