icon

Attribut für Kostengruppen - PythonPart

Agi_M
Agi_M
04.04.2025 - 07:11

Hallo,

ich habe das Video gefunden und war total begeistert, dass man das Attribut der Kostengruppen automatisch an das Bauteil dranschreiben kann (0:55-1:40 min).

https://www.youtube.com/watch?v=zfHkuLeHOfU

Daraufhin habe ich das Python-Part-Paket installiert.

Da ich das Attribut nicht in den Standard-Attibuten von Allplan gefunden habe, habe ich das Attribut "KG_DIN276" selber angelegt.

Die Formel
p:assignKG(@IFC Entity@;@IFC PredefinedType@;@Tragendes Bauteil@;@Außenliegend@) habe ich händisch abgetippt. Nach dem Ausführen ist leider eine Fehlermeldung, wie im Screenshot, erschienen.

Kann es vielleicht damit zusammenhängen, dass das Attribut @618@ - "Außenbauteil" bei uns die Bezeichnung "Außenliegend" hat?
Was habe ich falsch gemacht und wie kann ich es zum Funktionieren bringen?

Ich feue mich auf Eure hilfreichen Tipps!

Anhänge (1)

img
PP.JPG
Typ: image/jpeg
38-mal heruntergeladen
Größe: 35,23 KiB

Hilfreichste Antwort anzeigen Hilfreichste Antwort verbergen

Florian_Keim
Florian_Ke…
10.04.2025 - 07:55 *

Der PythonPart Workflow zeigt aus meiner Sicht gut was derzeit oft in der BIM Welt schief läuft:

Modelle werden mit (überflüssigen) Informationen zugeballert, nur weil es möglich ist. Der Mehrwert wird aber nicht betrachtet!
Dabei sage ich nicht (!!!) das es überflüssig ist die Information der Kostengruppen aus dem Modell ersehen zu können.

ABER

Es ist nicht Sinnvoll Daten "doppelt" abzulegen (--> Datenhygiene, SSoT --> Single Source of Truth)
Wie in dem Video und in der Anleitung ersichtlich, benötigt es für den Workflow die ifc Standard Attribute, die genau die Klassifizierung der DIN 277 beschreiben.
Modellersteller sind schon genug damit beschäftigt diese Informationen korrekt in den Modellen zu halten.
Das Klassifizieren muss anschließend dort satt finden wo es benötigt wird: Also beim Import der ifc Modelle in der Zielsoftware, und das über die angesprochenen Standardattribute.

Für Denjenigen, der Das ifc-Modell anschließend weiter verwendet bietet ein zusätzliches Attribut also keinen Mehrwert, sondern es birgt nur die Gefahr von Unstimmigkeiten.

Viele Grüße
Florian

LinkedIn-Profil

www.vollack.de

Florian_Keim
Florian_Ke…
04.04.2025 - 10:50 *

Solange die Attributnummer stimmt ist es irrelevant wie das Attribut heisst. Hast du ggf eine nicht Deutschland-deutsche Installation?
Aber:
Das Formel Attribut wird für den Workflow mittels PythonPart aus meiner Sicht nicht benötigt.

Das Video ist da etwas verwirrend. Es wird zuerst der Weg mittels Formel-Attribut gezeigt und danach der mittels PythonPart und verknüpfter Excel Datei.
Das Formel-Attribut findet auch in der Anleitung von Allplan keine Erwähnung. Einfach mal direkt mit dem PythonPart versuchen. dafür wird das Standardattribut "Klassifikationsschlüssel" verwendet

die Daten sind hier zu beziehen

Viele Grüße
Florian

LinkedIn-Profil

www.vollack.de

Agi_M
Agi_M
08.04.2025 - 14:12

In Diegnostics und Einstellungen wird angezeigt, dass das Standard-Land: DEU und die Sprache: DEU ist.

Bei den PythonParts sehe ich die Schwierigkeit bei änderungen an den Attibuten. Vor allem denkt vieleicht nicht jeder von dem IFC Export daran das Tool nochmal auszuführen und die Fehleranfälligkeit steigt bei jedem Attibut, welches sich nicht automatisch generiert-vor allem wenn auch Verkstudenten und Bauzeichner, die ggf. die Zusammenhänge nicht ganz verstehen oder am Anschlag ihrer Kapazität sind, aktiv am Projekt mitarbeiten.

Mit der Formel habe ich schon mal im anderen Büro gearbeitet und würde mich sehr freuen, die Vorteile dieses Attributs wieder genießen zu können.

Florian_Keim
Florian_Ke…
10.04.2025 - 07:55 * [Hilfreichste Antwort]

Der PythonPart Workflow zeigt aus meiner Sicht gut was derzeit oft in der BIM Welt schief läuft:

Modelle werden mit (überflüssigen) Informationen zugeballert, nur weil es möglich ist. Der Mehrwert wird aber nicht betrachtet!
Dabei sage ich nicht (!!!) das es überflüssig ist die Information der Kostengruppen aus dem Modell ersehen zu können.

ABER

Es ist nicht Sinnvoll Daten "doppelt" abzulegen (--> Datenhygiene, SSoT --> Single Source of Truth)
Wie in dem Video und in der Anleitung ersichtlich, benötigt es für den Workflow die ifc Standard Attribute, die genau die Klassifizierung der DIN 277 beschreiben.
Modellersteller sind schon genug damit beschäftigt diese Informationen korrekt in den Modellen zu halten.
Das Klassifizieren muss anschließend dort satt finden wo es benötigt wird: Also beim Import der ifc Modelle in der Zielsoftware, und das über die angesprochenen Standardattribute.

Für Denjenigen, der Das ifc-Modell anschließend weiter verwendet bietet ein zusätzliches Attribut also keinen Mehrwert, sondern es birgt nur die Gefahr von Unstimmigkeiten.

Viele Grüße
Florian

LinkedIn-Profil

www.vollack.de

Agi_M
Agi_M
10.04.2025 - 08:09

Ganz meine Meinung!

Nemo
Nemo
10.04.2025 - 08:17 *

Ich teile diese Meinung nicht vollumfänglich.

Wenn man die Information "Kostengruppe" über ein Formel-Attribut generieren läßt,
kann es zu keinen "Unsitmmingkeiten" kommen. Wenn sich eines der "beteiligten" Attribute ändert,
wird automatisch die Kostengruppe neu "ausgewertet".

Insofern ist sogar die Methode, die "Kostengruppe" mit dem PythonPart einmalig statisch an die Objekte zu schreiben, nicht zielführend, da nicht "assoziativ"!

Es handelt sich auch nicht um "doppelt abgelegte Daten", selbst wenn eine direkte Abhängigkeit zu anderen Attributen besteht, da diese Abhängigkeit nicht trivial und auch nicht linear ist!
Wenn die abhängigen Attribute alle auch im IFC-Modell vorhanden sind, ist es möglicherweise egal, wann man dieses Datum "Kostengruppe" "übersetzt".

Möglicherweise braucht es aber noch zusätzliche Informationen, welche nur in Allplan-Attributen oder Element-Eigenschaften, nicht aber im IFC-Modell verfügbar sind, um eine genaue Zuordnung zu treffen. In diesem Fall wäre eine "Übersetzung" in Allplan alternativlos.

‹2020-2029›
201920202021202220232024202520262027202820292030
‹2020-2029›
201920202021202220232024202520262027202820292030