Allplan Forum: BIM Attribute mit hilfe von Datenbak erstellen und verwalten

JanRei

26.05.2020 - 13:20

Hallo zusammen,

da in der Infrastrukturplanung derzeit noch keine BIM-Standards (P-Sets, Attribute,...) vorhanden sind, erarbeitet unser Büro derzeit einen umfangreichen Attributkatalog für verschiedene Pilotprojekte. Damit die Daten immer aktuell sind udn auch von verschiedenen Benutzern abgerufen werden können haben wir uns dafür entschieden, eine Datenbank (Access) anzulegen in der alle Attribute verwaltetet werden.

In Allplan ist es bekanntermaßen möglich Attribute innerhalb des Programms selbst zu erstellen. Da dies bei einer großen Anzahl Attribute aber sehr mühselig und fehleranfällig bei Änderungen ist, ist mir der Gedanke gekommen die Attribute durch ein Skript erstellen zu lassen.

Soweit mir bekannt enthält die Datei AttributeDefinitionCollectionLocal_de.xml die Attributdefinitionen. Die Idee ist jetzt diese Datei durch das Skript zu beschreiben und so automatisch die Attribute zu erstellen. Hat jemand bereits Erfahrung mit einem solchen Vorgehen gemacht?

In der Datei wird jedem Attribut beim Erstellen eine Uid zugewiesen. Wie wird diese generiert bzw. was sind zulässige Werte die hier eingetragen werden können?

Gruß
Jan

Brücken und Ingenieurbau
VIC Planen und Beraten GmbH
https://www.vic-gmbh.de/

Anhänge (1)

Typ: image/jpeg

99-mal heruntergeladen

Größe: 9,42 KiB

Hilfreichste Antwort anzeigen Hilfreichste Antwort verbergen

Nemo

15.01.2021 - 17:22 *

Der Eingabetyp "Listbox ohne Eingabe" erzeugt den Attributtyp "Enum-Attribut".

Für alle nicht Programmierer: Eine Enumeration ist ein Aufzählunstyp.
Eingeführt wurden diese Enum-Attribute eigentlich, damit man die Werte in der Definitions-XML bereits lokalisieren kann, wenn es Strings sind. z.B. beim den Attributen Gewerk , Umbaukategorie, Türanschlag oder Ansichtsart.
Eine Enumeration ist eine Liste von festgelegten Werten. Der Sinn dabei ist: Man speichert nicht den Wert im Attribut, sondern nur die Position des Wertes innerhalb der Liste. Der "entsprechende Wert" kommt aus der Definition des Attributes.

Bei der Speicherung in der AttributeDefinitionCollection.xml wird daraus jedoch ein Key-Value-Pair:

<AttributeDefinition>
...
<Enumeration>
      <Item>
        <Key>0</Key>
        <Value />
      </Item>
      <Item>
        <Key>1</Key>
        <Value>F30</Value>
      </Item>
      <Item>
        <Key>2</Key>
        <Value>F90</Value>
      </Item>
...
</Enumeration>
...
</AttributeDefinition>

Dabei wird nur der Key im Attribut gespeichert.

Nun würde man erwarten, dass, wenn man den Wert Key 1 = "F30" löscht, der Key der darauffolgenden
Werte (Key 2="F90", Key 3="BW" usw.) gleich bleibt. Das ist scheinbar nicht der Fall.

Es ist sehr gefährlich bzw. unmöglich, Werte aus der Liste zu löschen!
Durch die Änderung der Keys ändern sich projektweit die angezeigten Werte in den Attributen der Elemente! Meist unbemerkt und unbeabsichtigt!

Der Eingabetyp "ComboBox" verfährt anders. Er enthält nur eine Liste von "Vorschlagswerten" für den Attribut-Wert. Der Wert wird vollständig im Attribut gespeichert. Dadurch kann man die Auswahlliste beliebig erweitern, ohne dass die Attribut-Werte verfälscht werden.

Durch das oben genannte Verhalten verwenden wir keine Enum-Attribute mehr.
Wir verwenden ausschliesslich Attribute mit Eingabemethode "Combobox", auch wenn dadurch die Einheitlichkeit der Werte nicht gewahrt werden kann! Auch sind bei uns grundsätzlich Änderungen an den Attributen verboten!
Diese darf nur der Admin anlegen und ändern.

21 - 26 (26)

Nemo

17.01.2021 - 10:03 *

Nein, Markus, globale Datenwandlung war in dem Fall nicht gemeint. Man kann die "Interpretation" des Wertes auch beim Lesen des Attribut-Wertes machen. Wenn der Wert nicht zum Datentyp passt, kann man eine Konvertierung versuchen: Zahl 123 in String "123" Ganzzahl 123 in Gleitkommazahl 123,00 usw. Das macht auch Excel nicht anders. Auch in den Excel-Formeln wird ggf. automatisch eine Konvertierung in den Zieldatentyp gemacht (s. Datentyp Variant). Beim Enum-Attribut müsste dazu eben auch der Wert neben dem Key als Fall Back gespeichert werden.

zum_loesch…

17.01.2021 - 11:31

auch hier war die antwort klar, ist aber zu kurz gefasst oder falsch!

derzeit wird bei einem enum die lage in der liste gespeichert. d.h. um hier mehr zu haben, müsste alles angefasst/angepasst werden -> Datenwandlung über ALLES notwendig!

da das enum in allen beschriftungen (Formeln) UND Reports auf zwei arten verwendet sein kann - einmal als textentsprechung und einmal als zahl (was bei mehrsprachigen dingen viel sinn macht!), müssten hier auch alle mögliche vorkommen angepasst werden.

damit ist eine interpretation des typs anhand des inhalts nach einer änderung als "lösung" vermutlich nicht möglich.

damit folgt, dass die vermutlich "einzige" lösung, das verhindern der änderung des Typs von attributen und die änderung des eingabemechanismusses für eine ENUM-liste sein dürfte.

Namenlos gezeichnet in vollem Bewusstsein - ignorant, in eigen Augen vermutlich höflich, dennoch unhöflichst, unfreundlichst wer einen/viele vermutete - sich von alters erschließende Namen nennt.
[b]

Nemo

17.01.2021 - 12:11 *

...beim Enum-Attribut hast Du natürlich recht:
Ohne Änderungen an der Datenstruktur (ohne DATWA) ist diese Problem nicht zu lösen!

Aber dann sollte man wenigstens das Mögliche machen:
Die Änderung der Eingabemethode darf nachdem das Attribut einmal definiert wurde, nicht mehr möglich sein.
Ebenso müßte dann aber die Änderung des Datentyps im Nachhinein nicht mehr möglich sein.
Und auch die Änderung der Enum-Werte müßte dann blockiert werden, zumindest das Löschen von Werten, solange man nicht sicherstellt, dass die anderen Keys nicht verändert werden!

Das Lesen des Attribut-Wertes kann man aber schon versuchen zu optimieren,
gerade wenn der Anwender aus Versehen bereits den Attribut-Typ geändert hat!

Ich bin sicher, hier wird man bei Allplan eine Lösung finden, wenn man sich des Problems annehmen sollte.

@Allplan_er
Man könnte versuchen, den vorherigen Zustand der Datei AttributeDefinitionCollectionLocal_de.xml im Verzeichnis \Prj\xml oder Std\xml aus der Volumenschattenkopie wiederherzustellen.

Wenn das nicht funktioniert, dann einfach die Definition in Allplan wieder zurück in "Listbox ohne Eingabe" ändern, und die Werte in der Liste wieder eingeben.

zum_loesch…

17.01.2021 - 12:27

beim lesen des wertes ist das auch nicht ganz so einfach, wie es sich excel machen kann.
es gibt bei der interpretation von zahlen das internationale problem des zeichens für die trennung von vorkommastellen von den nachkommastellen inkl. der problematik wie mit den - zumeist konträr zu dem ersten trennzeichen - trennzeichen für die tausender-stelle verfahren werden kann/muss.

Nemo

17.01.2021 - 12:40 *

..dieses "internationale" Problem exisitert nur, wenn zwischen Erstellung und "Interpretation" der Daten die Lokalisierung (das Land) gewechselt hat. Das ist aber praktisch nie der Fall, und so kann man diesen Fall ggf. vernachlässigen, jedenfalls beim Lösungsansatz...

Im Übrigen akzeptiert Allplan schon immer Punkt und Komma als Dezimaltrennzeichen in Eingabefeldern.
Es ist sicher einfach, diese "Toleranz-Logik" in den "Interpretationsalgorithmus" zu übertragen!
Für das Umwandeln von Strings in numerische Daten gibt es ausreichend erprobte und fehlertolerante Algorithmen, die sogar gute Ergenisse liefern, wenn die Lokalisierung unbekannt ist.

Und wie gesagt, dieser Algorithmus kommt erst zum "Tragen", wenn der gelesene Datentyp vom definierten Datentyp abweicht! Ohne Änderung an der Attribut-Defintion also nie! Es ist eine "Daten-Versicherung" für Fehleingaben bei der Attribut-Definition.

zum_loesch…

17.01.2021 - 17:17

bei den Eingabefeldern ist es klar, DASS eine Zahl kommen soll und die Eingabe der 1000-er-Punkte macht wirklich niemand.
Bei attributwerten ist das nicht so klar. wenn dies so "einfach" wäre, wäre die Funktion VALUE() sicher "neutral" mit Punkt und komma gebaut worden und nicht nur mit punkten als dezimaltrennzeichen.

Problematisch wird bei der betrachtung mit "punkt=komma -> Zahl" jeglicher Datenübergang in teilen international.

ich schätze das risiko einer fehlinterpretation - klar in einzelfällen - für sehr hoch und dann kaum durchschaubar ein.
wenn man das ganze selbst "baut" mit VALUE(), weiß man im zweifel auch was geschieht, bzw. jemand im büro.

21 - 26 (26)