Første skritt på veien – IFC

English translation – Click here

Vår anbefaling går i retning av å utvide IFC til også å ta med seg de landskapsobjektene som i dag ikke er definert i IFC standarden.

Universitetet i Stavanger

Med generell erfaring fra ulike prosjekter, møter og studier vil vi anbefale at Statsbygg tar initiativ til å utvide IFC til også å ta med seg Landskapsarkitektur /urban design. Statsbygg har gjennom sitt internasjonale og nasjonale arbeid for BIM gjort at de fleste store byggeprosjekter i Norge i dag krever BIM;  Statsbygg, Forsvarsbygg, Helseforetakene osv.. I disse prosjektene benyttes IFC.

IFC formatet klarer å overføre både geometri og egenskapsdata knyttet til geometri mellom ulike programvare. Egendefinerte objekter og egenskaper følger også med ved en IFC eksport noe som gir store muligheter selv om de får  «propertysets» som ikke er innarbeidet (native) i IFC-standarden. I dag har vi ikke noe alternativ åpent format som kan måle seg med IFC.  Den store fordelen med formatet er at det er godt akseptert og innarbeidet i mange av programvarene som vi benytter i bygg- og anleggsnæringen.

Ved nærmere studie av IFC objekter og objekter for landskap viser det seg at landskap som designpremissgiver utomhus ofte jobber med objekter som tilhører andre fagområder. De fleste fagområder som er tilknyttet bygg er også representert utomhus. Slik som byggeteknikk, elektro, vann, akustikk, osv. IFC har definert allerede mange objekter som også kan benyttes utomhus slik som ; trapp, lys, rekkverk, gulv, mur/vegg, osv. Dermed gjenstår det kun noen få objekter som ikke er definert godt i IFC;  vegetasjon og terreng med sine representative objekter som kantstein. En mer komplett oversikt er vist i teksten IFC for LARK – Eksempel brukt i Revit  Objekter utomhus må kunne forholde seg til geografisk høyde eller et referanse gulv som svært sjelden er horisontalt, etasjenivåer erstattes. Behovet for utvidelse av IFC består i å lage egne objektklasser med definerte «propertysets» (egenskapsdata) for landskapsobjekter, eller å utvide eksisterende objektklasser med egenskaper knyttet til landskap.

Det er viktig at landskapsarkitektene kommer i gang med å levere sine 3D modeller som BIM, dvs med objektinformasjon. Det er viktig å fokusere nøkternt og realistisk for å komme raskt på plass. Ettersom det internasjonalt ikke er noe åpent format som utpeker seg i dag for landskapsprosjekter vil vi anbefale å se på hva som faktisk fungerer i dag. Fokuser på formater som er innarbeidet i bransjen og i eksisterende programvare. Det som utpeker seg er IFC og LandXML. Med konkrete prosjekterfaringer i bruk av disse formatene og med den erfaring vi har tilnærmet oss ved denne oppgaven vil vi anbefale å få på plass IFC for landskapsarkitektur.

Hovedverktøy brukt av landskapsarkitekter i Norge i dag er AutoCAD Civil 3D fra Autodesk. Novapoint Landskap fra Novapoint bruker også AutoCAD som plattform. To av tre hovedforhandlere av Autodesk-produkter var på BA-nettverksmøte før sommeren 2012 og hevdet der at det ikke var noe problem å programmere en IFC eksporter fra Civil3D hvis det fantes en IFC standard for landskapsobjekter og evt andre samferdselsfag. Med tanke på at Autodesk sin beste IFC eksporter er fra AutoCAD Architecture i følge Cad-Q, burde det være mulig å få denne funksjonaliteten over til Civil3D også.

Målet er å benytte åpen BIM. Erfaring viser at proprietær BIM ligger teknologisk foran åpen BIM. Ønsket om at hele det bygde prosjektet skal kunne utveksles med 3D BIM bør være et viktig mål. Vectorworks Landmark, Architerra med Archicad og Siteworks og LandCAD for Revit viser at landskapsarkitekter kan benytte programvare som jobber med IFC i dag. I Norge er det samlet sett for få prosjekteksempler med disse verktøyene, men flere og flere prosjekter viser at landskapsarkitekter kan gjennomfører visse type prosjekter helt og holdent med disse programmene.

Store og små byggeprosjekter vil med dette få hele det bygde miljøet både inne og ute inn i en felles modell hvor alle fagmodellene har relevante egenskapsdata. 3D modeller med ubegrensede muligheter for å knytte til seg egenskapsdata vil gi store muligheter i hele verdikjeden. Arbeidet må med å få utvidet IFC til også å ta med seg landskapsobjekter bør kunne gå raskt. Slik vi ser det kan mye av IFC objektene for bygg også benyttes for utomhus. Noen få objekter fra landskap som terreng og vegetasjon må implementeres med sine spesifikke egenskapsdata. Øvrige generiske objekter fra andre fag som ofte landskapsarkitekten er designpremissgiver for i en tidligfase kan med fordel også tas med. Som VA sine sluk, rister, kumlokk, renner osv.

Hovedargumentet for å gå videre med IFC er at dette formatet allerede er godt innarbeidet i de fleste programvarene som benyttes i byggenæringen i Norge i dag. De fleste landskapsarkitekter vil kunne få sine modeller over i IFC format og dermed sikre at vi som bransje får geometri og egenskapsdata også fra landskap allerede i morgen. Bransjen har ikke tid til å vente lenger på at programvareleverandørene skal implementer og teste ut nye formater. Faget landskap vil med dette begynne arbeidet med å standardisere sitt fag med tanke på BIM.

På litt lengre sikt er det naturlig å tenke at programvare som landskapsarkitekten jobber med skal kunne utveksle data til minst tre til fire viktige åpne formater. Første skritt på veien er formatet IFC. Dette sikrer at landskap kan eksporterer og importerer all geometri med egenskapsdata. I neste omgang er det ønskelig at samme program skal kunne eksporterer og importerer LandXML. Foreløpig kan ikke dette formatet brukes som utveksling i prosjektsammenheng da det ikke støtter all geometri og informasjon men er viktig i utveksling av stikningsdata til byggeplass. Programvare må utvikles slik at landskapsarkitekten skal kunne sende og importere alle stikningsdata som LandXML. Programmer må kunne bygges opp slik at man på alle objekter har innebygd eller kan definere selv hva som skal følge med av geometri og informasjon ved en slik eksport. Det tredje formatet et datautveksling mot GIS. GIS er BIM i en annen målestokk så her må vi kunne utnytte geometri og egenskapsdata. Landskapsarkitekt skal kunne importere original GIS filer inn i sine programvare og kunne eksportere til GIS formater. CityGML er et åpent format som landskap skal måtte utveksle data med og vil bli viktigere i årene som kommer.

Prioritert rekkefølge for tilpasning av filformater for Landskapsarkitekter:

  1. IFC – Utveksling av all geometri og nødvendig egenskapsdata mellom ulike fag i prosjekteringsgruppen. Utveksling mot kunden for kontroll av areal og funksjonskrav.
  2. LandXML – Utveksling av nødvendig geometri og egenskapsdata til byggeplass. Maskinstyring og stikningsdata.
  3. SOSI/GML (GIS) – Utveksling av geometri og egenskapsdata mot kartverket. Regulering, temakart
  4. CityGML – Utveksling av nødvendig geometri og egenskapsdata mot bymodeller.

Filformatene slik de er i dag gir også en oversikt over hvilken type geometri og informasjon som er relevant i de ulike fasene som det her henvises til. Dette er ment som en foreløpig oversikt for å klargjøre og tydeliggjøre at vi ikke nødvendigvis kun kan ha et format men at vi bør kunne jobbe med flere type formater. Formatene som det her henvises til er tilpasset forskjellig bruk mer enn faglig innhold. Det er denne bruken som er viktig å få frem slik at man ikke utelukker fag men heller ser på hvordan man kan få med seg hele det byde miljøet inn i felles åpne standarder for informasjonsutveksling. Den naturlige rekkefølgen på hvordan landskapsarkitekter burde kunne  innhente og bruke relevant informasjon i en og samme programvare i et byggeprosjekt eller samferdselsprosjekt skulle helst vært som følger.

Grunnlagsdata – Rekkefølgen beskriver overordnet nivå ned mot detaljert nivå – LOD og tilbake til overordnet nivå etter bygging

  • SOSI/GML (GIS) – innhente eksisterende kartdata med nødvendig egenskapsdata, temakart.
  • CityGML – innhente deler av en bymodell med bygg og infrastruktur og deres egenskapsdata for å se prosjektet i sammenheng med omgivelsene.
  • IFC – innhente detaljert modeller av som bygget situasjon på bygg og landskap der prosjektet har felles grensesnitt.
  • LandXML – nye innmålinger som punkt, linjer, flater med nødvendig egenskaper i stedet for punktsky eller flatemodell som DWG slik man får i dag.

Programmering og Prosjektering

  • IFC – utveksling av detaljerte modeller i prosjekteringsgruppen og mot byggherre

Bygging

  • LandXML – mot byggeplass som utsettingsdata for maskinstyring og oppmåler
  • IFC – Detaljerte modeller som byggeplass benytter for å få ut byggdetaljer, database for produktdatablader, fremdriftsplanlegging, osv.

Som bygget

  • IFC – detaljert som-bygget-modell til byggherre/ bestiller av oppdraget inneholder link til byggdetaljer, produktdatablader, vedlikehold, forvaltning, levetid, monteringsdato, bilder fra byggeplass linket til objekter…osv. Modellen er en database for all dokumentasjon og relevant informasjon om byggeprosjektet.
  • CityGML – som bygget modell med relevant data som skal inn i en bymodell for å vise ny situasjon
  • SOSI/GML (GIS) – som bygget data som skal inn i kartverkets kartmodeller med nødvendig egenskapsdata

We recommend to expand the IFC format to include the landscape objects not yet defined in the IFC standard.

With general experience from a range of projects, meetings and studies, we recommend that Statsbygg (The Norwegian Government’s key construction and property adviser) initiate an  expansion of IFC to also include objects for landscape architecture and urban design. Statsbygg has, through their work with BIM both nationally and internationally, ensured that most large scale construction projects in Norway today demand BIM deliveries. In addition to Statsbygg’s own, Forsvarsbygg (The Norwegian Defense construction adviser), Helseforetakene (National hospital and health facilities) and others use IFC as their preferred data exchange format.

The IFC format transfers geometry, as well as connected object properties, through different types of software. Custom objects are also included in an IFC data export, which yields great possibilities – even though they may receive property sets not native to the IFC-standard. As of today, there is a lack of real alternatives to IFC. We have no comparable open formats for information modelling. However, the great advantage with this format is that it is accepted and incorporated into many of the software programs used in the construction business.

Looking closer at IFC objects – and landscape objects, in particular – it is revealed that landscape as a premise for outdoor design often utilise objects “belonging” to other disciplines. Most connected disciplines to the building industry are also represented outdoors, such as construction and electrical engineering, waterwork, acoustics and so on. The IFC format has already defined plenty of objects for these purposes, suitable for outdoor use. There are stairs, lighting fixtures, rails, floors, walls and so on – meaning there are just a few objects not defined well enough in IFC, such as vegetation and terrain, with representative objects like curbstones (For a detailed list, refer to the text IFC for Land. Arch. – Example from Revit).

Outdoor objects must be able to relate to geographical elevations, or a reference surface – more often than not non-planar – and floor levels must be replaced. The proposed expansion of IFC consists of creating dedicated object classes with defined property sets for landscape objects, or, to expand existing object classes with properties related to landscape.

It is important that landscape architects begin the delivery of 3D models as information models. To ensure a hasty process, there must be a realistic and sober focus on this issue. In the absence of an open, international format for landscape projects, we will base our recommendations on what actually works today, focusing on formats incorporated in the business as well as existing software. IFC and LandXML are the formats that shows the most promise in this regard. With our combined experience of their use –  in concrete projects, as well as through this study – we will recommend to establish IFC for landscape architecture.

The main tool landscape architects in Norway use today are Autodesk’s AutoCAD Civil 3D. Novapoint Landskap from Novapoint is also based on the AutoCAD platform. Two out of three main distributors of Autodesk products were present at the BA-network meeting prior to the Summer of 2012, stating that programming an IFC exporter from Civil 3D posed no challenge if landscape objects and related disciplines were included in the standard . Concerning the top IFC exporter from Autodesk is through AutoCAD Architecture, according to Cad-Q, it should be possible to extend this functionality to Civil 3D as well (IFC export, albeit only for solid objects, are now supported in Civil 3D 2016).

The goal is the use of open BIM standards. Experience shows that proprietary BIM is ahead of open BIM technologically. The wish that the entire built project should be able to be exchanged with 3D BIM should be an important goal. Vectorworks Landmark, Archicad’s Architerra and Revit’s Siteworks and LandCADD show that landscape architects can use existing software to work with IFC. In Norway there is a lack of project examples utilising these tools, but an increasing number of projects show that landscape architects can complete certain types of projects through the use of these programs alone.

Through this development, small and overall scale construction projects will assemble the entire built environment – external and internal – in an unified model where all disciplines are provided with relevant property sets. 3D models with infinite possibilities to attach properties will be of great value in the process. The effort to include landscape objects in the expansion of IFC should be able to have a hasty progression. As we see it, many of the IFC objects for buildings can also be used outdoors. A few designated objects such as terrain and vegetation must be implemented with specific property sets. Other generic objects from disciplines often planned by the landscape architect in early stages of a design (drains and grates, manhole covers etc) could be included with added benefit.

The main argument to proceed with IFC is that this format already is well incorporated in most of the software used by the construction industry in Norway today. Most landscape architects will be able to transfer their models to the IFC format and ensure that our profession get geometry and property data from landscape tomorrow. The business cannot wait for the software developers to implement and test new formats. The landscape architects will then begin the effort to standardise their profession with information modelling in mind.

Looking further, it is natural to think that our software should be able to exchange data to at least three to four important, open formats. The first step is IFC, ensuring that landscape objects can be exported and imported with all geometry and property data intact. Next, we would wish that the same software could export and import LandXML. At the moment this format cannot be used for exchange in projects as it does not support all geometry and information, but it is important when submitting survey data to the construction site. Software needs to be developed that the landscape architect is able to send and import all survey data as LandXML. Software needs to be built in such a manner that all objects include or can be customised to include a level of geometry and information through such an export. The third format is data exchange through GIS. GIS is BIM in a greater scale, and it must be possible to take advantage of its geometry and property sets. A landscape architect should thus be able to import original GIS files to their software and export to GIS formats. CityGML is an open format landscape will have to use for data exchange which will be increasingly important in the future.

List of formats accustomed to landscape architecture, in order of priority:

  1. IFC – Exchange of all geometry and necessary property data between various disciplines in the design team. Exchange to client for area control and functionality demands;
  2. LandXML – Exchange of necessary geometry and property data to construction site. Control of site machinery and survey data;
  3. SOSI/GML (GIS) – Exchange of geometry and property data with the mapping services. Planning regulations, themed maps, and
  4. CityGML – Exchange of necessary geometry and property data with urban development models.

The existing file formats also yields an overview of what types of geometry and information relevant for various phases, as it will be referred to here. This is meant as a temporary overview to clarify that we not necessarily need a single format, but rather are able to work with several. The formats listed here are sorted by field of use rather than professional content. This type of use is important to highlight to avoid disciplines from being left out. Rather we want to include the entirety of our physical surroundings – in common, open standards – for information exchange. The natural order of how landscape architects should both gather and use relevant information in the same software in a building construction or transport construction project should be as follows;

Source data – ordered by level of detail (LOD) from overall scale to detailed planning, and back to overall scale after completion.

  • SOSI/GML (GIS) – Extract existing geographical data with necessary properties, themed maps.
  • CityGML – Import the parts of an urban development model containing buildings, infrastructure and their properties in order to compare the project with its physical surroundings.
  • IFC – Import detailed models of the as-built situation for buildings and landscape where the projects overlap.
  • LandXML – New surveys as points, lines and shapes with necessary properties rather than point clouds or shape models in .DWG-format as provided today.

Programming and design

  • IFC – Exchange of detailed models with the design team and client.

Building

  • LandXML – Data as survey points for control of machinery on site
  • IFC – Detailed models for on site studies of building details, extraction of product information, schedules, etc.

As built

  • IFC – Detailed model for client that includes links to building details, product information, maintenance and operation data, expiration dates, dates of assembly, on site construction photos linked to objects and so on. The model is a database for all documentation and relevant information in the project.
  • CityGML – As-built model with relevant data to be inserted into an urban development model, showing the new situation.
  • SOSI/GML (GIS)  As-built data with relevant data to be included in the national mapping agency’s model sets.

Legg igjen en kommentar

Din e-postadresse vil ikke bli publisert. Obligatoriske felt er merket med *

*


*

Du kan bruke disse HTML-kodene og -egenskapene: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>