Bakgrunn - BIM for landskap
Informasjonsmodell for landskapsobjekter rev. 01.11.2012 BIM FOR LANDSKAPSARKITEKTUR Arbeidet med en felles informasjonsmodell for landskapsobjekter er et initativ fra arbeidsgruppen “BIM for landskap”. Forprosjektet som presenteres her er i regi av, og finansiert av Statsbygg. Denne pdf ’en er lastet ned fra www.underland.no, og er en eksport av artiklene som ligger der. Innholdet på nettsiden kan være oppdatert etter at denne pdf ’en ble generert, vi anbefaler derfor å besøke www.underland.no for å få tilgang til oppdatert informasjon. Kontaktperson Statsbygg Ida Grjotheim [[email protected]] Kontaktpersoner “BIM for landskap” Knut Halgeir Wik, Baar Bakke landskapsarkitekter [[email protected]] Åge Langedrag, Multiconsult [[email protected]] Bjørn Amund Enebo, Bjørbekk & Lindheim landskapsarkitekter [[email protected]] Table of Contents Bakgrunn Bakgrunn Norske nasjonale standarder NS3450 - hvem NS3451 - hvor NS3420 - hva NS4400 VIPS Statens vegvesen Prosesskoden NVDB HB138 HB138 Objektkodelista DAKAT SOSI Internasjonal standardisering Danmark England Sverige DWG IFC CityGML LOD CityGML for landskap LandXML KML Omniclass Objektklassifisering Objektklassifisering Krav til objektklasser Objektklasser Objektbibliotek Vegen videre Vegen videre Første skritt på veien - IFC IFC for LARK - BIM Manual 1.x Statsbygg IFC for LARK - CityGML IFC for LARK - Eksempel brukt i Revit IFC for LARK - Tidligere arbeider Avslutning Om BIM for landskap BIM - Noe mer enn bare Bygg Kilder til BIM for Landskap Artikler og nettsider BIM for Anlegg 2 2 5 6 7 9 10 11 12 13 14 15 17 20 21 22 23 26 27 29 30 31 32 34 35 37 38 42 42 43 45 46 47 47 48 52 53 55 68 71 71 72 76 78 82 Rapporter Webinar Begrepsavklaring 84 89 90 Bakgrunn Bakgrunn Bakgrunn Bakgrunn Utfordringer i bransjen Landskapsarkitekter opplever å falle mellom to stoler når det kommer til å velge verktøy og metode for å jobbe med digitale metoder. De jobber med prosjekter i stort spenn i skala, med alt fra hager og parker knyttet til bygninger til plasser og torg, parkanlegg, kirkegårder, gater, fortau og til de lange linjer på infrastrukturprosjekter for veier og jernbane. Vi er arkitekt/formgiver/premissgiver for design for «livet mellom husene», men verktøyene for å håndtere alt dette er ikke tilrettelagt for landskapsarkitekten. De er mer spesialisert på det bygningsmessige med arkitektverktøyene som Revit og Archicad, og utenfor bygget er de mest tilrettelagt for de tekniske fagene og for infrastruktur med sine lange strukturer bygget opp fra en veikropp. Landskapsarkitekter i Norge jobber tradisjonelt i sistnevnte kategori med CAD-baserte verktøy som Civil 3D. Landskapsarkitektur er ofte noe helt annet enn repetitive strukturer av vegger, tak og gulv eller lange linjer med faste bredder som en vei. Riktignok er det ofte møblering, vegetasjon og kanter som kan bygges opp likt fra gang til gang, men det er også en stor oppgave å kunne jobbe med terreng, presise fall og avvanning på en logisk og enkel måte. Ingen av disse verktøyene kan jobbe plastisk med terreng, kna det som en bulldoser eller grave det opp i hauger. Det finnes verktøy som kan forme terrenget og som kan håndtere komplekse former og store terrengdata og gi helt presise beregninger av fallforhold tilpasset våre krav til universell utforming eller minimumsfall for å få overvannet til å renne den rette veien. Man kan få programmer til å vise ulike lagtykkelser for oppbygning av ulike terrengflater og som dynamisk følger toppflaten når man endrer høyden eller fallet. Men ingenting av dette er gjort i en fei. De setter alle store krav til teknisk kompetanse hos den som skal formgi terrenget. Slik kompetanse er ikke utbredt blant landskapsarkitekter. I det minste ikke ennå. Det er også et dilemma at det er blant den yngre generasjon landskapsarkitekter man finner de som kan beherske den nye teknologien og som settes til å modellere landskapet mens det er den eldre generasjon som innehar stor påvirkningskraft på formgivning og lang erfaring med prosjekter, men som ikke har den samme forståelsen for hvordan dette kan omsettes i en digital terrengmodell. BIM for landskapsarkitektur Bakgrunnen for opprettelsen av arbeidsgruppen BIM for landskapsarkitektur – BFL – ble til i 2009 ved at Statsbygg fra årsskiftet 2010 krevde BIM for alle fag i alle sine prosjekter. Også andre store utbyggere på bygg og anleggsiden jobbet med lignende krav og BIM-strategi. Disse nye kravene innebar objektbaserte 3D-modeller på åpne formater. Landskapsarkitekter var ikke og er fortsatt ikke i stand til å levere modeller som tilfredsstiller disse kravene. Arbeidsgruppa utviklet et samarbeid og et nettverk for å utvikle landskapsarkitekters muligheter innenfor BIM og har med dette prosjektet fått anledning til å komme et stykke videre på veien mot å lage objektklasser for landskapsobjekter og forsøke å se videre framover mot en komplett landskapsinformasjonsmodell. Det er også et mål å finne verktøy som passer for vårt arbeidsfelt og forsøke å påvirke programleverandører til å gi oss verktøy som er enkle å bruke samtidig som de kan utføre oppgaven ihht. de nye kravene som ny teknologi fører med seg. 1 Bakgrunn Bakgrunn Hovedoppgave Dette forprosjektet har kommet istand ved hjelp av et prosjekt utlyst av Statsbygg. Hovedoppgaven for prosjektet som er formulert i prosjektbeskrivelsen: Dette prosjektets hovedoppgave er å begynne arbeidet med å standardisere digitalisert informasjon i form av en landskapsinformasjonsmodell, mao en parallell til bygningsinformasjonsmodellen på byggsiden. Å tette hele dette gapet mellom utviklingen på bygg og landskap er en stor oppgave og vi vil anse dette prosjektet som en begynnelse på dette arbeidet. Konkret vil dette prosjektet utføre følgende deloppgaver: 1. Kartlegge eksisterende klassifikasjonsstandarder for å vurdere om eksisterende standarder helt eller delvis kan “adopteres” for bruk innen modellering av landskap i Norge 2. Utarbeide forslag til objektklasser 3. Lage skisse til hovedprosjekt Metode Gruppen har jobbet sammen i ulike workshops hvor vi mellom møtene har fordelt arbeid oss i mellom. Alle tre i gruppen har god erfaring med å jobbe konkret i oppdrag hvor kunden stiller krav til 3D og informasjon på objekter. Gruppens representanter har vært delaktig i eksterne fora som BuildingSmart, BA-Nettverket, Tversektorialt samarbeidsprosjekt, Programvareleverandørenes brukerdager og lanseringsseminarer, Teknisk forum infrastruktur, De 6 store osv. Gruppen har brukt mye tid på å søke etter dokumenter, rapporter, artikler og prosjekteksempler som kan være til hjelp i den første delen av arbeidet med å samle inn grunnlagsinformasjon. Avgrensning av oppgaven Oppgaven med å samle informasjon og få en oversikt som skal resultere i en anbefaling for hovedprosjekt har vist at mye arbeid er gjort og mye skjer når det gjelder standardiseringsarbeid. Landskapsarkitektur griper inn i mange nivåer og mange standardiseringer som er under endring. Derimot er det få steder vi har funnet som kan gi et godt svar på en vei å gå videre. Vi har valgt å samle så mye informasjon som vi har kommet over i vårt arbeid slik at dette er tilgjengelig for videre arbeider. Når det gjelder anbefaling til videre arbeider ser vi at det bør jobbes på flere nivåer. Vår anbefaling er resultat av et ønske om å få på plass en løsning som gir landskapsarkitekter mulighet for å modellere alle sine objekter i 3D med egenskapsdata og dele denne informasjonen inn i en tverrfaglig prosjekteringsgruppe. Vår anbefaling for videre arbeid er å fokusere på hva vi kan ta tak i som allerede er tilgjengelig av programvare, metoder og utvekslingsformater slik at landskapsarkitekter kan få på plass en midlertidig løsning som er akseptert i den Norske bransjen. Denne løsningen vil kunne være til stor hjelp mens man jobber med en mer dypgående standardisering som vil ta tid og må tilpasse mange ulike standardiseringsarbeid som nå foregår parallelt, slik som LandXML, IFC, CityGML, SOSI til GML. 2 Bakgrunn Bakgrunn Disposisjon Rapporten er satt opp med en generell innledning som beskriver dagens utfordringer og oppgavens begrensninger. Videre er det henvist til ulike Norske og internasjonale standarder som vil være viktig å ta utgangspunkt i eller hente egenskaper fra når man skal objektifisere landskapsarkitekturfaget. Objektklassifisering viser i første omgang hvilke krav vi ser for oss bør stilles til fagets objekter og vi har laget noen eksempler på hvordan dette kan settes i system. Veien videre beskriver vår anbefaling til et hovedprosjekt og midlertidige arbeider som vil kunne gi mye med de programvarene og standardene som vi har tilgjengelig i dag. I dette kapittelet har vi også beskrevet noen eksempler som viser til gjennomførte arbeider som bør følges opp for å få på plass en midlertidig løsning som viser seg fungerer frem til man har en mer ISO sertifisert standard også for landskapsarkitekturfaget. Om BIM for landskap, har vi prøvd å samle de viktigste kildene som har vært til inspirasjon for vår arbeid og for videre arbeider. 3 Bakgrunn Norske nasjonale standarder Norske nasjonale standarder Norsk standard er innarbeidet i bygge- og anleggsbransjen og derfor et logisk utgangspunkt når vi skal se på et objektbibliotek for landskapsobjekter. Serien med aktuelle NS-er er gjennomgått kort under, samt SOSI og Statens veivesens Prosesskode/NVDB/DAKAT. Ingen av standardene er dekkende eller i stand til å fungere som et objektbibliotek, men for prosjektet har de vært en viktig referanseliste og rettesnor for hvilke objekter som er tatt med og hvordan de er klassifisert. 4 Bakgrunn NS3450 - hvem NS3450 - hvem Omfang: Standarden fastsetter regler for redigering av og innhold i dokumenter som skal ligge til grunn for tilbud på eller avtale om utførelse av bygg, anlegg, installasjoner, drift og vedlikehold. Standarden er en komplett oversikt over hva et prosjekt skal inneholde for å kunne realiseres og fungerer som en huske-/sjekkliste for strukturering av et prosjekt. Hovedkapitler: A Prosjektinformasjon B Konkurranseregler og kvalifikasjonskrav C Kontraktsbestemmelser D Beskrivende del E Svardokumenter I standardens tillegg A beskrives kapittelinndeling av prosjektbeskrivelser av bygg med kapittel 01 Rigging og drift, 03 Graving, sprenging, 71 Anleggsgartnerarbeid osv. Denne inndelingen beskriver også hvem som står for utførelsen av arbeidene Standarden kan lastes ned gratis her: http://www.anskaffelser.no/filearchive/ns03450-no.01.pdf 5 Bakgrunn NS3451 - hvor NS3451 - hvor NS3451 Bygningsdelstabellen Standarden kjennes best som Bygningsdelstabellen og danner grunnlag for beskrivelse av alle objekter (bygningsdeler) for bygg og anlegg. Bygningsdelstabellen bygger på den internasjonale standarden ISO 12006-2 Building construction – Organization of information about construction works – Part 2: Framework for classification of information. ISO 12006-2 er grunnlag for standardisering i en rekke andre land som OmniClass i USA, Sverige med BSAB 96, England med Uniclass 1997 og Danmark med DBK 2006. Alle disse standardene baserer seg på en liste/tabell av elementer=bygningsdeler og design elements=bygningsdelstyper som til sammen utgjør et byggverk/anlegg. Bygningsdelstabellen brukes ofte i sammenheng med kostnadsberegninger i tidligfase-prosjekter og er gjort tilgjengelig på mange ulike felt. For eksempel finnes den som et kostnadsberegningsverktøy for smart-telefoner med app-en Norsk Prisbok. Bygningsdelstabellen er det nærmeste vi kommer en objektliste for landskap innen Norsk Standard. Av den grunn er det viktig at innholdet i Bygningsdelstabellen blir ivaretatt i utarbeidelsen av LIM-objektbiblioteket. Se også Statsbygg BIM manual 1.2 – A.3 Referanser: ISO 12006-2 Building construction — Organization of information about construction works — Part 2: Framework for classification of information … NS 3451 Bygningsdelstabell (forkortelse: NS 3451) – INFO: Innholdet i NS 3451 svarer grovt sett til elementtabeller som ‘OmniClass Table 21 – Elements’. Bygningsdelstabellens omfang Sitat: Standarden fastlegger inndeling i bygnings- og installasjonsdeler for systematisering, klassifisering, koding m.m. av informasjon som omfatter de fysiske delene av bygningen og de tilhørende utvendige anlegg. Inndelingen kan brukes til byggebeskrivelser, statistikk og tilbakeføring av erfaringer om kostnader, bruksegenskaper, varighet og annet. Videre kan inndelingen benyttes i forbindelse med referansesystemer for merking av bygningsdeler på tegninger, skjema mv. og i det utførte bygget. Inndeling Bygningsdelstabellen er bygd opp med tre nivåer, med økende grad av detaljering fra 1-sifret til 3-sifret nivå. 1-sifret bygningsdel For landskap finner vi hovedsakelig bygningselementene i bygningsdel (1-sifret) 7 Utendørs. 2-sifret bygningsdel 6 Bakgrunn NS3451 - hvor På 2-sifret nivå er Bygningsdelstabellen delt slik: 70 Utendørs, generelt 71 Bearbeidet terreng 72 Utendørs konstruksjoner 73 Utendørs VVS 74 Utendørs elkraft 75 Utendørs tele og automatisering 76 Veger og plasser 77 Park og hage 78 Utendørs infrastruktur 79 Andre utendørs anlegg 3-sifret bygningsdel Hoveddel 7 Utendørs er her gjengitt i sin helhet. Generelt ser man at det er mange koder som ikke skal benyttes og at det også er mange objekter som mangler i forhold til å dekke alle mulige objekter man har behov for i et prosjekteringsbibliotek. Tabell 7- Utendørs 7 Bakgrunn NS3420 - hva NS3420 - hva Beskrivelsestekster for bygg, anlegg og installasjoner Standarden er svært utbredt i bransjen for beskrivelse av hva som skal bygges og hvordan utførelsen skal være for å kunne prissettes. Det er åpenbart at en god kobling mellom en LIM-objektliste og NS3420 hadde kunnet gi store fordeler for utarbeidelse av komplette prosjektdokumenter. Hovedformål I standardens hovedformål står det: NS 3420 er et standardisert system av postgrunnlag for delprodukter og ytelser innen bygge- og anleggsarbeider, med hovedformål å danne grunnlaget for utarbeidelsen av poster i en detaljbeskrevet prisforespørsel. Standarden inneholder beskrivelse av de enkelte delprodukters eller ytelsers omfang og prisgrunnlag samt krav til materialer, utførelse, toleranser, prøving og kontroll. I tillegg fastsetter standarden regler for mengdeberegning. Landskap i NS3420 Hovedelementene på objektnivå som beskrives for landskap i NS3420 er samlet i Del K: Anleggsgartnerarbeider, men også andre deler som Del F Grunnarbeider – del 1 (Vegatsjonsrydding, masseflytting, massutskifting mm) og Del G Grunnarbeider - del 2 (asfaltdekker, kunstgressdekker mm), Del Z Drift og vedlikehold og andre deler er høyst relevante for LIM-objekter. Komplett oversikt over strukturen for Del K: Anleggsgartnerarbeider kan ses (forhåndsvisning) og kjøpes her: http://www.standard.no/no/Sok-og-kjop/Sokeresultater/ og søk på anleggsgartnerarbeider 8 Bakgrunn NS4400 NS4400 NS 4400 Planteskolevarer NS 4400 Planteskolevarer fastlegger generelle krav til kvalitet, størrelse, merking og emballering for treaktige planter… I tillegg til denne generelle standarden er det fastlagt spesifikke standarder for planteslag som brukes i hager og grøntanlegg (NS 4401 til NS 4413). Standarden oppgir kriterier som grein, tellende grein, herkomst, bredde osv som vil være aktuelle egenskapsdata som kan knyttes til LIM-objekter på grøntanleggsiden De spesifikke standardene under NS 4400 er som følger: NS4401 Vegetativt formerte roseplanter NS4403 Løvtrær NS4404 Frukttrær NS4405 Stauder NS4406 Slyngplanter og klatreplanter NS4407 Bringebærplanter NS4408 Bærbusker NS4409 Jordbærplanter NS4410 Hekkplanter og masseplanter NS4411 Planter til viderekultur NS4412 Grunnstammer for frukttrær NS4413 Barplanter (koniferer) Objekter i et objektbibliotek for vegetasjonsobjekter bør ha egenskaper som referer seg til NS 4400. 9 Bakgrunn VIPS VIPS VIPS (Vegvesenets Interaktive PlanleggingsSystem) VIPS er et lukket format innarbeidet i Vianova systems sin programvare. Entreprenører har uttalt at de ser fordel med å kunne motta VIPS fra de prosjekterende fordi filformatet og programvare gir mulighet for at modellen kan bearbeides videre av mottakeren. Modellen er ikke død og låst som den er ved evt eksport til DWG. For riktig masseberegning vil avdekket fjell under bygging alltid være annerledes en antatt fjell fra prosjektering. Derfor trenger entreprenør og kunne jobbe videre med den prosjekterte 3D modellen slik at de får riktig masseberegninger. Denne egenskapen er kjent fra byggebransjen når det gjelder formatet IFC hvor man kan fortsette å jobbe på objekter modellert i én programvare og videre importert i en annen programvare. 10 Bakgrunn Statens vegvesen Statens vegvesen Statens vegvesen har gjennom mange år standardisert all produksjon på nyanlegg og drift/vedlikehold. Prosesskoden (HB025) er i likhet med NS3420, beskrivelsestekster som brukes til beskrivelser for prissetting av veganlegg. Vegvesenet har også samlet en database for alle veiene i landet i en Nasjonal veidatabank – NVDB. For nyanlegg og informasjonmodellering har de utarbeidet en egen håndbok – HB138-Modellgrunnlag som har en egen objektkodeliste. Vi har også sett nærmere på vegvesenets datakatalog – DAKAT. 11 Bakgrunn Prosesskoden Prosesskoden Håndbok 025 Prosesskode 1 – Standard beskrivelsestekster for vegkontrakter, hovedprosess 1–7 Prosesskoden inneholder detaljerte beskrivelsestekster for nyanlegg og drift/vedlikehold for veganlegg. Prosesskoden har under Hovedprosess 7 Vegutstyr og miljøtiltak beskrevet mange av landskapets objekter og den beskriver også hvordan objektet skal implementeres, feks for et tre vil også jord og plantehull beskrives i samme prosess. Prosesskoden kan ikke uten videre ses i sammenheng med objekter i et landskapsbibliotek, men er interessant som en helhet sammen med objektkodelista og de andre standardene fra vegvesenet. 12 Bakgrunn NVDB NVDB NVDB – Norsk veidatabank – er en database/register for alle veiene i landet. NVDB er utviklet av Statens vegvesen og Kartverket for å blir et informasjonssystem som sikrer optimal drift, forvaltning og utvikling av det offentlige vegnettet i Norge (Kartverket, 2009). Databasen skal være lett å presentere som kartbilder og tilgjengeliggjøres som internettløsninger som for eksempel visveg.no 13 Bakgrunn HB138 HB138 Statens vegvesens Håndbok 138 – Modellgrunnlag (HB138) setter krav om at ”som utført”-data skal leveres for bl.a. NVDB og objektene som skal være med er definert av Objektkodelista. Objektkodelista definerer alle objekter med et objektnavn, definisjon og kode som bestemmes fra NVDB eller Prosesskoden (HB025). Fagmodeller HB138 definerer fagmodeller for hvert fag 3.3.2 Fagmodell veg 3.3.3 Fagmodell konstruksjoner 3.3.4 Fagmodell tunnel 3.3.4 Fagmodell VA, grøft og rørledning 3.3.5 Fagmodell bergsikring, geotekniske konstruksjoner og tiltak 3.3.6 Fagmodell skilt, signal og oppmerking 3.3.7 Fagmodell vegutstyr 3.3.8 Fagmodell kabelføringsanlegg 3.3.9 Fagmodell tekniske installasjoner 3.3.10 Fagmodell landskapstiltak 3.3.11 Reguleringsflater og grunnerverv 3.3.12 Ytre miljø/beregningsmodell Til sammen danner dette en stor samlet Tverrfaglig modell (3.4), en Prensentasjonsmodell (3.5) samt en Som utført modell (3.6) Kravet til innholdet i feks Fagmodell landskap er detaljert og omfattende og kan inneholde Design og utforming, Terrengforming, Vegetasjon, Analyser, Formingsveileder, Intensjonsbeskrivelse, Skjøtsel, Rigg og marksikring. Terrengmodellen skal inneholde byggegroper, plantehull, jordlag med lagtykkelser osv. Terrenget eksporteres til LandXML (triangulering) og evt 3D-geometri som volumobjekter. Objekter referes med et punkt (xyz) og langsgående objekter refereres som en referanselinje, eksempelvis en kantstein refereres med en linje for innerkanten av kantsteinen. Også her er LandXML utvekslingsformat og stikningsdata. Objekter for Vegetasjon skal være relativt detaljerte og inneholde mye informasjon både i forhold til geometri (størrelse ved utplanting/utvokst) og innhold (art-/sortsnavn mm) som skal kunne trekkes ut. Dette er ikke løst i forhold til utvekslingsformatene (LandXML, SOSI) som ikke bærer med seg denne funksjonaliteten/informasjonen. Dette vil kun komme til nytte i det proprietære formatet som benyttes til prosjekteringen. 14 Bakgrunn HB138 HB138 foreligger pr dags dato i en høringsutgave, men er allerede tatt i bruk i en del prøveprosjekter. HB138 er relativt ambisiøs i forhold til landskapsinformasjonsmodellering og beskriver en prosess som fungerer godt utfra å få stikningsdata mellom prosjekterende og utførende, men i forhold til objektbasert modellering med informasjonsbærende objekter er det fortsatt et stykke vei å gå. 15 Bakgrunn HB138 Objektkodelista HB138 Objektkodelista Objektkodelista som er et vedlegg til HB138 er en flat fil med koder for hver enkelt objekttype. Standarden er CAD-basert, og forholder seg til lagstrukuren i tegneverktøyet. HB 138 definerer den slik: Objektliste Definerer digitale objekter som benyttes til planlegging, prosjektering og bygging Angir hvilke objekter som inngår i de ulike fagmodellene Listen må tilpasses hvert prosjekt individuelt Objektkodelista er publisert som et regneark. Landskapstiltak er en egen flik i regnearket. Objektkodene er seksifret, og det er i hovedsak stikningsdata som er representert i lista. Til hver enkelt objektkode er det knyttet en tekststreng som beskriver objektet enten det er definert av NVDB eller henvisning til HB025 Prosesskoden. Alle fag opererer i den samme lista. Landskap havner i hovedsak under hovedprosess 7, vegutstyr og miljøtiltak. 16 Bakgrunn HB138 Objektkodelista Utsnitt av objektkodelista med fliken Landskapstiltak http://banettverket.no/resources/1/BA2012/26012012/2012.02.31_Objektkodeliste.xlsx Objektkodelista er i skrivende stund under utarbeidelse, og har foreløpig vært et dynamisk element som kan tilpasses bruk. For landskapsobjekter er feltkodelista brukbar som kobling mot NVDB og Dakat, men det er lite informasjon i strukturen som kan være relevant å ta med i LIM. Så vidt vi kan bedømme baserer HB 138 seg fortsatt på et system med modell og beskrivelse som separate dokumenter. 17 Bakgrunn HB138 Objektkodelista 18 Bakgrunn DAKAT DAKAT DAKAT – Datakatalogen er en oversikt over alle objektene som utgjør kjernen i NVDB. DAKAT kan brukes som et verktøy på internet via en egen applikasjon der objekter listes opp i 4 kolonner: Kategori, objekttype, egenskapstype og tillatte verdier: DAKAT versjon 2.21 Eksempelet viser objekttype Tre og alle egenskapstypene knyttet til objektet. Egenskapstypen Type/form vil her ha tillate verdier Trær, frittstående / Tregruppe / Trelund osv Objekttabellen er svært detaljert og inneholder mange objekter og egenskaper som vil kunne være aktuelle for et LIM-objektbibliotek. Også måten den er strukturert på er noe dette prosjektet griper fatt i med oppbygningen av landskapsinformasjonsmodellen og eksemplene på objektbibliotek. 19 Bakgrunn SOSI SOSI SOSI – Samordnet Opplegg for Stedfestet Informasjon SOSI-standarden har vært kjent i landskapsarkitekturen i lang tid siden Kartverket i Norge har forsynt den bygg- og anleggsrelaterte delen av bransjen med kart på SOSI-format i mange år. SOSI-koder (temakoder) på lagstrukturen i DAK-plattformen har vært, og brukes fortsatt aktivt som grunnlagsmateriale for et hvert prosjekt. Temakodene er seg selv et omfattende objektbibliotek som inneholder de nødvendig koder for å kartfeste informasjon, eller sagt på en annen måte at objekter i landskapet er standardisert og gjengitt på en måte som kan visualiseres i form av et kart. De detaljerte kartene for landets kommuner er tilgjengelig via Norge Digitalt-samarbeidet og benevnes gjerne med FKB (felles kartbase). Hovedbetydningen for ”BA-LARK-bransjen” ligger i at all kartfestet informasjon er digitalisert og tilgjengeliggjort i SOSI-formatet. Det fungerer som et utvekslingsformat og lagringsformat for geografiske data. Temakodene er ikke lenger en del av SOSI-standarden (fra versjon 4.0, 2009), men siden de er så godt innarbeidet blant brukermiljøene har kartverket en oversikt over temakoder som kan lastes ned her. SOSI-formatet er et åpent utvekslingsformat (plattformuavhengig) og inneholder også mye mer i form av geodata som benyttes i større grad av andre deler av bransjen på GIS-plattformen. Utviklingen av SOSI dreies over mot GML (Geography Markup Language) som gradvis vil ta over som utvekslingsformat av geografiske data i Norge. SOSI/GML utvikles videre ihht internasjonale standarder (Wikipedia-lenker: ISO/TC 211, ISO 19136) Objekter i SOSI-standarden er geometrisk bestemt som punkt, linje eller flate. SOSI/GML vil fortsatt spille en viktig rolle som data over eksisterende forhold, det som allerede er bygget. Det pågående arbeidet med denne rapporten vil teste ut hvorvidt disse standardene vil være anvendelig for LIM-objekter, men gitt at de en gang skal bygges vil de også måtte kunne gjengis innenfor dette systemet. 20 Bakgrunn Internasjonal standardisering Internasjonal standardisering 21 Bakgrunn Danmark Danmark BIPS BIPS (byggeri – informationsteknologi – produktivitet – samarbejde) www.bips.dk. Er for sammenligningens skyld i norske øyne en blanding mellom Standard Norge og buildingSMART. BIPS Utvikler danske standarder og IT til byggebransjen. Cuneco Cuneco – Center for produktivitet i byggeriet. Cuneco er et igangværende prosjekt med en varighet på 4 år for utvikling og implemetering av modellbasert byggeri i hele byggebransjen. http://cuneco.dk/ BIPS er oppbygget med 7 ulike forum som består av referansepersoner fra bransje, fag og organisasjoner. Forumene initierer prosjekter og BIPS administrerer og samordner prosjektene mellom de ulike forumene. Prosjektet for landskapsobjekter er et sådan prosjekt og i samarbeid med de har vi sett likhetstrekkene med situasjonen her til lands: Landskap henger etter i arbeidet med standardisering og bruk av BIM og faller mellom to stoler når det gjelder verktøy som enten er basert på bygg eller på infrastruktur. Prosjektgruppa DBK 2006 (Dansk Byggeklassifikation) beskriver en modell av byggeriet. Landskap har ikke ”vært med” i definisjonen. Landskapsobjektprosjektet har kommet i gang for å inkludere dette i DBK BIPS arbeider for objektklassifisering med en generisk struktur. For eksempel en dør er en dør gjennom hele veien av prosjektet, den kan ha en mengde ulike egenskaper/metadata, men den er en dør. Ikke et nummer eller kode som forandres gjennom prosjektet i ulike detaljeringsnivå. 22 Bakgrunn Danmark Figuren viser hvordan et objekt berikes med stadig større mengde informasjon/egenskaper gjennom de ulike prosessene. Men det er det samme objektet hele veienog det er ulike egenskapssett som er viktig for de ulike fasene BIPS-Landskapsobjektgruppa vil etterfølge denne strukturen i sitt arbeid og er ute etter å etablere et samarbeid med de andre nordiske landene samt England for å utveksle erfaringer og finne en felles plattform å gå videre med. Første ledd i samarbeidet har vært møte mellom BFL og BIPS-Landskap m.fl. i København i juni 2012. Dette utdraget fra Frank Hasling Pedersens prosjektskisse illustrerer veldig godt våre felles utfordringer: Den store forskel: Overflade og objekter Stort set alle andre elementer i en byggeproces kan behandles som enkeltstående geometriske objekter der kan adderes og kombineres i det uendelige – som soldater i geled. Terrænmodellen derimod er unik og kan ikke adderes ligesom objekterne. Den kan derimod bestå af mange forskellige designparametre, med helt vilkårlige geometriske udstrækninger – vidt forskellige og samtidigt indbyrdes afhængige. Terræn overfladen er geometrisk kompleks og ikke rumlig på i samme omfang som Lidt forenklet kan man 23 Bakgrunn Danmark sige, at z værdien er voldsomt underrepræsenteret) Der kræves andre værktøjer at til opbygge, behandle og undersøge overfladen. Med almindeligt anvendte CAD programmer til arkitektarbejde (AutoCAD, Micro station, Sketch up mfl.) kan man ikke bare trække og skubbe i et terræn, som var det en væg, et vindue eller en bunke sand i virkelighedens verden for den sags skyld. Heri ligger den væsentligste udfordring: Den praktiske digitale behandling af overfladen. Kun de færreste og største CAD programmer har disse værktøjer, som ud over stor computerkraft, kræver en erfaring med 3D modellering, som kun de allerfærreste landskabsarkitekter har. 24 Bakgrunn England England Landscape Institute – BIM OpenProject De engelske myndighetene vedtok i 2011 at alle offentlige byggeprosjekter skulle prosjekteres med 3D BIM innen 2016. dette har ført til at den engelske bygg- og anleggsindustrien har fått et stort initiativ til å ruste seg for BIM-prosjektering. Av den grunn har Landscape Intitute satt igang et prosjekt for å kartlegge hva dette vil innebære for landskapsarkitekter i England. Prosjektet har en aktiv prosjektgruppe som bl.a. har utarbeidet en guide for landskapsarkitektkontorer for å kartlegge deres tilnærming til BIM og hvilke steg de bør ta for å komme seg videre i prosessen. Nettsiden gir en enkel innføring et godt innblikk i hva BIM vil innebære for bransjen. http://www.landscapeinstitute.org/knowledge/BIMOpenProject.php BIM Academy BIM Academy ved University of Northumbria tilbyr bl.a. etterutdanning og BIM seminarer med tema innen landskap bl.a. De ser behov for at landskapsarkitekter også kommer på banen og etterspør landskapsarkitekter og deres erfaringer med BIM http://ewtrial.wordpress.com/2012/01/11/landscape-architects-is-building-information-modelling-bim-im proving-your-business/ http://www.bimacademy.ac.uk/ 25 Bakgrunn Sverige Sverige I Sverige har man i dag flere pilotprosjekter som tester ut BIM for Anlegg. Trafikverket, som tilsvarer Jernbaneverket og Statens vegvesen her i Norge, har som mål at 70% av alle egnede prosjekter skal leveres som BIM fra og med 2014. (http://www.byggindustrin.com/trafikverket-byter-papper-mot-bim__9174) Bygghandlingar 90 – del 7 http://www.bygghandlingar90.se/band-7/ Bygghandlingar 90 Bygghandlingar 90 är en publikation med rekommendationer från byggsektorn om hur bygghandlingar ska utformas enhetliga och användbara. Bygghandlingar är det som ligger till grund för produktionen av ett byggprojekt. Bygghandlingar 90 förkortas ofta till BH90 och finns i 8 delar som redovisar hur man skall utforma olika delar av bygghandlingar. BH90 del 7 heter ”Redovisning av anläggning” och senaste utgåvan kom ut 2011. Del 7 innehåller bland annat anvisningar för redovisningar av digitala anläggningsmodeller, landskap och anläggningsinformation. Del 7 innehåller också hur man kan klassificera och koda objekt. I anläggningsprojekt används digital information i olika CAD-program och för att få en effektiv användning behövs regler för kodningen av informationen. Dessa regler behöver vara överenskomna och följas av alla aktörer. Det finns en internationell standard för benämning av CAD-lager som heter SS-ISO 13567. För kodning av objekt hänvisas till nationella regler och praxis. I bygghandlingar 90 del 7 finns förslag på hur kodning av landskapsinformation kan utformas. Det är en tabell som är en vidareutveckling av Vägverkets rithandbok. 35 35 Bygghandlingar 90 Del 7 Redovisning av Anläggning, utgåva 2, Klas Eckerberg, Lars Andersson, Niklas Lindberg, Mica Lindfors 2011 Tekst hentet fra side 23 i rapporten: Gemensamt kodsystem och dess betydelse för utvecklingen av BIM 26 Bakgrunn Sverige i anläggningsbranschen En av forfatterne av rapporten, Klas Eckerberg, er landskapsarkitekt og har utdypet dette for oss med et konkret eksempel: Vi använder nu dessa anvisningar ibland annat det stora projektet ”Förbifart Stockholm” … Här kommer de digitala modellerna att användas som kontraktsunderlag och i produktionen. Här har vi bland annat kodning för ”granskningsstatus”, det vill säga om objekten är godkända för användning eller inte. För att klassificera objekten använder vi ”BSAB byggdelar”, som är den svenska tolkningen av ISO 12006-2 ”Element”. Vi bygger sedan på dessa med byggdelstyper (”Designed Elements”), som utgörs av ”recept” för hur konstruktionen ska se ut. Här kopplar vi till tabellen ”BSAB produktionsresultat”, motsvarande ISO ”work result”. Det fungerar utmärkt! För det vi kallar ”landskapsinformation”, det vill säga existerande byggda och naturgivna objekt använder vi ”Kodlista BH90 för landskapsinformation”, som är en utveckling av tidigare Vägverkets tabell. Klas Eckerberg forteller videre at de har valgt å benytte seg av allerede innarbeidede tabeller og standarder som beskriver bygningsdelstyper framfor å bygge på standardiseringsarbeid som går mot å beskrive objekter utfra hvordan de ser ut: … arbete pågår att se över ISO 12006-2, i syfte att införa en ny tabell baserat på en ”kompositionell” klassificering. Jag var tidigare positiv till detta, eftersom man då utgår inte från funktion eller produktionsresultat utan endast från hur objektet ”ser ut”. En byggnad har väggar, dörrar, tak och så vidare. Efter att ni har provat att kombinera funktion med produktionsresultat genom att använda byggdelstyper känns det inte längre nödvändigt. Det skulle vara förvirrande att införa en ny tabell. I Sverige har BSAB en mycket stark ställning. 27 Bakgrunn DWG DWG DWG DWG er et lukket format fra Autodesk og er native-formatet til programmet AutoCAD. DWG-formatet har fått svært stor utbredelse og i dag kan de fleste programvare eksportere til og importere fra DWG. Formatet er ikke godt egnet for BIM da det bl.a. ikke gir noen enkel mulighet til å knytte egenskapsdata til objektene. Block-er i AutoCAD er sammensatte symboler som representerer et objekt og de kan berikes med attributter (tekststrenger) som bærer egenskaper. For eksempel kan et tresymbol ha en attributt som beskriver treets botaniske navn. Alle typer AutoCAD-objekter kan også få en form for egenskaper tilknyttet seg med hjelp av XDATA som gir hvert objekt en GUID. Den kan i sin tur brukes i en database som kan inneholde valgfrie egenskaper (Klas Eckerberg, 2012, epost). Sistnevnte teknikk benyttes bl.a. i Novapoint Landskap der informasjon om planter legges på objekter (plantefelt og plantesymboler) og leses ut av programmet i plantelister osv. Den store fordelen med DWG-formatet er at det er godt innarbeidet hos alle programvareleverandørene og gir svært god sikkerhet i at eksport av 2D og 3D geometri blir likt ved import i de øvrige programvarene. I alle store tverrfaglige samferdselsoppdrag i Norge i dag forplikter alle prosjekterende å utarbeide et felles notat som beskriver utveksling av digitale 3D filer. Både Statens Vegvesen (SVV) og Jernbaneverket (JBV) stiller nå krav om dette som vedlegg til kontrakt. I disse notatene er det i dag kun DWG som er eneste utvekslingsformat som benyttes mellom de prosjekterende. Dette viser at vi har et stort behov for et åpent utvekslingsformat for samferdsel som også tar med seg egenskapsdata på objekter. «BIM» i samferdsel fokuserer i hovedsak på 3 punkter som bransjen vet fungerer ved å eksporterer til DWG. 1. 3D geometri av objekter, flater, linjer og punker 2. Stikkedata som egne flater, linjer og punkter som har egenskapsdata kun ved lagnavnet som disse stikkedata ligger på. Hvert prosjekt har sitt eget objektkodesystem som skal sikre unike koder for ulike objekter. Denne koden må legges inn på riktige lagnavn for at mottakeren skal kunne gjenkjenne hvilke objektkategorier stikkedata tilhører. 3. Visualisering i Virtualmap. Systematisk navngiving av lag som dermed kan automatisere prosessen i visningsverktøyet Virtualmap. Navngivingen på lag bestemmer materiale og om objektet skal vises i 3D modellen. Krever kontroll og god del resurser med å holde denne vedlike. Denne metoden er en form for lukket BIM (proprietær), mens det vi etterstreber er en åpen BIM (openBIM) og som offentlige oppdragsgivere kan etterspørre. Krav om leveranse i et proprietært filformat er ikke tillatt i offentlige konkurranseutsatte prosjekter. I samferdselsprosjekter er det likevel fortsatt slik at DWG tillates som leveranse siden det er det eneste formatet som fungerer tilfredsstillende for tverrfaglig samordning av prosjektdata. 28 Bakgrunn IFC IFC IFC er en datamodell og et utvekslingsformat som er skapt for å beskrive og utveksle bygg- og anleggsinformasjon. Det er et objektbasert filformat, som betyr at objekter, relasjoner og hierarki i modellen gjenspeiles i IFC-fila. BuildingSMART har innført begrepet buildingSMART DATA MODELL som erstatning for IFC, men i praksis brukes IFC som et begrep på denne datamodellen http://en.wikipedia.org/wiki/Industry_Foundation_Classes Flere av objektklassene i IFC (http://www.buildingsmart-tech.org/ifc/IFC2x3/TC1/html/index.htm) og deres beskrivelser har likheter med landskapsobjekter. Se under Objektklasser for eksempler på dette. Mange av objektene vi modellerer utomhus, ligner både i form og funksjon på innendørs objekter. Gulv, vegger, trapper, møblering, belysning er eksempler. IFC som format har frem til i dag vært begrenset til å ta med seg bebyggelse og kun en meter utenfor byggets vegger. Alle fag som har modeller utenfor bygget er ikke tatt med i IFC-standarden. Statsbygg satte krav til alle nye prosjekter fra 2010 skulle leveres på formatet IFC. I etterkant har Forsvarsbygg, Helseforetakene, Undervisningsbygg med flere satt som krav at deres byggeprosjekter skal være 3D BIM modeller med utveksling på åpent format – IFC. IFC er det åpne formatet som i dag er anerkjent internasjonalt som utvekslingsformat for bygg. Formatet er innarbeidet i de fleste programvarene som benyttes på byggsektoren. Det er anerkjent og innarbeidet i bransjen at man nå må forholde seg til IFC som åpent format når man jobber med byggeprosjekter. Vi ser at flere og flere aktører i byggenæringen har eller får nye programvare som baserer seg på formatet IFC. Tanken er at alle byggeprosjekter har en felles totalmodell i formatet IFC. Ulike aktører som ønsker å benytte seg av informasjon fra denne totalmodellen må bruke programvare som forholder seg til IFC. Statsbygg bruker idag flere type programvare som alle jobber med IFC formatet. Kapittel D.2 Analyser som brukes av Statsbygg (informativt) i Statsbyggs BIM-manual 1.2 beskrives det hvilke type analyser som Statsbygg ønsker gjennomføre på alle sine byggeprosjekter. Dette er kun mulig når alle objektet i en 3D modell også inneholder egenskapsdata og ikke bare geometri. BuildingSMART som forvalter formatet IFC har hatt flere ulike delprosjekter hvor man har sett på om fag utenfor byggets vegger også kan standardiseres i henhold til IFC. Et av disse prosjektene er dokumenter i en australsk rapport som bygger opp under vårt arbeid. 29 Bakgrunn CityGML CityGML CityGML er to ting: En geografisk (geospatial) informasjonsmodell Et utvekslingsformat som bygger på GML3 GML står for Geography Markup Language og er en standard for utveksling av geodata på XML format. Standarden er under utvikling av ISO/TC 211. CityGML er et åpent utvekslingsformat og informasjonsmodell designet for å utveksle virtuelle 3-dimensjonale by- og landskapsmodeller. Modellens innhold, både med tanke på semantikk, geometri, topologi og utseende er ivaretatt i standarden. Et interessant aspekt ved standarden er inndelingen i Level of Detail (detaljeringsnivåer) fra LOD0-LOD4. Dette legger til rette for bedre tilpasning av datasettet til ulik bruk, for eksempel i utredninger og prosjektering, og videre bruk av data. Hierarkiet mellom tematiske klasser, sammenstillinger, relasjoner mellom objekter og romlige egenskaper er også inkludert i standarden. CityGML er publisert som en åpen datamodell og et xml-basert format for lagring og utveksling av virtuelle bymodeller. Standarden er implementert som et skjema for GML3, den utbyggbare standarden for romlig datautveksling utstedt av OGC og ISO TC211. CityGML er ment å bli en åpen standard, og kan derfor benyttes gratis. fritt etter http://www.citygml.org/index.php?id=1523 30 Bakgrunn LOD LOD LOD – Level of Detail «CityGML tar ikke bare hånd om den grafiske representasjonen av urbane modeller, men tar særlig vare på representasjonen av semantiske (språklige / tematiske) egenskaper, taksonomier (klassifikasjoner) og ansamlinger/klynger av digitale terrengmodeller. Også arealer, vegetasjon, vannforekomster, transportfasiliteter og møblering i by. Den underliggende modellen skiller mellom fem ulike detaljnivå (Level Of Detail, LOD). Objekter blir mer detaljert med økende LOD, både mhp geometri og tematisk oppdeling. CityGML kan, men må ikke, inneholde flere representasjoner av samme objekter i forskjellige LOD samtidig.» Kilde: http://www.citygml.org/index.php?id=1532 LOD -nivåene av definerer en detaljeringsgrad på objektene i forhold til hvilken fase man jobber med. Vi har forsøkt å definere vår egen tolkning av LOD tilpasset norske forhold: Forslag til tolkning av LOD tilpasset norske forhold 31 Bakgrunn LOD PDF: LOD for landskap Kilde: UMB-ILP Definisjon av LOD LOD – Level of development LOD har også blitt brukt på en annen måte i BIM-sammenheng, da i betydningen Level of Development der det beskriver 5 nivåer fra den konseptuelle/skissefasen til ferdig bygget: 32 Bakgrunn CityGML for landskap CityGML for landskap Beskrivelsen av CityGML skaper forventninger om at dette kan være en relevant informasjonsmodell for prosjektering, bygging og drift av landskapsobjekter. Som SIG3D selv beskriver som bakgrunnen for initativet med å utvikle en rikere informasjonsmodell for utveksling av urbane modeller: (OBS google-oversetting): «I de senere år har de fleste virtuelle 3D bymodeller blitt realisert som rent grafiske eller geometrisk modeller, neglisjere den semantiske og topologisk aspekter. Dermed kan disse modellene nesten bare brukes til visualisering formål, men ikke for tematiske søk, analyse oppgaver eller romlig data mining. Siden den begrensede reusability av modeller hemmer bredere bruk av 3D byens modeller, hadde en mer generellmodellering tilnærming for å bli tatt for å tilfredsstille informasjonsbehovet til de ulike bruksområder.» Objekter One current limitation with CityGML, however, is that objects created in this format are not compatible with standard GIS formats. “It would require someone [sic] like ESRI to make templates for using CityGML, and that will take a lot of effort,” notes Cote. ESRI and other GIS vendors would have to figure out how to turn CityGML data into a geodatabase. Cote thinks this would be a complicated geodatabase model and could take ESRI as long as a year to complete (Cote 2007). Kilde: LATIS: Integrating BIM Technology Into Landscape Architecture 33 Bakgrunn LandXML LandXML LandXML er et åpent, internasjonalt format utviklet for utveksling av anlegg, oppmåling, samferdsel- og infrastrukturdata, og særlig veg. Schema for landxml 1.2 (siste) inneholder ustrakte standarder for definisjon av veger, men ingen spesifikke objekttyper som kan brukes direkte for landskap. Det er mulig at enkelte elementer (som Surface og GradeSurface) kan brukes videre, men det er i liten grad knyttet relevante egenskaper til objektene. LandXML er særlig tatt i bruk at CAD-baserte verktøy. Standarden inneholder på samme måte som IFC et nivå av tilpassede objekter. Property-, DocFileRefeller nestedFeature-elementer kan knyttes til de ulike elementene for å berike modellen med informasjon. Skrive- og lesemuligheter for slike Property-sets er avhengig av programvaren som skal skape og tolke filene, og hvor streng den er med å vise egenskaper som ikke er definert i standarden. (Dette er for øvrig også en utfordring med «property sets» i IFC.) LandXML-standarden er delt opp i Elements, Complex types og Simple types. En av fordelene med landxml som utvekslingsformat for landskapsarkitekter, er at det importeres direkte av flere maskinstyringsverktøy. Kilde: http://www.landxml.org/schema/LandXML-1.2/documentation/LandXML-1.2Doc.html LANDxml er en åpen standard, en xml-dialekt til bruk innen samferdsel, infrastruktur og landmåling. ( http://en.wikipedia.org/wiki/List_of_XML_markup_languages) LandXML er allerede i dag et sentralt utvekslingsformat for stikningsdata, og de mest sentrale dakbaserte prosjekteringsverktøyene innen samferdsel og infrastruktur kan eksportere og importere data i dette formatet. Formatet er trukket frem i HB 138 Modellgrunnlag fra Statens vegvesen / VD som det sentrale utvekslingsformatet for veg. BuildingSMART vurderer å se om de skal støtte arbeidet med å videreutvikle formatet slik at man kan komme frem til et åpent utvekslingsformat også for samferdsel. Mye arbeid gjenstår hvis det er tilfelle. http://www.buildingsmart.no/events/nordic-openinfra-landxml-workshop Fordel med formatet er at det er akseptert internasjonalt og innarbeidet hos de fleste programvareleverandørene. Formatet har ennå ikke dataordbok for alle fag som er tilknyttet et samferdselsoppdrag. Utfordringene med formatet er at det ikke kan ta med seg 3D geometri på en god måte. 3D solider går ikke å eksportere. Det er flere «dialekter» av formatet som lager noen utfordriner. Det er begrenset hva man kan få med av informasjon på objektene. Formatet er godt innarbeidet i ulike programmer som benyttes for utstikking og maskinstyring på byggeplass. Formatet slik det er i dag egner seg lite som utvekslingsformat mellom ulke fag i prosjekteringsprosessen. Håndbok 138 fra SVV stiller krav til at vi skal levere på åpne formater og vi skal levere originalfilene fra de proprietære fagverktøyene. Dermed sikrer de seg å få tilgang til BIM modellene da det ikke fins noe slik felles åpent format. SVV er statlig og kan ikke kreve leveranse på lukkede formater. I HB 138 brukes 34 Bakgrunn LandXML LandXML som et åpent format som alle skal levere på selv om SVV vet at dette formatet ikke egner seg for alle fag, se info under punkt Landxml. Green Building XML The Green Building XML schema, referred to as «gbXML», was developed to facilitate the transfer of building information stored in CAD building information models, enabling integrated interoperability between building design models and a wide variety of engineering analysis tools and models available today. Today, gbXML has the industry support and wide adoption by the leading CAD vendors, Autodesk, Graphisoft, and Bentley. Kilde: http://www.gbxml.org/ 35 Bakgrunn KML KML KML (Keyhole Markup Language) er en OGC-standard for visning av data på kart. KML distribueres ofte som KMZ, som er en zippet versjon av dataene. KMZ-filen kan inneholde punkter, linjer, flater, COLLADA-3dmodeller, bilder og ikoner, og informasjon på nettverkt. http://en.wikipedia.org/wiki/Keyhole_Markup_Language KML er interessant for LIM pga at det er et åpent, internasjonalt format, og det gjenkjennes av en lang rekke åpent tilgjengelig programvare. Google Earth er best kjent av disse. Utveksling av data som KML gjør dermed prosjekterte data tilgjengelig for flere. 36 Bakgrunn Omniclass Omniclass Omniclass Table 21 Omniclass er totalt en samling av 15 ulike tabeller som til sammen er en klassifisering som favner om hele det bygde miljø. Tabellene bygger på ISO 12006-2, Section 4. Tabellene er som følger: Table 11 – Construction Entities by Function Table 12 – Construction Entities by Form Table 13 – Spaces by Function Table 14 – Spaces by Form Table 21 – Elements (includes Designed Elements) Table 22 – Work Results Table 23 – Products Table 31 – Phases Table 32 – Services Table 33 – Disciplines Table 34 – Organizational Roles Table 35 – Tools Table 36 – Information Table 41 – Materials Table 49 – Properties Omniclass Table 21 kan forenklet sett kalles den internasjonale bygningsdelstabellen (USA, Canada). Den har også en struktur og en oppdeling samt detaljeringsnivå som minner om Bygningsdelstabellen. Den presenterer Elements i tabellform (Table 21 Elements) og definerer de som Elements og Designed Element. An Element is a major component, assembly, or “construction entity part which, in itself or in combination with other parts, fulfills a predominating function of the construction entity” (ISO 12006-2). A Designed Element is an “Element for which the work result(s) have been defined.” (ISO 12006-2). Elementene er definert med et nummer på en- til fire- nivåer, hvert nivå med 2 sifre, for eksempel 21-07 20 80 Landscaping. Det fjerde nivå er underliggende hovedtitlene, for eksempel 21-07 20 80 30 Plants Tabellen under viser hovedtitlene opp til 3. nivå for noen av “landskaps”-elementene OmniClass 2011 Number OmniClass 2011 Title 21-07 00 00 Sitework 21-07 10 00 Site Preparation 37 Bakgrunn Omniclass 21-07 10 10 Site Clearing 21-07 10 20 Site Elements Demolition 21-07 10 30 Site Element Relocations 21-07 10 50 Site Remediation 21-07 10 70 Site Earthwork 21-07 20 00 Site Improvements 21-07 20 10 Roadways 21-07 20 20 Parking Lots 21-07 20 30 Pedestrian Plazas and Walkways 21-07 20 40 Airfields 21-07 20 50 Athletic, Recreational, and Playfield Areas 21-07 20 60 Site Development 21-07 20 80 Landscaping 21-07 30 00 Liquid and Gas Site Utilities 21-07 30 10 Water Utilities 21-07 30 30 Storm Drainage Utilities 21-07 40 50 Site Lighting Utfyllende tabell på 4. nivå for noen av “landskaps”-elementene OmniClass 2011 Number 21-07 00 00 21-07 10 00 21-07 10 10 21-07 10 10 10 21-07 10 10 30 … 21-07 10 70 21-07 10 70 10 21-07 10 70 20 21-07 10 70 30 21-07 10 70 35 21-07 10 70 40 21-07 10 70 45 21-07 10 70 50 21-07 10 70 55 21-07 10 70 60 … 21-07 20 10 21-07 20 10 10 21-07 20 10 20 21-07 20 10 40 21-07 20 10 70 21-07 20 10 80 21-07 20 20 21-07 20 20 10 21-07 20 20 20 OmniClass 2011 Title Sitework Site Preparation Site Clearing Clearing and Grubbing Tree and Shrub Removal and Trimming … Site Earthwork Grading Excavation and Fill Embankments Erosion and Sedimentation Controls Soil Stabilization Rock Stabilization Soil Reinforcement Slope Protection Gabions … Roadways Roadway Pavement Roadway Curbs and Gutters Roadway Appurtenances Roadway Lighting Vehicle Fare Collection Parking Lots Parking Lot Pavement Parking Lot Curbs and Gutters 38 Bakgrunn Omniclass 21-07 20 20 40 21-07 20 20 70 21-07 20 20 80 21-07 20 30 21-07 20 30 10 21-07 20 30 20 21-07 20 30 30 21-07 20 30 40 21-07 20 30 70 21-07 20 30 80 21-07 20 40 21-07 20 40 10 21-07 20 40 20 21-07 20 40 40 21-07 20 40 70 21-07 20 40 80 21-07 20 50 21-07 20 50 10 21-07 20 50 30 21-07 20 50 50 21-07 20 60 21-07 20 60 10 21-07 20 60 20 21-07 20 60 25 21-07 20 60 30 21-07 20 60 35 21-07 20 60 40 21-07 20 60 45 21-07 20 60 50 21-07 20 60 60 21-07 20 60 70 21-07 20 60 80 21-07 20 60 85 21-07 20 80 21-07 20 80 10 21-07 20 80 20 21-07 20 80 30 21-07 20 80 50 21-07 20 80 70 21-07 20 80 80 21-07 30 00 21-07 30 10 21-07 30 10 10 21-07 30 10 30 21-07 30 10 50 … Parking Lot Appurtenances Parking Lot Lighting Exterior Parking Control Equipment Pedestrian Plazas and Walkways Pedestrian Pavement Pedestrian Pavement Curbs and Gutters Exterior Steps and Ramps Pedestrian Pavement Appurtenances Plaza and Walkway Lighting Exterior Pedestrian Control Equipment Airfields Aviation Pavement Aviation Pavement Curbs and Gutters Aviation Pavement Appurtenances Airfield Lighting Airfield Signaling and Control Equipment Athletic, Recreational, and Playfield Areas Athletic Areas Recreational Areas Playfield Areas Site Development Exterior Fountains Fences and Gates Site Furnishings Exterior Signage Flagpoles Covers and Shelters Exterior Gas Lighting Site Equipment Retaining Walls Site Bridges Site Screening Devices Site Specialties Landscaping Planting Irrigation Turf and Grasses Plants Planting Accessories Landscape Lighting Landscaping Activities Liquid and Gas Site Utilities Water Utilities Site Domestic Water Distribution Site Fire Protection Water Distribution Site Irrigation Water Distribution … 39 Bakgrunn Omniclass 21-07 30 30 21-07 30 30 10 21-07 30 30 20 21-07 30 30 30 21-07 30 30 40 21-07 30 30 50 … 21-07 40 50 21-07 40 50 10 21-07 40 50 20 21-07 40 50 50 21-07 40 50 90 … 21-07 90 10 21-07 90 10 10 21-07 90 10 20 21-07 90 10 40 21-07 90 10 90 Storm Drainage Utilities Storm Drainage Utility Connection Storm Drainage Piping Culverts Site Storm Water Drains Storm Drainage Pumps … Site Lighting Area Lighting Flood Lighting Building Illumination Exterior Lighting Supplementary Components … Tunnels Vehicular Tunnels Pedestrian Tunnels Service Tunnels Tunnel Construction Related Activities 40 Objektklassifisering Objektklassifisering Objektklassifisering Objektklassifisering Objektklassifisering er kjernen i all modellbasert prosjektering. Man er avhengig av et standardisert objektklassifiseringssystem, slik at informasjon på objekter lages og tolkes på samme måte. 41 Objektklassifisering Krav til objektklasser Krav til objektklasser Det må stilles noen omforente krav til objektbiblioteket, både med tanke på innhold og struktur. Identitet: Navn på objektklasse Hver objektklasse gis unike navn, og klassene må defineres entydig. Objektklassen skal beskrives med en presiserende utfyllende tekst, som skiller objektklasser fra hverandre. Beskrivende tekst hentes gjerne fra eksisterende standarder. Kun arbeidsgruppa kan definere navn på objektklasser. To objektklasser kan ikke ha samme navn. Utveksling: Åpne formater Det er et absolutt krav og en forutsetning at objektene utveksles (import/eksport) på åpne, internasjonale formater, som kan leses og skrives av relevante prosjekteringsverktøy. Om objektene i tillegg utveksles på proprietære formater er opp til produsenten. Databasen med landskapsinformasjonsobjekter må legges til rette for nedlasting av ulike filformater og –versjoner, feks på samme måte som http://www.nationalbimlibrary.com/. Eksempler på åpne internasjonale formater: IFC CityGML LandXML GBxml SOSI? Industry foundation classes Format for bymodeller basert på Geographic Markup Language Format for infrastruktur og samferdsel basert på Extensive Markup Language Green Building XML Samordnet opplegg for stedfestet informasjon GIS BIM-LE (LandskapsElementer) skiller seg fra BE (BygningsElementer) ved at alle objektene kan få nytt liv i en GIS-informasjonsflyt. Alle prosjekterte objekter bør inneholde informasjon som er relevant for videre GIS-arbeidsflyt. Det vil si geografisk informasjon, linjer, punkter og flater som definerer plassering og utstrekning. Dette er informasjon med enklere detaljnivå / ekstrakt av prosjekterte data. Se beskrivelsen av LOD for mer uttømmende informasjon. Tilpasning/relasjoner til andre standarder Samtlige landskapsobjekter må kunne knyttes til de eksisterende standardene som beskriver egenskaper og prosesser for bygging/anlegg av landskapselementer. Relevante standarder er: SOSI Eget felt for å knytte riktig SOSI-kode til objektet NVDB/Prosesskoden 42 Objektklassifisering Krav til objektklasser Eget felt for å knytte objektet til riktig prosess i Prosesskoden og NVDB NS 3451 Eget felt for å knytte objektet til riktig kode i bygningsdelstabellen NS 44xx Egne felt som refererer til relevante/riktige poster i standardene for planteskolevarer. Det bør også tilrettelegges for fritekstfelter, slik at feks informasjon om lokale standarder og entreprisedata kan legges inn. NS for objektklassifisering Objektklassene i standarden må være i tråd med den kommende Norsk Standard for BIM Objektbibliotek. (http://www.standard.no/en/Sectors/Bygg-og-anlegg/Digital-byggeprosess/BIM-Objektbibliotek/) Dette kan legge føringer for fremdrift, informasjon og struktur på objekter, publisering og vedlikehold av en felles objektbase. Anonyme objekter Alle objekter skal kunne beskrives anonymt både geometrisk og semantisk. Dette kan løses med anonyme versjoner av objekter, eller objekter som anonymiseres ved eksport. Analyse Objektene må inneholde relevante data om kostnad, tid, utseende, vekt, relasjoner og andre egenskaper, slik at det kan kjøres 3-4-5-6D analyser på prosjekterte data. Kvalitet Kvaliteten på objektene bør sikres av en egen arbeidsgruppe. Aspekter som sjekkes er objektklasse, geometri, eksport/import i prosjekteringsverktøy, relasjoner til riktige standarder etc.. Deling av data og informasjon Databasen av landskapsobjekter er et produkt som eies av Statsbygg, NLA, NAML, SVV… (?). Bruk av objekter fra databasen skal være gratis, og det kan ikke forventes vederlag for å bidra med objekter til databasen. 43 Objektklassifisering Objektklasser Objektklasser 44 Objektklassifisering Objektbibliotek Objektbibliotek Det bør etableres et samlet , webbasert objektbibliotek for landskapsobjekter, feks etter mal fra det engelske http://www.nationalbimlibrary.com/ Object Types » Hard Landscaping » Under objekttyper Hard Landscaping ligger en User Guide som bekriver hvilken navngiving og egenskaper som bør ligge til disse objekten. Navngiving og egenskaper bør knyttes opp mot arbeid fra Starndard Norge og tilpasses dette arbeidet. Eksempelobjekter viser at det i dag er fult mulig å lage enge landskapsobjekter for harde dekker. Hvis man benytter samme objektfunksjon også for Soft Landscaping, noe som også er gjort på prosjekter i Norge, vil man kunne lage et komplett objektbibliotek også for «myke dekker». Et annet objektbibliotek som man kan skjele til er BIMobject.com som har sitt utspring fra Sverige og inneholder ulike BIM-objekter fra ulike leverandører av utstyr, møbler osv. Her er også en meny som viser objekt-typer for landskap. 45 Vegen videre Vegen videre Vegen videre Vegen videre Dette forprosjektet bør følges opp av et hovedprosjekt som går dypere inn i de viktigste aspektene Komplett oversikt over objektklasser Oversikten over objektklasser må kompletteres, og modelleres i et egnet format. UML er en mulighet. Modelleringen bør også være i tråd med standarder satt av internasjonale aktører, se feks ISO TC211, OGC og OMG. Objektbibliotek Det bør bestrebes å lage et nasjonalt, universelt og standardisert objektbibliotek som kan brukes som ressurs for alle landskapsarkitekter. Dette kan være et kommersielt produkt, men vår anbefaling er at det etableres som en brukerstyrt, åpen og gratis tjeneste. Internasjonale aktører Arbeidet med objektklassene må synkroniseres mot internasjonale aktører. Det er særlig aktuelt å samarbeide med de nordiske land og England. Entreprenører, oppdragsgivere og anleggsgartnere Anleggsgartnere og andre utførende må på banen for å ta i bruk prosjekterte data. Entreprenørene vil få en hel mengde nye data å forholde seg til (på nye måter), det må lages systemer for å strukturere og håndtere dette. Oppdragsgivere må informeres og læres opp i hva som kan bestilles, og hva man kan forvente av et landskaps-bim-prosjekt. Dette må gjøres i tett samarbeid med landskapsarkitekten, slik at misforståelser unngås. I en oppstartsfase kan det godt hende at ikke alle typer prosjekter kan være med på denne utviklingen. Forvaltning av data Videre bruk av data i offentlig forvaltning og som grunnlag for FDVU må standardiseres, og relevante data til ulike formål må kunne ekstraheres fra objektene. Dette gjelder både egenskaper og geometri. Aktørene som skal bruke dataene må derfor på banen for å definere hvilke data som er nødvendig til hva. 46 Vegen videre Første skritt på veien - IFC Første skritt på veien - IFC 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 47 Vegen videre Første skritt på veien - IFC 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 48 Vegen videre Første skritt på veien - IFC 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 49 Vegen videre Første skritt på veien - IFC 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 50 Vegen videre IFC for LARK - BIM Manual 1.x Statsbygg IFC for LARK - BIM Manual 1.x Statsbygg I første omgang et forslag på hvordan BIM manual 1.x fra Statsbygg kan innarbeide krav til LARK med allerede eksisterende IFC standarder. Forslaget baserer se på å se hvilke objekter og egenskaper til objekter som det stilles krav til for ARK og ta disse erfaringene med og sammenligne disse med krav til LARK. Arbeidet er kun ment som en start og er ikke komplett. C.2 Landskapsarkitektfaglig modellering (LARK) Landskapsarkitektmodellen inneholder alle andre tekniske fag utomhus. Landskapsarkitekten er designer og premissgiver for alt utenfor bygget, men også utomhusarealer på bygg som overdekning av kjeller og takhager er Landskapsarkitektens ansvarsområder. Landskapsarkitektmodellen er kompleks i den forstand at de involverte objektene ofte «eies» av forskjellige roller gjennom prosessen. Landskap modellerer konstruksjoner som senere RIB tar over; strøm, lys og lysfundamenter som RIE tar over; sluk, renner, vanningsanlegg som RIV tar over eller kobler seg til; veg og vegobjekter som VEG tar over, terrengbehandling som linkes opp mot RIG. 70 Rigg og drift 71 Terrengbehandling 72 Konstruksjoner 73 Utendørs VVS 74 Utendørs el.kraft 75 Utendørs tele og automatisering 76 Veier og plasser 77 Park og hage 78 Vann og avløp 79 Annet Utendørs Skisseprosjekt – standard modelleringskrav Tema Type 51 Vegen videre IFC for LARK - CityGML IFC for LARK - CityGML Flere og flere rapporter henviser til forholdet mellom det bygde miljøet IFC og bymodeller – CityGML. Denne oversikten viser dataflyt mellom IFC – CityGML og CityGML – IFC. http://www.citygmlwiki.org/index.php/IFCExplorer_CityGML_-_IFC_Converter 52 Vegen videre IFC for LARK - CityGML http://www.ifcwiki.org/index.php/IfcExplorer_CityGML_Export 53 Vegen videre IFC for LARK - Eksempel brukt i Revit IFC for LARK - Eksempel brukt i Revit Denne oversikten viser hvordan LARK kan benytte seg av eksisterende programvare og tilpasse den så godt som mulig til LARK sin måte å jobbe med 3D objektbasert modellering. Undertegnede har gjennomført ulike landskapsprosjekter i tidsrommet 2005 til i dag 2012 basert på Autodesk Revit som 3D modelleringsverktøy for prosjektering, tegningsproduksjon, mengdekontroll, kostnadsoverslag, utsettingsdata osv. Denne oversikten prøver å ta de erfaringer man har fra gjennomførte prosjekter og de LIM objektene som vi nå har kommet frem til i denne rapporten og sette dette i system. Denne oversikten viser at vi kan klare å levere mye Landskap mot IFC hvis vi nå i første omgang er villig til å forenkle LIM objektene og ser sammenhenger og muligheter i eksisterende programvare som er mer tilpasset for andre fagdisipliner. På lengre sikt bør LIM objekter få sin egen IFC definisjon. Der det i denne oversikten kommer IfcBuildingElementProxy bør man kunne komme frem til egne IFC definisjoner i Norge som vi kan benytte her frem til vi får på plass en internasjonal IFC standard for Landskap. Ved praktisk bruk av denne oversikten vil det komme frem mange viktige punkter som igjen er bra å ta med inn i et standardiseringsarbeid med tanke på IFC for LARK. Denne oversikten er kun ment som et første utkast basert på egne erfaringer og ønskes supplert av andre med tilsvarende erfaringer. Oversikt over funksjoner i Revit og hvordan de kan tolkes og brukes av LARK for 3D objektbasert modellering. De viktigste arealer/flatene som LARK bør bruke aktivt i Revit er enten <Toposurface> eller <Floor> hvor <Floor> gir de største fordelene med tanke på objektbasert modellering. <Floor> IfcSlab <Toposurface> IfcBuildingElementProxy 54 Vegen videre IFC for LARK - Eksempel brukt i Revit <Floor> i Revit gir store muligheter for LARK. Alle lag som man bruker på dekker, veier, plasser og vegetasjonsfelt kan legges inn i <Floor>. Dermed er det enkelt å ha kontroll på mengder, tykkelser, detaljtegninger osv.. når totaltykkelsen på alle <Floor> til en hver tid er korrekt. <Floor> har mulighet til å sette høyde på alle ytterkanter eller hjørner men også legge inn punkthøyder eller knekklinjer manuelt. Når man benytter <Floor> for Landskap bør man ikke benytte <Levels>. Man bør oppretter et nedre nivå som man definerer som Havnivå +/- 0.00. Alle dekker modelleres på dette nivået og «løftes» så opp til riktig høyde over havet. Alle justeringer, og høydepåskrift vil da hele tiden gi høyde over havet (kotehøyde) noe som er viktig når man jobber med landskapsarkitektur. Høydejustering på <Floor> kan gjøres på flere ulike måter. På detaljnivå bør man kun la <Floor> ligge på Havnivå +/- 0,00 og man løfter flatene ved å bruke funksjonen <Modify Floor> / <Modify Sub Elements>. Denne måten å sette høyde på <Floor> gir mulighet for å lage dobbelkrumme flater der det er mulig. Ulempen med å jobbe med <Toposurface> er at det kun er en flate uten tykkelse. Hver gang man gjør en endring på flaten bruker den mye datakraft på å generere flaten på nytt. Jo mer kompleks flaten er jo lenger tid tar dette <Roof> benyttes ikke av to viktige årsaker. Den ene er at <Roof> alltid forholder seg med fast høyde på bunnen. Hvis man endrer tykkelsen på <Roof> forblir bunnen på samme nivå men toppen endres. For LARK er dette problematisk da høyde på topp er viktigst for å ha kontroll på fall. Den andre årsaken til at <Roof> ikke benyttes er at landskapsobjekter ikke kan <Hostes> (objektet forholder seg høydemessig) til denne flaten. <Building Pad> er også vanskelig å benytte for Landskap. Den påvirker <Toposurface> og dermed bruker mye datakraft ved små endringer. Den største begrensningen ligger i justering av høyde og skjæringsvinkel mot terreng. <Building Pad> skjærer kun vinkelrett i terrenget. Enten vertikal skjæring eller vertikal fylling. Hvis man ønsker å ha fall på <Building Pad> kan man kun benytte <Slope Arrow>. Både på <Floor> og <Building Pad> har man begrensning til kun å bruke en <Slope Arrow> per flate. Hvis man kunne benyttet flere <Slope Arrow> på lik linje med <Roof> ville det kanskje gitt flere muligheter for å bruke både <Floor> og <Building Pad>. Kantstein som avslutning på <Floor> benyttes <Slab Edge> eller <Model In-Place> <Slab Edge> IfcBuildingElementProxy I detaljnivå benyttes <Component>/ <Model In-Place>. Under valg av <Family Category> and <Parameters> velges <Walls>. Ved valg av <Forms> velges <Sweep>. Ved valg av <Sweep> velges <Pick Path> og <Pick 3D Edges>. Grunnen til at man velger dette er fordi <Slab Edge> klarer ikke å generere 3D volum hvis kanten er del av dobbeltkrum flate og buet. Andre ganger klarer ikke funksjonen å koble volumer sammen. For at man skal være helt sikker på å få med seg riktig volum av kantstein hele veien bør man bruke denne funksjonen. Valg av <Walls> er for at man da kan ta ut mengder på lengden 55 Vegen videre IFC for LARK - Eksempel brukt i Revit av kantstein. Det beste var om <Slab Edge> kunne klare å lage volum også på dobbeltkrumme kanter samtidig som man kunne fått ut antall løpemeter i <Schedules>. Det fins ingen gode løsninger for kantstein på <Toposurface> direkte i Revit. Da må man over på SiteWorks og LandCAD fra Eagle Point. Distribuert i Norden gjennom Cad-Q. Alle landskapsobjekter (Component) som benyttes utomhus må kunne <Hostes>til både <Toposurface> og <Floor>. Disse objektene kan enten alltid forholde seg horisontalt eller følge vinkel på overflaten. Fordelen med disse objektene er at de enten kan linkes til en flate eller man kan overstyre og låse objektene til en faste høyder over havet. De objekt <Family´ene> som gjør dette i Revit er: <Furniture> IfcFurniture <Lighting Fixtures> IfcLightFixtureType <Parking> IfcBuildingElementProxy <Planting> IfcBuildingElementProxy <Plumbing Fixtures> IfcFlowTerminal <Site> IfcSite <Structural foundation> IfcFooting I LIM prosjektet har vi skissert opp en liste med objekter vi mener bør være en del av LARK sine objekter. Hvis jeg prøver å sette disse objektene inn i system i forhold til Components> nevnt i teksten over vil det bli som følger: <Floor>: (LARK) (Eksempel) Terreng (Soft landscape) Vegetasjon (Vegetasjons oppbygging avhengig av Vegetasjon og grunnforhold. Ulik oppbygging om det er på dekker, jord, løsmasser, sprengstein, fjell.) Trær 56 Vegen videre IFC for LARK - Eksempel brukt i Revit Busker Stauder Blomster Gress Plastring Løsmasser Plasser (Hard landscape) (Eksempler se NBS National BIM Library, UK, Objedt types, Hard Landscaping) Veier (Roads) <Furniture>: (LARK) Utemøbler Bord Stoler Benker Avfall Sykkel Pullert Plantekasse/urner Stammevern Treomramming – (<Nested Families>) Inn i en <Generic Model floor based> for å lage hull i gulvet for utsparing for trestamme og rotvolum. ……. Lek og idrett Lekeapparater Sklie Huske 57 Vegen videre IFC for LARK - Eksempel brukt i Revit Klatre Hoppe Sandkasse Tårn Mål Ballspill Fotball Håndball Nett Badminton Tennis Volleyball Kurv Basket Skilt Innfelt – (<Nested Families>) Inn i en <Generic Model face based> for å kunne linkes til en flate. Flaten vil kunne variere på vegg, inn i granittelementer osv. Må kunne forholde seg til flere type objekter Veggmontert – (<Nested Families>) Inn i en <Generic Model face based> for å kunne linkes til en flate. I hovedsak vil denne flaten kunne være en vegg men noen ganger kan den også være lurt å kunne linkes til andre objekter som ikke er vegg og derfor <face based>. Puller Mast Henge – Forholde seg til høyde over terreng og derfor ok slik den er <Ligting Fixtures> (RIE/EL) Utebelysning Nedfelt – (Nested Families) Inn i en Generic Model floor based for å lage hull i gulvet der lysarmaturen kommer. Innfelt – (Nested Families) Inn i en Generic Model face based for å kunne linkes til en flate. Flaten vil kunne variere fra opptrinn i trapp, på vegg, inn i granittelementer osv. Må kunne forholde seg til flere type objekter Veggmontert – (Nested Families) Inn i en Generic Model face based for å kunne linkes til en flate. I hovedsak vil denne flaten kunne være en vegg men noen ganger kan den også være lurt å kunne linkes til andre objekter som ikke er vegg og derfor face based. Puller Mast Henge – Forholde seg til høyde over terreng og derfor ok slik den er <Parking> (LARK) (All oppmerking på dekker) Oppmerking Vei 58 Vegen videre IFC for LARK - Eksempel brukt i Revit Parkering Symbol (HC) Tekst Lek og idrett Taktil <Planting> (LARK) Vegetasjon Trær Løv Bar Frukt Busker Busker Roser Slyngplanter Hekkplanter Stauder Bunndekke (Blomster) – Inngår som del av beskrivelse av overflate på <Floor>. Evt eget volum som ligger over Floor og definerer ulike områder med plantemix. (Gress) – Inngår som del av beskrivelse av overflate på <Floor> <Plumbing Fixtures> (VA) VA (Vann og Avløp) Sluk – (Nested Families) Inn i en Generic Model floor based for å lage hull i gulvet der sluk kommer. Rist – (Nested Families) Inn i en Generic Model floor based for å lage hull i gulvet der Rist kommer. Renne – (Nested Families) Inn i en Generic Model floor basedfor å lage hull i gulvet der Renne kommer. Slisserenne Nedfelt renne Kumlokk – (Nested Families) Inn i en Generic Model floor based for å lage hull i gulvet der Kumlokket kommer. Vannpost Brannhydrant Frittstående konstruksjoner som LARK modellerer utomhus er identiske med de objektene arkitekten har til å modellere i bygg. De objektene som nå nevnes er tilnærmet identiske for ARK og LARK. Derfor kan disse brukes uten noen store tilpasninger for Landskap når det gjelder klassifisering i IFC. Formgiving, egenskaper og relasjoner på objektene må endres noe for å kunne brukes godt også ute. <Wall> IfcWall 59 Vegen videre IFC for LARK - Eksempel brukt i Revit <Structural Foundation> IfcFooting <Stair> IfcStair <Ramp> IfcRamp <Railing> IfcRailing <Floor> IfcSlab <Wall> (LARK) Støttemurer (RIB/RIG) Plasstøpt Prefab Gabion Murer Plasstøpt Prefab Gabion Murt Stablet Spunt Vegger Vegg i bygg Leevegg (evt <Railing>) Ballvegg Støyskjerm (evt <Railing>) <Structural Foundation> (LARK) Fundament for Utemøbler (Se relevante objekter definert under <Furniture>) Fundament for Belysning (Se relevante objekter definert under <Ligting Fixtures>) Fundament for Vegetasjon (Rotsone for trær?) (Se relevante objekter definert under <Planting>) Fundament for Konstruksjon og bygg (Se relevante objekter definert under <Wall>, <Stair>, <Ramp>, <Railing ) <Stair> (LARK) Trapper Terrengtrapp Eseltrapp Frittstående trapp Amfi 60 Vegen videre IFC for LARK - Eksempel brukt i Revit Sittetrinn Trappetrinn <Ramp> (LARK) Mindre rampekonstruksjon med repos For store terrengramper anbefales å benytte <Floor> da <Ramp> kun har begrenset mulighet for innstilling av fallforhold. <Ramp> har ikke mulighet for lagvis oppdeling av dekker slik som man kan med <Floor>, noe som er relevant når man skal jobbe med store ramper i terrenget. <Railing> (LARK) (eksempel) Rekkverk Håndløper Gjerde Ballnett Skjermer <Railing> funksjonen har store fordeler ved at den er regelstyrt. Mange eksempler hvor denne funksjonen har store fordeler. Forholder seg høydemessig til en <Slope Arrow> som man finner igjen i <Stair>, <Ramp> og <Floor> . Hvis man jobber med høydesetting på <Floor> på andre måter en <Slope Arrow> fungerer ikke relasjonen mellom <Railing> og <Floor>. <Railing> fungerer heller ikke i forhold til <Toposurface>. LandCAD for Revit har funksjon som fungerer bedre mot <Toposurface> og <Floor> hvis man bygger opp <Railing> med objektfamilier som kan <Hoste> seg til flatene <Toposurface> og <Floor>. <Floor> (LARK) Konstruksjonsdekke i bygg (Likt som for Arkitekt) Terrassegulv Brygge IfcSlabTypeEnumeration= ’baseslab’ for gulv på grunn (Veger og plasser) ‘floor’ for dekke(r) over bakken (Brygger) ‘roof’ for topp- eller takdekker (Takterrasse) 61 Vegen videre IFC for LARK - Eksempel brukt i Revit Oversikt over hvordan det er direkte link mellom mengder i tabell og modell når det plasseres ekstra treomramming da disse automatisk lager hull i <Floor>. Se i tabell og sammenlign mengdeoversikt på dekke. 62 Vegen videre IFC for LARK - Eksempel brukt i Revit 63 Vegen videre IFC for LARK - Eksempel brukt i Revit 64 Vegen videre IFC for LARK - Eksempel brukt i Revit 65 Vegen videre IFC for LARK - Eksempel brukt i Revit 66 Vegen videre IFC for LARK - Tidligere arbeider IFC for LARK - Tidligere arbeider En sentral rapport utarbeidet i 2009 viser at man tidligere har jobbet med å se om Landskap kan innarbeides i IFC og hvilke muligheter dette vil gi. I dag tre år senere har teknologien forbedret seg, flere prosjekteksempler støtter opp under dette og det er jobbet frem flere akademiske rapporter omkring BIM for Landskap. http://www.construction-innovation.info/images/pdfs/3._2007-001-EP_Final_Report.pdf Forord fra rapporten: …1. PREFACE Since 1995 the buildingSMART International Alliance for Interoperability (buildingSMART) has developed a robust standard called the Industry Foundation Classes (IFC). IFC is an object oriented data model with related file format that has facilitated the efficient exchange of data in the development of building information models (BIM). The Cooperative Research Centre for Construction Innovation has contributed to the international effort in the development of the IFC standard and specifically the reinforced concrete part of the latest IFC 2×3 release. Industry Foundation Classes have been endorsed by the International Standards Organisation as a Publicly Available Specification (PAS) under the ISO label ISO/PAS 16739. For more details, go to http://www.tc184-sc4.org/About_TC184-SC4/About_SC4_Standards/ The current IFC model covers the building itself to a useful level of detail. The next stage of development for the IFC standard is where the building meets the ground (terrain) and with civil and external works like pavements, retaining walls, bridges, tunnels etc. With the current focus in Australia on infrastructure 67 Vegen videre IFC for LARK - Tidligere arbeider projects over the next 20 years a logical extension to this standard was in the area of site and civil works. This proposal recognises that there is an existing body of work on the specification of road representation data. In particular, LandXML is recognised as also is TransXML in the broader context of transportation and CityGML in the common interfacing of city maps, buildings and roads. Examination of interfaces between IFC and these specifications is therefore within the scope of this project. That such interfaces can be developed has already been demonstrated in principle within the IFC for Geographic Information Systems (GIS) project. National road standards that are already in use should be carefully analysed and contacts established in order to gain from this knowledge. The Object Catalogue for the Road Transport Sector (OKSTRA) should be noted as an example. It is also noted that buildingSMART Norway has submitted a proposal for an “IFC for Roads” project. This project will collaborate closely with developments in this area and ensure that the resulting definitions match Australian practice. ……. 68 Vegen videre IFC for LARK - Tidligere arbeider 69 Avslutning Om BIM for landskap Avslutning Om BIM for landskap BIM er et godt kjent prosjekteringsparadigme blant arkitekter og tekniske disipliner i bygg. Arkitekt, RIB, RIV og RIE kan jobbe objektbasert med intelligente modeller og tilhørende egenskapsdata. Stadig mer programvare blir spisset mot denne typen prosjektering, ikke bare de rene prosjekteringsverktøy men også analyse- og kalkyleverktøy. De største oppdragsgiverne krever BIM-leveranser allerede på konkurransenivå, og de offentlige etatene er forpliktet til å etterspørre data på åpne, internasjonale og dokumenterbare formater. Dette kan leveres for bygg. Utenfor bygget derimot, gjelder andre lover. Prosjekteringsverktøyene støtter i begrenset grad objektbaser prosjektering, og utvekslingsformatene er i hovedsak proprietære. Flere fag jobber i 3D med geometri, men informasjonen utveksles fremdeles i tradisjonelle beskrivelser, og med mengdelister som regneark. Vi ønsker å standardisere landskapsarkitektens objekter, slik at BIM’en for hele anlegg blir komplett. Design og kostnader utomhus kan få store konsekvenser for helheten av et prosjekt. Vi ser det som viktig at landskapsarkitekten opptrer på samme arena som arkitekt og vegplanlegger, som premissgiver for det helhetlige designet utomhus. Landskapsarkitektens rolle er å binde sammen bygg, veg og konstruksjon med landskap, derfor må alle fag inn i samme modell. 70 Avslutning BIM - Noe mer enn bare Bygg BIM - Noe mer enn bare Bygg Siden viser lenke til noen utvalgte nettsider som omhandler BIM som er mest relevant for Landskap sett i sammenheng med rapporten. Det meste som er skrevet om BIM omhandler bygg, men mer og mer informasjon beskriver nå også hele det bygde miljøet. Vi har valgt å forholde oss til BIM som omhandler hele det bygde miljøet og dermed også tar med seg Landskap. Andre definisjoner ute i markedet som også omhandler mye av det samme er : LIM – Landscape Information Modell (Landskaps Informasjons Modell), SIM -Site Information Modell, AIM – Anleggs Informasjons Modell. De kan alle ses på som det samme som BIM for landskap slik vi benytter oss av begrepet i dette prosjektet. B-en er ikke bare en Bygning i en BygningsInformasjonsModell, men det er også B for å Bygge i en ByggeInformasjonsModell(ering). I den forstand havner også landskap innunder B-en. I det engelske BuildingInformationModel er denne doble betydningen tilstede i ordet Building. Generell intro til BIM som omhandler hele det bygde miljøet. http://www.youtube.com/watch?v=FPaja7mLiTE Statsbygg sine krav til BIM 71 Avslutning BIM - Noe mer enn bare Bygg http://www.statsbygg.no/FoUprosjekter/BIM-Bygningsinformasjonsmodell/ Vianovasystems informerer om BIM for Infrastruktur 72 Avslutning BIM - Noe mer enn bare Bygg http://www.vianovasystems.no/BIM Bim Task Group 73 Avslutning BIM - Noe mer enn bare Bygg http://www.bimtaskgroup.org/cobie-uk-2012/ 74 Avslutning Kilder til BIM for Landskap Kilder til BIM for Landskap Oversikt over ulike tekster og rapporter som beskriver hvilken situasjon som er for landskapsarkitekter i dag og hvilke muligheter som er til stede for å få landskapsarkitekturfaget med til å definere sin rolle i BIM. Tekstene har vært til inspirasjon og hjelp under arbeidet for å bekrefte de erfaringer som gruppen har med det å jobbe med BIM for Landskap. Ulike rapporter, artikler og tekster har de siste årene beskrevet godt den situasjonen som landskapsfaget står overfor. Denne informasjonen må man bruke litt tid på å finne ved å søke etter ulike søkeord på nettet. Iherdig og systematisk søking gjør at man etter en stund finner ganske mye informasjon som til sammen er til hjelp for å se hvilke muligheter landskapsfaget har til å tilnærme seg BIM. I Norge har vi ikke noen god informasjonsportal for landskap med tanke på BIM. Vi i Norge bør ha en direkte link fra NLA sin side til Landscape Institute UK som nå jobber i detalj med å informere og hjelpe sine medlemmer med tilnærming til BIM. 75 Avslutning Kilder til BIM for Landskap http://www.landscapeinstitute.org/knowledge/WhatisBIM.php 76 Avslutning Artikler og nettsider Artikler og nettsider Den viktigste oppsummeringen fra ulike artikler som det her vises til tilsier at landskapsarkitektbransjen ikke har råd til å vente med å se hva som skjer. Ingen tar tak i innovasjon for landskap utenom landskapsarkitektene selv. Det er helt nødvendig at man i Norge får på plass en massiv informasjonskampanje på lik linje man nå ser i England. Vi i Norge kan raskt komme opp på et akseptabelt nivå også for landskapsarkitekter men dette krever egeninnsats. Til å begynne arbeidet må hver enkelt landskapsarkitekt ta ansvar med å skaffe seg informasjon om hva BIM vil si for sitt fagfelt. Kontorer må ta ansvar for å lede den innovasjonen som trengs for å få landskapsfaget opp og å kunne jobbe etter BIM metodikk. Teknologien er tilgjengelig. Artikler, rapporter og denne rapporten i seg selv viser at landskapsfaget kan levere BIM og jobbe etter BIM metodikk på lik linje som øvrige fag i bransjen. Det som kreves er egeninnsats og modning hos den enkelte. Kjente prosesser og rutiner skal gradvis endres. Det viktig er å sette i gang slik at overgangen kan foregå etter hvert enkelt kontors modning og innsats. Get ready for BIM but buy nothing Landscape Institute / News, 14. aug 2012 http://www.landscapeinstitute.org/news/index.php/news_articles/view/get_ready_for_bim_but_bu y_nothing/ Landscape Information Modeling av Marc Goldman, DesignIntelligence / Articles, 3. mai 2011 77 Avslutning Artikler og nettsider http://www.di.net/articles/landscape_information_modeling/ Game On for A/E/C av John Aaron Phillips, DesignIntelligence / Articles, 30. april 2012 http://www.di.net/articles/game_on_aec/ A Landscape Architect’s Review of Building Information Modeling Technology 78 Avslutning Artikler og nettsider av Travis Flohr, Landscape Journal: design, planning, and management of the land, Volume 30, Number 1, 2011, pp. 169-170 (Article) http://muse.jhu.edu/journals/landscape_journal/v030/30.1.flohr.pdf Vectorworks Gets It av James L. Sipes, ASLA, Landscape Architecture Magazine, Vol 102, no 2, Feb 2012. Evaluering av Vectorworks Landmark og programmets egnethet for bruk i landskapsarkitektur http://download2.nemetschek.net/www_misc/IPA12473-Web.pdf 79 Avslutning Artikler og nettsider BIM Workflow in Landscape Architecture: Addressing the Opportunities and Challenges av Micah Lipscomb / Eric Gilbey / James Sipes, alle ASLA ATTENDEE HANDOUT WED-A7 BIM Workflow: Addressing Opportunities and Challenges, 2011 Annual Meeting ASLA http://www.asla.org/uploadedFiles/CMS/Meetings_and_Events/2011_Annual_Meeting_Handouts /WED-A7%20BIM%20Workflow_Addressing%20Opportunities%20and%20Challenges.pdf 80 Avslutning BIM for Anlegg BIM for Anlegg http://www.vectura.se/PageFiles/1584/exjobb_MarcusOhlsson.pdf?epslanguage=sv ……. 6 Slutsatser och rekommendationer Hur ser BIM-arbetet ut i anläggningsbranschen i de nordiska länderna idag? De nordiska länderna använder BIM i anläggningsbranschen i den grad att samordningsmodeller används. Samordningsmodellerna består av olika 3Dmodeller och används för kvalitetskontroller. Maskinstyrning och mängdberäkningar kan idag använda 3D-modellerna. 3D-modellerna innehåller idag inte objekt med intelligens utan alla kvalitetskontroller görs manuellt. 81 Avslutning BIM for Anlegg Hur har kodproblematiken lösts i de olika nordiska länderna? Inget land i norden har idag helt löst kodproblematiken med BIM. Sverige ska genom pilotprojekt bestämma ett fungerande kodsystem som är anpassat till både väg och järnväg. I Norge har de största beställarna bestämt system för hur kodningen ska se ut. Kvar återstår att koda alla delar som används i väg- och järnvägsprojekt. Danmark ska genom projektet ”Den Digitale Anlaeg” bestämma standard för kodning och anpassa kodning till BIM-modeller. Finland ska genom projektet ”InfraFINBIM” utveckla kodstandarder som är lämpade för BIM-modeller. Finns det några uppenbara kopplingar mellan hur utvecklat BIMarbetssättet är och hur kodproblematiken har lösts? Alla nordiska länder har insett vikten av ett kodsystem anpassat för BIM och börjat med att lösa den problematik. För att ta vidare BIM arbete till ett nästa steg behövs kodproblematiken lösas………. 82 Avslutning Rapporter Rapporter Disse foreløpig seks akademiske avhandlingene har vært viktige bidrag inn i dokumentasjonene omkring muligheter og utfordringer omkring BIM for Landskap. De har vært til stor inspirasjon og en bekreftelse på mye av det arbeidet som er lagt ned i å søke etter ytterligere dokumentasjon. LATIS – Integrating BIM Technology into Landscape Architecture av James L. Sipes, ASLA Da rapporten LATIS – Integrating BIM Technology into Landscape Architecture kom i 2008 var det en stor lettelse for alle som i noen år hadde sett mulighet for at landskap måtte være med i den rivende BIM utviklingen man så i bransjen generelt. Rapporten er noe av det mest dypgående og beste som gruppen har klart å fremskaffe omkring tema BIM for landskap. Den har en god innledning som beskriver generell tilnærming til BIM sett fra en Landskapsarkitekts ståsted. Introduksjonene til BIM er godt forklarende og kan også være en god introduksjon for andre fag en landskap som ønsker å tilnærme seg BIM. Videre tar rapporten for seg å sammenligne dagens arbeidsformer opp mot BIM. I kapittel 4 dokumenterer og beskriver forfatteren det store behovet for en åpen standard for utveksling av objekter med egenskapsdata. I kapittel 7 beskrives hvilke prosjekter som det kan være nærliggende for landskapsarkitekter å benytte BIM programvare som arkitektene benytter siden landskapsarkitekter i dag ikke har et eget fullverdig godt BIM designverktøy. Beskrivende tekst om rapporten: http://landscapeandurbanism.blogspot.no/2008/06/bim-and-landscape-architecture.html Rapporten kan kjøpes hos American Society of Landscape Architects (ASLA), Landscape Architecture Technical Information Series (LATIS) http://www.asla.org/ISGWeb.aspx?loadURL=latis 83 Avslutning Rapporter BIM for landskap av Marius Berg Bostadløkken Masteroppgave ved Institutt for landskapsplanlegging, UMB, 2009 http://www.umb.no/statisk/vrlab/BIM%20for%20Landscape.pdf BIM for landskap fra 2D til 5D, studieobjekt Hersleb skole, Oslo av Henning Lindgren Jensen Masteroppgave ved Institutt for landskapsplanlegging, UMB, 2012 84 Avslutning Rapporter http://brage.bibsys.no/umb/bitstream/URN:NBN:no-bibsys_brage_31132/1/BIM%20for%20lands kap_Fra%202D%20til%205D_HenningLindgrenJensen.pdf BIM för landskapsarkitekter av Olle Lenngren Masteroppgave ved Sveriges lantbruksuniversitet, Fakulteten för naturresurser och lantbruksvetenskap, Institutionen för stad och land, avdelningen för landskapsarkitektur, Uppsala, 2012 http://stud.epsilon.slu.se/4636/1/lenngren_o_120810.pdf 85 Avslutning Rapporter Under evalueringen av vår rapport ble vi kontaktet av Klas Eckerberg fra Sverige. Han har jobbet mange år med problemstillinger omkring landskapsarkitektens bruk av digitale verktøy. Klas Eckerberg er en viktig ressursperson når det gjelder standardiseringsarbeid for anlegg og landskap i Sverige. Han har publisert flere arbeider, men to avhandlinger nevnes her spesielt. Disse går grundig til verks og dokumenterer selve kjernen omkring de utfordringer og muligheter som ligger tilgjengelig for landskapsarkitektene og bruk av digitale verktøy. Videre arbeider med et hovedprosjekt bør involvere nærmere kontakt med Klas Eckerberg. Information Technology in Landscape Architecture Development of Tools, Methods, and Professional Role av Klas Eckerberg Licentiatavhandling, Institutionen för landskapsplanering, Ultuna, Uppsala 1999 http://pub.epsilon.slu.se/472/1/eckerberg_lic_thesis3.pdf Etta eller nolla ? Landskapsarkitekter, yrkeskunnande och informationsteknologi av Klas Eckerberg 86 Avslutning Rapporter Doctoral thesis, Swedish University of Agricultural Sciences, Institutionen för landskapsplanering Ultuna, Uppsala 2004 http://pub.epsilon.slu.se/550/1/avhandling_eckerberg.pdf 87 Avslutning Webinar Webinar Gruppen har fått tillatelse fra Nemetschek til å ha en link til denne filmen som tar opp et webinar som var i sommer 2012.Applying BIM Workflows to Landscape Architecture Filmen er svært informativ med tanke på å dokumentere og beskrive BIM for Landskap i dag. Filmen dokumenterer på et generelt nivå de fleste digitale verktøy som landskapsarkitekter benytter i dag og setter disse i et system med tanke på BIM. Filmen er forbilledlig i forhold til å informere uten å reklamere for mye om sitt eget produkt Vectorworks Landmark. http://download2.nemetschek.net/www_movies/webinars/BIM-Workflows-In-Landscape-Architecture.m ov 88 Avslutning Begrepsavklaring Begrepsavklaring CRS: Coordinate Reference System. I et bim-prosjekt er det viktig at alle jobber i samme CRS. LOD: Har to betydninger i BIM-sammenheng. Dette prosjektet fokuserer på den første av disse (Level Of Detail ): 1. Level Of Detail. Noen standarder opererer med forskjellig detaljeringsgrad etter skala og behov. CityGML er et eksempel 2. Level of Development. Beskriver 5 nivåer fra den konseptuelle/skissefasen til ferdig bygget Schema / Skjema Et schema er en datamodell i en maskinlesbar form. IFC består for eksempel av et slikt skjema, og tilhørende «menneskelesbare» definisjoner. Skjemaet beskriver et sett av datatyper, og deres relasjoner. Prosjekterte data som utveksles med IFC skal dermed være i tråd med datamodellen for IFC. http://www.buildingsmart-tech.org/implementation/faq/faq-specific-ifc-spec Informasjonsmodell: En informasjonsmodell definerer ulike egenskaper ved objekter eller konsepter, det kan være utseende, begrensninger, regler, relasjoner eller andre egenskaper. http://en.wikipedia.org/wiki/Information_model. I vår sammenheng er en informasjonsmodell en definisjon av alle relevante landskapselementer, med spesifikke navn og definisjoner. Informasjonsmodellen definerer i liten grad utseende, bortsett fra i tilfeller der utseende er en vesentlig egenskap. Objektklasse En klasse av objekter med mange like egenskaper. Navn og definisjon på objektklasser må være helt entydig, og helst i tråd med etablerte standarder (NS, ISO. IAI etc) Alle objekter skal passe inn i en objektklasse. Ingen objekter kan tilhøre to objektklasser. Grafisk representasjon: Kun utveksling av utseende / geometri. En fullverdig utveksling av en landskapsinformasjonsmodell kan ikke kun være grafisk, men i enkelte sammenhenger kan kun geometri utveksles (feks for å redusere mengden data, og konsentrasjon rundt relevante data). 89 Avslutning Begrepsavklaring Taksonomi: Anvendelsen av og læren om klassifisering. http://no.wikipedia.org/wiki/Taksonomi Topografiske egenskaper: Beskrivelse av terrengforhold http://no.wikipedia.org/wiki/Topografi Parametrisk Brukes i BIM-sammenheng om egenskaper hos objekter der den grafiske representasjonen av objektene beregnes matematisk etter et sett av regler. Feks. er en modell av en trapp parametrisk hvis den automatisk øker/reduserer antall trinn når høyden mellom topp og bunn endres. Eller med en parametrisk terrengmodell kan et tre eller en benk som er plassert på en terrengoverflate flytte treet eller benken opp og ned automatisk når terrenget justeres. FDV: Forvaltning, drift og vedlikehold IFC: Industry Foundation Classes IFD: International Framework of Dictionaries IDM: Information Delivery Manual BFL BIM for Landskap LIM LandskapsInformasjonModell(ering). I mangel av et bedre ord for BIM for landskap. GeoDesign Ulike definisjoner verserer. ESRI har tatt i bruk begrepet som et rammeverk for sine analyseverktøy, og skriver: «Geodesign provides a design framework and supporting technology for professionals to leverage 90 Avslutning Begrepsavklaring geographic information, resulting in designs that more closely follow natural systems.» http://www.esri.com/technology-topics/geodesign/ Utvekslingsformat Modellfilen i prosjekteringsverktøyet inneholder ofte informasjon som ikke er relevant for andre enn den prosjekterende (hjelpelinjer/-volumer, notater, tekst etc). Ved eksport til et utvekslingsformat sørger man for at bare relevante data utveksles til andre parter. Utvekslingsformatet som velges må kunne inneholde fullverdig (ukomprimert) informasjon og geometri, og det må kunne leses av alle som trenger det. I utgangspunktet bør utvekslingsformatet være åpent og internasjonalt. 3D Geometri. Data som beskriver objektets tredimensjonale form/utseende og plassering 4D Data som beskriver objektets anleggstidspunkt (ikke levetid?) 5D Data som beskriver objektets anleggskostnad. 6D Data som beskriver objektets behov for FDVU. Feks driftssyklus, kostnader ved drift etc. Semantiske egenskaper I mangel av bedre begrep? Dette beskriver objektene med navn, hva objektet er. Det semantiske hierarkiet har direkte relasjon til det geometriske hierarkiet. (Fra CityGML.org) BE BygningsElementer. Brukes i Norsk Standard-sammenheng, feks NS3420 og BuildingSmart http://www.standard.no/Global/PDF/Bygg,%20anlegg%20og%20eiendom/Sluttrapport%20for%20NS34 20%20og%20Building%20Smart%20-%20samlet.pdf 91 Powered by TCPDF (www.tcpdf.org)
© Copyright 2024