BCF 2.1 vs. BCF 3.0: Wo liegt der Unterschied?

Kurzantwort: BCF 3.0 ist eine strenger strukturierte Weiterentwicklung von BCF 2.1 – kein anderes Format. BCF 2.1 wurde im Oktober 2014 und BCF 3.0 im Juni 2021 veröffentlicht, jeweils von buildingSMART International. In BCF 3.0 werden Projektwerte wie Status, Typen und Prioritäten als reguläre Daten statt in einem erweiterten XSD-Schema gespeichert. Außerdem sind Pflichtfelder, Dokumente und Viewpoints genauer definiert. Beide Versionen verwenden die Endung .bcf; erst die Datei bcf.version im Archiv nennt das Schema. Wählen Sie in der Praxis die Version, die jedes Werkzeug in Ihrem Workflow öffnen kann.

BCF 2.1 und BCF 3.0 erfüllen denselben grundlegenden Zweck: Sie übertragen BIM-Issues zwischen verschiedenen Anwendungen, ohne das vollständige Modell mitzuliefern.

Beide Versionen können Topics, Kommentare, Viewpoints, Snapshots und Verweise auf Modellelemente enthalten. BCF 3.0 ist kein vollständig anderes Format, sondern eine stärker strukturierte und strengere Weiterentwicklung von BCF 2.1.

Für die meisten Teams lautet die praktische Frage daher: Welche Version kann jedes Werkzeug im Workflow korrekt öffnen?

Was haben BCF 2.1 und BCF 3.0 gemeinsam?

Der Koordinationsablauf bleibt weitgehend gleich.

Eine BCF-Datei kann ein Issue beschreiben, Status und Priorität festhalten, eine Diskussion enthalten und einen Viewpoint speichern, der den Prüfer zur betreffenden Stelle im Modell zurückführt.

Beide Versionen verwenden die Dateiendung .bcf. Am Dateinamen erkennen Sie die Version nicht; eine kleine Datei namens bcf.version im Archiv gibt an, welches Schema das Paket verwendet.

Deshalb können BCF 2.1 und BCF 3.0 in einem Viewer fast identisch aussehen. Die wesentlichen Unterschiede liegen darin, wie Daten strukturiert, validiert und zwischen Anwendungen ausgetauscht werden.

Was hat sich mit BCF 3.0 geändert?

BCF 3.0 zielt vor allem auf mehr Konsistenz. Projektwerte, Pflichtfelder, Dokumente und Viewpoints sind klarer definiert als in BCF 2.1.

Projektwerte werden als reguläre Daten gespeichert

BCF-Projekte verwenden häufig eigene Listen für Status, Typen, Prioritäten, Nutzer, Labels und Phasen. In BCF 2.1 wurden diese Werte üblicherweise in einem Erweiterungsschema namens extensions.xsd definiert, auf das project.bcfp verwies.

XSD steht für XML Schema Definition. Vereinfacht gesagt ist es ein Regelwerk, das Software mitteilt, welche Werte zulässig sind. In BCF 2.1 standen Optionen wie Open, In Progress und Closed direkt in diesem Regelwerk.

BCF 3.0 trennt das Regelwerk von den eigentlichen Projektdaten. Das Standardschema bleibt unverändert, während Status, Typen und andere projektbezogene Listen direkt in extensions.xml gespeichert werden.

Einfach ausgedrückt:

• BCF 2.1: Zulässige Werte stehen in einem angepassten XSD-Schema.
• BCF 3.0: Zulässige Werte werden als gewöhnliche XML-Daten aufgelistet.

Das ist für Anwendungen leichter zu lesen und auszutauschen, weil sie kein verändertes Validierungsschema interpretieren müssen, nur um Status oder Nutzer eines Projekts zu ermitteln.

Pflichtfelder werden eindeutiger durchgesetzt

In BCF 2.1 konnte ein Topic ohne TopicType oder TopicStatus existieren. In BCF 3.0 sind beide Werte erforderlich.

Das erhöht die Konsistenz, kann bei der Konvertierung älterer Dateien aber fehlende Angaben sichtbar machen. Ein Konvertierungswerkzeug muss den Nutzer gegebenenfalls auffordern, Typ oder Status auszuwählen, bevor es die neue Datei erstellen kann.

BCF 3.0 definiert auch Pflichttexte klarer: Ein erforderliches Feld darf nicht lediglich vorhanden, aber leer sein.

Projektinformationen sind einfacher aufgebaut

BCF 2.1 verwendete project.bcfp für zwei Zwecke: Die Datei konnte das BCF-Projekt beschreiben und zugleich auf das XSD-Erweiterungsschema verweisen. Da das Projektelement selbst optional war, konnte die Datei ausschließlich als Verweis auf das Schema dienen.

In BCF 3.0 liegen die Erweiterungswerte in extensions.xml. Wenn project.bcfp enthalten ist, enthält die Datei die Projektinformationen und benötigt eine nicht leere ProjectId.

Die ProjectId identifiziert das BCF-Projekt, zu dem die Topics gehören. Sie ist keine Kennung eines IFC-Modells.

Dokumente haben eine definierte Struktur auf Projektebene

BCF 2.1 konnte Dokumente referenzieren, die bei einzelnen Topics oder an externen Speicherorten lagen. Die Ablage von Dokumenten auf Projektebene war jedoch weniger klar strukturiert.

BCF 3.0 führt die optionale Datei documents.xml und einen eigenen Ordner Documents ein. Jedes gespeicherte Dokument erhält eine GUID; ursprünglicher Dateiname und Beschreibung werden separat erfasst.

So können Anwendungen ein Dokument eindeutig einmal speichern und von den betreffenden Topics darauf verweisen.

Issue-IDs eignen sich besser für Serverplattformen

Jedes BCF-Topic besitzt eine GUID, doch lange technische Kennungen sind in Besprechungen und im Arbeitsalltag unpraktisch.

BCF 3.0 ergänzt die optionale ServerAssignedId. Damit kann ein Server einem Issue eine kurze projektspezifische Kennung wie STR-142 geben, während die GUID seine dauerhafte technische Identität bleibt.

Das ist besonders nützlich, wenn BCF-Dateien zwischen Desktop-Anwendungen und cloudbasierten Issue-Management-Systemen ausgetauscht werden.

Viewpoints sind genauer beschrieben

BCF 3.0 ergänzt die Definitionen orthografischer und perspektivischer Kameras um ein Seitenverhältnis. Das perspektivische Sichtfeld wird als vertikaler Winkel definiert; sein zulässiger Bereich wächst von den in BCF 2.1 verwendeten 45 bis 60 Grad auf Werte zwischen 0 und 180 Grad.

Die neuere Spezifikation erlaubt außerdem ausdrücklich Snapshots als PNG oder JPEG.

Diese Änderungen liefern Anwendungen mehr Informationen, um die ursprüngliche Ansicht wiederzugeben. Das Ergebnis hängt dennoch davon ab, wie vollständig der jeweilige Viewer den Standard umsetzt.

Welche BCF-Version sollten Sie verwenden?

Verwenden Sie BCF 2.1, wenn Kompatibilität Vorrang hat – insbesondere, wenn ältere oder seit Langem eingesetzte BIM-Werkzeuge beteiligt sind.

Verwenden Sie BCF 3.0, wenn alle Anwendungen im Workflow die Version unterstützen und Sie strengere Validierung, einfachere Projekterweiterungen, eine definierte Dokumentverwaltung und bessere Unterstützung serverseitiger Issue-Kennungen benötigen.

Wählen Sie eine Version nicht nur, weil ihre Nummer höher ist. Eine gültige BCF-3.0-Datei nützt nichts, wenn die empfangende Anwendung nur BCF 2.1 versteht.

In Projekten mit mehreren Plattformen ist meist die neueste Version am sichersten, die alle beteiligten Werkzeuge zuverlässig unterstützen.

Lassen sich BCF 2.1 und BCF 3.0 konvertieren?

Ja, doch die Konvertierung umfasst mehr als das Ändern einer Versionsnummer.

Bei der Konvertierung von BCF 2.1 nach 3.0 müssen Projektwerte aus der XSD-Struktur nach extensions.xml übertragen und fehlende Pflichtfelder gegebenenfalls ergänzt werden.

Bei der Konvertierung von BCF 3.0 nach 2.1 müssen diese Projektwerte wieder durch ein Erweiterungsschema abgebildet werden. Neuere Angaben wie ServerAssignedId oder die Dokumentstruktur aus BCF 3.0 haben im älteren Format unter Umständen keine direkte Entsprechung.

Die zentralen Issues, Kommentare und Viewpoints lassen sich in der Regel erhalten. Prüfen Sie die konvertierte Datei trotzdem in der Anwendung, die sie empfangen soll.

BCF 2.1 und BCF 3.0 mit Bimlyte konvertieren

Bimlyte kann BCF 2.1 und BCF 3.0 öffnen und Issues in der Version exportieren, die eine andere Anwendung benötigt.

Fügen Sie die Datei einem Bimlyte-Projekt hinzu, öffnen Sie das Menü der BCF-Datei und wählen Sie Export as. Wählen Sie anschließend BCF 2.1 oder BCF 3.0. Fehlen Angaben, die die Zielversion verlangt, fordert Bimlyte Sie vor dem Erstellen der Datei zum Ergänzen auf.

Die Konvertierung findet lokal in Ihrem Browser statt. BCF-Datei und Projektdaten werden nicht auf einen Server hochgeladen.

Lesen Sie die Schritt-für-Schritt-Anleitung zum Konvertieren zwischen BCF 2.1 und BCF 3.0 oder öffnen Sie Bimlyte und exportieren Sie die Version, die Ihr Workflow benötigt.