Klassifitseerimise tarkvaraline spetsiifika

by Raido Puust

Selles osas toome näiteid, kuidas erinevates tarkvarades on klassifitseerimine võimaldatud, mida saad iseseisvalt katsetada läbi näitefailide ja/või nende baasil luua oma enda tarkvara mall (või olemasolevat uuendada).

Sisujuht

Klassifitseerimise tarkvaraline spetsiifika

Autodesk AutoCAD

Autodesk AutoCAD tarkvara on kasutatud väga erinevate joonestamise- ning modelleerimisega seotud ülesannete juures ning seda on võimalik väga edukalt kasutada ka ühe osana BIM/korrashoiu mudelitele infosisu loomiseks, kuid kuna see ei toeta omaduste grupi funktsionaalsust (ingl property set), mida saab eksportida IFC faili, siis seda selles alalõigus rohkem ei käsitleta. Samas tuleme selle juurde tagasi läbi AutoCAD vertikaaltoodete nagu AutoCAD Architecture, AutoCAD MEP ning Autodesk Civil 3D, sest üldiseid 2D/3D komponente saab klassifitseerida just nendes vertikaaltoodetes. Lisaks on oluline märkida, et kuna paljud teised tarkvarad kasutavad AutoCAD tarkvara oma baasplatvormina, siis tuleb tähele panna, mismoodi on klassifitseerimist nendes lisatoodetes (või pluginates) võimaldatud.

AutoCAD Architecture / MEP / Autodesk Civil 3D

AutoCAD Architecture / MEP / Civil 3D on levinud, ehituskomponendil baseeruvad, ehitusinfo modelleerimise platvormid. Need on laialdaselt kasutusel nii eraldiseisvalt kui läbi lisatarkvarade, mis neid oma alusplatvormina kasutavad (nt Architecture / MEP platvormi: hsbcad, MagiCAD; Autodesk Civil 3D platvormi: Trimble Novapoint). Lisaks toetavad need ka IFC eksporti (nt IFC 4.3 eksport on saadaval Civil 3D tarkvarale, mis kaasab uuendusena infravaldkonna komponente).

Kõigi eelnimetatud kolme tarkvara juures saab n-ö esimese taseme klassifitseerimisena kasutada funktsionaalsust, mis defineeritav: Style Manager > Multi-purpose Objects > Classification Definitions, kust võib ka näitefaili osas leida ehituskomponentide eeldefineeritud CCI klassifikaatorid (vt joonis).

Pane tähele, et antud näites on kasutusel atribuutide nimetamise skeem, mis algab koodiga (2 tähte, 3 numbrit, nt eelneval pildil AC175_). Need nimetused on defineeritud CIA-EE andmebaasis, kust leiab ka omaduse definitsiooni ning algallika ja/või seosed teiste omadustega, kui neid peaks olema defineeritud (sh ETIM, IFC omadused). Koodi osale järgneb tekstiline osa (kasutusel ka neid eristav alakriips). Tekstilise osa eesmärk on tagada inimloetavus. Samas ei ole kasutusel ei täpitähti ega ka tühikuid või lisakriipse. Nagu varasemalt markeeritud on atribuutide nimetused paigas infovahetuse nõuetega.

Tagasi Classification Definitions sektsiooni juurde. Selle peamine funktsionaalsus on tekitada seosed põhiklassifikaatori ning olemasolevate omaduste grupi (property set) vahel. Teisisõnu, kui mõni joonisel olev komponenti on klassifitseeritud kindla koodiga, siis saab selle külge lisada vaid kindlaid omaduste gruppe. Seega töötab see kui filter olukorras, kus meil on ehk kümneid erinevaid omaduste gruppe, mis igaüks mõeldud väga konkreetsele varaklassile. Lisafunktsionaalsusena saab seda kasutada ka olukorras, kui soovitakse üldine klassifikaator eksportida IFC struktuuri IfcClassificationReferences. Samas ei pruugi see iga IFC versiooniga (või tarkvaras) olla toetatud (nt IFC 2×3 on OK, aga IFC 4×3 juures mitte). Sellest hoolimata on need kaks asja eraldiseisvad ja üks ei sega teist. Olgu siinkohal markeeritud ka lihtne näide, kuidas käib klassifikaatoril põhineva omaduste grupi seadistus (pane tähele, et see võib Style Manager akna teha väga aeglaseks, eriti siis kui klassifikaatoreid on väga palju, kuna tundub, et tarkvara ketrab “iga liigutuse peale” kogu nimekirja läbi, et kindlat linnukest leida – aga see on vaid Style Manager aken ja mitte joonisel olles).

Niisiis, veendu, et AC175_KomponentKlassKood oleks rakendatud neile objekti gruppidele, kus soovid seda funktsionaalsust kasutada (tavapärane Property Set Definition ei saa seega kasutada Applies To sektsioonis linnukest, mida pole lisatud Classification Definitions sektsiooni Applies To paanile – vastupidine olukord on lubatud). Alloleval pildil on valitud enamus Civil Bridge algusega valikud.

Nüüd liigume Property Set Definitions juurde. Ja selles näites kasutame lihtsalt eelnevalt defineeritud kahte omaduste gruppi, A001 ning A010. Neist esimese, A001 juures määrame, et seda saab kasutada kui valitud klassifikaator ULD (saab ka mitu valida!).

Nüüd A010 omaduste grupile valime aga näiteks ULC.

Klikime OK ja sulgeme dialoogi. Kui nüüd valida mõni komponent ja määrata klassifikaatorina (Properties paleti ülemises osas) kas ULC või ULD, muutub ka dialoogis Add Property Sets esitatav sisu. Ühel juhul näidatakse A010 ja teisel juhul A001.

Kasutada võib ka käsku AECPSDUTOATTACH, misjärel lisatakse automaatselt kõikidele objektidele need omaduste grupid, mida parasjagu neile võimaldatud (eeldab, et klassifikaator oleks määratud). Selline meetod võimaldab lihtsustada omaduste gruppide kaasamist kui neid on palju ja need sõltuvad objekti tüübist, mida omakorda reguleerub konkreetne, CCI klassifikaator. Lisatud klassifikaatorit saab kasutada teatud omaduste automaatseks täitmiseks, aga seda juba väljaspool Civil 3D tarkvara (sh läbi Dynamo liidese, millest juttu edaspidi).

Lisaks Classification Definitions sektsioonile, on CCI klassifikaatorid kaasatud näidisjoonisesse ka läbi List Definitions valikute (vt allolev joonis). See võimaldab atribuutidele määrata teatud nimekiri võimalikke väärtuseid.

Style Manager dialoogi kasutatakse ka erinevate omaduste gruppide (Property Set Definitions) loomiseks. Just olulisemad, põhiklassifitseerimisega seotud atribuudid, on näitena lisatud ka näidisjoonisesse. Property Set Definition nimetus (seda saab vaadata ka kui andmemalli) algab sektsiooni tähega, kust pärinevad valitud omadused ning seejärel lisatakse number, mis esitab andmemalli valitud omaduste rühma. Seega võib vastavalt vajadusele (infosisunõuetele) koostada erinevaid andmemalle, mis kaasavad erinevaid omadusi ning seega ka erinevat numbrilist osa, et unikaalselt neid rühmasid/andmemalle identifitseerida (nt klassifikaatori/objekti tüübi põhine andmemall). Näiteks üldise klassifitseerimisega seotud omadused ehitise tasandil on koondatud andmemalli A001 alla, millele võib lisada ka tekstilise osa: A010_AdminEhitis (vt allolev joonis). Samas kui suurem osas klassifitseerimist tehakse ikkagi elemendi tasandil ja selleks on omaette atribuutide grupp nimetusega A010_AdminElement. Pane tähele, et see tekstiline osa võiks olla lihtsasti mõistetav (inimloetav) ning mitte segadust tekitav. Samas kui tähe-numbriline osa (A001, A010) on ennekõike masinloetav.

Teatud omadusi on võimalik automaatselt täita kui selles on markeeritud mingi üldklassifikaator. Selleks võib kasutada ka väliseid rakendusi ja seejärel importida Civil 3D tarkvarasse. Osasid omadusi on võimalik Property Set Definitions dialoogis ka automatiseerida, nt atribuudi väärtuste kokku liitmine, et seeläbi esitada viitetunnust.

Omaduste gruppe (Property Set Definitions) võib ühetaoliselt luua kõikide objektide lõikes, või siis diferentseeritult lähtuvalt Applies To valikutest, kuid sellisel juhul peaks omaduste grupi nimetused olema eristuvad, et neid oleks lihtsam kasutada või ka automaatselt rakendada. Teisisõnu, omaduste grupi nimetused tuleb hoolikalt läbi mõelda ja neid samu nimetusi kasutada ka teistes tarkvarades, mis sama loogikat toetavad, et mistahes IT-süsteemi kokku tõstes säiliks nende ühetaolisus, mõistetavus. Omaduste gruppe võib liigitada ka projekti staadiumi järgi, ehkki üht ja sama omaduste gruppi võib kasutada ka universaalsena, lihtsalt me ei täida infovälju, mis pole mingiks projekti staadiumiks veel teada.

Järgides eelnevalt toodud põhimõtteid saame komponendid, tehnilised süsteemid jne klassifitseerida, identifitseerida ning lisada neile ka tüübi tunnuse. See kõik asendaks mistahes, varasemalt kasutusel olevaid, nimetamise reegleid, sest topelt-süsteemi pole mõtet kasutada. Tõsi, teatud olukordades võib olla vaja siduda varale ka mingi muu ID väärtus, mis lähtub kasutatud IT-süsteemi arhitektuurist ja varade registrist aga see on siis lisaomadusena märgitav, mis aitab informatsiooni üle kanda ühest süsteemist teise. Ja mõistagi võivad mõnes projektis olla kasutusel ka erinevad klassifitseerimissüsteemid paralleelselt (nt CCI-EE ja Uniclass paralleelne kasutamine), kuid nende vajadus peab olema selgelt defineeritud/teavitatud, et kasutaja ei satuks segadusse.

Autodesk Revit

Autodesk Revit on ennekõike hoonete, konstruktsioonide ning hoone-siseste insener-tehniliste lahenduste modelleerimise pakett, mida osaliselt kasutatakse ka väliala modelleerimises (asendiplaan, sillad, müratõkkeseinad jne). Klassifitseerimissüsteemi saab siin kasutusele võtta läbi Project Parameters funktsionaalsuse, kus esmalt defineerime need omadused, mille kaudu soovime klassifikaatori või mistahes sellega seotud muu parameetri kasutusele võtta. Selleks on mitu võimalust. Need omadused võib ära defineerida projekti mallis, kuid neid võib olemasolevasse projekti sisse tuua teisest projektist või projekti mallist (Manage > Transfer Project Standards). Soovi korral võib need omadused sisse tuua ka läbi Shared Parameters faili või kasutada mõnda lisapluginat, milles üldjuhul need impordid mugavamalt teostatavad (nt DiRootsOne ParaManager). Sellisel juhul saame lihtsamini ümber mängida, mis sektsioonis me neid parameetreid soovime kuvada (sh märkida, kas tegemist on tüübi või unikaalse parameetriga). Shared Parameters on ka oluline siis kui soovime neid omadusi jagada teiste projekti partneritega (kes kasutavad samuti Autodesk Revit või GUID põhist tarkvara – samas näiteks Autodesk Architecture / MEP / Civil 3D kasutavad oma enda unikaalse ID süsteemi, milleks on Handle).

Samas ei ole GUID ehk Globally Unique Identifier CCI kontekstis enam oluline, sest meie unikaalseks tunnuseks saab just nimelt CIA-EE omaduse nimetus (2 tähte + 3 numbrit, vt sissejuhatavat osa eespool). Üldiselt on soovitav, et need omadused oleksid meil esmalt projektis olemas ja seadistatud viisil, mis määravad, kus neid omadusi kuvatakse.

Allpool näide, kus omadus AC125_EhRuumKlassKood (esitab ehitatud ruumi CCI koodi) on seotud vaid Autodesk Revit ruumide kategooriatega. Lisaks pane tähele, et antud omadus on kaasatud Identity Data sektsiooni ning see märgitud kui Instance omadus, mis tähendab, et seda saab muuta kõikide ruumobjektide juures eraldiseisvalt (sõltumata sellest, kas see on sama tüüpi või mitte). Oluline! Teatud gruppide juures saamegi kasutada vaid Instance tüübina defineeritud omadusi (üheks näiteks ongi ruumobjektid).

Varasemates näidetes on CCI-ga seotud omadused kaasatud Identity Data sektsiooni alla. Lähtuvalt aga atribuudi iseloomust (Instance või Type) jaguneksid need omadused ära Properties vs Type Properties dialoogide vahel.

Need omadused, mis ei ole otseselt seotud klassifitseerimisega / identifitseerimisega, on aga lisatud Data sektsiooni alla (ka siis kui see omadus ise sobituks pigem mõne teise kategooria alla, mida Autodesk Revit pakub). Sellisel juhul on neid lihtsam leida, kuna kõik ühes kohas.

Üks CCI-ga seonduv atribuut (näidisprojektis) istub ka IFC Parameters sektsioonis. Tegemist on parameetriga AJ300_IfcClassReference, mis täidetakse kujul: CCIkood: CCImõiste (nii nagu CCI-EE tabelis on need kirjutatud, ilma tüübi/ID väärtuseta, tegemist on peatasandi klassifitseerimisega, mis IFC eksportimisel liigub õigesse sektsiooni, vt hilisemat näidet).

CCI-kesksest omaduste sisestamist oleme varasemalt juba käsitlenud. Siinkohal tasub lisaks märkida, et juhul kui on tegemist Instance omadustega, siis sisuliselt tähendab see seda, et igale valitavale komponendile peaksime vastava lahtri ära täitma, ka siis kui tegemist on sama tüübiga. Aga, et lihtsamini neid sisestamisi teha (nt akendele panna külge CCI põhiklassifikaator QQA, Aken – ehk siis ühised omadused, selleks võib juba kasutada erinevaid Autodesk Revit funktsionaalsusi, sealhulgas Select All Instances (parema klikiga valik ja seejärel täites ära ühised omadused Properties paletil) või hoopis teha seda läbi spetsifikatsioonide (Schedules tabelite). Võimalusi on mitmeid. Kuna klassifitseerimine kaasab aga väga palju sellist infot, mis on ette kirjutatud ja me peame etteantud nimekirjast õige väärtuse valima, mitte seda iga kord uuesti sisse toksima (kirjavigade oht), saab kasutada lisapluginaid. Üheks näiteks, mida allpool vaatame, on Autodesk Interoperability Tools.

Autodesk Interoperability Tools / Standardized Data olemus ja kasutamine

Ehkki klassifitseerimissüsteemi saab siin kasutusele võtta ka lihtsalt läbi omaduste defineerimise ja nende täitmise, vaatame siinkohal omaette pluginat, mis võimaldab lihtsamini kaasata olemasoleva klassifitseerimissüsteemi sisu. Selleks on Autodesk Interoperability Tools koosseisu kuuluv Standardized Data plugin.

Vaatame esmalt, kuidas Autodesk Interoperability Tools koosseisus olev Standardized Data aitab klassifitseerimissüsteemi lihtsamini kasutusele võtta. Laadi alla mall (leitav allalaadimise sektsioonist, MS Excel fail), ava Autodesk Revit, veendu, et oled installeerinud Autodesk Interoperability Tools töövahendid, kliki: Standardized Data > Assign Classification (või ka Assign Picklist)

Esimesel käivitamisel ei pruugi olla näha nupukest Picklist.

Kliki esimesel nupul Options ning lisa lisarada, kust võib leida alla laaditud või loodud lisamalle (MS Exceli failid).

Sektsioonis Picklists lisa enda arvutist või võrgukettalt aadressid, kust võib MS Excel faile leida. Allpool lihtsalt näide.

[Defaults]
ShowPublicDbs=true
LocalDbFolder=C:\01-taltech\30_Projects\CCI-EE\templates\standardized-data

Peale Picklist nupu kuvamist, Load New PickList, seejärel juba My Library sektsioon ning vali sobiv MS Excel fail.

Peale hiirega valiku tegemist, kliki OK. Seejärel kliki ka Click here to load, et andmebaas laadida.

Järgnevalt saad asuda klassifitseerimise juurde. Ehk siis plugina kaudu laaditakse CCI-EE tabelid ja kuvatakse vastavalt valitud elemendi iseloomule. Siinkohal on oluline märkida, et valitud tabelid aitavad meil täita just nimelt CCI põhiklassifikaatoreid (mitte sellega seotud tüüpi/alatüüpi). Samas saab Autodesk Interoperability Tools töövahendit kasutada väga erinevate mallidega “paralleelselt”. Ehk siis ühe malli kaudu täidame mingit kindlat projekti staadiumis teadaolevat infot (nt mingi osa infot on teada üldisemal kujul juba projekti varajases staadiumis, “aken on aken”, “post on post”). Seejärel võib eksisteerida teine mall, mille kaudu saame lihtsustada tüüpide täitmist. Lisaks võib eksisteerida omaette mall, mille kaudu saab täita infosisu nõuetest tulenevaid omaduste väärtuseid (nimekirjadest valikutena). Need omadused, mis meie näites on Data sektsioonis. Tuleb tähele panna, et mall peab olema defineeritud viisil, kus iga tööleht sisaldab projekti parameetri viidet, ainult siis suudetakse seda ka täita. Ei ole sisuliselt vahet, kas projekti parameeter on Type või Instance. Antud töövahend otsib lihtsalt mallis märgitud omadust ja täidab selle seal, kus see parasjagu asub. Allpool näide, kus komponendi CCI klassifikaatorit defineerivad kaks omadust (vt malli töölehte CCI table CO, ning ülemisi ridasid NUMBER PARAMETER, DESCRIPTION PARAMETER).

Klassifitseerida saad selle töövahendi kaudu sisuliselt kolmes erinevas põhivaates (Facility, Element, Space). Esmalt, Facility vaade. Kui ühtegi komponenti valitud pole, siis me räägime Ehituskompleksi või Ehitise taseme klassifitseerimisest, ja need liiguvad meil üldjuhul Project Information dialoogi.

Kui nüüd esmalt valida paanilt Facility hüpikust kas CCI table CC või CCI table CE, klassifitseerimegi oma ehitise kompleksi/ehitise koodi järgi. Näiteks, valime kompleksina A – Elamukompleks. Seejärel dialoogi allosas Assign. Sarnaselt võime teha ka CCI tabel CE osas, kus valime näiteks AA – Eramu. Jällegi klikime Assign nupul. Antud info on seejärel kuvatud Project Information dialoogis.

Sulge Project Information dialoog. Käivita uuesti klassifitseerimise töövahend, Assign Classification nupust. Pane tähele, et kui mingil hetkel on vaja uuesti klassifitseerida juba olemasolevate koodidega komponente, siis tuleb sul eemaldada linnuke Options > Blanks only. Vastasel juhul muudatust ei teostata.

Kui nüüd aga liigud edasi Picklist sektsiooni ja valid näiteks 3D vaatest mõne elemendi, oletame, et selleks on aken, aktiveeritakse paan Element ning selle all on omakorda hüpik erinevate klassifitseerimissüsteemi alamtabelitega. Saad need nüüd akna puhul ühekaupa valida/täita.

Valime näiteks CCI table CO. Saame kasutada otsingusõna aken, ning seejärel saame kiiremini ka soovitud sektsiooni/koodi juurde. Valime selle ja klikime Assign.

Sulge Standardized Data dialog. Vali aken ning kontrolli selle omadusi. Pane tähele, et vastavad omadused on täidetud Identity Data sektsioonis.

Sellega oleme põgusalt tutvunud Autodesk Interoperability Tools plugina Standardized Data olemusega. Ääremärkusena võib öelda, et vastavat dialoogi ei pea sulgema kui soovid klassifitseerimisega jätkata. Lihtsalt vali järgmine element või ka elementide grupp (Select All Instances > Visible in View), vali kood, mida soovid lisada ning seejärel Assign. Vali uus elementide grupp ja jätka. Saad jooksvalt CCI-EE tabeleid vaadata, et lisada ka teisi koode. Omaduste lihtsamaks sisestamiseks võib kasutada ka teisi töövõtteid, sh teha seda läbi Dynamo liidese. Samas on oluline märkida, et sisu täidetakse ikkagi Autodesk Revit failis ja mitte alles eksporditavas failis. Seega, peavad Autodesk Revit ja näiteks sellest tuletatud muu formaat (IFC, MS Excel eksport) sisaldama täidetud omadusi täpselt samas mahus. Vastasel korral võimaldame andmete erinevat interpreteerimist lähtuvalt valitud failist/andme tüübist.

Märkus. Juhul kui kasutad atribuuti Type seades, siis täidetakse kõik sama tüübiga komponendid korraga.

IFC eksport ühes klassifitseerimissüsteemist tulenevate koodidega

Enne konkreetse näite juurde minemist peame aru saama, kuidas klassifitseerimiskoode kuvatakse IFC-s. IFC juures saame peatasandi klassifikaatori lisada IfcClassificationReference mahtu (need on CCI koodid, mõisted, mis tulevad CCI-EE tabelist, ilma tüübi või ID väärtuseta). See loob universaalse CCI põhise klassifitseerimise ka IFC struktuuris, mis aitab geomeetriat filtreerida, andmeid üle kanda või muul viisil üldtaseme infot vaadata. Samas kui ülejäänud omadused (sh tüübi, ID ja viitetunnustega seonduv aga ka infosisu esitavad CCI-järgsed omadused) kuvatakse teistes sektsioonides.

Selleks, et kaasata IfcClassificationReference seost, on projekti malli lisatud omadus nimetusega AJ300_IfcClassReference. Kaasame selle omaduse aktiivse projekti IFC Parameters alla.

Selle täitmiseks on meil võimalik samuti ette valmistada Standardized Data mall, kuid antud juhul täidame selle lihtsalt käsitsi. Parameetri sisestus lähtub loogikast, et KOOD: Mõiste. Seega näiteks akna kirjeldamiseks täidame vastava välja kui: QQA: Aken (mõlemad variandid peaks töötama, kas pannakse peale koolonit tühik või mitte).

Enne IFC eksporti peame veel osutama, kust IfcClassificationReference osa loetakse. Selleks vali File > Export > IFC. Redigeerime <In-Session Setup> seadistust, kuid mõistagi võid selleks ka uue seadete grupi luua. Kliki Modify Setup > Property Sets > Classification Settings…

Saad seejärel sisestada erinevat infot, mis puudutab kasutatavat klassifitseerimissüsteemi (sh tabeli versioon, veebiaadress, kust see pärineb jne). Pane tähele ka kasti: Classification field name = AJ300_IfcClassReference, see mängib olulist rolli IFC struktuuri IfcClassificationReference täitmist.

Märkus. Classification Settings määratakse alljärgnevalt (lähtuvalt IFC versioonist):

IFC 2×3

Name – IfcClassification.Name
Source (Publisher) – IfcClassification.Source
Edition – IfcClassification.Edition
Edition date – IfcClassification.EditionDate (ei ekspordita selles versioonis, IFC 2×3)
Documentation location – IfcClassificationReference.Location
Classification field name – omaduse nimetus, kust klassi kood ning mõiste loetakse (kood: mõiste)

Kui vaadata eksporditud IFC faili, leiame (ridade numbrid võivad erineda):

#1214108=IFCCLASSIFICATION(‘Ehituskeskus’,’2023.08.0.1′,#1214109,’CCI-EE’);
#1214110=IFCCLASSIFICATIONREFERENCE(‘www.ehituskeskus.ee’,’QQA’,’Aken’,#1214108);

IFC 4.x (IFC 4.3 toob kaasa mõned muudatused)

#1214342=IFCCLASSIFICATION(‘Ehituskeskus’,’2023.08.0.1′,’2023-11-28′,’CCI-EE’,$,’www.ehituskeskus.ee’,$); (erisuste kohta IFC 4.3 kontekstis vaata veebilehte)
#1214343=IFCCLASSIFICATIONREFERENCE(‘www.ehituskeskus.ee’,’QQA’,’Aken’,#1214342,$,$); (erisuste kohta IFC 4.3 kontekstis vaata veebilehte)

Ekspordi IFC fail (veendu, et oleks valitud ka soovitud omaduste grupid) ning vaata IFC faili mõnes vabalt valitud vaaturis/veebiteenuses. Siinkohal näide Trimble Connect kasutamisel.

Pane tähele, et kasutatav IFC vaatur võib eelnevalt kirjeldatud omadusi nimetada erinevalt:

Location – www.ehituskeskus.ee – IfcClassificationReference.Location
ItemReference – QQA – IfcClassificationReference.ItemReference
Name – Window – IfcClassificationReference.Name
RelatingClassification.Source – Ehituskeskus – IfcClassification.Source
RelatingClassification.Edition – 2023.08.0.1 – IfcClassification.Edition
RelatingClassification.Name – CCI-EE – IfcClassification.Name

Üldjuhul ei peaks me sama infot kahes kohas esitama (eriti olukorras, kus neid saab eraldiseisvalt redigeerida). Seega ei pruugi üldist klassifikaatorit ka Identity Data (või muu valitud grupp, kuhu omadus kuulub) all näidata ning piirduda IfcClassificationReference sektsiooniga. Samas võib duubeldamine olla vajalik just viitetunnuste tegemiseks.

Lisaks tasub tähele panna, et erinevad IFC vaaturid võivad sama infot kuvada erinevat moodi. Näiteks, BIMcollab ei kuva sektsiooni IfcClassificationReference, selle asemel kuvatakse see info esimesel paanil, Summary.

Solibri Anywhere kuvab vastavat infot Classification paani all.

BIMvision kuvab vastavat infot samuti Classification paani all.

Ehitise/kompleksi kontekstis eelnimetatud tarkvarad klassifikaatorit IFC vaaturis ei kuva, kuid see on IFC failis olemas:

#141=IFCPROPERTYSINGLEVALUE('AC135_EhKompleksKlassKood',$,IFCTEXT('A'),$);
#142=IFCPROPERTYSINGLEVALUE('AC140_EhKompleksKlassNimi',$,IFCTEXT('Elamukompleks'),$);
#143=IFCPROPERTYSINGLEVALUE('AC145_EhitisKlassKood',$,IFCTEXT('AA'),$);
#144=IFCPROPERTYSINGLEVALUE('AC150_EhitisKlassNimi',$,IFCTEXT('Eramu'),$);

Sellega oleme tutvunud klassifitseerimise tehnilise poolega Autodesk Revit näitel. Järgides eelnevalt toodud põhimõtteid saame komponendid, tehnilised süsteemid jne klassifitseerida, identifitseerida ning lisada neile ka tüübi tunnuse. See kõik asendaks mistahes, varasemalt kasutusel olevaid, nimetamise reegleid, sest topelt-süsteemi pole mõtet kasutada. Tõsi, teatud olukordades võib olla vaja siduda varale ka mingi muu ID väärtus, mis lähtub kasutatud IT-süsteemi arhitektuurist ja varade registrist aga see on siis lisaomadusena märgitav, mis aitab informatsiooni üle kanda ühest süsteemist teise. Ja mõistagi võivad mõnes projektis olla kasutusel ka erinevad klassifitseerimissüsteemid paralleelselt (nt CCI-EE ja Uniclass paralleelne kasutamine), kuid nende vajadus peab olema selgelt defineeritud/teavitatud, et kasutaja ei satuks segadusse.