Datenbanken und IFC

[Luise23]

Hallo, ich habe nochmal eine frage zu IFC, eigene Eigenschaftssets und eigene Datenbanken. Ich erstellte aus dem BIM-Fachmodell Landschaft und Freianlage eigene Eigenschaftssets im Datenmanager, die ich später über entsprechende Ifc-Daten meinen Objekten zur Freianlage verküpfen möchte. Jetzt wollte ich aber meine viele Eigenschaftssets mal speichern, da sie ja sonst nicht für spätere Projekte verfügbar sind. Ich fand jetzt aber nur heraus, dass man erst eigene Datenbanken mit den selben Merkmalen meiner Eigenschaftssets erstellen muss, um diese exportieren zu können, für spätere Datein. Ist das richtig und man muss alles doppelt eingeben? ich dachte die Version 2025 verfügt über einen anderen, kürzeren Weg. 

[Sperlinm]

Moin @Luise23,

Du kannst die Datenmanagereinstellungen als XML speichern. Diese sind dann im Benutzerodner von VW enthalten und können auch in anderen Dokumenten genutzt werden.... Wenn ich dich richtig verstanden habe. Darin sind eigentlich alle Einstellungen des Managers enthalten.

[HebHeb]

Ich würde unbedingt alles in den internen Vectorworks-Datenbanken verarbeiten, um die dort eingegebenen oder errechneten Werte (z. B. über Zuweisungsformeln) anschließend einfach in die pSets „durchzuschleifen“
Das erleichtert aus meiner Sicht die Verwaltung der Daten erheblich – insbesondere im Hinblick auf unterschiedliche LOIN-Stufen oder bei einem Wechsel der IFC-Version.

Die aus dem Datenmanager exportierten XML-Dateien verarbeite ich bevorzugt in externen Programmen weiter, um daraus wiederum Importe für andere Vectorworks-Projekte zu generieren.

Das direkte Schreiben bzw. Verarbeiten in pSets habe ich schon immer als eine Art Einbahnstraße bzw. Endstation empfunden – wenig flexibel und mit hohem Verwaltungsaufwand verbunden.
Daher mein Ansatz: Einheitliche VW-Datenbankstruktur in allen Projekten → pSet-Zuweisung (also tatsächlich „doppelt“).

Diese „Doppelung“ lässt sich jedoch geschickt durch Skripte organisieren – sowohl extern über die XML-Dateien (so habe ich bisher alle Datenbanken, Datensets und IFC-pSets auf Basis der VW-Datenbanken regelbasiert erstellen lassen), als auch intern in Vectorworks über Marionette oder Vectorscript (inkl. Zuweisungsformeln).
Gerade die "interne" Umsetzung via Marionette/Vectorskript inkl der Zuweisungsformlen gehe ich aktuell verstärkt an, da sie bei großen Datenmengen (z. B. pSets mit 100+ Einträgen pro Bauteil) eine erhebliche Zeitersparnis bringt...

 

Bearbeitet 26. August von HebHeb

[Luise23]

vor einer Stunde schrieb HebHeb:

Ich würde unbedingt alles in den internen Vectorworks-Datenbanken verarbeiten, um die dort eingegebenen oder errechneten Werte (z. B. über Zuweisungsformeln) anschließend einfach in die pSets „durchzuschleifen“
Das erleichtert aus meiner Sicht die Verwaltung der Daten erheblich – insbesondere im Hinblick auf unterschiedliche LOIN-Stufen oder bei einem Wechsel der IFC-Version.

Die aus dem Datenmanager exportierten XML-Dateien verarbeite ich bevorzugt in externen Programmen weiter, um daraus wiederum Importe für andere Vectorworks-Projekte zu generieren.

Das direkte Schreiben bzw. Verarbeiten in pSets habe ich schon immer als eine Art Einbahnstraße bzw. Endstation empfunden – wenig flexibel und mit hohem Verwaltungsaufwand verbunden.
Daher mein Ansatz: Einheitliche VW-Datenbankstruktur in allen Projekten → pSet-Zuweisung (also tatsächlich „doppelt“).

Diese „Doppelung“ lässt sich jedoch geschickt durch Skripte organisieren – sowohl extern über die XML-Dateien (so habe ich bisher alle Datenbanken, Datensets und IFC-pSets auf Basis der VW-Datenbanken regelbasiert erstellen lassen), als auch intern in Vectorworks über Marionette oder Vectorscript (inkl. Zuweisungsformeln).
Gerade die "interne" Umsetzung via Marionette/Vectorskript inkl der Zuweisungsformlen gehe ich aktuell verstärkt an, da sie bei großen Datenmengen (z. B. pSets mit 100+ Einträgen pro Bauteil) eine erhebliche Zeitersparnis bringt...

 

ok, vielen dank. Für die Erstellung von Datenbanken, habe ich jedoch keine Zeit mehr, aufgrund einer kommenden Abgabe. Inwieweit erleichtert sich die Verwaltung der Daten aber für dich? Ich habe bisher wenig bis keine Erfahrung mit IFC und Skripten und dachte über den Datenmanager ist es zunächst die schnellste Lösung oder auch einfachste. Mit Skripten habe ich generell noch nicht gearbeitet. Hast du ein bestimmtes Programm, mit dem du die Dateien extern bearbeitest? Vielleicht schaffe ich diesen Ansatz noch auszuprobieren. 

Bearbeitet 26. August von Luise23

[HebHeb]

Hier im Forum stößt sicherlich der eine oder andere noch auf diesen Beitrag. Deshalb finde ich es sinnvoll, ab und zu Anregungen und Gedanken zu teilen – auch wenn das nicht in jeder Situation die exakt richtige Lösung sein kann. Vielleicht ist aber doch etwas Nützliches dabei.

Das hier ist also nur ein Einblick, wie ich es aktuell handhabe. Ich habe vollstes Verständnis, wenn das nicht für jeden passend ist und je nach Kontext andere Ansätze besser funktionieren.
(Zum Beispiel verwalte ich derzeit eine zentrale Vorlage für ein größeres Büro.)
 

Mit Notepad++ lassen sich die XML-Dateien leicht einsehen und die dahinterliegende Syntax nachvollziehen – das ist nicht besonders kompliziert.
 

In meiner Arbeit verwende ich je Vectorworks-Datenbank immer die gleichen Datenfelder für IFC-pSets. Anstelle von „db“ steht im Datenbanknamen dann „ifc“ . Felder inkl Formatierung etc = identisch zur VW Datenbank.
Damit ich diese Felder nicht manuell und doppelt anlegen muss, erstellt mir ein Python-Skript die Strukturen automatisch (die sind auch in der xml des Datenmappings gespeichert)

Zusätzlich leite ich aus der IFC-4.3-Version noch IFC4 und IFC2x3 ab und ersetze dabei z. B. nicht mögliche Entities (in IFC4 oder 4.3) durch BuildingElementProxy.
Jedes Datenbankfeld erhält außerdem einen LOIN-Präfix („###_*“).

So erzeuge ich mir für die Stufen 100, 200, 300, 400 und 500 jeweils eine XML-Datei – in Summe also 15 XML-Dateien, die alle aus einer einzigen Ursprungsdatei generiert werden.

Diese alle einzeln zu pflegen, wäre aus meiner Sicht nicht vertretbar, und wäre in der Form auch niemals realisierbar gewesen (zumindest bei vertretbarem Zeitaufwand...)