Informasjonsmodell for landskapsobjekter. rev LANDSKAPSARKITEKTUR

Transkript

1 Informasjonsmodell for landskapsobjekter rev BIM FOR LANDSKAPSARKITEKTUR

2 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 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 for å få tilgang til oppdatert informasjon. Kontaktperson Statsbygg Ida Grjotheim [Ida.Grjotheim@statsbygg.no] Kontaktpersoner BIM for landskap Knut Halgeir Wik, Baar Bakke landskapsarkitekter [knut@barbakke.no] Åge Langedrag, Multiconsult [aage.langedrag@multiconsult.no] Bjørn Amund Enebo, Bjørbekk & Lindheim landskapsarkitekter [bae@blark.no]

3 Table of Contents Bakgrunn Bakgrunn Norske nasjonale standarder NS hvem NS hvor NS 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

4 Rapporter Webinar Begrepsavklaring

5 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

6 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

7 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

8 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

9 Bakgrunn NS hvem NS 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: 5

10 Bakgrunn NS hvor NS 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 Building construction Organization of information about construction works Part 2: Framework for classification of information. ISO 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 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 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

11 Bakgrunn NS 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

12 Bakgrunn NS hva NS 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: og søk på anleggsgartnerarbeider 8

13 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

14 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

15 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

16 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

17 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

18 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 Fagmodell veg Fagmodell konstruksjoner Fagmodell tunnel Fagmodell VA, grøft og rørledning Fagmodell bergsikring, geotekniske konstruksjoner og tiltak Fagmodell skilt, signal og oppmerking Fagmodell vegutstyr Fagmodell kabelføringsanlegg Fagmodell tekniske installasjoner Fagmodell landskapstiltak Reguleringsflater og grunnerverv 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

19 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

20 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

21 Bakgrunn HB138 Objektkodelista Utsnitt av objektkodelista med fliken Landskapstiltak 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

22 Bakgrunn HB138 Objektkodelista 18

23 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

24 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

25 Bakgrunn Internasjonal standardisering Internasjonal standardisering 21

26 Bakgrunn Danmark Danmark BIPS BIPS (byggeri informationsteknologi produktivitet samarbejde) 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. 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

27 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 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

28 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

29 Bakgrunn England England Landscape Institute BIM OpenProject De engelske myndighetene vedtok i 2011 at alle offentlige byggeprosjekter skulle prosjekteres med 3D BIM innen 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. 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 proving-your-business/ 25

30 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 ( 9174) Bygghandlingar 90 del 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 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 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 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

31 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 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 , 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

32 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

33 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 Flere av objektklassene i IFC ( 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

34 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 30

35 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: 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

36 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

37 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

38 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: LANDxml er en åpen standard, en xml-dialekt til bruk innen samferdsel, infrastruktur og landmåling. ( 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. 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

39 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: 35

40 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. 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

41 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 , 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 ). A Designed Element is an Element for which the work result(s) have been defined. (ISO ). Elementene er definert med et nummer på en- til fire- nivåer, hvert nivå med 2 sifre, for eksempel Landscaping. Det fjerde nivå er underliggende hovedtitlene, for eksempel Plants Tabellen under viser hovedtitlene opp til 3. nivå for noen av landskaps -elementene OmniClass 2011 Number OmniClass 2011 Title Sitework Site Preparation 37

42 Bakgrunn Omniclass Site Clearing Site Elements Demolition Site Element Relocations Site Remediation Site Earthwork Site Improvements Roadways Parking Lots Pedestrian Plazas and Walkways Airfields Athletic, Recreational, and Playfield Areas Site Development Landscaping Liquid and Gas Site Utilities Water Utilities Storm Drainage Utilities Site Lighting Utfyllende tabell på 4. nivå for noen av landskaps -elementene OmniClass 2011 Number 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

43 Bakgrunn Omniclass 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