Jeśli tu jesteś, to zapewne już zapoznałeś się z pierwszą częścią artykułu poświęconego IFC i temu, co powinien zawierać idealny plik.
Znajdziesz go tutaj.
Zapraszam do kontynuacji dyskusji na ten temat.
Chętnie podzielę się dalszymi przemyśleniami na temat tego zagadnienia.
Jeśli interesuje Cię temat IFC 4.3, nie zapomnij sprawdzić innych artykułów poświęconych temu tematowi na naszym blogu.
- Infrastruktura drogowa w schemacie IFC 4.3
- IFC 4.3 w projekcie drogowym (CASE STUDY)
- Relacje w infrastrukturalnym modelu IFC 4.3
- Przestrzenny podział projektu infrastrukturalnego w IFC
- IFC 4.3 na budowie
- Webinar o IFC 4.3
- Ticket to openBIM
- Export IFC 4.3
- 7 najważniejszych zmian w IFC kształtujących openBIM dla infrastruktury
- Przesyłanie Danych z Civil 3D do Quadri i Eksport do IFC 4.3
- Pięć skutecznych narzędzi do zapewnienia jakości danych w modelach BIM
- Właściwości w IFC
- Idealny IFC, część 1
Właściwości (ifcPropertySets)
Z pewnością możemy uznać, że jednym z głównych powodów, dla których korzystamy z formatu IFC, jest możliwość dodawania znacznej ilości informacji do poszczególnych obiektów. To właśnie z tego powodu wielokrotnie słyszałem argumenty za stosowaniem IFC 2×3 w projektach infrastrukturalnych, mimo że ten standard nie jest idealnie dopasowany do tej branży.
Ta możliwość wynika głównie z tzw. zestawów właściwości, znanych jako Property Sets. Jest to mechanizm umożliwiający szczegółowe opisanie danych. Pomimo iż, każda klasa IFC dostarcza domyślne zestawy właściwości, często okazuje się, że są one niewystarczające i nie spełniają oczekiwań użytkowników.
W praktyce własne właściwości są często preferowane. Omówiłem szeroko tę kwestię w artykule (link), ale chciałbym podkreślić jedną istotną rzecz. Aby właściwości zostały poprawnie zapisane, konieczne jest dokładne dopasowanie typów danych dla wartości właściwości. Jest to kluczowe dla skutecznej interpretacji danych z plików IFC i ich dalszego przetwarzania.
Na przykład, gdy chcemy zapisać dokładną liczbę, warto użyć typu danych “Real”, dla numerów warto wybrać “Integer”, a dla tekstów “String”. Odpowiednie dopasowanie typów danych ułatwia późniejszą analizę danych, na przykład gdy chcemy zsumować wszystkie liczby itp.
Nie możemy także zapominać o QuantitySets. W wielkim skrócie, działają one bardzo podobnie do Property Sets, ale pozwalają na dodawanie wartości, ilości, powierzchni itp.
Kolory (ifcColourRGB)
Kolory w IFC pełnią kluczową rolę w identyfikacji różnych elementów budynków lub infrastruktury, ułatwiając rozpoznawanie poszczególnych części modelu i dodając aspekt wizualny.
Mogą być używane do kategoryzacji różnych rodzajów danych w modelu, na przykład poprzez oznaczanie różnych typów materiałów budowlanych różnymi kolorami.
Dodatkowo, kolory mogą również służyć do odróżniania stopnia zaawansowania różnych obiektów. (Eg. MMI status)
W modelu IFC, kolor jest reprezentowany przez obiekt ifcColourRGB, który definiuje wartości RGB w zakresie od 0 do 1. Jednak często kolory RGB są prezentowane za pomocą wartości od 0 do 255. W związku z tym, kolory RGB zapisane w formacie IFC i w programach BIM są konwertowane.
Materiał (ifcMaterial)
Materiał odgrywa kluczową rolę w każdym elemencie konstrukcyjnym, stanowiąc fundament jego istnienia. W modelach BIM, informacje dotyczące materiałów są nieodłączną częścią, będąc jednymi z najczęściej uwzględnianych danych w projektach budowlanych.
W standardzie IFC istnieje dedykowana definicja, znana jako ifcMaterial, która umożliwia wprowadzanie informacji o materiale. Chociaż możliwe jest również korzystanie z standardowych PropertySets do tego celu, ifcMaterial zapewnia strukturalne podejście do reprezentacji właściwości materiałów w modelu.
Materiał może być dodawany do elementów bezpośrednio jako ifcMaterial, może być reprezentowany jako pojedyncza warstwa (ifcMaterialLayer), lub jako zestaw wielu warstw (ifcMaterialLayerSet). Na przykład, ściana budynku może być złożona z różnych warstw o różnej grubości, wykonanych z różnorodnych materiałów.
Dodatkowo, IfcMaterial może również zawierać informacje dotyczące prezentacji, takie jak style linii, wzory kreskowania czy kolory powierzchni. Co więcej, materiały mogą posiadać swoje unikalne właściwości. Dlatego też, informacje dotyczące materiałów są istotnym elementem, który warto uwzględniać w każdym modelu IFC.
Klasyfikacja (ifcClassification)
Wyobraź sobie, że jesteś częścią zespołu pracującego nad międzynarodowym projektem BIM. Naszym celem jest skuteczne zarządzanie modelem informacyjnym, który obejmuje różnorodne typy obiektów. Chcemy nie tylko opisać te obiekty zgodnie ze standardowymi klasami dostępnymi w schemacie IFC, ale także dostosować je do lokalnych standardów klasyfikacji, takich jak CoClass, UniClass czy NVDB (Norweska Klasyfikacja Danych Budowlanych).
Dodatkowo, aby ułatwić pracę w międzynarodowym zespole, planujemy dodać tłumaczenia do każdego obiektu w języku ojczystym użytkownika.
W tej sytuacji klasyfikacja IFC staje się niezastąpionym narzędziem do uwzględnienia tych informacji w naszych obiektach. Chociaż istnieje możliwość ręcznego wprowadzenia danych, zarówno w przypadku dostosowania do lokalnego standardu, jak i przypisania do odpowiednich tłumaczeń, możemy wykorzystać mechanizm połączenia klasyfikacji z bsDD (BuildingSMART Data Dictionary). Warto zaznaczyć, że choć bsDD nie jest konieczne do korzystania z klasyfikacji IFC, stanowi doskonały sposób na dostosowanie się do zewnętrznych standardów klasyfikacji.
Ogólnie rzecz biorąc, Klasyfikacja IFC umożliwia nam bardziej efektywne zarządzanie naszymi danymi poprzez możliwość dodawania zewnętrznych informacji.
Typy
W branży architektonicznej, inżynieryjnej i budowlanej (AEC) kluczowe jest zrozumienie różnicy między “type” a “occurrence” (Ciężko przetłumaczyć mi to na angielski, szczególnie drugie słowo). Na przykład, podczas tworzenia rysunków okien, w większości przypadkach definiujemy typ okna, a nie konkretny egzemplarz. Każde okno zamontowane na miejscu jest traktowane jako “occurrence” tego typu. Ta różnica jest istotna również w kontekście szacowania kosztów. Zamiast oceniać każde pojedyncze okno, szacujemy koszty na podstawie typu okna.
Podobnie, w zarządzaniu obiektami, rozróżniamy typy produktów (takie jak określony model od producenta) od konkretnych “egzemplarzy” (“occurance”), posiadających unikalne identyfikatory, takie jak kody kreskowe czy numery seryjne.
Dlatego istotnym elementem w formacie wymiany danych (IFC) są typy (ifcTypeObject). Choć nie wszystkie programy obsługują ten mechanizm, warto docenić jego zalety. Przy odpowiedniej implementacji może on przyczynić się do zmniejszenia rozmiaru plików poprzez referencję jednej geometrii wielokrotnie. Dodatkowo, umożliwia jednorazowe dodanie informacji czy właściwości do typu, zamiast umieszczania ich na wielu obiektach.
Podsumowanie
Podsumowując, chciałbym podkreślić, że powyży tekst to subiektywna ocena oparta na moim doświadczeniu.
Cały tekst opiera się na moich obserwacjach, a uważam, że wymienione elementy stanowią absolutne minimum, które powinno być zrozumiałe dla użytkowników plików IFC.
Oczywiście istnieje możliwość rozszerzenia listy o dodatkowe punkty, jednakże uważam, że te wymienione są fundamentem, który powinien charakteryzować dobry plik IFC.
Dziękuję za zapoznanie się z artykułem i zachęcam do dalszego czytania kolejnych tekstów na ten temat.
