Infrastruktura komunikacyjna do premiery standardu IFC 4×3 była bardzo ubogo reprezentowana w schemacie IFC. Oczywiście było i jest możliwe wygenerowanie pliku zawierającego model BIM w oparciu o schemat IFC 2×3 (Nie widzę sensu używania IFC 4 dla infrastruktury). Jednakże obiekty używane do prezentacji poszczególnych elementów są bardzo ogólne i ubogie w dodatkowe informacje charakterystyczne dla tej branży.
W standardzie IFC 2×3 warstwy nawierzchni w modelu drogowym opisuje się przy pomocy ifcSlab oraz ifcBeam. Brakuje także przestrzennego podziału projektu charakterystycznego dla branż występujących w projektach infrastrukturalnych. Możemy się spotkać jedynie z wertykalnym podziałem projektu budowlanego, którego poszczególnymi poziomami są obiekty przestrzenne takie jak ifcBuilding, ifcBuildngStorey.
Oczywiście można się upierać, że w projektach bazujących na schemacie IFC 2×3 tak naprawdę liczą się informacje znajdujące na obiektach BIM, “na samym dnie”. Dzieje się tak, ze względu na to iż obecnie istnieją programy, które przedstawiają dane BIM w każdy sposób jaki chcemy oraz pozwalają nam bardzo dobrze mapować informacje. Jednakże taki zabieg wymaga dodatkowej pracy i niekoniecznie jest dostępne dla wszystkich stron w projekcie w jednakowy i przystępny sposób.
W tym kontekście możemy mówić o przewadze konkurencyjnej. Firmy, które potrafią działać z dużą liczbą skomplikowanych danych, są pionierami w dziedzinie otwartego środowiska BIM.
Przykładem takiej firmy jest Norconsult. Pisałem już na bimcorner.com o mojej pracy jako BIM Koordynator oraz o użyciu IFC tym w tym artykule. Przytaczam w nim sposób opisywania projektu infrastrukturalnego przy użyciu IFC 2×3
Przechodząc do meritum artykułu.
Wciąż, niezaprzeczalnie dobrze uporządkowany projekt wg odpowiedniego WBS (Work Breakdown Structure) daje większą wartość niż projekt z niejasną strukturą podziału. Naszym celem powinno być stworzenie projektu, który wszyscy rozumieją, mogą się do niego odnieść oraz wykorzystać dane w sposób autoryzowany. Kluczowe jest więc stworzenie wspólnych standardów dla branży, które pomogą usprawnić procesy w całym cyklu życia projektu (supply chain).
Mając wspólny standard będziemy mogli dostosować systemy, ustalać wymagania do projektów, przeprowadzać walidację, wykorzystywać modele cyfrowe w wielu miejscach.
Jest to krok milowy w kierunku automatyzacji.
W momencie rozpoczęcia projektu powinniśmy już myśleć o tym, w jaki sposób nasze dane, które stworzymy zostaną wykorzystane w całym cyklu życia budowli.
Chciałbym Cię zaprosić do przeczytania artykułu na temat schematu IFC 4×3 w projekcie drogowym.
Słowem wstępu o IFC 4.3
Schemat IFC 4×3 jako pierwszy wprowadza szeroką gamę definicji umożliwiających zaprezentowanie projektu budowlanego w sposób usystematyzowany dla branży infrastrukturalnej.
W kontekście IFC należy rozgraniczyć trzy główne grupy tematyczne
- Obiekty (fizyczne namacalne obiekty (podbudowa), fizycznie istniejące
obiekty (droga), wirtualne obiekty (linia trasowania), aktorzy, procesy, koszty) - Właściwości (charakterystyczne informacje mogące być powiązane z obiektem)
- Relacje (zależności pomiędzy obiektami)
- Obiekty (fizyczne namacalne obiekty (podbudowa), fizycznie istniejące
Na łamach tego artykułu przybliże pierwszy temat. Kolejne dwa zostaną omówione w osobnej części. Zależy mi na opisaniu obiektów użytych do opisania projektu drogowego oraz modelu BIM. Z tego względu celowo pominę temat aktorów, procesów, kosztów, zasobów. (Jest to na pewno temat do rozwinięcia w kontekście ogólnego schematu ifc.)
A - Definicja obiektów
Powyższe cegiełki to abstrakty. Abstrakt można przyrównać to do umownego zbioru obiektów kategoryzujące je na różnym poziomie szczegółowości.
Polecam zapoznać się z całą strukturą IFC 4×3 pod tym linkiem
ifcProduct jest abstraktem reprezentującym dowolny obiekt, który odnosi się do kontekstu geometrycznego lub przestrzennego. Produkt jeśli posiada geometrię występuje w określonej lokalizacji w przestrzeni. Może być umieszczany względem innych obiektów, ale ostatecznie względem ustalonego układu współrzędnych.
Oprócz produktów fizycznych (IfcElement) i elementów przestrzennych (IfcSpatialElement). IfcProduct obejmuje również elementy niefizycznie, takie jak adnotacja, siatka kartezjańska, linia trasowania itp.
W kontekście budowli drogowej opiszę następujące abstrakty:
- ifcSpatialElement – przestrzenny podział projektu drogowego
- ifcElement – fizyczne komponenty
- ifcLinearElement – odcinki liniowe tworzące linię trasowania
- ifcAnnotation – informacja z geometrią, np. Linie stakeout
- ifcPositioningElement
ifcSpatialElement - Przestrzenny podział projektu drogowego
ifcSite jest częścią ifcSpatialStructureElement, który w hierarchii jest elementem abstraktu ifcSpatialElement
Każdy z tych obszarów zakłada zaprojektowanie i wybudowanie kilku budowli. Są to np. tunele, mosty, kolej, drogi, budynki, urządzenia techniczne. Budowle te w sposób generalny możemy nazwać ifcFacility, a poszczególne typy budowli odpowiednio:
-
- ifcBridge
- ifcRailway
- ifcRoad
- ifcBuilding
- ifcMarineFacility
- ifcTunnel (wkrótce)
Tak jak w przypadku ifcSite każdy z tych typów jest podkategorią ifcSpatialStructureElement co oznacza, że możemy wykorzystać te obiekty do przestrzennego podziału naszych obszarów na mniejsze zbiory branżowe.
Kolejnym poziomem podziału obiektu budowlanego jest podział na części. Każda część jest powiązana z branżą, którą reprezentuje. W tym przypadku mamy do czynienia z następującym podziałem na części:
- ifcBridgePart
- ifcFacilityPartCommon
- ifcMarinePart
- ifcRailwayPart
- ifcRoadPart
PredefinedType, ObjectType, UsageType
PredefinedType
Każdy obiekt będący podzbiorem ifcObject możemy dalej scharakteryzować za pomocą PredefinedType. Atrybut ten zawiera określenia charakteryzujące dany obiekt, tzw. enumeracje. Przykładowo ifcRail może służyć do określenia wielu elementów, jednakże enumeracja, czyli wartość dla atrybutu PredefinedType pozwana na dokładniejszą identyfikację obiektu.
Enumeracja dla ifcRail
TYPE IfcRailTypeEnum = ENUMERATION OF
(BLADE
,CHECKRAIL
,GUARDRAIL
,RACKRAIL
,RAIL
,STOCKRAIL
,USERDEFINED
,NOTDEFINED);
END_TYPE;
Dokładne wskazanie obiektu jest istotne, gdyż niektóre zestawy właściwości (Psets) mogą mieć szczególne zastosowanie do jednego z typów obiektu.
ObjectType
W przypadku braku enumeracji dla obiektu, możemy określić jego własny typ. Do tego celu służy parameter ObjectType. Może on zostać użyty w przypadku jeżeli wartość dla PredefinedType jest ustalona jako USERDEFINED. Tak więc za pomocą ObjectType możemy przypisać własną wartość. Może być to wartość służąca do określenia obiektu zgodnie z taksonomią reprezentującą standardy lokalne.
Przykładowo ifcRoad nie posiada wartości dla parametru PredefinedType. W systemie ustalamy wartość jako USERDEFINED, przy parametrze ObjectType możemy określić jaka jest to droga. Może być to własny tekst np. autostrada, droga lokalna, droga gminna
UsageType
W kontekście elementów ifcFacilityPart przybliżmy takżę parameter UsageType, który w tym przypadku dodatkowo służy do charakterystyki obiektu. Przykładowo drogę można podzielić w różnych wymiarach. Możemy mówić o podłużnej bądź poprzecznym podziale drogi. W przypadku podłużnego podziału drogi, mamy na myśli podział drogi na segmenty/odcinki. Podział boczny wskazuje nam podział na charakterystyczne części takie jak jezdnia, pobocze utwardzone, pobocze zielone.
TYPE IfcFacilityUsageEnum = ENUMERATION OF
(LATERAL
,LONGITUDINAL
,REGION
,VERTICAL
,USERDEFINED
,NOTDEFINED);
END_TYPE;
Przykładowo ifcRoadPart ma następujące typy (PredefinedType):
TYPE IfcRoadPartTypeEnum = ENUMERATION OF
(BICYCLECROSSING
,BUS_STOP
,CARRIAGEWAY
,CENTRALISLAND
,CENTRALRESERVE
,HARDSHOULDER
,INTERSECTION
,LAYBY
,PARKINGBAY
,PASSINGBAY
,PEDESTRIAN_CROSSING
,RAILWAYCROSSING
,REFUGEISLAND
,ROADSEGMENT
,ROADSIDE
,ROADSIDEPART
,ROADWAYPLATEAU
,ROUNDABOUT
,SHOULDER
,SIDEWALK
,SOFTSHOULDER
,TOLLPLAZA
,TRAFFICISLAND
,TRAFFICLANE
,USERDEFINED
,NOTDEFINED);
END_TYPE;
Powyższy rysunek przedstawia podział drogi na segment podłużny (LONGITUDINAL). Segment podłużny możemy dalej podzielić poprzecznie (LATERAL). Podział poprzeczny pozwala uporządkować obiekty przestrzennie. Droga posiada charakterystyczne elementy takie jak jezdnia, pobocze, chodnik, rów. Przykładowo barierę energochłonną należy spodziewać się pod abstraktem ifcRoadPart / ROADSIDE.
Podział pionowy (VERTICAL) jest rzadziej stosowany w budowlach linowych. Częściej pojawia się w kontekście budowli wertykalnych.
Podsumowując ten akapit budowlę drogową można podzielić przestrzennie na obszary (ifcSite), te z kolei na branże (ifcRoad). Branżę drogową można podzielić na segmenty podłużne (ifcRoadPart), oraz poprzecznie części (ifcRoadPart).
Komponenty fizyczne
Każdy obiekt fizyczny jest powiązany ze strukturą przestrzenną projektu. Przykładowo ifcRoad, dzieli model na podłużne segmenty ifcRoadPart, a ifcRoadPart w swoim zbiorze zawiera elementy fizyczne tworzące budowle drogowe.
Obiektami fizycznymi używanymi do opisu modelu drogowego mogą być np. warstwy nawierzchni ifcCourse, obiekty opisujące roboty ziemne (ifcEarthworksFill),obiekty opisujące wzmocnione podłoże (ifcReplacementSoil), krawężnik ifcKerb, rów otwarty ifcPipeSegment Niektóre z obiektów możemy połączyć w jeden. Przykładowo ifcCourse jest częścią ifcPavement.
Także w przypadku elementów fizycznych, każdy z obiektów posiada parametr PredefinedType opisujący poszczególny typ.
ifcCourse
TYPE IfcCourseTypeEnum = ENUMERATION OF
(ARMOUR
,BALLASTBED
,CORE
,FILTER
,PAVEMENT
,PROTECTION
,USERDEFINED
,NOTDEFINED);
END_TYPE;
ifcEartwhorksFill
TYPE IfcEarthworksFillTypeEnum = ENUMERATION OF
(BACKFILL
,COUNTERWEIGHT
,EMBANKMENT
,SLOPEFILL
,SUBGRADE
,SUBGRADEBED
,TRANSITIONSECTION
,USERDEFINED
,NOTDEFINED);
END_TYPE;
ifcLinearElement & ifcPositioningElement - Elementy tworzące linię trasowania
Objekt ifcAlignment służy do opisania linii trasowania w projekcie drogowym. Służy także do definiowania odniesienia oraz pozycjonowania elementów wzdłuż budowli liniowych takich jak drogi, koleje, mosty i inne. Umiejscowienie obiektów wzdłuż linii trasowania jest określone przez metodologię odniesienia liniowego (Linear Referencing System)
Zgodnie z zasadami modelowania IFC, elementy linii trasowania są zorganizowane w dwie duże części. Obie części współpracują ze sobą, ale można ich również używać niezależnie od siebie
- Biznesowe aspekty linii trasowania – Tutaj nacisk kładziony jest na strukturę schematu jak najbardziej zbliżoną do terminologii biznesowej. Możliwe jest posiadanie bardzo szczegółowej struktury segmentów z dołączonymi wieloma właściwościami specyficznymi dla domeny. Przykładami właściwości specyficznych dla dziedziny są prędkość projektowa lub przechyłka
- Reprezentacja z zasobami geometrii IFC – Tutaj nacisk kładziony jest na wykorzystanie jak największej liczby ustalonych elementów geometrii IFC. Proponowane jest mapowanie między aspektami biznesowymi a geometrią IFC.
W IFC pojedyncza linia trasowania musi posiadać geometrię poziomą (X/Y) w przyjętym układzie odniesienia. Ponadto może posiadać:
- Geometrię wertykalną, wzdłuż horyzontalnej, w przezstrzeni Z
- Dodatkowa linię trasowania (np. offsett)
- Geometrię 3D (obliczoną z horyzontalnej i wertykalnej informacji, lub z danych geospetial)
ifcAlignment wspótworzą inne obiekty takie jak:
- ifcAlignmentSegment,
- ifcAlignmentCant,
- ifcAlignmentHorizontal,
- ifcVertical.
Temat ifcAlignment jest bardzo złożonym tematem. Na przestrzeni lat zostało stworzona bardzo duża ilość materiałów. W celu zwiększenia wiedzy w tym obszarze polecam zapoznać się z dokumentacją techniczną buildingSMART pod tym linkiem
ifcAnnotation
Adnotacje obejmują dodatkowe punkty, krzywe, tekst, wymiarowanie, kreskowanie i inne formy notatek graficznych. Zawiera również wirtualne lub symboliczne reprezentacje dodatkowych elementów modelu, które nie reprezentują produktów ani struktur przestrzennych, takich jak elementy wydarzeń, punkty pomiarowe, linie konturowe itp.
Przykładowo krawędzie warstw nawierzchni, poszczególnych komponentów, są istotnymi informacjami dla geodetów. Dzięku użyciu ifcAnnotation możemy zapisać te informacje, które mogą zostać użyte na placu budowy jako dane do tyczenia (stakeoutdata).
