W poprzednich artykułach skupiałem się głównie na zaletach schematu IFC oraz jego zastosowania.
Dziś krótki, wakacyjny artykuł na temat tego, co nie do końca mi się podoba w IFC.
Nie ma wątpliwości, że IFC to najlepszy schemat wymiany informacji o projektach budowy oraz zarządzania obiektami.
W branży budowlanej nie brakuje słów krytyki pod adresem IFC. Niestety w większości są one niesprawiedliwe i wynikają głównie ze złej konfiguracji, nieodpowiedniej implementacji oprogramowania, złego zarządzania modelem (jeśli w naszym modelu panuje chaos, trudno oczekiwać, aby IFC był czytelny i użyteczny).
Są jednak pewne minusy, o których warto wspomnieć.
1. Na początek – Baza danych Specyfikacji IFC
Mimo, iż oficjalnie najnowsza wersja to IFC4.1 wciąż najpopularniejsza i najszerzej stosowana jest wersja IFC2x3, na której bazowałem w poprzednich artykułach.
W dokumentacji tej można znaleźć wszystkie informacje dotyczące schematu, lecz pierwsze wrażenia poruszanie się po stronie z zawartością przypomina surfowanie po Internecie 20 lat temu lub sprawdzanie programu w Telegazecie.
Pisząc poprzednie artykuły powoli przyzwyczajam się do dokumentacji online schematu IFC. Okazuje się funkcjonalna i logiczna. Im bardziej doświadczonym użytkownikiem jesteś tym lepiej się w niej poruszasz, ale… czy nie mogłaby być bardziej atrakcyjna z wizualnego punktu widzenia? Często pierwsze wrażenie powstrzymuje nowych użytkowników od dalszego poznawania tejże dokumentacji.
Przeglądanie diagramów schematu przyprawia o kolejny ból głowy. Są one jak najbardziej logiczne i profesjonalne, natomiast z punktu widzenia kogoś, kto jest zainteresowany poznaniem bliżej.
Diagramy, zasoby, domeny, topologie…….
W Internecie można znaleźć wiele samouczków dotyczących korzystania z dokumentacji IFC. Myślę jednak, że o wiele lepiej byłoby, gdyby nie byłaby potrzebna dokumentacja wyjaśniająca dokumentacje….
2. Wersje IFC
O ile numeracja wersji jest jak najbardziej zrozumiała i wyjaśniona przez buildingSmart
O tyle już nazwy kolejnych wersji są całkowicie niezrozumiałe.
Jak już wspominałem wyżej, najpopularniejsza stosowana wersja jest IFC2x3. Dlaczego 2×3 a nie 2.3 ?
Wszystko zaczęło się całkiem normalnie. Pierwsza wersja ( nr 1.0.0.0) nosiła nazwę IFC 1.0 – Bardzo proste i logiczne. Dlaczego kolejna to (nr 1.1.0.0) to już IFC1.5? Potem robi się już tylko ciekawiej. Kolejna wersja o numerze 2.0.0.0 (zgodnie z konwencja podana przez buildingSmart) nosi nazwę IFC 2.0 – uff. Logicznie. Ale już następna (nr 2.1.0.0) nosi nazwę IFC2x …- Skąd się wziął ten x i co zrobił z poczciwa kropka?
Wspominana przeze mnie wersja IFC2x3 w końcowej swojej wersji to właściwie IFC2x3 TC1…
Następnie mamy przeskok i pominięcie nr3… nie ma IFC3 a od razu IFC4. Co się stało z trójką?
W przypadku IFC4 nie ma już X, przejść na IFC 4.1, mamy teraz IFC4add1 (Rozumiem, ze rozszerzenia „add”, „TC” są wzięte z opisu numeracji – add od „addemdums”, TC od „corrigendums”) – jednak wprowadza to pewna dezorientacje wśród użytkowników.
Mysle, ze o wiele bardziej zrozumiała i sensowna byłaby standardowa numeracja jak we wszystkich aplikacjach: IFC 1.0, IFC 1.2.1 IFC2.0 itd…?
3. Skróty, skróty, skróty….
openBIM bazuje na otwartych standardach takich właśnie jak IFC. Wśród tych standardów są również IDM, MVD, IFD, bsDD…. Można się pogubić w mnogości tych wszystkich skrótów. Pod tym względem jednak w BIM jesteśmy na to skazani o czym możesz się przekonać w artykule 22 POJĘCIA W BIM, KTÓRE WARTO ZNAĆ
4. IFC tu IFC tam…wszędzie IFC.
Dlaczego każda klasa musi mieć przedrostek Ifc? IfcDoor, IfcBeam, IfcWall…. Nazwanie obiektu po prostu Door, lub Wall będzie bardziej czytelne i prostsze. A więc zamiast IFCDOOR – DOOR, IFCWALL – WALL, IFCBEAM – BEAM. Żaden z elementow nie stracil przez to ani trochę na swoim znaczeniu a opis jest po prostu czytelniejszy.
Podsumowanie
Osobiście uważam IFC za najlepszy dostępny schemat do wymiany informacji o konstrukcjach i do zarządzania obiektami. W każdym dużym projekcie budowlanym bierze udział wielu interesariuszy korzystających z różnych narzędzi.Jest jak najbardziej normalne, że każdy uczestnik projektu może korzystać z wybranych przez siebie narzędzi, pod warunkiem, że może wymieniać dane z innymi. Dlatego tak ważne dla BIM jest możliwość użycia otwartego formatu jakim jest IFC, aby każdy, bez względu na używane oprogramowanie natywne, mógł wymieniać informacje w jasny, czytelny i możliwy dla każdego sposób.
Im bardziej zatem schemat IFC, jego działanie oraz dokumentacja będą czytelne i przejrzyste, tym lepiej dla tych wszystkich, którzy w codziennej pracy go używają, wymieniają informacje o projekcie czy wykorzystują model IFC do zarządzania obiektami.
Hej Janusz,
Przyjemna czytanka do kawy 😉
Generalnie totalnie zgadzam się z tym co napisałeś, najbardziej frustrujące jest poruszanie się po bazie wiedzy na temat standardów/formatu. To samo z IDM, czy też BCF.
Co do IFC3 przypomniał mi się zabieg, zastosowany przez Microsoft (Windows 8.1->Windows 10) i Apple z iPhone 8 do iPhone X: nikt nie wiem dlaczego, ale jednak… 😀
Pozdrawiam serdecznie,
Hej Karol,
Dzieki za komentarz.
Mysle, ze mozna by znalezc jeszcze wiecej rzeczy, ktorych uzytkownicy nie lubia ale …po co drazyc 🙂 Generalnie schemat robi swoja robote tylko ma te kilka frustrujacych elementow.
Dobre porownanie z numeracja Windows czy wersji Iphone. Moze zrobili taki zabieg z tego samego powodu , dla ktorego w samolotach nie ma 13 rzedu ? 😉
Pozdrawiam
Janusz
Januszu,
podpisuje się pod tym, że Ifc dla nowego użytkownika (a nawet dla zaawansowanego) może być mało przejrzyste.
Dodałbym jeszcze archaiczny język, w którym jest napisane.
Jak przyjdzie IFC5 i json to plik wtedy będzie bardziej czytelny.