ROCZNIKI GEOMATYKI 2019 m TOM XVII m ZESZYT 1(84): 87–99
Analiza mo¿liwoœci zastosowania modelu IFC
do opisania obiektów infrastrukturalnych
na wybranych przyk³adach
Analysis of the possibility of using the IFC model
to describe infrastructural objects on selected examples
Micha³ Wyszomirski 1, Andrzej Szymon Borkowski 2 Politechnika Warszawska, Wydzia³ Geodezji i Kartografii
1 Zak³ad Kartografii
2 Katedra Gospodarki Przestrzennej i Nauk o Œrodowisku Przyrodniczym
S³owa kluczowe: technologia BIM, IFC, projekty infrastrukturalne Keywords: BIM technology, IFC, infrastructure projects
Wprowadzenie
Projekt o charakterze infrastrukturalnym to zamierzenie budowlane lub inna ingerencja w œrodowisko przyrodnicze polegaj¹ca na przekszta³ceniu lub zmianie sposobu wykorzysta-nia terenu, obejmuj¹ce miêdzy innymi budowê: dróg, mostów, kolei, lotnisk, sieci oraz in-nych budowli o charakterze liniowym, które pe³ni¹ role s³u¿ebn¹, a ich czas u¿ytkowania jest stosunkowo d³ugi. Projekty infrastrukturalne spe³niaj¹ z regu³y jedn¹ lub kilka z wymienio-nych funkcji: transferow¹, us³ugow¹, integracyjn¹, akceleracyjn¹. Standardy wykorzysty-wane w technologii BIM (ang. Building Information Modeling) s¹ szeroko stosowykorzysty-wane w bran¿y AEC (ang. Architecture Engineering and Construction), ale mo¿liwoœæ przetwarza-nia neutralnego modelu danych dla obiektów infrastrukturalnych nie jest dostêpna wœród standardów OpenBIM zak³adaj¹cych wykorzystanie otwartych standardów do tworzenia modeli BIM. Organizacja BuildingSMART International utworzy³a grupê robocz¹ o nazwie
InfraRoom, która podejmuje inicjatywy maj¹ce na celu uzupe³nienie tej luki (BuildingSMART
International, 2018). Zadaniem grupy InfraRoom jest wypracowanie wspólnych zasad dla osi¹gniêcia integracji procesu w fazie projektowania, budowy i utrzymania infrastruktury. Grupa uwa¿a, ¿e opracowanie i wdro¿enie odpowiednich modeli informacji o budynku (BIM) jest wa¿nym czynnikiem umo¿liwiaj¹cym osi¹gniêcie oczekiwanych celów. Przewiduje siê, ¿e praca grupy doprowadzi do opracowania nowych standardów IDM i MVD oraz odpo-wiednich zestawów terminów okreœlonych w bSDD dla infrastruktury (BuildingSMART International, 2018). Ponadto koniecznoœæ zapewnienia interoperacyjnoœci modeli
stosowa-nych w dziedzinach budownictwa oraz informacji przestrzennej zosta³a dostrze¿ona przez komitety techniczne ISO/TC 59/SC 13 (Organization and digitization of information about
buildings and civil engineering works, including building information modelling (BIM))
(International Organization for Standardization, 1987) oraz ISO/TC 211 (Geographic
infor-mation/Geomatics) (International Organization for Standardization, 1994) w raporcie
tech-nicznym ISO/AWI TR 23262 (GIS (Geospatial) / BIM interoperability) (International Orga-nization for Standardization, 2018). Nale¿y siê zatem spodziewaæ rozszerzenia standardu IFC (Industry Foundation Classes), bêd¹cego modelem danych stosowanym w BIM, o nowe klasy obiektów reprezentuj¹cych obiekty infrastrukturalne. Zanim jednak to nast¹pi bêd¹ pojawia³y siê modele BIM obiektów infrastrukturalnych wykorzystuj¹ce do zapisania tych obiektów dostêpne obecnie klasy IFC. W zwi¹zku z tym systemy informacji przestrzennej korzystaj¹ce z danych pochodz¹cych z modeli BIM, w tym systemy GIS, powinny byæ przygotowane na przetwarzanie danych z modeli IFC, w których zapisano obiekty infra-strukturalne, wykorzystuj¹c do tego celu klasy obiektów dotychczas stosowane wy³¹cznie do reprezentacji elementów sk³adaj¹cych siê na konstrukcjê, wyposa¿enie budynku lub za-gospodarowanie terenu w bezpoœrednim s¹siedztwie budynku. Wprowadzenie mo¿liwoœci modelowania obiektów infrastrukturalnych w technologii BIM ma olbrzymie znaczenie dla kierunków przep³ywu i metod transformacji danych BIM i GIS. Dotychczas zak³ada³o siê, ¿e modele BIM bêd¹ dostarcza³y danych o wnêtrzach budynków, natomiast systemy GIS bêd¹ zasila³y systemy Smart City danymi o topografii miasta, obejmuj¹c wszystko inne poza wnê-trzami budynków. W przypadku rozszerzenia IFC o mo¿liwoœæ modelowania obiektów in-frastrukturalnych kierunki przep³ywu danych pomiêdzy BIM i GIS mog¹ byæ inne.
Proces projektowy w technologii BIM obejmuje pewne ustalenia wizualne, systemowe lub geometryczne okreœlaj¹ce relacje miêdzy poszczególnymi elementami architektoniczny-mi b¹dŸ konstrukcyjnyarchitektoniczny-mi. W znacznej architektoniczny-mierze relacje te powstaj¹ w wyniku pewnego proce-su, przep³ywu informacji, dostosowywania siê do przepisów, uzgodnieñ oraz regulacji. Osta-tecznym efektem tych dzia³añ jest przejœcie od fazy koncepcji do uzyskania realnego i spe³-niaj¹cego wszystkie za³o¿enia obiektu finalnego (Borkowski, 2018). Tym samym modele BIM i GIS ró¿ni¹ siê znacznie zarówno na poziomie koncepcyjnym, jak i technologicznym. Warto te¿ zwróciæ uwagê na ró¿nice w zastosowanych modelach pojêciowych: GIS zazwy-czaj wykorzystuje model semantyczny CityGML, BIM model parametryczny IFC. Wymiana informacji pomiêdzy ró¿nymi systemami opieraj¹cymi siê na ró¿nych modelach to zagadnie-nie z³o¿one, ale te¿ znane w informatyce. Rozwi¹zañ problemu interoperacyjnoœci poszukuje siê przede wszystkim na poziomie uzyskania zgodnoœci semantycznej, czyli na poziomie modeli pojêciowych. Sam problem konwersji na poziomie technicznym (np. kwestia forma-tu danych) zwykle nie stanowi istotnej bariery (Gotlib, Wyszomirski, 2018).
Podstawy modelu IFC
Model danych IFC jest standardem zapisu trójwymiarowego modelu obiektu, wspoma-gaj¹cym przetwarzanie i zarz¹dzanie danymi o obiekcie budowlanym. Specyfikacja IFC jest ca³y czas rozwijana przez buildingSMART. IFC to otwarty format zapisu danych s³u¿¹cy do przekazywania informacji miêdzy uczestnikami procesu budowlanego (inwestor, projektant, wykonawca), oparty na strukturach danych bazuj¹cych na obiektach i relacjach. Plik w formacie IFC zawiera kompletne dane o obiekcie, takie jak (Kasznia i in., 2017):
m po³o¿enie w przestrzeni,
m struktura i uk³ad obiektu z rozbiciem na elementy sk³adowe,
m szczegó³owe dane o typach elementów wraz z ich atrybutami (typowymi lub dodat-kowymi),
m zale¿noœci pomiêdzy elementami.
IFC to format danych, który w za³o¿eniu ma zapewniæ bezstratne przekazywanie infor-macji o obiekcie in¿ynierskim miêdzy ró¿nymi programami lub systemami informatycznymi. Format ten wykorzystuje model relacyjny i zosta³ napisany w jêzyku modelowania danych przemys³owych EXPRESS zdefiniowany przez komitet ISO TC184/SC4, jako ISO10303-11 (International Organization for Standardization, 2004). Ten sam jêzyk definicji danych jest u¿ywany w formacie STEP. Jego zalet¹ jest to, ¿e jest kompaktowy i w ³atwy sposób poz-wala w³¹czaæ regu³y sprawdzania poprawnoœci danych w obrêbie ich specyfikacji. Model danych wykorzystany w IFC zak³ada istnienie kilkuset typów elementów podlegaj¹cych dziedziczeniu obiektowemu, zorganizowanych w strukturze hierarchicznej (ang. object-based
inheritance hierarchy). Mo¿e przenosiæ informacje o ca³ym budynku (nawet grupie
budyn-ków) lub o jego fragmencie, na przyk³ad jednej kondygnacji. Przyjmuje siê, ¿e w projekcie ka¿dy oddzielny budynek zostanie przekazany jako model niezale¿ny. Jeœli to konieczne, budynek mo¿na podzieliæ na kilka czêœci lub bran¿e wed³ug uzgodnienia zespo³u projektowe-go. Ka¿dy budynek jest przekazywany jako pojedynczy plik. W przypadku du¿ych budyn-ków konieczny mo¿e siê okazaæ podzia³ ca³ego modelu na kondygnacje i segmenty lub jedno i drugie dla uproszczenia operacji zwi¹zanych z projektem (Tomana, 2016).
Sposób zapisu modelu budynku w IFC
Zgodnie z definicj¹ w IFC4 (Industry Foundation Classes Release 4), struktura danych dotycz¹cych elementów budynku ma postaæ hierarchiczn¹, obejmuj¹c¹ podzia³ budynku na kondygnacje i pomieszczenia (rys. 1).
Sposób zapisu obiektów w modelu IFC i relacji pomiêdzy nimi zosta³ poni¿ej opisany na przyk³adzie obiektu klasy pomieszczenie (IfcSpace), jednak jest on aktualny dla wszystkich klas obiektów dziedzicz¹cych z klasy IfcProduct. reprezentuj¹cej ka¿dy obiekt maj¹cy kon-tekst geometryczny lub przestrzenny. Obiekty klas pochodnych klasy IfcProduct zawieraj¹ reprezentacjê kszta³tu i lokalizacjê obiektów w przestrzennej strukturze projektu (building-SMART International Ltd, 2018).
Obiekty przestrzennej struktury budynku: IfcProject (projekt), IfcSite (dzia³ka),
IfcBuil-ding (budynek), IfcBuilIfcBuil-dingStorey (kondygnacja) i w³aœciwy obiekt klasy IfcSpace
(po-mieszczenie) s¹ ze sob¹ powi¹zane za pomoc¹ obiektów agreguj¹cych klasy
IfcRelAggrega-tes. Relacje pomiêdzy obiektami stanowi¹cymi przestrzenn¹ strukturê budynku, w tym
tami klasy IfcSpace i obiektami przenosz¹cymi atrybuty opisowe s¹ realizowane przez obiek-ty klasy IfcRelDefinesByProperties. Obiekobiek-ty tej klasy definiuj¹ zale¿noœci pomiêdzy obiekta-mi wskazywanyobiekta-mi przez atrybut RelatedObjects a zbiorem atrybutów (klasy IfcPropertySet) wskazywanym przez atrybut RelatingPropertyDefinition. Atrybut obiektu klasy
IfcProper-tySet o nazwie HasProperties wskazuje na listê obiektów klasy IfcComplexProperty
okreœla-j¹cych zestawy atrybutów. Atrybut obiektu klasy IfcComplexProperty o nazwie
HasProper-ties wskazuje na listê obiektów klasy IfcPropertySingleValue przenosz¹cych pojedyncze
geometrycz-ne s¹ zapisywageometrycz-ne w inny sposób. Atrybut obiektu klasy IfcSpace o nazwie Representation wskazuje na obiekt klasy IfcProductDefinitionShape. Atrybut obiektu klasy
IfcProductDe-finitionShape o nazwie Representations wskazuje na listê obiektów klasy IfcShapeRepresenta-tion. Atrybut obiektu klasy IfcShapeRepresentation o nazwie Items wskazuje na listê
obiek-tów klasy IfcExtrudedAreaSolid. Atrybut obiektu klasy IfcExtrudedAreaSolid o nazwie
Swept-Area wskazuje na obiekt klasy IfcArbitraryClosedProfileDef. Atrybut obiektu klasy IfcArbi-traryClosedProfileDef o nazwie OuterCurve wskazuje na obiekt klasy IfcPolyline. Atrybut
obiektu klasy IfcPolyline o nazwie Points wskazuje na listê obiektów klasy IfcCartesianPoint, które reprezentuj¹ punkty naro¿ne ³amanej zamkniêtej stanowi¹cej obrys pomieszczenia w lokalnym uk³adzie wspó³rzêdnych tego pomieszczenia. Relacje pomiêdzy lokalnym uk³a-dem wspó³rzêdnych pomieszczenia a lokalnym uk³auk³a-dem wspó³rzêdnych projektu s¹ zapisy-wane w oderwaniu od samej geometrii obiektu. Atrybut obiektu klasy IfcSpace o nazwie
ObjectPlacement wskazuje na obiekt klasy IfcLocalPlacement. Atrybut obiektu klasy Ifc-LocalPlacement o nazwie PlacementRelTo wskazuje na obiekt klasy IfcIfc-LocalPlacement.
Atrybut obiektu klasy IfcLocalPlacement o nazwie RelativePlacement wskazuje na obiekt klasy IfcAxis2Placement3D. Atrybut obiektu klasy IfcAxis2Placement3D o nazwie Location wskazuje na obiekt klasy IfcCartesianPoint. Atrybut obiektu klasy IfcAxis2Placement3D o nazwie Axis wskazuje na obiekt klasy IfcDirection. Atrybut obiektu klasy
IfcAxis2Place-ment3D o nazwie RefDirection wskazuje na obiekt klasy IfcDirection. Relacje pomiêdzy
obiektami reprezentuj¹cymi strukturê przestrzenn¹ budynku s¹ realizowane poprzez obiekty Rysunek 1. Postaæ hierarchiczna struktury danych dotycz¹cych elementów budynku
agreguj¹ce klasy IfcRelAggregates, których atrybuty RelatingObject i RelatedObjects wska-zuj¹ce na obiekty klasy IfcObjectDefinition definiuj¹ wektory relacji pomiêdzy obiektami. Poni¿ej zestawiono wszystkie atrybuty klasy IfcRelAggregates z uwzglêdnieniem atrybutów odziedziczonych z klasy IfcRoot oraz wprowadzonych bezpoœrednio przez definicjê klasy
IfcRelaggregates (tab. 1).
Zarówno atrybut RelatingObject jak i RelatedObjects s¹ wskaŸnikami na obiekty klasy
IfcObjectDefinition (tab. 1). Przy czym atrybut RelatedObjects przechowuje kolekcje
wskaŸ-ników. Jest to naturalne, poniewa¿ w budynku (wskazywanym przez RelatingObject) znaj-duje siê zazwyczaj kilka kondygnacji (wskazywanych przez atrybut RelatedObjects), a na kondygnacji (wskazywanej przez atrybut RelatingObject innego obiektu agreguj¹cego
IfcRelAggregates) znajduje siê jedno lub wiêcej pomieszczeñ (wskazywanych przez atrybut RelatedObjects). Klasa IfcObjectDefinition jest uogólnieniem jakiegokolwiek semantycznie
traktowanego obiektu lub procesu. Definicja obiektu mo¿e byæ nazwana z wykorzystaniem dziedziczonego atrybutu Name, który powinien byæ rozpoznawaln¹ przez u¿ytkownika ety-kiet¹ dla obiektu. Klas¹ dziedzicz¹c¹ z klasy IfcObjectDefinition jest klasa IfcObject (rys. 2).
IfcObject jest uogólnieniem jakiejkolwiek semantycznie traktowanej rzeczy lub procesu.
Przy-k³ady obiektów klasy IfcObject obejmuj¹ œciany, belki, pomieszczenia, modele ogólne, ale równie¿ procesy, koszty lub aktorów procesu inwestycyjnego, czyli osoby zaanga¿owane w proces projektowania b¹dŸ realizacjê obiektu. Nastêpnie w hierarchii dziedziczenia klas obiektów budynku w modelu IFC wystêpuje klasa IfcProduct, dziedzicz¹ca z IfcObject oraz klasa IfcSpatialElement dziedzicz¹ca z klasy IfcProduct.
Tabela 1. Zestawienie atrybutów obiektu klasy IfcRelAggregates t u b y r t A Typ Zdefiniowanyprzez d I l a b o l G IfcGloballyUniqueId(STRING) IfcRoot y r o t s i H r e n w O IfcOwnerHistory(ENTITY) IfcRoot e m a N IfcLabel(STRING) IfcRoot n o i t p i r c s e D IfcText(STRING) IfcRoot t c e j b O g n i t a l e R IfcObjectDefinition(ENTITY) IfcRelAggregates s t c e j b O d e t a l e R SETOFIfcObjectDefinition(ENTITY) IfcRelAggregates
Problematyka wykorzystania modelu IFC
do zapisu danych obiektu infrastrukturalnego
Definicja klasy IfcSpatialElement w modelu IFC to uogólnienie wszystkich elementów przestrzennych, które mog¹ byæ u¿yte do zdefiniowania struktury przestrzennej lub do zde-finiowania stref w obiekcie.
Zatem IfcSpatialElement mo¿e reprezentowaæ:
m Element hierarchicznej struktury przestrzennej budynku jako IfcSpatialStructureElement – struktura przestrzenna jest hierarchiczn¹ dekompozycj¹ projektu. Jest czêsto wykorzy-stywana do opisu struktury w celu zorganizowania projektu budowlanego. Przestrzenna struktura projektu mo¿e definiowaæ tyle poziomów dekompozycji, ile jest konieczne dla projektu budowlanego. Elementy w przestrzennej strukturze projektu to: dzia³ka, budy-nek, kondygnacja i pomieszczenie.
Rysunek 2.
Schemat dziedziczenia klas obiektów reprezentuj¹cych
elementy struktury budynku oraz elementy jego otoczenia;
ramk¹ oznaczono klasy obiektów reprezentuj¹cych strukturê
przestrzenn¹, elementy konstrukcyjne budynku
m Zewnêtrzny element przestrzenny jako IfcExternalSpatialStructureElement, który defi-niuje zewnêtrzne regiony na placu budowy. Regiony te mo¿na zdefiniowaæ (building-SMART International Ltd, 2018):
– logicznie, na przyk³ad instancja obiektu IfcExternalSpatialElement mo¿e reprezento-waæ przestrzeñ wokó³ budynku bez w³asnej reprezentacji kszta³tu lub
– fizycznie, na przyk³ad instancja obiektu IfcExternalSpatialElement mo¿e przedsta-wiaæ pochy³y teren wokó³ budynku, aby zidentyfikowaæ czêœæ zewnêtrznej powierzchni budynku, która znajduje siê pod ziemi¹.
Klasa IfcExternalSpatialElement wprowadza jeden w³asny atrybut o nazwie
Predefined-Type, który jest typu IfcExternalSpatialElementTypeEnum (tab. 2).
Tabela 2. Zestawienie atrybutów obiektu klasy IfcExternalSpatialElement t u b y r t A Typ Zdefiniowanyprzez d I l a b o l G IfcGloballyUniqueId(STRING) IfcRoot y r o t s i H r e n w O IfcOwnerHistory(ENTITY) IfcRoot e m a N IfcLabel(STRING) IfcRoot n o i t p i r c s e D IfcText(STRING) IfcRoot e p y T t c e j b O IfcLabel(STRING) IfcObject t n e m e c a l P t c e j b O IfcObjectPlacement(ENTITY) IfcProduct n o i t a t n e s e r p e R IfcProductRepresentation(ENTITY) IfcProduct e m a N g n o L IfcLabel(STRING) IfcSpatialElement e p y T d e n i f e d e r P IfcExternalSpatialElementTypeEnum ) M U N E ( t n e m e l E l a i t a p S l a n r e t x E c f I
Definicje typu wyliczeniowego IfcExternalSpatialElementTypeEnum w modelu IFC s¹ nastêpuj¹ce (buildingSMART International Ltd, 2018):
m EXTERNAL – zewnêtrzna przestrzeñ powietrzna wokó³ budynku,
m EXTERNAL_EARTH – obiekt kubaturowy zewnêtrzny pokryty ziemi¹ znajduj¹cy siê bezpoœrednim s¹siedztwie budynku,
m EXTERNAL_WATER – obiekt kubaturowy zewnêtrzny pokryty wod¹ znajduj¹cy siê w bezpoœrednim s¹siedztwie budynku,
m EXTERNAL_FIRE – przestrzeñ zajmowana przez s¹siaduj¹cy budynek, m USERDEFINED – zdefiniowany przez u¿ytkownika,
m NOTDEFINED – niezdefiniowany.
Na ten moment model IFC pozwala zapisywaæ obiekty:
m stanowi¹ce wnêtrze budynku – obiekty klas IfcBuilding, ifcBuildingStorey, ifcSpace, m obiekty zewnêtrzne klasy IfcExternalSpatialElement, których atrybut
IfcExternal-SpatialElementTypeEnum okreœla ich typ,
m obiekty stanowi¹ce elementy konstrukcyjne, pochodne klasy IfcElement, która jest generalizacj¹ wszystkich komponentów, które sk³adaj¹ siê na produkty bran¿y AEC; elementy te mog¹ byæ logicznie zawarte w elemencie struktury przestrzennej – bu-dynku, kondygnacji lub pomieszczeniu,
m ponadto mo¿liwe jest wykorzystanie klasy IfcSpatialZone – niehierarchiczna i poten-cjalnie nak³adaj¹ca siê dekompozycja projektu pod pewnymi wzglêdami funkcjonalny-mi. Strefa przestrzenna mo¿e byæ u¿ywana do reprezentowania strefy termicznej, strefy konstrukcyjnej, strefy oœwietleniowej lub strefy u¿ytkowej. Strefa przestrzen-na mo¿e mieæ swoje niezale¿ne rozmieszczenie i reprezentacjê kszta³tu.
Zapisanie infrastrukturalnego projektu BIM w modelu IFC, który nie ma jeszcze definicji klas obiektów infrastrukturalnych, bêdzie siê wi¹za³o z koniecznoœci¹ kompromisu i wyko-rzystania klas dostêpnych w modelu IFC do zapisu obiektów w modelu.
Obecnie opracowywane s¹ propozycje poszerzenia koncepcji i standardów BIM dla dzie-dziny infrastruktury. BuildingSMART pracuje nad rozszerzeniem IFC w zakresie reprezento-wania infrastruktury. Aktualna wersja modelu IFC koncentruje siê g³ównie na domenie bu-dynków i obejmuje szeroki zakres klas, które umo¿liwiaj¹ wymianê szczegó³owych modeli budynków, ale nie nadaje siê dobrze do modelowania obiektów infrastrukturalnych. Aby rozwi¹zaæ ten problem podejmowane s¹ starania standaryzacyjne (Vilgertshofer et al., 2017). G³ównym zadaniem nowej wersji standardu IFC jest zamodelowanie danych dotycz¹cych projektów infrastrukturalnych, takich jak: drogi, linie kolejowe, mosty i tunele. Pozwoli to zaspokoiæ zapotrzebowanie na znormalizowane dane dotycz¹ce obszaru infrastruktury, szczególnie, ¿e obecnie istnieje bardzo ograniczone wsparcie dla wymiany danych dla tego sektora (Gao et al., 2016). Równolegle s¹ rozwijane projekty rozwoju modelu IFC dla:
m projektów mostowych (IFC-Bridge) (Yabuki et al., 2006; Lebegue et al., 2012), m tuneli (IFC-Tunnel) w oparciu o niemiecki projekt IFC Tunnel Project (Amann et al.,
2013; Borrmann et al., 2012; Borrmann, Jubierre, 2013; Hegemann et al., 2012) oraz projekt The Japanese Shield-Tunnel Project (Yabuki et al., 2007),
m dróg (IFC-Road) (Lee, Kim, 2011).
Ponadto w 2012 roku zosta³o za³o¿one konsorcjum OpenINFRA w ramach dzia³alnoœci
buildingSMART w celu opracowania opartych na IFC modeli danych dla obiektów
infra-strukturalnych, w tym dróg, mostów, tuneli i kolei, które znajd¹ siê w standardzie IFC 5 (Liebich, 2019; Borrmann et al., 2019) .
Przyk³ady wykorzystania modelu IFC
do zapisu modelu obiektu infrastrukturalnego
Do zbadania struktury zapisu danych dotycz¹cych projektów infrastrukturalnych w mo-delu IFC wybrano trzy modele BIM: 1) k³adkê dla pieszych z windami dla osób z niepe³no-sprawnoœciami, 2) most konstrukcji ³ukowej (rozporowej) 3) drogê wojewódzk¹ o parame-trach drogi ruchu przyspieszonego (M.A.D. Engineers, 2018), (GrabCAD, a STRATASYS solution, 2018).
W modelu k³adki, chodnik, po którym poruszaj¹ siê piesi, zapisany zosta³ jako IfcSlab (rys. 3), barierki to klasa ifcRailing (porêcz), natomiast schody odpowiadaj¹ IfcStairFlight. S³upy konstrukcyjne k³adki oraz szybów windowych odnotowano jako IfcBuildingElement
Proxy. Przeszklenia i wejœcia do windy zosta³y zapisane jako IfcPlate (p³yta), dach dŸwigu
osobowego – IfcRoof, a szprosy w œcianach os³onowych szybu windy to obiekt klasy Ifc
Member (liniowy element konstrukcyjny). Droga pod k³adk¹ uto¿samiona jest z klas¹ IfcSlab
(strop). Krawê¿niki nietypowo zapisane s¹ jako IfcFurnishingElement (mebel).
W przypadku modelu mostu barierki stworzone zosta³y z wykorzystaniem dwóch klas IFC: IfcBeam (belka) i IfcMember (rys. 4). Filary i konstrukcja ³ukowa na moœcie to elemen-ty uto¿samione z klas¹ IfcElementBuildingProxy. Pas zieleni rozdzielaj¹cy pasy ruchu rów-nie¿ powsta³ z dwóch klas: trawnik to standardowe IfcSlab, ale podwy¿szenie, na którym znajduje siê powierzchnia trawnika, to klasa IfcWallStandardCase (œciana podstawowa). Jezdnia, to IfcSlab .
R
ysunek 3.
W
idok aksonometryczny zaprojektowanej k³adki oraz podgl¹d struktury pliku IFC w popularnej przegl¹darce plików IFC BIMV
ision
Rysunek 4.
Widok aksonometryczny
Rysunek 5. Droga wojewódzka o parametrach drogi ruchu przyspieszonego
W przypadku drogi wojewódzkiej (rys. 5) podstawowe elementy modelu to jest: jezdnie, kostka betonowa dziel¹ca pasy ruchu w przeciwleg³e strony, trawnik w obrêbie linii rozgra-niczaj¹cych lub nasyp drogowy zosta³y zapisane w klasie IfcSlab (strop). Mniejsze elemen-ty, takie jak: barierki lub latarnie wzd³u¿ drogi zosta³y skojarzone z IfcBuildingElementProxy, reprezentuj¹ce specjalne elementy, którym IFC nie przyzna³ jeszcze definicji.
Przedstawione przyk³ady potwierdzaj¹ koniecznoœæ utworzenia oddzielnych klas elemen-tów infrastrukturalnych, w celu zapewnienia odpowiednich powi¹zañ (relacji) wymaganych w procesie interoperacyjnoœci aplikacji typu BIM.
Wnioski
Coraz wiêksza popularnoœæ technologii BIM w projektach infrastrukturalnych wymusza koniecznoœæ opracowania modelu IFC dedykowanego dla projektów infrastrukturalnych, w których znajd¹ siê definicje klas obiektów reprezentuj¹cych elementy sk³adowe budowli i/ lub budynków o charakterze infrastrukturalnym. Umo¿liwi to tworzenie modeli tych obiek-tów z u¿yciem dedykowanych klas obiekobiek-tów zamiast dotychczas u¿ywanych elemenobiek-tów geometrycznie podobnych, ale reprezentuj¹cych zupe³nie inne klasy. Istnieje pilna potrzeba stworzenia kompleksowego, neutralnego modelu danych, zdolnego do reprezentowania za-równo semantycznych, jak i geometrycznych aspektów g³ównych prac infrastrukturalnych. U³atwi to wymianê danych i otwarty dostêp do danych w kontekœcie planowania, realizacji i konserwacji projektów infrastruktury cywilnej, w tym drogowej i kolejowej, mostów oraz tuneli, a ostatecznie wszystkich budowli (BuildingSMART International, 2018).
G³ówne wyzwania w tym zakresie:
m umo¿liwienie wymiany danych opartych o otwarte standardy w zakresie planowania, realizacji i konserwacji prac infrastrukturalnych, takich jak: transport drogowy i kole-jowy, a ostatecznie wszystkich aspektów œrodowiska budowlanego;
m umo¿liwienie wymiany informacji i otwarty dostêp do danych miêdzy bazami danych stosowanymi przez aplikacje do zarz¹dzania aktywami;
m umo¿liwienie trwa³ego archiwizowanie informacji o aktywach opartych o otwarte standardy;
m umo¿liwienie zarz¹dzania informacjami o cyklu ¿ycia obiektów infrastrukturalnych opartych o otwarte standardy;
m umo¿liwienie ³¹czenia informacji zwi¹zanych z projektem, na przyk³ad wymagania i analizy ryzyka wraz z informacjami o aktywach.
Zanim jednak powstanie rozszerzony model IFC, zawieraj¹cy klasy reprezentuj¹ce obiek-ty infrastrukturalne i ich elemenobiek-ty sk³adowe, bêd¹ powstawa³y modele BIM u¿ywaj¹ce klas obiektów stanowi¹cych elementy budynku do tworzenia modeli obiektów infrastruktural-nych. W procesie analizy modelu BIM, jak równie¿ w procesie integracji danych BIM i GIS nale¿y uwzglêdniæ tê przejœciow¹ sytuacjê, w której klasy obiektów nie bêd¹ odzwierciedla³y rzeczywistoœci, na przyk³ad trawnik reprezentowany przez obiekt IfcSlab, czyli strop, co bêdzie prowadzi³o do tworzenia semantycznie niespójnych modeli danych.
Podziêkowania. Autorzy dziêkuj¹ dwóm anonimowym recenzentom za cenne wska-zówki.
Finansowanie. Publikacja artyku³u zosta³a sfinansowana ze œrodków statutowych Wy-dzia³u Geodezji i Kartografii Politechniki Warszawskiej.
Literatura (References)
Amann Julian, Borrmann Andre, Hegemann Felix, Jubierre Javier, Flurl Matthias, Koch Christian, König Marcus, 2013: A Refined Product Model for Shield Tunnels based on a Generalized Approach for Align-ment Representation. Procedings of the 1st International Conference on Civil and Building Engineering Informatics (ICCBEI 2013, November).
Autodesk Inc., 2018: Revit IFC manual. Autodesk Inc.
Borkowski Andrzej S., 2018: Programowanie stropów w BIM (Floor programming in BIM). Builder 118: 70-73. Borrmann Andre, Jubierre Javier, 2013: A Multi-Scale Tunnel Product Model Providing Coherent Geometry and Semantics. Procedings of the ASCE International Workshop on Computing in Civil Engineering Conference (2013, June).
Borrmann Andre, Amann Julian, Chipman Tim, Hyvärinen Juha, Liebich Thomas, Muhiè Sergej, Plume Jim, Scarponcini Paul, 2019: IFC Infra Overall Architecture Project. Documentation and Guidelines. Retrieved 2019.01.07 from https://www.buildingsmart.org/wp-content/uploads/2017/07/08_bSI_OverallArchitecure_ Guidelines_final.pdf
Borrmann Andre, Ji Yang, Jubierre Javier, 2012: Multi-scale geometry in civil engineering models: Consistency preservation through procedural representations. Procedings of the 14th International Conference on Computing in Civil and Building Engineering.
BuildingSMART International, 2018: BuildingSMART Infrastructure Room. Retrieved 2018.05.25 from BuildingSMART International: https://www.buildingsmart.org/standards/rooms-and-groups/infrastructure-room/
Summary. Retrieved 2018.05.23 from BuildingSMART International home of openBIM:
https://buildingsmart-1xbd3ajdayi.netdna-ssl.com/wp-content/uploads/2017/07/2015-Work-Plan.pdf BuildingSMART International, 2018: Infrastructure Room Charter. Retrieved 2018.05.23 from
Building-SMART International home of openBIM: https://buildingsmart-1xbd3ajdayi.netdna-ssl.com/wp-content/ uploads/2017/07/Draft-Charter-v11-20160310.pdf
BuildingSMART International, 2018: Industry Foundation Classes Release 4 (IFC4). Retrieved 2018.12.11 from IFC4 Documentation: http://www.buildingsmart-tech.org/ifc/IFC4/final/html/
Gao G., Liu Y.-S., Wu J.-X., Gu M., Yang X.-K., & Li H.-L., 2016: IFC Railway: A Semantic and Geometric Modeling Approach for Railways based on IFC. Procedings of the 16th International Conference on Computing in Civil and Building Engineering: 1188-1195.
Gotlib Dariusz, Wyszomirski Micha³, 2018: Cele i wybrane problemy konwersji modeli BIM na modele GIS (Conversion between BIM and GIS models – objectives and selected issues). Roczniki Geomatyki 16 (1): 19-31, Warszawa, PTIP.
GrabCAD, a STRATASYS solution, 2018: Popular moldels | 3D CAD Model Collection | GrabCAD Community Library. Retrieved 2018.06.11 from GrabCAD: Design Community, CAD Library, 3D Printing Software: https://grabcad.com/library
Hegemann F., Lehner Karlheinz, König Markus, 2012: IFC-based product modeling for tunnel boring machi-nes. Proceedings of the 9th European Conference on Product and Process Modeling: 289-296.
International Organization for Standardization, 1987: ISO/TC 59/SC 13 Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM). Lysaker, Norway: International Organization for Standardization.
International Organization for Standardization, 1994: ISO/TC 211 Geographic information/Geomatics. Stoc-kholm, Sweden: International Organization for Standardization.
International Organization for Standardization, 2004: ISO 10303-11:2004 Industrial automation systems and integration – Product data representation and exchange – Part 11: Description methods: The EXPRESS language reference manual. International Organization for Standardization.
International Organization for Standardization, 2018: ISO/AWI TR 23262 GIS (Geospatial) / BIM interope-rability. International Organization for Standardization. Retrieved from https://www.iso.org/standard/ 75105.html
Kasznia Dariusz, Magiera Jacek, Wierzowiecki Pawe³, 2017: BIM w praktyce (BIM in practice). Warszawa, Wydawnictwo Naukowe PWN: 306 s.
Lebegue E., FiLs B., Gual, J., 2012: IFC-Bridge V3 Data Model – IFC 4, Edition R1.
Lee Sangho, Kim, Bonggueun, 2011: IFC Extension for Road Structures and Digital Modeling. Procedia Engineering 14. The Twelfth East Asia-Pacific Conference on Structural Engineering and Construction (EASEC-12): 1037-1042.
Liebich T., 2019: IFC for Infrastructure. (RetrXeved 2019.01.07 from buildingSMART) Model Support Group: https://www.buildingsmart.de/kos/WNetz?art=File.download&id=1601
M.A.D. Engineers Sp. z o. o, 2018: Modele IFC (IFC Models). Pobrano 2018.06.11 z lokalizacji BIMblog.pl: http://www.bimblog.pl/modele-ifc/
Tomana Andrzej, 2016: BIM – Innowacyjna technologia w budownictwie. Podstawy, standardy, narzêdzia (Innovative technology in construction. Foundations, standards, tools). Kraków, PWB MEDIA Zdzie-b³owski Spó³ka Jawna.
Vilgertshofer Simon, Amann Julian, Willenborg Bruno, Borrmann Andre, Kolbe Thomas H., 2017: Linking BIM and GIS Models in Infrastructure by Example of IFC and CityGML. ASCE International Workshop on Computing in Civil Engineering, 2017 June.
Yabuki Nobuyoshi, Azumaya Yuichiro, Akiyama Minoru, Kawanai Yasushi, Miya Toru, 2007: Fundamental study on development of a shield tunnel product model. Journal of Civil Engineering Information
Appli-cation Technology 16: 261-268.
Yabuki Nobuyoshi, Lebegue Eric, Gual Jean, Shitani Tomoaki, Li Zhantao, 2006: International Collaboration for Developing the Bridge Product Model “IFC-Bridge”. Joint International Conference on Computing and Decision Making in Civil and Building Engineering, 2006, June 14-16: 1927-1936.
Streszczenie
Standardy wykorzystywane w modelowaniu budynków s¹ dojrza³e, ale aktualnie nie obejmuj¹ metod modelowania obiektów infrastrukturalnych. Nale¿y siê zatem spodziewaæ rozszerzenia standardu IFC o nowe klasy obiektów reprezentuj¹cych obiekty infrastrukturalne w najbli¿szym czasie. Zanim jednak to nast¹pi bêd¹ pojawia³y siê modele BIM obiektów infrastrukturalnych wykorzystuj¹ce do-stêpne obecnie klasy IFC. Analiza dostêpnych autorom modeli BIM obejmuj¹cych obiekty infrastruk-turalne wykaza³a, ¿e do budowy modelu s¹ wykorzystywane klasy obiektów stanowi¹cych elementy budynku. W procesie analizy modelu BIM, jak równie¿ w procesie integracji danych BIM i GIS nale¿y uwzglêdniæ sytuacjê, w której klasy obiektów nie bêd¹ odzwierciedla³y rzeczywistoœci. Ponadto istnie-j¹ce ju¿ modele BIM obiektów infrastrukturalnych najprawdopodobniej nie zostan¹ przebudowane po wprowadzeniu rozszerzonego modelu IFC, zatem semantyka tych modeli bêdzie niepoprawna. Budo-wa spójnych systemów informacji przestrzennej obejmuj¹cych dane pochodz¹ce z modeli BIM musi zatem uwzglêdniaæ koniecznoœæ translacji klas u¿ytych w tych modelach do ich w³aœciwych odpowied-ników.
Abstract
The standards used in Building Information Modelling are mature, but currently they do not include methods for modelling of infrastructural objects. It is expected that the IFC standard will be extended with new classes of objects representing infrastructural objects in the near future. However, before this happens, BIM models of infrastructural objects will appear that will use the currently available IFC classes. The analysis of BIM models available to the authors, including infrastructural objects, showed that the classes of elements of a building are used to build the model. When the BIM model is analysed, as well as when BIM and GIS data are integrated, attention should be paid to such cases when object classes will not reflect the reality. In addition, existing BIM models of infrastructural objects are unlikely to be rebuilt after the introduction of the extended IFC model, so the semantics of these models will be incorrect. Development of coherent spatial information systems including data from BIM models must therefore take into account the need to translate the classes used in these models to their respective counterparts.
Dane autorów / Authors details: mgr in¿. Micha³ Wyszomirski
https://orcid.org/0000-0002-5407-0536 michal.wyszomirski@pw.edu.pl mgr in¿. Andrzej Szymon Borkowski https://orcid.org/0000-0002-7013-670X andrzej.borkowski@pw.edu.pl Przes³ano /Received 3.09.2018
Zaakceptowano / Accepted 31.01.2019 Opublikowano / Published 30.03.2019
